Re: dmd.conf... again
On Wednesday, 12 August 2015 at 12:21:14 UTC, Rikki Cattermole wrote: On 13/08/2015 12:16 a.m., Atila Neves wrote: [...] Perhaps this small snippet from my Windows install might shred some light. Specifically the LIB property. [Environment32] LIB=%@P%\..\lib LINKCMD=%@P%\link.exe [Environment64] LIB=%@P%\..\lib64 Tried setting LIB, still doesn't work. Sigh. Atila
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 14:05:57 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 13:46:24 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 13:00:45 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: [...] I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila Have you run dmd from the directory you unzipped it to? libphobos2.a is in there I think, so ld wouldn't be able to find it. Just did, didn't work. Tried it from lib64 and lib32 as well, nothing. Atila Hmm, I'll setup a VM later this evening to test, see if I can figure it out. This really should be easier.
Re: Does D have syntax for adding subscopes to classes?
On Wednesday, 12 August 2015 at 15:21:28 UTC, GregoryP wrote:
I'm just wondering if, or how much of the following is possible
in some way in D:
class Foo {
int x;
sub Bar {
int x;
int getFooX(){ return super.x; }
sub FooBar {
int x;
int y;
int addXes(){ return x + super.x + super.super.x; }
}
}
}
Where the Xes are accessible outside the class by Foo.x,
Foo.Bar.x, Foo.Bar.FooBar.x.
[Nested classes][0] maybe?
[0]: http://dlang.org/class.html#nested
Re: D for Game Development
On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote: Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system. Well I'm not sure what percent serious system programming is done by other people, but I don't do any. I'll take your word that the MS linker is required. Regardless, my point is more about the importance of a seamless installation on Windows than necessarily about what is required or not. It is easy to get started with DMD on Windows, roughly equivalent to python or R (what I more commonly program in). This makes it easy for people to get started learning D and playing around with RDMD. That's a good thing. By contrast, it seems quite complicated to get LDC or GDC working on Windows. I see explanations of how to build from source. There also appears to be a binary on the github page, but I haven't gotten it working (I didn't exactly try that hard though). I just hope that if DMD is replaced or moved to using LLVM, then care is taken to ensure that installation remains as simple as it currently is. This isn't unique to D. I just tried to install the Clang Windows binary and I got a message about MSVC integration failing. I have Visual Express 2008, so I figure maybe a newer version is required, but it doesn't say anywhere on the download page what version is required (the building page says VS 2013 is, but shouldn't the download page clearly explain that?). Moreover, it doesn't bring up any kind of option for me to download and install what is missing. I would consider the installation of Lyx to be a good example of a seamless installation. Lyx requires MiKTeX, so if it detects it's missing during installation, then it will download it. It might also update your version of MiKTeX also.
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 15:22:39 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 14:05:57 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 13:46:24 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 13:00:45 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: [...] I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila Have you run dmd from the directory you unzipped it to? libphobos2.a is in there I think, so ld wouldn't be able to find it. Just did, didn't work. Tried it from lib64 and lib32 as well, nothing. Atila Hmm, I'll setup a VM later this evening to test, see if I can figure it out. This really should be easier. It really should. I straced it and it's trying to link to phobos with `-l:libphobos2.a`. I've never seen a colon in library options before and the (ancient) gcc on the system doesn't seem to like it one bit. I added a hand-compiled gcc 4.9 to my PATH and... it worked. Atila
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 15:30:09 UTC, Atila Neves wrote: I've never seen a colon in library options before and the (ancient) gcc on the system doesn't seem to like it one bit. ohhh, I have seen that before, I was on a CentOS 5 VM and it didn't like that colon either. It was added to dmd about two or three years ago, I remember it breaking my thing. I think I 'fixed' it by just linking manually in the makefile for that vm.
Re: Does D have syntax for adding subscopes to classes?
On Wednesday, 12 August 2015 at 15:24:43 UTC, sigod wrote:
[Nested classes][0] maybe?
Example with them:
class Foo {
int x;
class Bar_ { // underscore cuz we have to declare
variable too
int x;
int getFooX() { return this.outer.x; }
class FooBar_ {
int x;
int y;
int addXes() { return x + this.outer.x +
this.outer.outer.x; }
}
FooBar_ FooBar;
this() {
FooBar = new FooBar_; // the var must
also be initialized in a ctor
}
}
Bar_ Bar;
this() {
Bar = new Bar_; // same out here
}
}
void main() {
auto foo = new Foo();
import std.stdio;
writeln(foo.Bar.FooBar.addXes());
}
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 15:30:09 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 15:22:39 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 14:05:57 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 13:46:24 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 13:00:45 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: [...] I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila Have you run dmd from the directory you unzipped it to? libphobos2.a is in there I think, so ld wouldn't be able to find it. Just did, didn't work. Tried it from lib64 and lib32 as well, nothing. Atila Hmm, I'll setup a VM later this evening to test, see if I can figure it out. This really should be easier. It really should. I straced it and it's trying to link to phobos with `-l:libphobos2.a`. I've never seen a colon in library options before and the (ancient) gcc on the system doesn't seem to like it one bit. I added a hand-compiled gcc 4.9 to my PATH and... it worked. Atila From man ld :) -l namespec Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a. On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a. (By convention, a .so extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename. So in this case it could probably work with -lphobos2. Maybe -L-l:libphobos2.a was chosen to force the linking with the static lib (as can be seen in the second paragraph for systems that supports both). // Joakim
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 15:49:37 UTC, Joakim Brännström wrote: From man ld :) It's only there if you have a new enough ld for the feature to be supported! One of the work CentOS VMs I have to use sometimes doesn't have it. $ ld --version GNU ld version 2.17.50.0.6-14.el5 20061020 Copyright 2005 Free Software Foundation, Inc. lol $ man ld -larchive --library=archive Add archive file archive to the list of files to link. This option may be used any number of times. ld will search its path-list for occurrences of libarchive.a for every archive specified. On systems which support shared libraries, ld may also search for libraries with extensions other than .a. Specifically, on ELF and SunOS systems, ld will search a directory for a library with an extension of .so before searching for one with an extension of .a. By convention, a .so extension indicates a shared library.
[Issue 14912] New: Move initialisation of GC'd struct and class data from the callee to the caller
https://issues.dlang.org/show_bug.cgi?id=14912
Issue ID: 14912
Summary: Move initialisation of GC'd struct and class data from
the callee to the caller
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Currently, druntime will initialise all GC'd data in the caller.
Examples:
_d_newclass():
p[0 .. ci.init.length] = ci.init[];
_d_newitemT():
memset(p, 0, _ti.tsize);
_d_newitemiT():
memcpy(p, init.ptr, init.length);
In each example, results in a system call. And because the implementation is
always hidden away, the optimizer (or an optimizing backend) cannot assume
anything about the contents of the pointer returned in these calls.
For instance, in very simple case:
class A
{
int foo () { return 42; }
}
int test()
{
A a = new A(), b = a;
return b.foo();
}
If the contents of 'a' set by the caller in the compiler, we would have the
following codegen (pseudo-code):
int test()
{
struct A *a;
struct A *b;
a = new A();
*a = A.init;
b = a;
return b.__vptr.foo(b);
}
From that, an optimizer can break down and inline the default initializer
without the need for memset/memcpy:
// ...
a = new A();
a.__vptr = typeid(A).vtbl
a.__monitor = null;
// ...
Perform constant propagation to replace all occurrences of b with a:
// ...
return *(a.__vptr + 40)(a);
// ...
Global value numbering to resolve the lookup in the vtable, and de-virtualize
the call:
// ...
return A.foo(a);
// ...
After some dead code removal, the inliner now sees the direct call and is ready
to inline A.foo:
int test()
{
struct A *a = new A();
a.__vptr = typeid(A).vtbl.ptr
a.__monitor = null;
return 42;
}
There is another challenge here to remove the dead GC allocation (that will
have to wait for another bug report). But I think that this simple change is
justified by the opportunity to produce much better resulting code when using
classes in at least simple ways - haven't even considered possibilities when
considering LTO.
If there's no objections, I suggest that we should make a push for this. It
will require dmd to update its own NewExp::toElem, and to remove the
memcpy/memset parts from druntime.
--
Re: Hello Assembly!
On Wednesday, 12 August 2015 at 22:32:30 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 22:18:41 UTC, Adam D. Ruppe wrote: [...] Here's an example: [...] Wow, very cool thanks!
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 23:27:16 UTC, Tofu Ninja wrote: On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: [...] The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. I think this is a much better idea. Nic
Hello Assembly!
So i was playing around with the D inline assembly trying to make
it say hello world on my windows setup...
void main(){
asm
{
myhello:
db HELLO, WORLD$;
mov EAX , myhello;
mov AH, 0x09;
int 0x21;
}
}
I figure this should do it. but i'm running into problems.
Anybody know why?
Re: Hello Assembly!
On Wed, 12 Aug 2015 22:10:30 +, Taylor Hillegeist wrote: I figure this should do it. but i'm running into problems. Anybody know why? Describe problems
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better.
Re: More threads - Slower program ??
On Wednesday, 12 August 2015 at 23:15:48 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 23:06:32 UTC, Yuxuan Shui wrote: What is wrong here? I didn't look too closely, but there's some memory allocations going on there which have the potential of locking all the threads any time one of them tries to allocate. Parallelism's benefits are largely erased by the memory allocator lock and can be set back by the cache being invalidated as it jumps around that allocated memory, so you generally want to make sure the threads are doing work on local variables only. This restricts what you can do with strings, since most the std.string functions allocate new strings for their return values... Is there a way to do thread-local allocations?
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 19:12:53 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 18:57:05 UTC, Adam D. Ruppe wrote: I've been looking at a company's build system recently and it makes me think this is a bad idea: we have enough problems tracking import dependencies and changes as it is without other files being written in the middle of the process too. Yes, you cannot use the file system for this. You could make it work by having a central write-once key-value database, then block all imports from non-existing keys until they become available. And error out if either keys never materialize or if a key is written twice. I see your point. But not using the file system would imply that the debugging and transparency advantages would not work. Maybe a combination of both could work? A central database that tracks which files have been generated and which have not, but the imported code still lies on the file system. Although that seems overly complex and would imply a differantiation in the import syntax between generated and non generated files.
Re: D fund
On Wednesday, 12 August 2015 at 18:19:48 UTC, Bruno Medeiros wrote: Actually, it seems BountySource is experimenting with a monthly payment model: https://salt.bountysource.com/ Invite only at the moment, but I think you can submit request if you are the project leader. Interesting, they seem to recognize the problems I have with their main service... perhaps they can become the patreon of open source if they pull this off.
More threads - Slower program ??
Here is a small program (https://gist.github.com/yshui/a426f73be77d1d699555) that uses taskPool to parallely reading from /proc/pid/ and sum the swap usage. Individual tasks has zero dependency between each other, but when I remove the 'defaultPoolThreads(1)' line, the programs takes 8x more CPU time and also runs longer in total (I have 12 cores). What is wrong here?
Re: Hello Assembly!
On Wednesday, 12 August 2015 at 22:18:41 UTC, Adam D. Ruppe wrote:
The way you'd typically do it on Windows is to just call one of
the win32 api functions, similarly to how you'd do it from C or
regular D, just calling the functions manually.
Here's an example:
import core.sys.windows.windows; // make the names of C funcs
available
void main() {
int written; // just let D handle the local var for us
asm
{
// the goal is:
// WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE),
myhello.ptr, myhello.length, written, null);
// so call GetStdHandle first
push STD_OUTPUT_HANDLE;
call GetStdHandle;
// the return value is now in EAX
mov EBX, EAX; // save it for later in EBX
// we push arguments from right to left for the
WriteConsoleA call..
push 0; // null
mov EAX, written; // local vars in D are available too
push EAX; // written
push 13; // length of HELLO, WORLD\n
lea EAX, myhello; // the address of our string
push EAX; // pointer
push EBX; // our saved handle from before
call WriteConsoleA;
jmp past_hello; // need to jump past the string since it
isn't actually executable code!
myhello:
db HELLO, WORLD\n;
past_hello:
nop;
}
}
That should run successfully.
Putting the string in a db like that isn't ideal either, you
should probably just put it in an ordinary D variable too so the
compiler can place it in the right place.
Then you can also load it. Since D asm complains about the .ptr
property thinking it means an instruction, I would do something
like:
string hello = HELLO, WORLD\n;
auto myhello = hello.ptr;
Then you can just `mov EAX, myhello;` and it will work.
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 18:57:05 UTC, Adam D. Ruppe wrote: I've been looking at a company's build system recently and it makes me think this is a bad idea: we have enough problems tracking import dependencies and changes as it is without other files being written in the middle of the process too. I'd prefer it if these were always done as separate steps so it can be more easily integrated into other build scripts. (Build systems and scripts suck btw, but they suck less than the confusion caused when files can be read and written arbitrarily by the compiler, which already has hidden dependencies). +100
Re: Hello Assembly!
On Wednesday, 12 August 2015 at 22:18:41 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 22:10:32 UTC, Taylor Hillegeist wrote: So i was playing around with the D inline assembly trying to make it say hello world on my windows setup... Have you ever written assembly for Windows before? Your code looks more like DOS (aside from the EAX, which would be overwriten by the AH mov anyway! In DOS, I think it was DX.) But DOS code won't work here anyway, since it was 16 bit and D makes 32 or 64 bit exes. The way you'd typically do it on Windows is to just call one of the win32 api functions, similarly to how you'd do it from C or regular D, just calling the functions manually. Ahh, It probably is! I was looking for a minimal example. DOS != Windows CMD I was following the example on http://web.archive.org/web/20100529113659/http://home.comcast.net/~fbkotler/clueless.html It is werid working with asm on windows... RISC/asm is much more fimilar to me..
[Issue 14913] New: The return attribute cannot be on the left side of a function declaration
https://issues.dlang.org/show_bug.cgi?id=14913
Issue ID: 14913
Summary: The return attribute cannot be on the left side of a
function declaration
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
struct Test
{
int n;
//Error: declaration expected, not 'return'
return ref int test()
{
return n;
}
}
--
[Issue 14912] Move initialisation of GC'd struct and class data from the callee to the caller
https://issues.dlang.org/show_bug.cgi?id=14912 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from ki...@gmx.net --- Great find. I didn't like it either, but didn't realize the actual implementation isn't available for the optimizer! --
Re: Hello Assembly!
On Wednesday, 12 August 2015 at 22:14:58 UTC, Justin Whear wrote: On Wed, 12 Aug 2015 22:10:30 +, Taylor Hillegeist wrote: I figure this should do it. but i'm running into problems. Anybody know why? Describe problems object.Error@(0): Access Violation 0x00402028 0x38004023 0x6C0018FF 0x38004023 0xE50018FF 0xA1004022 0x010041E0 0x3800 0x5C0018FF 0x3801 0xD00018FF 0xF40100FD 0x780018FD 0x1E0018FF Thats pretty much it!
Re: Where will D sit in the web service space?
On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better. Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it.
Re: More threads - Slower program ??
On Wednesday, 12 August 2015 at 23:06:32 UTC, Yuxuan Shui wrote: What is wrong here? I didn't look too closely, but there's some memory allocations going on there which have the potential of locking all the threads any time one of them tries to allocate. Parallelism's benefits are largely erased by the memory allocator lock and can be set back by the cache being invalidated as it jumps around that allocated memory, so you generally want to make sure the threads are doing work on local variables only. This restricts what you can do with strings, since most the std.string functions allocate new strings for their return values...
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job.
Re: DIP81: Writing files at compile time
Please no.
Should these aliases kind be illegal ?
The following alias declaration is totally legal but actually
it's not usable
---
class Foo
{
void something(size_t param){}
}
class Bar
{
private Foo foo;
this(){foo = new Foo;}
alias somethingelse = foo.something;
}
void main(string[] args)
{
auto bar = new Bar;
//bar.somethingelse(0u);
}
---
The call doesn't work but the declaration is fine. What is
possible to make with this declaration ?
Re: Hello Assembly!
On Wednesday, 12 August 2015 at 22:10:32 UTC, Taylor Hillegeist wrote: So i was playing around with the D inline assembly trying to make it say hello world on my windows setup... Have you ever written assembly for Windows before? Your code looks more like DOS (aside from the EAX, which would be overwriten by the AH mov anyway! In DOS, I think it was DX.) But DOS code won't work here anyway, since it was 16 bit and D makes 32 or 64 bit exes. The way you'd typically do it on Windows is to just call one of the win32 api functions, similarly to how you'd do it from C or regular D, just calling the functions manually.
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 20:21:06 UTC, JDemler wrote: Maybe a combination of both could work? A central database that tracks which files have been generated and which have not, but the imported code still lies on the file system. Although that seems overly complex and would imply a differantiation in the import syntax between generated and non generated files. I think you should forget that there is a filesystem. You may have at least 4 storage areas: 1. a source bundle 2. generated source bundle 3. an output bundle 4. perhaps a temporary storage area So you need to differentiate between those. You don't have to differentiate between generated and non-generated if you only allow keys in 2 that do not exist in 1. When you reference a module you simply look at 1. first, if it does not exist you try 2. If you can write files to the output bundle (like .ini or .xml files etc) you might also need specify the mime-type.
Re: DIP81: Writing files at compile time
And for this to work you also need a highly concurrent compiler.
Re: Where will D sit in the web service space?
On Monday, 13 July 2015 at 07:11:35 UTC, Ola Fosheim Grøstad wrote: On Sunday, 12 July 2015 at 19:02:23 UTC, Brad Anderson wrote: I'd consider D a failure if it couldn't fill both of these roles. D is a general purpose systems programming language. It doesn't and shouldn't care about what you are using it for. There is plenty of overlap in what you need for high performance web backends and high performance gamedev. Here's the deal: there is no such thing as a general purpose (system) language in the empirical sense. We might have been lead to believe that C or C++ were general purpose, but that only happend because there were no visible viable alternatives. C is more and more becoming a kernel/embedded language, C++ is more and more becoming a legacy/niche language. C++ is only a game dev language after you add various extensions (e.g. simd). It is only a number-crunching language after you add some other extensions. So you need a direction in the feature set towards an application area. When you get new languages that cut down on development time (like Rust and Go) the C/C++ application domain will leak over to those niches based on the desired feature set. But the feature set needs to be complete for that application area (e.g. GC with the right characteristics, inlining/simd, GPU programming etc). D needs to complete the feature set for some sizeable domain in order to compete in this emerging market of many languages (thanks to LLVM). Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, What I am saying is people do not know what they want at times. They get up everyday and they have a new idea on what D should be. Follow such comments and you will make some bad decisions. Currently, we are in a world where p. languages are driven by the demands of today. Who knew that JavaScipt will become the language for the web? But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. Now back to D: The absence of certain tools and frameworks does not mean D is not picking up (not catching interests). The language is still maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. With extensions, D can fit in any domain and this obviously takes time. I am so tired(:;) of seeing them (rust, Go, Pony, Cat, ..) everywhere, if one thinks rust rust OR JavaScript is the language they are planing to use for your next record-breaking kernel, . Because D cannot be them all. The comparison war a bad chakra
[Issue 14912] Move initialisation of GC'd struct and class data from the callee to the caller
https://issues.dlang.org/show_bug.cgi?id=14912 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw ibuc...@gdcproject.org --- I don't think this would be particularly difficult to change in dmd either as this kind of callee initializing already done for scoped classes and classes that have their own new(size_t) allocator. --
Re: DIP81: Writing files at compile time
On Thursday, 13 August 2015 at 00:58:14 UTC, JDemler wrote: On Wednesday, 12 August 2015 at 23:27:16 UTC, Tofu Ninja wrote: On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. While this might work for very simple and basic mixins, with the combination of TMP and compile time reflection this becomes not only impractical but also impossible. Think again about the vibe.d example: There is one mixin handeling all the template-type combinations. How would such a mixin be expanded? The resulting code differs from template to template and from type to type. I suppose such an expansion flag would need to expand templates as well, which is still not a bad idea. Templates can be hard to follow sometimes and expanding them out in all their forms could be helpful for debugging and for tooling as well. Though there would be a lot of expansions.
Re: std.data.json formal review
On 8/12/2015 10:10 AM, deadalnix wrote: Thing is, the schema is not always known perfectly? Typical case is JSON used for configuration, and diverse version of the software adding new configurations capabilities, or ignoring old ones. Hah, I'd like to replace dmd.conf with a .json file.
Re: Where will D sit in the web service space?
On 13/08/2015 10:17 a.m., rsw0x wrote: On Wednesday, 12 August 2015 at 22:10:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 21:16:28 UTC, karabuta wrote: Not long ago, C++ was the perfect programming language that everybody was running to. Then came ~ Java, Well, C++ was never considered a good language by anyone. It was shunned at universities by lecturers. Java was basically Simula67 with a different syntax and some adjustments. But the demand of the past shifted to the web and now the worst p. language rules the web (Sorry if you love JS too much but there is too much bugs). Now we are stuck in it, who knows until when before the world rushes to a new domain. I am actually starting to kinda like TypeScript 1.5… And next gen EcmaScript will have comprehensions… maturing, and I see it maturing like gold. When D grows up (even though it is doing powerful things in its infancy), you and I will appreciate that it did not rush into any domain. The contributor list to Rust1.2 claims 180 people were involved... http://blog.rust-lang.org/2015/08/06/Rust-1.2.html If you focus on a domain more people will have a significant interest in making it work better. Rust is also backed by a major organization. I(and others from what it seemed) was hoping Facebook using D internally and hiring major D developers would have Facebook promote/champion D a bit, but this did not happen. D needs a major corporation to champion it. Even so, D at Facebook is like D kinda still in it's infancy. Anyway. Do we really want newbies who think OOP is the best thing since sliced bread to come and try D out just because Facebook is using it?
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 20:39:31 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 August 2015 at 20:21:06 UTC, JDemler wrote: Maybe a combination of both could work? A central database that tracks which files have been generated and which have not, but the imported code still lies on the file system. Although that seems overly complex and would imply a differantiation in the import syntax between generated and non generated files. I think you should forget that there is a filesystem. You may have at least 4 storage areas: 1. a source bundle 2. generated source bundle 3. an output bundle 4. perhaps a temporary storage area So you need to differentiate between those. You don't have to differentiate between generated and non-generated if you only allow keys in 2 that do not exist in 1. When you reference a module you simply look at 1. first, if it does not exist you try 2. If you can write files to the output bundle (like .ini or .xml files etc) you might also need specify the mime-type. I am not sure if I understand your idea correctly: The compiler would in case of an export(name, content) write the content both to a internal database and the filesystem and then only use the internal one? Or could the content of the internal database be copied to the file system at the end of the compilation process? Or is only the output bundle written to the file system?
Re: D fund
On Thursday, 13 August 2015 at 00:22:05 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 18:19:48 UTC, Bruno Medeiros wrote: Actually, it seems BountySource is experimenting with a monthly payment model: https://salt.bountysource.com/ Invite only at the moment, but I think you can submit request if you are the project leader. Interesting, they seem to recognize the problems I have with their main service... perhaps they can become the patreon of open source if they pull this off. This is actually really cool, D needs to see if it can get on this. Andrei! Get on this! I want to give D money!
Re: Should these aliases kind be illegal ?
On 08/13/2015 12:17 AM, anonymous wrote:
The following alias declaration is totally legal but actually it's not
usable
---
class Foo
{
void something(size_t param){}
}
class Bar
{
private Foo foo;
this(){foo = new Foo;}
alias somethingelse = foo.something;
}
void main(string[] args)
{
auto bar = new Bar;
//bar.somethingelse(0u);
}
---
The call doesn't work but the declaration is fine. What is possible to
make with this declaration ?
I believe it currently just does the same thing as:
---
class Foo{
void something(size_t param){}
}
class Bar{
private Foo foo;
this(){foo = new Foo;}
alias somethingelse = typeof(foo).something;
}
---
But IMO the appropriate response here is to just make it work as one
would expect, not to make it illegal.
Attributes not propagating to objects via typeinfo?
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared));
//true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared)); //false
}
What's the reason that the shared propagates to the typeinfo for
the struct, but not for the class declaration?
Re: DIP81: Writing files at compile time
On 13/08/2015 6:37 a.m., JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! Problem: debugging The debugger cannot attach to mixedin code; one has to print the resulting code with pragma(msg, ) to inspect it Fix: Make D interface file generation include the source code e.g. statements. Pros: - Already have most of the code to do this Cons: - None. Problem: compile-speed Even if the resulting code does not change, mixedin code has to be compiled anyway True. Why is this a problem exactly? Problem: scalability If the generated code is needed in two seperated places of the code, it has to be mixedin twice or has to be mixedin into a special module which introduces overhead Not a problem? The result should *theoretically* the return value should be cached. We could even go so far as to have ``mixin(string)`` as the return type. To cache the AST and force compile time only. Perhaps even make it return the assembly code itself for runtime? Problem: transparency As user of a library which relys on compile time code generation one has often no idea what code is generated See debugging problem for the solution. We do not need to add a new language feature based upon these problems and use cases. We can solve it by simply extending one we already have. D interface files. Making them generate the full source code instead of just the interface.
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 23:27:16 UTC, Tofu Ninja wrote: On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! The benefits of this I see are debugging, actually having the generated files makes it much simpler to see what is going wrong. Otherwise the utility of this can be achieved with string mixins. A simple alternative to this would be a flag to the compiler to expand mixins and output the new files. This would also be great for tooling, an IDE could use this and allow you to expand a mixin in place to see what it looks like. And currently all the auto complete engines I have seen for D don't handle mixins very well. Expanding them would make autocompletion a simpler job. While this might work for very simple and basic mixins, with the combination of TMP and compile time reflection this becomes not only impractical but also impossible. Think again about the vibe.d example: There is one mixin handeling all the template-type combinations. How would such a mixin be expanded? The resulting code differs from template to template and from type to type.
Indivisual Incremental Compalation with dub
I have a file that takes a while to compile with a static interface. Is there any way i can make dub keep the object file of only that file(for faster compilation)?
Re: std.data.json formal review
Am 12.08.2015 um 00:21 schrieb deadalnix: On Tuesday, 11 August 2015 at 21:06:24 UTC, Sönke Ludwig wrote: See http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.payload.html The question whether each field is really needed obviously depends on the application. However, the biggest type is BigInt that, form a quick look, contains a dynamic array + a bool field, so it's not as compact as it could be, but also not really large. There is also an additional Location field that may sometimes be important for good error messages and the like and sometimes may be totally unneeded. Urg. Looks like BigInt should steal a bit somewhere instead of having a bool like this. That is not really your lib's fault, but that's quite an heavy cost. Consider this, if the struct fit into 2 registers, it will be passed around as such rather than in memory. That is a significant difference. For BigInt itself, and, by proxy, for the JSON library. Agreed, this was what I also thought. Considering that BigInt is heavy anyway, Dimitry's suggestion to store a BigInt* sounds like a good idea to sidestep that issue, though. Putting the BigInt thing aside, it seems like the biggest field in there is an array of JSONValues or a string. For the string, you can artificially limit the length by 3 bits to stick a tag. That still give absurdly large strings. For the JSONValue case, the alignment on the pointer is such as you can steal 3 bits from there. Or as for string, the length can be used. It seems very realizable to me to have the JSONValue struct fit into 2 registers, granted the tag fit in 3 bits (8 different types). I can help with that if you want to. The question is mainly just, should we decide on a single way to represent values (either speed, or features), or let the library user decide by either making JSONValue a template, or by providing two separate structs optimized for each case. In the latter case, we could really optimize on all fronts and for example use custom containers that use less allocations and are more cache friendly than the built-in ones. However, my goal when implementing this has never been to make the DOM representation as efficient as possible. The simple reason is that a DOM representation is inherently inefficient when compared to operating on the structure using either the pull parser or using a deserializer that directly converts into a static D type. IMO these should be advertised instead of trying to milk a dead cow (in terms of performance). Indeed. Still, JSON nodes should be as lightweight as possible. 2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch. Using a tagged union like structure is definitely what I'd like to have, too. However, the main goal was to build the DOM type upon a generic algebraic type instead of using a home-brew tagged union. The reason is that it automatically makes different DOM types with a similar structure interoperable (JSON/BSON/TOML/...). That is a great point that I haven't considered. I'd go the other way around about it: providing a compatible typeid based struct from the enum tagged one for compatibility. It can even be alias this so the transition is transparent. The transformation is not bijective, so that'd be great to get the most restrictive form (the enum) and fallback on the least restrictive one (alias this) when wanted. As long as the set of types is fixed, it would even be bijective. Anyway, I've just started to work on a generic variant of an enum based algebraic type that exploits as much static type information as possible. If that works out (compiler bugs?), it would be a great thing to have in Phobos, so maybe it's worth to delay the JSON module for that if necessary. The optimization to store the type enum in the length field of dynamic arrays could also be built into the generic type. Now Phobos unfortunately only has Algebraic, which not only doesn't have a type enum, but is currently also really bad at keeping static type information when forwarding function calls or operators. The only options were basically to resort to Algebraic for now, but have something that works, or to first implement an alternative algebraic type and get it accepted into Phobos, which would delay the whole process nearly indefinitely. That's fine. Done is better than perfect. Still API changes tend to be problematic, so we need to nail that part at least, and an enum with fallback on typeid based solution seems like the best option. Yeah, the transition is indeed problematic. Sadly the alias this idea wouldn't work for for that either, because operators and methods of the enum based algebraic type usually have different return types. Or do you perhaps mean the JSON - deserialize - manipulate - serialize - JSON approach? That
Re: std.data.json formal review
On Tuesday, 11 August 2015 at 21:06:24 UTC, Sönke Ludwig wrote: However, my goal when implementing this has never been to make the DOM representation as efficient as possible. The simple reason is that a DOM representation is inherently inefficient when compared to operating on the structure using either the pull parser or using a deserializer that directly converts into a static D type. IMO these should be advertised instead of trying to milk a dead cow (in terms of performance). Maybe it is better to just focus on having a top-of-the-line parser and then let competing DOM implementations build on top of it. I'm personally only interested in structured JSON, I think most webapps use structured JSON informally.
[Issue 14906] dmd dumps core at incorrect enum declaration
https://issues.dlang.org/show_bug.cgi?id=14906 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1a5b4098e7a7f0bbdfd3c8035a93d1e71471afc1 fix Issue 14906 - dmd dumps core at incorrect enum declaration https://github.com/D-Programming-Language/dmd/commit/d4b1b3a2b19fd0e32162876d6c182c79b63a93e7 Merge pull request #4881 from 9rnsr/fix14906 Issue 14906 - dmd dumps core at incorrect enum declaration --
[Issue 14906] dmd dumps core at incorrect enum declaration
https://issues.dlang.org/show_bug.cgi?id=14906 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: std.data.json formal review
Am 11.08.2015 um 23:52 schrieb deadalnix: On Tuesday, 11 August 2015 at 21:27:48 UTC, Sönke Ludwig wrote: That is not going to cut it. I've been working with these for ages. This is the very kind of scenarios where dynamically typed languages are way more convenient. I've used both quite extensively and this is clear cut: you don't want what you call the strongly typed version of things. I've done it in many languages, including in java for instance. jsvar interface remove the problematic parts of JS (use ~ instead of + for concat strings and do not implement the opDispatch part of the API). I just said that jsvar should be supported (even in its full glory), so why is that not going to cut it? Also, in theory, Algebraic already does more or less exactly what you propose (forwards operators, but skips opDispatch and JS-like string operators). Ok, then maybe there was a misunderstanding on my part. My understanding was that there was a Node coming from the parser, and that the node could be wrapped in some facility providing a jsvar like API. Okay, no that's correct. My position is that it is preferable to have whatever DOM node be jsvar like out of the box rather than having to wrap it into something to get that. But take into account that Algebraic already behaves much like jsvar (at least ideally), just without opDispatch and JavaScript operator emulation (which I'm strongly opposed to as a *default*). So the jsvar wrapper would really just be needed for the cases where really concise code is desired when operating on JSON objects. We also discussed an alternative approach similar to opt(n).foo.bar[1].baz, where n is a JSONValue and opt() creates a wrapper that enables safe navigation within the DOM, propagating any missing/mismatched fields to the final result instead of throwing. This could also be combined with a final type query: opt!string(n).foo.bar
[Semi OT] DDT Eclipse Plugin
I just install eclipse with the DDT plugin(https://ddt-ide.github.io/) and it worked well. It has auto complete, dub support(with a minor case senativity bug),and other IDE features.
Re: std.data.json formal review
Am 12.08.2015 um 08:28 schrieb Dmitry Olshansky: On 12-Aug-2015 00:21, Sönke Ludwig wrote: Am 11.08.2015 um 20:15 schrieb Dmitry Olshansky: On 11-Aug-2015 20:30, deadalnix wrote: Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. +1 Also most JS engines use nan-boxing to fit type tag along with the payload in 8 bytes total. At least the _fast_ path of std.data.json should take advantage of similar techniques. But the array field already needs 16 bytes on 64-bit systems anyway. We could surely abuse some bits there to at least not use up more for the type tag, but before we go that far, we should first tackle some other questions, such as the allocation strategy of JSONValues during parsing, the Location field and BigInt/Decimal support. Pointer to array should work for all fields 8 bytes. Depending on the ratio frequency of value vs frequency of array (which is at least an ~5-10 in any practical scenario) it would make things both more compact and faster. Maybe we should first have a vote about whether BigInt/Decimal should be supported or not, because that would at least solve some of the controversial tradeoffs. I didn't have a use for those personally, but at least we had the real-world issue in vibe.d's implementation that a ulong wasn't exactly representable. Well I've stated why I think BigInt should be optional. The reason is C++ parsers don't even bother with anything beyond ULong/double, nor would any e.g. Node.js stuff bother with things beyond double. The trouble begins with long vs. ulong, even if we'd leave larger numbers aside. We'd really have to support both, but choosing between the two is ambiguous, which isn't very pretty overall. Lastly we don't have BigFloat so supporting BigInt but not BigFloat is kinda half-way. That's where Decimal would come in. There is some code for that commented out, but I really didn't want to add it without a standard Phobos implementation. But I wouldn't say that this is really an argument against BigInt, maybe more one for implementing a Decimal type. So please make it an option. And again add an extra indirection (that is BigInt*) for BigInt field in a union because they are extremely rare. Good idea, didn't think about that. My view generally still is that the DOM representation is something for convenient manipulation of small chunks of JSON, so that performance is not a priority, but feature completeness is. I'm confused - there must be some struct that represents a useful value. There is also the lower level JSONParserNode that represents data of a single bit of the JSON document. But since that struct is just part of a range, its size doesn't matter for speed or memory consumption (they are not allocated or copied while parsing). And more importantly - is JSONValue going to be converted to jsvar? If not - I'm fine. Otherwise whatever inefficiency present in JSONValue would be accumulated by this conversion process. By default and currently it isn't, but it might be an idea for the future. The jsvar struct could possibly be implemented as a wrapper around JSONValue as a whole, so that it doesn't have to perform an actual conversion of the whole document. Generally, working with JSONValue is already rather inefficient due to all of the dynamic allocations to populate dynamic and associative arrays. Changing that would require switching to completely different underlying container types, which would at least make the API a lot less intuitive. We could of course also simply provide an alternative value representation that is not based on Algebraic (or an enum tag based alternative) and is not augmented with location information, but optimized solely for speed and low memory consumption.
[Issue 14910] New: Take!R does not offer length for char[]
https://issues.dlang.org/show_bug.cgi?id=14910
Issue ID: 14910
Summary: Take!R does not offer length for char[]
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: schneider.ced...@gmx.de
unittest
{
char[] chars = ['h', 'e', 'l', 'l', 'o'];
assert(chars.take(2).length == 2);
}
This unittest fails to compile, complaining that Take!char[] does not have a
length, despite Take!R claiming to offer a length property if the input range
does.
--
Re: Derelict, SDL, and OpenGL3: Triangle Tribulations
On Wednesday, 12 August 2015 at 05:58:23 UTC, BBasile wrote: On Wednesday, 12 August 2015 at 05:46:27 UTC, Mike Parker wrote: On Wednesday, 12 August 2015 at 05:34:22 UTC, BBasile wrote: [...] It seems to me that your driver is doing things it isn't actually supposed to do. This code is binding a vertex buffer object with a function which is supposed to bind a vertex array object. The only reason the vbo is bound at all is because of the call to glBindBuffer in the misnamed initVAO -- a function which never even initializes a vao. The spec actually requires a vao to be created and a shader program to be bound, so I would expect a conforming driver to show nothing. I expect a couple of calls to glError will not come up empty. Right, the triangle is well drawn but glGetError returns 1282. Maybe the OP has a different OGL implementation. At least NVidia driver renders a triangle for this code. Depends on what context gets created in this case. A core profile context shouldn't render anything without a bound shader. NVidia likes backwards compatibility, so it's possible this code works, it's just using fixed function pipeline rendering, which isn't typically what people want when they mention GL3. Might as well use glBegin/glEnd, and it would work too.
Re: std.data.json formal review
On 12-Aug-2015 00:21, Sönke Ludwig wrote: Am 11.08.2015 um 20:15 schrieb Dmitry Olshansky: On 11-Aug-2015 20:30, deadalnix wrote: Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. +1 Also most JS engines use nan-boxing to fit type tag along with the payload in 8 bytes total. At least the _fast_ path of std.data.json should take advantage of similar techniques. But the array field already needs 16 bytes on 64-bit systems anyway. We could surely abuse some bits there to at least not use up more for the type tag, but before we go that far, we should first tackle some other questions, such as the allocation strategy of JSONValues during parsing, the Location field and BigInt/Decimal support. Pointer to array should work for all fields 8 bytes. Depending on the ratio frequency of value vs frequency of array (which is at least an ~5-10 in any practical scenario) it would make things both more compact and faster. Maybe we should first have a vote about whether BigInt/Decimal should be supported or not, because that would at least solve some of the controversial tradeoffs. I didn't have a use for those personally, but at least we had the real-world issue in vibe.d's implementation that a ulong wasn't exactly representable. Well I've stated why I think BigInt should be optional. The reason is C++ parsers don't even bother with anything beyond ULong/double, nor would any e.g. Node.js stuff bother with things beyond double. Lastly we don't have BigFloat so supporting BigInt but not BigFloat is kinda half-way. So please make it an option. And again add an extra indirection (that is BigInt*) for BigInt field in a union because they are extremely rare. My view generally still is that the DOM representation is something for convenient manipulation of small chunks of JSON, so that performance is not a priority, but feature completeness is. I'm confused - there must be some struct that represents a useful value. And more importantly - is JSONValue going to be converted to jsvar? If not - I'm fine. Otherwise whatever inefficiency present in JSONValue would be accumulated by this conversion process. -- Dmitry Olshansky
Re: Derelict, SDL, and OpenGL3: Triangle Tribulations
On Wednesday, 12 August 2015 at 05:46:27 UTC, Mike Parker wrote: On Wednesday, 12 August 2015 at 05:34:22 UTC, BBasile wrote: [...] It seems to me that your driver is doing things it isn't actually supposed to do. This code is binding a vertex buffer object with a function which is supposed to bind a vertex array object. The only reason the vbo is bound at all is because of the call to glBindBuffer in the misnamed initVAO -- a function which never even initializes a vao. The spec actually requires a vao to be created and a shader program to be bound, so I would expect a conforming driver to show nothing. I expect a couple of calls to glError will not come up empty. Right, the triangle is well drawn but glGetError returns 1282. Maybe the OP has a different OGL implementation. At least NVidia driver renders a triangle for this code.
Re: Derelict, SDL, and OpenGL3: Triangle Tribulations
On Wednesday, 12 August 2015 at 05:26:33 UTC, JN wrote: You need a vertex and a fragment shader. You can't render anything in OGL3 without shaders. I thought that was the case, but the tutorial I was looking at didn't have any shaders at that point. I added a shader program. Also, you seem to be confusing Vertex Array Objects and Vertex Buffer Objects. You are creating a VBO and try to bind it as a VAO. You should put a glGenVertexArrays somewhere there. Aha! Yes, that's it, thanks! Once I understood the difference between VAO and VBOs, it was easy to fix. Thanks! On Wednesday, 12 August 2015 at 05:35:30 UTC, Mike Parker wrote: On Wednesday, 12 August 2015 at 03:32:47 UTC, DarthCthulhu wrote: So, any ideas what I'm doing wrong? Too much to list. I suggest you get going with a good tutorial. One of the best I've seen is by Anton Gerdelan [1]. The four basic tutorials he has on his site will be enough to get you up and running. He used to have a lot more there, but he's published them all in a book. Even though there are numerous free resources online, I think Anton's ebook is well worth the ~$9.00 you pay for it. His tutorials are quite detailed and do a lot more than showing you a bunch of code to copy and paste. Work your way through that book and you'll know your way around well enough to do what you need to do for any basic OpenGL renderer. On Wednesday, 12 August 2015 at 05:54:13 UTC, Mike Parker wrote: On Wednesday, 12 August 2015 at 05:35:30 UTC, Mike Parker wrote: One of the best I've seen is by Anton Gerdelan [1]. The four [1] http://antongerdelan.net/opengl/index.html Thanks very much for the resource! I had already looked at about a dozen different OGL3.x tutorials online, but this was the one which clicked for me. I'll definitely look into getting his book. Thanks again!
[Issue 14909] New: Template argument of std.algoirthm.iteration.chunkBy cannot access a local variable
https://issues.dlang.org/show_bug.cgi?id=14909
Issue ID: 14909
Summary: Template argument of std.algoirthm.iteration.chunkBy
cannot access a local variable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: tta...@gmail.com
The following code cannot be compiled.
I checked it by using DMD trunk (v2.068-devel-407dac3) in Mac OSX.
---
import std.algorithm.iteration;
void main()
{
auto n = 3;
auto s = [1,2,3].chunkBy!(a = a+n); /// Error: function
sample.main.ChunkByImpl!(__lambda1, int[]).ChunkByImpl.__lambda12 cannot access
frame of function D main
}
---
--
Re: DDT 0.13.0 released - DUB configurations support.
On Tuesday, 11 August 2015 at 17:03:35 UTC, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Brilliant! Thanks Bruno!
[Issue 14910] Take!R does not offer length for char[]
https://issues.dlang.org/show_bug.cgi?id=14910 ZombineDev petar.p.ki...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Hardware|x86_64 |All Resolution|--- |INVALID OS|Windows |All --
Re: vibe.d 0.7.24 released
On Tuesday, 11 August 2015 at 16:11:29 UTC, Sönke Ludwig wrote: Did you try to run dub upgrade again after the clean-caches? This is necessary, because dub.selections.json is supposed to be able to manually override dependency specifications in dub.json. I have a script called dubrenew.sh --8- #!/bin/bash rm dub.selections.json dub clean-caches --8- Works every time (dub upgrade can be used alternatively to deleting dub.selections.json)
Re: vibe.d 0.7.24 released
On Wednesday, 12 August 2015 at 09:42:20 UTC, ponce wrote: I have a script called dubrenew.sh --8- #!/bin/bash rm dub.selections.json dub clean-caches --8- Works every time (dub upgrade can be used alternatively to deleting dub.selections.json) Maybe dub upgrade should call dub clean-caches.
Re: Where the F*** is phobos on OSX nowadays ?
On Wed, 12 Aug 2015 11:16:55 +0200 Jacob Carlborg d...@me.com wrote: On 2015-08-11 23:55, Daniel Kozak via Digitalmars-d wrote: Not at all, I am using dvm and I like it. But OTOH it makes things sometimes wierd. My common habit is to do something like this: dmd somefile ./somefile. But without dvm I use latest (current installed vesion of dmd) but with dvm I use last setup vesion. And often I do not know which version of dmd I am using. Not sure I understand the problem. Ok, I find out whats wrong. I use -d parameter. So it was my fault.
Re: Where the F*** is phobos on OSX nowadays ?
On 2015-08-11 23:55, Daniel Kozak via Digitalmars-d wrote: Not at all, I am using dvm and I like it. But OTOH it makes things sometimes wierd. My common habit is to do something like this: dmd somefile ./somefile. But without dvm I use latest (current installed vesion of dmd) but with dvm I use last setup vesion. And often I do not know which version of dmd I am using. Not sure I understand the problem. -- /Jacob Carlborg
Re: std.data.json formal review
Anyway, I've just started to work on a generic variant of an enum based algebraic type that exploits as much static type information as possible. If that works out (compiler bugs?), it would be a great thing to have in Phobos, so maybe it's worth to delay the JSON module for that if necessary. First proof of concept: https://gist.github.com/s-ludwig/7a8a60150f510239f071#file-taggedalgebraic-d-L148 It probably still has issues with const/immutable and ref in some places, but the basics seem to work as expected.
Re: D for Game Development
On 2015-08-11 09:08, Timothee Cour via Digitalmars-d wrote: on OSX I only see libphobos2.a (including dmd 2.068) It's not supported on OS X. -- /Jacob Carlborg
Re: Release D 2.068.0
On Wednesday, 12 August 2015 at 02:46:41 UTC, Ben Boeckel wrote: On Tue, Aug 11, 2015 at 22:36:47 +, John Colvin via Digitalmars-d-announce wrote: Not true. AFAIK /usr/local is the only bit of /usr that *is* available for third-parties. Ah, mixed it up with this tidbit: The /usr/local folder remains accessible, however; it's a long-running convention in Unix and variants as a place to stash material and software that individual users rely on. El Capitan will also remove files from those directories that don't belong to Apple. So it isn't safe over an upgrade, but is accessible. --Ben El Capitan doesn't delete non-Apple-controlled stuff from /usr/local/, but it will from e.g. /usr/bin/
Re: vibe.d 0.7.24 released
On Tue, Aug 11, 2015 at 3:48 PM, Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: ... Most dynamic types really are static, you just don't always know the layout at compile time. But with a bit of ahead-of-time analyzers of the data, we can basically bridge that without needing a whole lot of extra work. I had made an object similar to your jsvar, now I just use your jsvar for all my REST api needs because it works basically like javascript which is great for consuming the data from the apis I use. You could use it to do the basic discovery and then generate a vibe/std json struct from there. Its great to have the more rigid JSON features in vibe.d too, they each have their place.
[Issue 13567] Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 ZombineDev petar.p.ki...@gmail.com changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #3 from ZombineDev petar.p.ki...@gmail.com --- Walter, so you agree that private functions should get attribute inference, like auto retrning functions? --
[Issue 14910] Take!R does not offer length for char[]
https://issues.dlang.org/show_bug.cgi?id=14910 ZombineDev petar.p.ki...@gmail.com changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #1 from ZombineDev petar.p.ki...@gmail.com --- See http://dlang.org/phobos/std_range_primitives#hasLength. Take provides a length property only if for its argument hasLength return true. If you know that you're only dealing with ASCII, you can cast the string to ubyte[], see: http://dpaste.dzfl.pl/fe93a68a3945. --
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 15:49:37 UTC, Joakim Brännström wrote: On Wednesday, 12 August 2015 at 15:30:09 UTC, Atila Neves wrote: [...] From man ld :) -l namespec Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it will search the library path for a file called libnamespec.a. On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a. (By convention, a .so extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename. So in this case it could probably work with -lphobos2. Maybe -L-l:libphobos2.a was chosen to force the linking with the static lib (as can be seen in the second paragraph for systems that supports both). Yeah, pretty sure that was it: when I called gcc myself it linked to the shared version. Maybe I should file a bug report for at least a proper error message when using it on ancient systems. Atila
IFTI with template alias fails in D, works in C++
main.d:
--
struct A(T, int D) {
this(string ignore){}
}
alias B(T)=A!(T, 1);
void fun1(T)(A!(T,1) a) { }
void fun2(T)(B!T a) { }
unittest{
auto a=A!(double,1)(a);
assert(is(typeof(a) == B!double));
fun1(a);//ok
fun2!double(a);//ok
// no IFTI here:
//fun2(a);//not ok:
//fun2 cannot deduce function from argument types !()(A!(double, 1)),
candidates are...
}
--
C++ works fine here:
main.cc:
--
templateclass T, int D
class A {
};
template class T
using B = AT, 1;
template class T
void fun(BT a) { }
void test(){
Adouble,1a;
fun(a);
}
--
I can use a workaround but it makes the code uglier. What's the recommended
way around this?
Could we support this as in C++?
[Issue 14911] New: Compiler found indexing in code new MyStruct[2].ptr
https://issues.dlang.org/show_bug.cgi?id=14911
Issue ID: 14911
Summary: Compiler found indexing in code new MyStruct[2].ptr
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kdm...@ya.ru
The following code does not compile with dmd v2.068.0.
void main()
{
int* buf1 = new int[2].ptr; // Ok
struct MyStruct {}
MyStruct* buf2 = (new MyStruct[2]).ptr; // Ok
// Error: expected TypeTuple when indexing ('[2]'), got 'MyStruct'
MyStruct* buf3 = new MyStruct[2].ptr;
}
--
Re: D for Game Development
On Wednesday, 12 August 2015 at 14:57:17 UTC, jmh530 wrote: Well I'm not sure what percent serious system programming is done by other people, but I don't do any. I understand your points. I meant to say that D is a system programming language (too), so it's tightly coupled to some internals of the OS. And Windows being a proprietary OS, Visual Studio or more precisely at least its runtime is likely to be required in the future as well. Almost ;) proper support for Win64 in LDC is about to be completed with the next release. It will most likely require Visual Studio 2015. But that's about it, you'll just need to extract an LDC archive. When invoking ldc2.exe, you'll need to make sure some environment variables are properly set up (e.g., by using a Visual Studio command prompt), for it to find the linker, libs etc. Last time I built clang (from source, using Visual Studio) I was amazed by how painless that was. LLVM requires VS 2013 atm (at least for building), but Windows/MSVC support is still being finalized (native MSVCRT exception handling etc.). VS 2008 is really quite old by now, so I'd really recommend upgrading (VS 2015 Community is free btw).
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 12:16:50 UTC, Atila Neves wrote: I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. If you use the dmd zip, everything just works when you just unzip it and use it all in-place. No need to move or copy files anywhere, no need for root.
Re: [Optimization] Speculatively not calling invariant on class objects
Remove allocation?
Re: Convert a hex color string into r,g,b components.
On Tuesday, 11 August 2015 at 22:11:51 UTC, Marcin Szymczak wrote:
I would really love to solve this problem using ranges, because
i am learning how to use them. Unfortunately even such a simple
task seems so hard for me ;(
I think writing a simple function to parse a string into a Color
would be best here.
Color parseRGBString(string theString){
if(theString.length != 7)
throw new Exception(Error. Cannot parse to
color: ~ theString);
return Color(
to!ubyte(theString[1..3], 16),
to!ubyte(theString[3..5], 16),
to!ubyte(theString[5..7], 16)
);
}
I could probably do more to ensure that the string actually does
represent a color (e.g. Check if no char is F etc).
Also, using ranges isn't always required, theres no such thing as
a too simple solution, as long as it works!
You can use this in a range then, e.g. say the user passes in
lots of strings to your program, you can
listOfColors.map!(a = a.parseRGBString); // and now you have a
lazily evaluated list of Color objects.
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 13:04:25 UTC, Atila Neves wrote:
On Wednesday, 12 August 2015 at 12:29:46 UTC, Dicebot wrote:
More info about what gets placed where please.
I have special dev layout on my system that co-exists with
system-wide installation of dmd. It is as simple as having
~/dlang/{dmd|druntime|phobos}, linking ~/dlang/dmd/src/dmd to
~/bin/dmd-dev and placing dmd.conf in ~/bin which adds all
those paths as -I and -L flags. Works just fine.
There's no system-wide installation (since I don't have root),
I just downloaded the zip for 2.068 and added dmd2/linux/bin64
to my PATH.
Atila
Yeah I have meant that it works _even_ if you also have
system-wide installation. No idea what dmd.conf they put into zip
- I never use it.
Re: Code Reviewer
On Wednesday, 12 August 2015 at 02:49:59 UTC, Rikki Cattermole wrote: On 12/08/2015 10:50 a.m., Clayton wrote: Hello everyone, Am looking for someone who could help review my code . As an entry exercise to D am converting 3 C implementations of popular pattern matching algorithms. The idea is to have 6 final implementations ( 3 compile-time and 3 runtime) . I think am basically done with the coding, but being a beginner myself, I feel I need some do some critics so I can improve (especially on the compiletime ones). I could have uploaded direct but I think the code may be way too long. Help will be dearly appreciated. Upload to e.g. Github/gist/pastebin. Hi Rikki, can I have your email so I add you to my repository on BitBucket?
Re: Code Reviewer
On 13/08/2015 12:09 a.m., Clayton wrote: On Wednesday, 12 August 2015 at 02:49:59 UTC, Rikki Cattermole wrote: On 12/08/2015 10:50 a.m., Clayton wrote: Hello everyone, Am looking for someone who could help review my code . As an entry exercise to D am converting 3 C implementations of popular pattern matching algorithms. The idea is to have 6 final implementations ( 3 compile-time and 3 runtime) . I think am basically done with the coding, but being a beginner myself, I feel I need some do some critics so I can improve (especially on the compiletime ones). I could have uploaded direct but I think the code may be way too long. Help will be dearly appreciated. Upload to e.g. Github/gist/pastebin. Hi Rikki, can I have your email so I add you to my repository on BitBucket? No need, as long as it is not propriety code feel free to post the links :) That way anybody who is willing to comment can.
dmd.conf... again
I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. According to the docs, I should be able to use a dmd.conf that's in the same dir as dmd itself, or in my home directory, or even specifying -conf=. None of these seems to tell dmd where to find phobos. I've also tried setting DFLAGS myself, but under no circumstances is dmd passing the -L where phobos is to ld, so I can compile but not link (well, I can if I use gcc!). Also tried dmd -L-L/path/to/phobos. Does anyone have a clue why this doesn't work? My dmd.conf looks like this: [Environment] DFLAGS=-I/nobackup/dlang/phobos/ -I/nobackup/dlang/druntime/import -L-L/nobackup/dlang/download/dmd2/linux/lib64 Atila
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 12:16:50 UTC, Atila Neves wrote: I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. According to the docs, I should be able to use a dmd.conf that's in the same dir as dmd itself, or in my home directory, or even specifying -conf=. None of these seems to tell dmd where to find phobos. I've also tried setting DFLAGS myself, but under no circumstances is dmd passing the -L where phobos is to ld, so I can compile but not link (well, I can if I use gcc!). Also tried dmd -L-L/path/to/phobos. Does anyone have a clue why this doesn't work? My dmd.conf looks like this: [Environment] DFLAGS=-I/nobackup/dlang/phobos/ -I/nobackup/dlang/druntime/import -L-L/nobackup/dlang/download/dmd2/linux/lib64 Atila Hmm, for me the dmd zip works out of the box. Unzip, add ...dmd2/linux/bin64 to PATH. Done. (The following is a stupid workaround that may be employed for libs that don't follow the normal naming convention. Phobos shouldn't be one of them but...) But lets say you want to force it to link to a specific lib that is in a lookup path you could use the full filename: -L-l:libphobos2.so
Re: vibe.d 0.7.24 released
Did you try to run dub upgrade Thanks! It's work!
[Optimization] Speculatively not calling invariant on class objects
This post got me thinking:
http://forum.dlang.org/post/mpo71n$22ma$1...@digitalmars.com
We know at compile time for a given object whether or not there
are any invariants, lack of any polymorphism, along with
disallowing invariants in interfaces means that for the given:
class NoInvariants { }
NoInvariants obj;
assert(obj);
It's only a case of checking each base class for any invariant
functions, and if none are found, then we can make an (almost)
reasonable assumption that calling _d_invariant will result in
nothing but wasted cycles.
However, these can't be omitted completely at compile-time given
that we can't guarantee if there are any up-cast classes that
have an invariant.
But we should be able to speculatively test at runtime whether or
not a call to _d_invariant may be required by doing a simple
pointer test on the classinfo.
So, given a scenario where we *know* that in a given method
'func', the this class object NoInvariants provably has no
invariants anywhere in it's vtable, we can turn calls to
_d_invariant into.
void func(NoInvariants this)
{
if (typeid(this) == typeid(NoInvariants))
{
/* Nothing */
}
else
{
_d_invariant(this);
}
}
A similar tactic is done in C++ when it comes to speculative
de-virtualization. [1]
Giving this a try on some very contrived benchmarks:
void test()
{
NoInv obj = new NoInv();
obj.func();
}
auto bench = benchmark!(test)(10_000_000);
writeln(Total time: , to!Duration(bench[0]));
I found that the patched codegen actually managed to consistently
squeeze out an extra 2% or more in runtime performance over just
turning off invariants, and in tests where the check was made to
fail, was pretty much a penalty-less in comparison to always
calling _d_invariant.
always_inv(-O2 w/o patch):
- Total time: 592 ms, 430 μs, and 6 hnsecs
always_inv(final, -O2 w/o patch):
- Total time: 572 ms, 495 μs, and 1 hnsec
no_inv(-O2 -fno-invariants):
- Total time: 526 ms, 696 μs, and 3 hnsecs
no_inv(final, -O2 -fno-invariants):
- Total time: 514 ms, 477 μs, and 3 hnsecs
spec_inv(-O2 w/ patch):
- Total time: 513 ms, 90 μs, and 6 hnsecs
spec_inv(final, -O2 w/ patch)
- Total time: 503 ms, 343 μs, and 9 hnsecs
This surprised me, I would have thought that both no_inv and
spec_inv would be the same, but then again maybe I'm just no good
at writing tests (very likely).
I'm raising a PR [2], granted that no one can see a hole in my
thought process, I'd be looking to get it merged in and let
people try it out to see if they get a similar improvement
general applications for in non-release builds.
Regards
Iain
[1]:
http://hubicka.blogspot.de/2014/02/devirtualization-in-c-part-4-analyzing.html
[2]: https://github.com/D-Programming-GDC/GDC/pull/132
Re: dmd.conf... again
On 13/08/2015 12:16 a.m., Atila Neves wrote: I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. According to the docs, I should be able to use a dmd.conf that's in the same dir as dmd itself, or in my home directory, or even specifying -conf=. None of these seems to tell dmd where to find phobos. I've also tried setting DFLAGS myself, but under no circumstances is dmd passing the -L where phobos is to ld, so I can compile but not link (well, I can if I use gcc!). Also tried dmd -L-L/path/to/phobos. Does anyone have a clue why this doesn't work? My dmd.conf looks like this: [Environment] DFLAGS=-I/nobackup/dlang/phobos/ -I/nobackup/dlang/druntime/import -L-L/nobackup/dlang/download/dmd2/linux/lib64 Atila Perhaps this small snippet from my Windows install might shred some light. Specifically the LIB property. [Environment32] LIB=%@P%\..\lib LINKCMD=%@P%\link.exe [Environment64] LIB=%@P%\..\lib64
Re: dmd.conf... again
More info about what gets placed where please.
I have special dev layout on my system that co-exists with
system-wide installation of dmd. It is as simple as having
~/dlang/{dmd|druntime|phobos}, linking ~/dlang/dmd/src/dmd to
~/bin/dmd-dev and placing dmd.conf in ~/bin which adds all those
paths as -I and -L flags. Works just fine.
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 12:29:46 UTC, Dicebot wrote:
More info about what gets placed where please.
I have special dev layout on my system that co-exists with
system-wide installation of dmd. It is as simple as having
~/dlang/{dmd|druntime|phobos}, linking ~/dlang/dmd/src/dmd to
~/bin/dmd-dev and placing dmd.conf in ~/bin which adds all
those paths as -I and -L flags. Works just fine.
There's no system-wide installation (since I don't have root), I
just downloaded the zip for 2.068 and added dmd2/linux/bin64 to
my PATH.
Atila
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 12:16:50 UTC, Atila Neves wrote: I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. If you use the dmd zip, everything just works when you just unzip it and use it all in-place. No need to move or copy files anywhere, no need for root. I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila
Re: Code Reviewer
On Tuesday, 11 August 2015 at 22:50:52 UTC, Clayton wrote: Hello everyone, Am looking for someone who could help review my code . As an entry exercise to D am converting 3 C implementations of popular pattern matching algorithms. The idea is to have 6 final implementations ( 3 compile-time and 3 runtime) . I think am basically done with the coding, but being a beginner myself, I feel I need some do some critics so I can improve (especially on the compiletime ones). I could have uploaded direct but I think the code may be way too long. Help will be dearly appreciated. Use this site: http://codereview.stackexchange.com/
Re: [Optimization] Speculatively not calling invariant on class objects
On Wednesday, 12 August 2015 at 12:48:53 UTC, Kagamin wrote: Remove allocation? My test isn't good enough for that. With scoped classes, the backend can actually devirtualize, inline and DCE pretty much everything except the one side effect I added. This is because it knows how the vtable is initialized, unlike with GC'd classes with _d_newclass. There is another optimization opportunity here... Regards Iain
Re: std.data.json formal review
On Wednesday, 12 August 2015 at 07:19:05 UTC, Sönke Ludwig wrote: We also discussed an alternative approach similar to opt(n).foo.bar[1].baz, where n is a JSONValue and opt() creates a wrapper that enables safe navigation within the DOM, propagating any missing/mismatched fields to the final result instead of throwing. This could also be combined with a final type query: opt!string(n).foo.bar In relation to that, you may find this thread interesting: http://forum.dlang.org/post/lnsc0c$1sip$1...@digitalmars.com
Re: D fund
On 2015-08-10 22:28, Andrei Alexandrescu wrote: Straight development plus minding releases, organizing DConf, website, media, PR, and more. -- Andrei I suggest that the foundation also owns all infrastructure, accounts and similar as much as possible. This is to avoid that a single person has this information and then leaves. -- /Jacob Carlborg
Re: D for Game Development
On Tuesday, 11 August 2015 at 00:56:57 UTC, Manu wrote: On 11 August 2015 at 01:15, jmh530 via Digitalmars-d digitalmars-d@puremagic.com wrote: One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it. I think some care would be taken to bundle the distribution so it's both minimal and convenient for users to install and get started with. Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system.
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 13:46:24 UTC, wobbles wrote: On Wednesday, 12 August 2015 at 13:00:45 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 12:16:50 UTC, Atila Neves wrote: [...] If you use the dmd zip, everything just works when you just unzip it and use it all in-place. No need to move or copy files anywhere, no need for root. I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila Have you run dmd from the directory you unzipped it to? libphobos2.a is in there I think, so ld wouldn't be able to find it. Just did, didn't work. Tried it from lib64 and lib32 as well, nothing. Atila
Re: dmd.conf... again
On Wednesday, 12 August 2015 at 13:00:45 UTC, Atila Neves wrote: On Wednesday, 12 August 2015 at 12:40:49 UTC, Adam D. Ruppe wrote: On Wednesday, 12 August 2015 at 12:16:50 UTC, Atila Neves wrote: I'm trying to use dmd on a VM where I don't have root privileges (don't ask). I can't copy dmd.conf to /etc. If you use the dmd zip, everything just works when you just unzip it and use it all in-place. No need to move or copy files anywhere, no need for root. I downloaded the zip, added linux/bin64 to PATH, tried compiling a hello world and got: usr/bin/ld: cannot find -l:libphobos2.a That's when I started trying to set the configuration but nothing seems to work. Atila Have you run dmd from the directory you unzipped it to? libphobos2.a is in there I think, so ld wouldn't be able to find it.
[Issue 13567] Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #4 from Martin Nowak c...@dawg.eu --- It would be a good step forward to less attribute clutter. --
Re: [Optimization] Speculatively not calling invariant on class objects
static __gshared NoInv obj;
void test()
{
obj.func();
}
obj = new NoInv();
auto bench = benchmark!(test)(10_000_000);
writeln(Total time: , to!Duration(bench[0]));
Re: std.data.json formal review
On Wednesday, 12 August 2015 at 08:21:41 UTC, Sönke Ludwig wrote: Just to state explicitly what I mean: This strategy has the most efficient in-memory storage format and profits from all the static type checking niceties of the compiler. It also means that there is a documented schema in the code that be used for reference by the developers and that will automatically be verified by the serializer, resulting in less and better checked code. So where applicable I claim that this is the best strategy to work with such data. For maximum efficiency, it can also be transparently combined with the pull parser. The pull parser can for example be used to jump between array entries and the serializer then reads each single array entry. Thing is, the schema is not always known perfectly? Typical case is JSON used for configuration, and diverse version of the software adding new configurations capabilities, or ignoring old ones.
Re: D fund
On 09/08/2015 14:22, ref2401 wrote: I don't have much experience and time to contribute to code-base directly. But I'd like to donate some money every month. I think (hope) there are several guys who would like to donate to. There must be the way to do it. Actually, it seems BountySource is experimenting with a monthly payment model: https://salt.bountysource.com/ Invite only at the moment, but I think you can submit request if you are the project leader. Might be a interesting model for D? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 18:37:40 UTC, JDemler wrote: Triggered by the original forum thread I wrote a DIP to further explain the idea of the writing files at compile time feature and its implications. http://wiki.dlang.org/DIP81 Please discuss! 1. How do you order imports and exports? 2. How do you support parallel compilation on a cluster?
