Re: Writing/Creating files at compile-time
On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
wrote:
> On Sunday, 9 August 2015 at 09:07:51 UTC, JDemler wrote:
>>
>> We can read files at compile-time:
>>
>> enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at compile-time and mixing it in is fun but has a few
>> flaws.
>> It isn't debuggable, the generated code cannot be directly inspected (we
>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>
>> If we could generate source files (.d) at compile time and then import
>> them using mixins or something else, these problems can be dealt with.
>
>
> what will bing D more awesomeness is a ctfe execute.
>
> enum file = execute("shell scripts");
I don't think so...
Re: Writing/Creating files at compile-time
On 9 August 2015 at 11:07, JDemler via Digitalmars-d wrote: > We can read files at compile-time: > > enum file = import(fileName); > > But we cannot write to a file or create files at compile time. > So, something like: enum contents = someCTFEStringFunction(); export(fileName, contents); Iain.
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 07:05:40 UTC, Iain Buclaw wrote: On 9 August 2015 at 11:07, JDemler via Digitalmars-d wrote: We can read files at compile-time: enum file = import(fileName); But we cannot write to a file or create files at compile time. So, something like: enum contents = someCTFEStringFunction(); export(fileName, contents); Ugh… please don't add more ugly features that has to be ripped out to bring the language to a sane state. A compiler should be able to compile all programs on a read only filesystem. If the language requires a filesystem to compile then I consider the language broken and in need of redesign.
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 07:50:29 UTC, Ola Fosheim Grøstad wrote: Ugh… please don't add more ugly features that has to be ripped out to bring the language to a sane state. A compiler should be able to compile all programs on a read only filesystem. If the language requires a filesystem to compile then I consider the language broken and in need of redesign. While I agree with you I am curious; where would the compiler place its artefacts and why can't "export" write to the same place? The way I see it files created by export would be transient anyway, generated each time you compile. bye, lobo
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
what will bing D more awesomeness is a ctfe execute.
enum file = execute("shell scripts");
I don't think so...
Its basically as bad, but the execute is frr more useful.
Re: D for Game Development
On Sunday, 9 August 2015 at 05:31:41 UTC, Walter Bright wrote: I agree, and now we ship a Phobos DLL, resolving that issue. I think most people these days associate "DLL" exclusively with windows. I certainly do.
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote: While I agree with you I am curious; where would the compiler place its artefacts and why can't "export" write to the same place? I think that is an implementation detail and not a language-issue. The way I see it files created by export would be transient anyway, generated each time you compile. Yes, or cached, but it should not be a file. You might want the ability to build resources (e.g. for Apple ios/osx bundles), but then you would need compiler support for those resource bundles. E.g. create a bundle as a "database" and then populate it programatically. If you go down the route of generating files you probably also would also need to build in "make" like dependency resolution so that the resources are built in the correct order... Another point: if "export" is needed to generate D-files then one would be better off adding AST-macros instead and generate the AST for whole modules in-memory. Saving the AST to disk for inspection would be a compiler-pragma.
Re: Writing/Creating files at compile-time
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote: > I think you mean dlopen, dlsym and dlclose. Not full file system access > geez. and root privs requirement. just to complement it all. > We are already getting so close to have a full blown CTFE implementation > that it isn't funny. i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it. signature.asc Description: PGP signature
Re: Writing/Creating files at compile-time
On Mon, 10 Aug 2015 08:33:49 +, Tofu Ninja wrote:
> On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
>> On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
>>>
>>> what will bing D more awesomeness is a ctfe execute.
>>>
>>> enum file = execute("shell scripts");
>>
>> I don't think so...
>
> Its basically as bad, but the execute is frr more useful.
but... you know what? there are shell scripts, and build scripts, and
such things, and hey, they can execute other scripts!
signature.asc
Description: PGP signature
Re: Writing/Creating files at compile-time
On Mon, 10 Aug 2015 07:50:27 +, Ola Fosheim Grøstad wrote: > Ugh⦠please don't add more ugly features that has to be ripped out to > bring the language to a sane state. hear, hear. signature.asc Description: PGP signature
Re: Writing/Creating files at compile-time
On 10 August 2015 at 10:59, via Digitalmars-d wrote: > On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote: >> >> While I agree with you I am curious; where would the compiler place its >> artefacts and why can't "export" write to the same place? > > > I think that is an implementation detail and not a language-issue. > >> The way I see it files created by export would be transient anyway, >> generated each time you compile. > > > Yes, or cached, but it should not be a file. You might want the ability to > build resources (e.g. for Apple ios/osx bundles), but then you would need > compiler support for those resource bundles. E.g. create a bundle as a > "database" and then populate it programatically. > > If you go down the route of generating files you probably also would also > need to build in "make" like dependency resolution so that the resources are > built in the correct order... > > Another point: if "export" is needed to generate D-files then one would be > better off adding AST-macros instead and generate the AST for whole modules > in-memory. Saving the AST to disk for inspection would be a compiler-pragma. > Who said anything about D-files? import() accepts any arbitrary text that you may want to embed in a program.
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 09:55:51 UTC, Iain Buclaw wrote: Who said anything about D-files? import() accepts any arbitrary text that you may want to embed in a program. And that is not a problem if it is reading a static file from the source-bundle, conceptually it just means you have split your source code into multiple files.
Re: Writing/Creating files at compile-time
On 10/08/2015 9:48 p.m., ketmar wrote: On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote: I think you mean dlopen, dlsym and dlclose. Not full file system access geez. and root privs requirement. just to complement it all. We are already getting so close to have a full blown CTFE implementation that it isn't funny. i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it. Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it.
Re: D for Game Development
On 10/08/15 10:43, John Colvin wrote: I think most people these days associate "DLL" exclusively with windows. I certainly do. Exactly. "DLL" on Windows and "shared library" on Posix. Although I think it's "dynamic library" on OS X. -- /Jacob Carlborg
Re: D for Game Development
On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote: On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. https://issues.dlang.org/show_bug.cgi?id=14896
Re: Writing/Creating files at compile-time
On 10-Aug-2015 13:22, Rikki Cattermole wrote: On 10/08/2015 9:48 p.m., ketmar wrote: On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote: I think you mean dlopen, dlsym and dlclose. Not full file system access geez. and root privs requirement. just to complement it all. We are already getting so close to have a full blown CTFE implementation that it isn't funny. i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it. Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it. Rather the only problem with CTFE is that it should to be within factor of x10 slower then real-time version not x1000 times slower. -- Dmitry Olshansky
Re: D for Game Development
On 10 August 2015 at 12:29, Jacob Carlborg via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 10/08/15 10:43, John Colvin wrote: > > I think most people these days associate "DLL" exclusively with windows. >> I certainly do. >> > > Exactly. "DLL" on Windows and "shared library" on Posix. Although I think > it's "dynamic library" on OS X. > > So many competing standards! We should invent a new name for them that will be universally used by all platforms. https://xkcd.com/927
Re: Writing/Creating files at compile-time
On 10/08/2015 10:31 p.m., Dmitry Olshansky wrote: On 10-Aug-2015 13:22, Rikki Cattermole wrote: On 10/08/2015 9:48 p.m., ketmar wrote: On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote: I think you mean dlopen, dlsym and dlclose. Not full file system access geez. and root privs requirement. just to complement it all. We are already getting so close to have a full blown CTFE implementation that it isn't funny. i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it. Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it. Rather the only problem with CTFE is that it should to be within factor of x10 slower then real-time version not x1000 times slower. Meh, thats a problem with the implementation. Not so much with the feature set or rather the desired feature set.
Re: D for Game Development
On 8/10/2015 3:32 AM, ponce wrote: On Monday, 10 August 2015 at 01:26:44 UTC, Walter Bright wrote: On 8/9/2015 2:03 PM, ponce wrote: Once I get back to Windows I will post the report. Thank you. https://issues.dlang.org/show_bug.cgi?id=14896 Good!
Binary file grammar
I have to read a binary file.
I can use std.stdio.File.rawRead to do this (and it's even
typesafe, awesome!!)
Currently, I'm doing this with a little helper function I've
called Get:
/// Creates a buffer to read the file. Handles a special case
string
T[] Get(T)(File f, size_t num=1){
static if(is(T == char)){
ubyte[] strLen = new ubyte[1];
f.rawRead(strLen);
ubyte[] strBuf = new ubyte[strLen[0]];
return (f.rawRead(strBuf));
} else {
T[] buf = new T[num];
return f.rawRead(buf);
}
}
Then to use it:
File f = File(filename, "rb");
auto versionNumber = f.Get!(ushort); // reads 2 bytes from file
into a ushort[]
auto nextByte = f.Get!(byte); // reads 1 byte into a byte[]
auto next5Bytes = f.Get!(byte)(5); // reads 5 bytes and puts them
into a byte[]
There is a lot of improvements to be made to the above, mostly
around returning a Range. Also, reusing buffers so as not to
allocate so much. That's probably Priority 1 actually.
That's all fine and dandy, will get to that.
There's some more complicated data in there too, like a string
which in this binary file is defined as a byte representing the
number of bytes in this string, followed by that number of bytes.
(Similar to a char[] in C/D I imagine).
So, to read that, I'd write:
auto myString = f.Get!(char)(f.Get!(byte)); // reads
f.Get!byte number of bytes into a char array.
While doing this I had the idea of implementing a more general
approach to this, using CTFE to build a struct / parserFunction
(Similar to Pegged [1] ).
You describe at compile time how this binary file looks, and then
the parser handles everything else.
Does anyone know of a good Binary Description Grammar out in the
wild? I'd rather not re-invent the wheel on that front, and just
use something standard. My Googling didn't come up with something
that could be considered "standard" however.
Any ideas?
Thanks
[1] https://github.com/PhilippeSigaud/Pegged
Re: D for Game Development
On 10 August 2015 at 05:00, Jacob Carlborg via Digitalmars-d wrote: > On 09/08/15 13:38, Manu via Digitalmars-d wrote: > >> In fact, we've been discussing for a few months that we'd have have >> another very promising opportunity to use D at work in a really >> appropriate context if I could rely on Android and iOS appearing >> within 6-12 months or so. > > > There's been quite a lot of activities lately in improving the Andriod and > iOS support by Joakim and Dan. Indeed, I've been watching with great interest. I wonder how .so files to work on those platforms? I expect iOS would leverage OSX support almost verbatim? On Android, all binaries are .so files; but I fear there will be a problem when a program is comprised of many .so files working together... will that mean as many instances of phobos and druntime?
Re: Writing/Creating files at compile-time
On Mon, 10 Aug 2015 22:22:49 +1200, Rikki Cattermole wrote: > Nah, I like CTFE a lot. if it will ever be augmented with AST macros... yes. until then, people will try to bolt extensions on it again and again, and i have a feeling that CTFE engine will become another abomination that makes D weirder, yet cannot be dropped due to "it's already used in too much D code". signature.asc Description: PGP signature
Re: Binary file grammar
it looks like you can use some serialization library instead, like Orange. structs that those library takes as input can be seen as a kind of grammar description. ;-) signature.asc Description: PGP signature
Re: Binary file grammar
On Monday, 10 August 2015 at 12:38:11 UTC, ketmar wrote: it looks like you can use some serialization library instead, like Orange. structs that those library takes as input can be seen as a kind of grammar description. ;-) Trouble with that is what if there's some funny formats some data is in? Like I described above a string which starts with a number and continues for that number of bytes. What if it's a string that goes on until you hit a '\0' ? A serialisation library like Orange couldnt do that, as it's merely for (de)serialising D objects, I think?
Re: D fund
On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Are you one of those guys who wears a Star Trek t-shirt to a Star Wars convention (or vice versa)? ;) - Jonathan M Davis
Re: D fund
On Monday, 10 August 2015 at 13:44:17 UTC, Jonathan M Davis wrote: On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Are you one of those guys who wears a Star Trek t-shirt to a Star Wars convention (or vice versa)? ;) - Jonathan M Davis You mean to say you're not? Gasp!
Re: D for Game Development
On 10 August 2015 at 06:51, Walter Bright via Digitalmars-d wrote: > On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: >> >> On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d >>> >>> But waiting for someone else to discover the same thing on some other >>> piece >>> of code means you'll be waiting a long time. >> >> I understand, but that's not sustainable. >> We can't be in a situation where I'm at work with a deadline, and I >> need to invoke the community to address a codegen issue that's >> blocking a release. Unexpected surprises like that with unknown/long >> turn-around times aren't a practical commitment. > > > It will NEVER get fixed if you don't file bug reports, and you'll continue > to be frustrated (and me too, because there's NOTHING I can do to improve > things based on what you post here). I think you misunderstood my point again. I'm trying to say that it's precarious to make a commitment to something you know (or suspect) has unknown issues. The practical outcome is that there's a strong pressure against making such a commitment (ie, not use D), and then certainly no bugs will be found or reported. The thing is, whatever bugs may or may not be discovered are almost certainly already 'fixed' in LLVM/GCC. There's no work to do there, those backends have legions of developers working on them every day. There is literally nothing DMD can ever to do catch up. It may be sad to admit, but it's just how it is. Maintaining and fixing the DMD codegen just takes time away from other things (I understand you argue that it's very little time in practical terms, but that's not really a great argument; it just admits that DMD is not progressing), and it has lead to a fragmented experience, which is the biggest practical issue I've been finding with D in recent times. DMD as a frontend to LLVM seems like the most practical and reliable option as the default offering. You did a lot of work to make debugging in DMD work well, and the work really paid off! DMD is the only windows compiler that produces a workable debugging experience. The consequence of that though, is to have created a situation where people necessarily rely on a tooling situation where they use 2 different compilers for debug and release, and because the other compilers are always a few versions out of date, you're behind on all the latest developments. If that effort to reverse engineer Microsoft's debuginfo were contributed to LLVM, almost every native developer, D or any language otherwise, would all be better off. So the point is, many of my modern D issues aren't issues that I can bug. I can't log on bugzilla: "using DMD for debug and LDC for release builds sucks; fix debuginfo in LLVM". That's obviously outside the scope of DMD, but I suggest that maybe it shouldn't be? DMD has become fairly reliable for me, I don't fight it much anymore (or maybe I'm just much better at knowing what works well?), but the larger ecosystem seems to be the biggest cause of friction now. These aren't problems that are easily directed to a particular bug tracker, they represent a conjunction of tooling, and maybe strategies need to be considered where core developers are aware of these issues. Leveraging the world of LLVM tooling is the most practical and bang-for-buck solution I can imagine. The other advantage of core dev using an LLVM backend, would be that port/architecture related bugs would become the business of core development. CI would necessarily have to build for many architectures, and PR's blocked until they work on ARM/iOS/etc. >> Last time I was concerned with this, x87 was destroying DMD >> performance. Floats were x87, moved to XMM (according to x64 ABI) when >> passed to functions, then moved back into x87 on the other side when >> they're operated on. >> Float code was overwhelmed with shuffling values between registers. >> Basically all hot code is float code in my line of work. > > > All I really need is a bugzilla issue with just ONE example of needlessly > using the x87 where a SIMD instruction would be better. Like I said, it's not a problem I have today. I was answering a question and discussing historical problems. >> I think Ethan was in discussions with you about this some time back? >> It was a problem at the time I left Remedy. > > > As I recall, I heard from Ethan just once since you left. That's a bummer. Sorry to hear that. I should catch up with those guys and see where they're at. > In contrast, I hear regularly from Sociomantic when they've got an issue, and > I'm able to > consequently help them be successful with D. Thing is, most of my 2015 blockers are outside the scope of DMD unless DMD decides to adopt LLVM as it's backend. DMD is in pretty good shape these days, it's just a shame it can't be used to compile software that runs on modern computers (arm, iOS, Android, web). We all need Android, iOS, Emscripten. We need equal confidence the ports work well as that DMD is released to a hi
Re: D for Game Development
On 10/08/15 14:25, Manu via Digitalmars-d wrote: I wonder how .so files to work on those platforms? I expect iOS would leverage OSX support almost verbatim? Shared libraries are not supported on OS X, at least not with DMD, not sure about LDC. On Android, all binaries are .so files; but I fear there will be a problem when a program is comprised of many .so files working together... will that mean as many instances of phobos and druntime? On Posix, when using shared libraries, there's only one shared Phobos and druntime. I assume it would be implemented the same way on Andriod. -- /Jacob Carlborg
Re: Binary file grammar
On 10/08/15 15:12, wobbles wrote: Trouble with that is what if there's some funny formats some data is in? Like I described above a string which starts with a number and continues for that number of bytes. What if it's a string that goes on until you hit a '\0' ? A serialisation library like Orange couldnt do that, as it's merely for (de)serialising D objects, I think? Orange can handle D strings. If it sees something like char* it will serialize it as a pointer to a char, not a C string. Orange supports custom archivers if you need the data in some special format. -- /Jacob Carlborg
Re: D for Game Development
On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote: I really hope this is a top-priority goal for the switch to DDMD. My understanding is that 2.069 is supposed to bring DDMD support. I think there has been a lot of heated discussion about something that really isn't that far away. Nevertheless, I think you've made your case well about sort of merging LDC and DMD. 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.
Re: D for Game Development
On Monday, 10 August 2015 at 14:44:42 UTC, Jacob Carlborg wrote: Shared libraries are not supported on OS X, at least not with DMD, not sure about LDC. Shared libraries works well here on OS X with LDC 0.15.2-beta2 (and only with LDC).
findSplit corner case bug?
Although it is a bit of a corner case, I would argue that the
following behaviour is buggy:
assert(findSplit!(reverseArgs!canFind)("078.12.13-4.5", ".-")
== tuple("078", ".1", "2.13-4.5"));
To understand why, consider the following more explicit code:
void main()
{
static bool oneOf(dchar a, string b)
{
bool r = false;
foreach(c; b)
{
if(c == a)
{
r = true;
break;
}
}
writefln(`matching a='%s' b="%s" returns %s`, a, b,
r);
return r;
}
auto s = findSplit!oneOf("078.12.13-4.5", ".-");
writefln("%s %s %s", s[0], s[1], s[2]);
}
Output:
matching a='0' b=".-" returns false
matching a='7' b=".-" returns false
matching a='8' b=".-" returns false
matching a='.' b=".-" returns true
078 .1 2.13-4.5
The findSplit documentation says: "result[1] is the portion of
haystack that matches needle". Yet, the only character for which
the predicate returned true was '.'. Therefore, that should be
the only part of result[1]. The alternative would be to clarify
and change the documentation, I guess.
BTW 1: it's not very clear what the predicate arguments are / can
be, unless I missed some part of the docs. Apparently, findSplit
tries to use both `bool function(dchar, dchar)` and `bool
function(dchar, string)`, IIRC.
BTW 2: Any particular reason for binaryReverseArgs to exist,
instead of always just using reverseArgs?
Re: D needs to focus and better the available resources
On Monday, 10 August 2015 at 04:07:05 UTC, Rikki Cattermole wrote: On 10/08/2015 5:29 a.m., karabuta wrote: [...] I have two separate plans right now for how to grow D. The first related to GUI's and game development is going very well. Although it'll take atleast another year before you should see anything interesting in Phobos. The second is all about web development, should see some pretty cool stuff this year. Especially if you watch my live stream! No seriously, you'll see it literally in about 6-7 hours time! (I stream twice weekly) https://www.livecoding.tv/alphaglosined/ I really like your projects. Very nice.
Re: D fund
On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Will the swag feature http://dlangcomicstrips.tumblr.com/ ?
Re: D fund
On Monday, 10 August 2015 at 16:58:15 UTC, vladde wrote: On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Will the swag feature http://dlangcomicstrips.tumblr.com/ ? Lol Wtf who makes those? They are hilarious!
Re: D fund
On Sunday, 9 August 2015 at 13:52:17 UTC, Andrei Alexandrescu wrote: On 8/9/15 5:15 AM, ref2401 wrote: Does the fund exist? Are there sponsors? How can one donate some money to D? There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei What exactly will any funds the D foundation gets be used for? Would be great if D could have full time paid devs working on it.
Re: D fund
On Mon, Aug 10, 2015 at 05:00:38PM +, Tofu Ninja via Digitalmars-d wrote: > On Monday, 10 August 2015 at 16:58:15 UTC, vladde wrote: > >On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: > >>On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: > >>>There will be a possibility with the D Language Foundation, > >>>hopefully by the end of this year. -- Andrei > >> > >>Looking forward to it. We can also use the foundation to sell some D > >>swag so that people will get something for their donation. After > >>all, nothing is cooler than wearing a D t-shirt to a > >>C++/Java/Go/Rust convention! > > > >Will the swag feature http://dlangcomicstrips.tumblr.com/ ? > > Lol Wtf who makes those? They are hilarious! Totally hilarious. I wan moar! ;-) T -- The richest man is not he who has the most, but he who needs the least.
Re: pthread_create oddity
On 8/8/15 8:40 AM, Andrei Alexandrescu wrote: pthread_getstacksize indicates 8,388,608 bytes. It doesn't seem excessive, but the 32-bit build does find that too big. If I try to set stack size to that value with pthread_setstacksize, indeed the thread fails. So it's not that you need to call pthread_setstacksize, you need to call it with a smaller value. -- Andrei Does the failure always happen with any thread create? Or only after you have created X threads? 8MB doesn't seem like that much, but if you created 100 threads at 8MB a piece... What about an equivalent C program? something doesn't seem right when the default value isn't working... -Steve
Re: D for Game Development
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? And apparently the same misguided obsession with iterators (aka ranges): https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146 …Rust has a long way to go… …Go is frozen… …D has a long way to go… …C++ is fit, moving and annoying… I guess the only way forward is to write your own language.
Re: D for Game Development
On Monday, 10 August 2015 at 19:25:45 UTC, Ola Fosheim Grøstad wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? To keep it short, this is the reason I am not using Rust.
Re: D for Game Development
On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack.
Re: D for Game Development
On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? And apparently the same misguided obsession with iterators (aka ranges): https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146 …Rust has a long way to go… …Go is frozen… …D has a long way to go… …C++ is fit, moving and annoying… I guess the only way forward is to write your own language. …[insert your language here] has a long way to go… :)
Re: D for Game Development
On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators. And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree.
Re: D fund
On 8/10/15 1:10 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 13:52:17 UTC, Andrei Alexandrescu wrote: On 8/9/15 5:15 AM, ref2401 wrote: Does the fund exist? Are there sponsors? How can one donate some money to D? There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei What exactly will any funds the D foundation gets be used for? Would be great if D could have full time paid devs working on it. Straight development plus minding releases, organizing DConf, website, media, PR, and more. -- Andrei
Re: D for Game Development
On Monday, 10 August 2015 at 20:20:36 UTC, Tofu Ninja wrote: On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators. overload new. It's "deprecated" but I used it the entire time I was required to use D without Phobos because it was just a massive pain. And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree. This exists, you can use a proxy GC.
Re: D fund
On Monday, 10 August 2015 at 20:28:10 UTC, Andrei Alexandrescu wrote: Straight development plus minding releases, organizing DConf, website, media, PR, and more. -- Andrei May I suggest copying some of what Boost does on their donate page (monthly recurring donations, esp.). I also like pypy's approach of having a call for donations for specific projects and showing the progress (you'd probably want to start small though).
Re: Binary file grammar
On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote: While doing this I had the idea of implementing a more general approach to this, using CTFE to build a struct / parserFunction (Similar to Pegged [1] ). You describe at compile time how this binary file looks, and then the parser handles everything else. Does anyone know of a good Binary Description Grammar out in the wild? I'd rather not re-invent the wheel on that front, and just use something standard. My Googling didn't come up with something that could be considered "standard" however. Any ideas? You should look into Construct (Python) - https://github.com/construct/construct If you are not afraid of Haskell, also take a look at https://github.com/bos/attoparsec
Re: D fund
Something I've been pondering for some time that could materialize a lot faster than the D foundation would be something like a kickstarter for me personally. If I could raise about $15,000 in the short term - a large sum of money, I admit - I could take a three month break from my day job and focus on D things; likely my own libraries (i'd like to finish the minigui and simple game bits especially) as well as documentation things, but maybe some bug fixes and perhaps phobos/druntime bits too if there's enough demand. I actually have a bit of an urge to write D documentation and tutorials, but that's actually even more time consuming than code, and less beneficial to me personally! (i already know the stuff i'd be documenting so it doesn't directly benefit me, whereas the code is something I can at least use myself) Three months isn't enough to change the D world, but with the day job on hold, it would be enough time to realistically achieve some useful, if modest, goals, like finishing some small libraries or a tutorial set. But I'm also hesitant to do it for a few reasons, chief among them being that it would take a large sum to actually warrant taking time off work... and without time off work, I don't really have the time to do this, and secondly that I would prefer to do the code my way still. however, would any of you be interested in that kind of thing?
Re: D fund
On 8/10/2015 6:44 AM, Jonathan M Davis wrote: Are you one of those guys who wears a Star Trek t-shirt to a Star Wars convention (or vice versa)? ;) If Luke and Kirk would only put aside their differences.
Re: D fund
On 8/10/2015 9:58 AM, vladde wrote: Will the swag feature http://dlangcomicstrips.tumblr.com/ ? Why didn't I know about that? Pretty dazz! (Who drew them? Keep 'em coming!)
Re: D for Game Development
On 11 August 2015 at 01:15, jmh530 via Digitalmars-d wrote: > On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote: >> >> I really hope this is a top-priority goal for the switch to DDMD. > > > My understanding is that 2.069 is supposed to bring DDMD support. I think > there has been a lot of heated discussion about something that really isn't > that far away. Nevertheless, I think you've made your case well about sort > of merging LDC and DMD. > > 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.
Re: DMD diagnostic - any way to remove identical lines from final dmd error log?
On Friday, 17 August 2012 at 13:10:52 UTC, Timon Gehr wrote: On 08/17/2012 02:17 PM, Marco Leise wrote: Am Tue, 14 Aug 2012 12:15:35 +0200 schrieb Don Clugston: Seriously, if you are finding ANY error messages for things which are not real errors, that is a bug. What about errors that are a result of erroneous types being used. Sometimes I read foo!(bar, _error_) in the error output and wonder if that helps me any, since the error is obviously farther above. The user should never see _error_. just filed: https://issues.dlang.org/show_bug.cgi?id=14905
Re: DMD diagnostic - any way to remove identical lines from final dmd error log?
On 8/13/2012 9:47 AM, Dmitry Olshansky wrote: I seriously consider writing a simple postprocessor for dmd's output. Once dmd became able to recover from errors and crawl on it started to produce horrific amounts of redundant text on failure. The current strategy the compiler uses on detecting a bug is it marks whatever symbol/expression/statement caused the bug as "poisoned". Then, every dependency on that poisoned symbol/expression/statement is also marked as "poisoned" and error messages for them are suppressed. This has been extremely successful at reducing cascaded, duplicated, and nonsense error messages. However, it is not completely implemented throughout the compiler.
Re: D needs to focus and better the available resources
On 11/08/2015 4:20 a.m., karabuta wrote: On Monday, 10 August 2015 at 04:07:05 UTC, Rikki Cattermole wrote: On 10/08/2015 5:29 a.m., karabuta wrote: [...] I have two separate plans right now for how to grow D. The first related to GUI's and game development is going very well. Although it'll take atleast another year before you should see anything interesting in Phobos. The second is all about web development, should see some pretty cool stuff this year. Especially if you watch my live stream! No seriously, you'll see it literally in about 6-7 hours time! (I stream twice weekly) https://www.livecoding.tv/alphaglosined/ I really like your projects. Very nice. Thank you. It means a lot!
Re: D fund
On 11/08/2015 11:55 a.m., Adam D. Ruppe wrote: Something I've been pondering for some time that could materialize a lot faster than the D foundation would be something like a kickstarter for me personally. If I could raise about $15,000 in the short term - a large sum of money, I admit - I could take a three month break from my day job and focus on D things; likely my own libraries (i'd like to finish the minigui and simple game bits especially) as well as documentation things, but maybe some bug fixes and perhaps phobos/druntime bits too if there's enough demand. I actually have a bit of an urge to write D documentation and tutorials, but that's actually even more time consuming than code, and less beneficial to me personally! (i already know the stuff i'd be documenting so it doesn't directly benefit me, whereas the code is something I can at least use myself) Three months isn't enough to change the D world, but with the day job on hold, it would be enough time to realistically achieve some useful, if modest, goals, like finishing some small libraries or a tutorial set. But I'm also hesitant to do it for a few reasons, chief among them being that it would take a large sum to actually warrant taking time off work... and without time off work, I don't really have the time to do this, and secondly that I would prefer to do the code my way still. however, would any of you be interested in that kind of thing? I suggested support via donation/subscribing to live streamers. Nobody even commented :/ Okay there is only two of us currently doing it but.. hey publicity + D code written. Would be great to get D core devs doing it and earning some money at the same time.
Where the F*** is phobos on OSX nowadays ?
And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ?
Re: Where the F*** is phobos on OSX nowadays ?
On Tuesday, 11 August 2015 at 04:51:03 UTC, deadalnix wrote: And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ? The problem, as usual, is Apple just breaking things willy nilly. https://issues.dlang.org/show_bug.cgi?id=14801 Say what you will about Microsoft but at least with them you don't have to fix a handful of new bugs with every minor OS or IDE upgrade.
