Re: Uphill
On Monday, 1 June 2015 at 05:45:56 UTC, Paulo Pinto wrote: On Monday, 1 June 2015 at 05:37:39 UTC, weaselcat wrote: On Monday, 1 June 2015 at 05:20:27 UTC, Paulo Pinto wrote: On Monday, 1 June 2015 at 05:14:59 UTC, Manu wrote: On 1 June 2015 at 14:05, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 1 June 2015 at 03:38:44 UTC, Manu wrote: On 1 June 2015 at 10:56, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 31 May 2015 09:08:27 +, Joakim wrote: Most mobile games are written in C/C++/OpenGL that will fade away soon. it's safe to ignore that in long-time plan. How so? Game dev's aren't moving away from native code any time soon... a large portion of ios, android, and steam games use unity, which outside of the core engine uses mono for programming. Ah, yeah, but Unity itself is all C code. Every modern game has a scripting solution, just that Unity has made that interface front-and-center. Lots of meaty Unity plugins are native too. Since last Unity version, C# is also compiled to native code via IL2CPP. Only because of mono's license update, it's why they've been using a nearly decade old mono for so long. No, only because they are too cheap to pay for the work of Xamarin. I doubt that the amount of money wasted in Danish salaries for writing a .NET native compiler is cheaper than paying for the licenses. AFAIK It's heavily based off of mono 2.0 code, it actually directly links against a lot of mono libraries to supply the CLR(or did, anyways.) However riding the fame wave is easy to forget how unknown they were before they firstly added Mono to their JavaScript and Boo offerings, followed by porting the engine to Windows. Boo requires mono ;) So I don't really get why Xamarin gets the blame and Unity is portraid as the good guys. For me they are just a company that got lucky using open source and now doesn't want to pay back. Xamarin is doing great without their money. I wasn't blaming Xamarin, unity owes a lot of their success to them - mono helped them greatly reduce the barriers of indie gamedev.
Re: Entry point a la git or go
On Sun, 31 May 2015 23:34:42 + weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 31 May 2015 at 23:31:00 UTC, Andrei Alexandrescu wrote: On 5/31/15 4:28 PM, weaselcat wrote: On Sunday, 31 May 2015 at 23:11:24 UTC, Andrei Alexandrescu wrote: How would this add value to our toolchain? Andrei Having to install/manage less packages and executables. git distributes a bunch of executables. -- Andrei do you mean as a default installation? pacman -Ql git | grep bin git /usr/bin/ git /usr/bin/git git /usr/bin/git-cvsserver git /usr/bin/git-receive-pack git /usr/bin/git-shell git /usr/bin/git-upload-archive git /usr/bin/git-upload-pack git /usr/bin/gitk Thaats not all, there are lots of others in /usr/lib/git-core pacman -Ql git | grep /usr/lib/git-core
Re: Make dub part of the standard dmd distribution
On 1/06/2015 5:57 p.m., Manu via Digitalmars-d wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote: On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. I thought it does that. If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker. Andrei dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions. Yeah, but regardless, that's what I want. I don't have version hell with C libs distributed this way...? Is this a problem that people are specifically trying to avoid? That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them. I get it, it sounds great... if your app suits the model. I have no D-only projects, all my programs combine many languages and ecosystems. There are also existing build systems that are well established that I prefer to use, integrate with IDE's, etc. I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically. dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. Point is, I don't have to do this with C. I just install the dev package, once, and I'm done. Package manager distributes updates automatically, everything it exactly how I want it. It's just not a wheel I have any interest in reinventing. I'm not trying to heckle. I just want someone to declare the word on where in the filesystem we put .d files, parallel to c includes. I think the single most important thing is for bindings against C libs that are installed by common -dev packages, it would be easiest if the bindings were fetched and installed the same way as the libs they refer to. Perhaps a new dub command (--locate)? $ dub build package --version=version --arch=arch --compiler=compiler --locate Base: ~/.dub/package-version/ Binary: ~/.dub/package-version/output.lib ImportPath: ~/.dub/package-version/source Pass Well you get the general gist. Fetches and builds if necessary for specific arch ext. Really it just minimizes output and only output location info.
Re: Make dub part of the standard dmd distribution
On 05/31/2015 11:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. Ditto. Dub's great if you let it be your buildsystem, but as soon as you want to use it as a package-manager-only it becomes an uphill battle with dub fighting back every step of the way (I speak from experience). That problem is worse if your project is a library that you want fetchable through dub. That's why I've been working on some PRs to fix all that. The first step is here (building/expanding on a flag another contributer recently added): https://github.com/D-Programming-Language/dub/pull/572 (Although I think I may need to change --data=libs and separate system libs from dependency libs since linkers expect those to be passed in differently.) The next step will be to add a flag to have that data get output in a compiler-ready argument list (your choice of compiler, of course). That'll let you do something comparable to pkg-config --cflags --libs. Then finally, a shortcut flag so you can just do something kinda like: rdmd --build-only `dub describe --cmdargs=rdmd` src/main.d And all your dependencies will be properly referenced (-I..., linker flags, etc).
Re: Make dub part of the standard dmd distribution
On 06/01/2015 01:21 AM, Andrei Alexandrescu wrote: I installed a Python program the other day. I think it's rather obscure - it's called lcinvestor. I got from knowing nothing about how to install Python stuff to having the application running in minutes. That doesn't even remotely match my experience trying to use/install python-based software/libs: https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really
Re: Make dub part of the standard dmd distribution
On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote: Let's make this part of 2.068: https://issues.dlang.org/show_bug.cgi?id=14636 It's preapproved. Who would want to work on it? IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not certain exactly what work he had in mind for that though, versus post-1.0.
Re: Make dub part of the standard dmd distribution
On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) Not sure how serious/joking you are about that, but when has declaring a standard whatever like that ever worked for anything ever? ;) Linux can't even agree with Linux on where things should go, apparently that's why C on linux has pkg-config.
[Issue 14639] New: Assigning init value to struct uses stack, causing segfault
https://issues.dlang.org/show_bug.cgi?id=14639
Issue ID: 14639
Summary: Assigning init value to struct uses stack, causing
segfault
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: tomerfil...@gmail.com
Consider the following snippet:
struct Biggy {
ulong[5] a;
}
__gshared Biggy biggy;
void main() {
biggy = Biggy.init;
}
produces the following code
Dump of assembler code for function _Dmain:
...
= 0x0047fa04 +4:movabs $0x6faef0,%rsi
0x0047fa0e +14:movabs $0x7d6a90,%rdi
0x0047fa18 +24:mov$0x1b774,%ecx
0x0047fa1d +29:rep movsq %ds:(%rsi),%es:(%rdi)
which is fine. However, adding a @disable this(this) to Biggy, i.e.,
struct Biggy {
ulong[5] a;
@disable this(this);
}
produces
Dump of assembler code for function _Dmain:
...
= 0x0047fba4 +4:movabs $0x7d6a88,%rsi
0x0047fbae +14:mov$0x1b774,%ecx
0x0047fbb3 +19:pushq (%rsi)
0x0047fbb5 +21:sub$0x8,%rsi
0x0047fbb9 +25:loop 0x47fbb3 _Dmain+19
0x0047fbbb +27:movabs $0x7d6a90,%rdi
0x0047fbc5 +37:callq 0x47fb70
_D7themain5Biggy8opAssignMFNaNbNcNiNjNfS7themain5BiggyZS7themain5Biggy
0x0047fbca +42:add$0xdbba0,%rsp
which, as you can see, copies Biggy.init onto the *stack* and then calls
opAssign on it. Notice that Biggy does not define opAssign, and even if it did,
it doesn't make sense to *copy* the type's init to a temp location.
Now since Biggy is big (~400KB), and the function is run on a stack-constrained
fiber, we got a very peculiar segfault.
Is there any reason for this odd behavior? I would have used memcpy, but
Biggy.init won't compile.
-tomer (weka.io)
--
Re: Make dub part of the standard dmd distribution
On 1 Jun 2015 08:45, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) Not sure how serious/joking you are about that, but when has declaring a standard whatever like that ever worked for anything ever? ;) Linux can't even agree with Linux on where things should go, apparently that's why C on linux has pkg-config. Leave it to the distribution is the safe option in my experience. To have something along the lines of what Manu wants, I guess we need something like virtualenv to allow building in a clean/standard environment.
Re: Why aren't you using D at work?
Joakim dl...@joakim.fea.st writes: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I often wonder if others share the importance of mobile cross-compilers? I wonder that sometimes too, considering it's only two people working on them. They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds. However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki: http://wiki.dlang.org/Build_DMD_for_Android And for iOS - https://github.com/smolt/ldc-iphone-dev I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far. It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction. Would putting up a binary build help? I can do that. In meantime I have been getting ready for upcoming LDC 0.16.0 with dmd frontend 2.067. Also coming soon is support of iOS sim in addition to existing arm support. Latest Xcode 6.3.1 apparently fixed something because now D dwarf debug kind of works. Xcode crashes sometimes while navigating the stack, but way better than thumb instruction level debugging.
Re: Why aren't you using D at work?
On 2015-06-01 01:04, Danni Coy via Digitalmars-d wrote: Wouldn't this mean basically pulling all of Tango into my project and then having two copies of practically everything? Not exactly sure what you mean. The linker will only pull in the symbols you're actually using. A module in Tango, compared with Phobos, doesn't depend on the rest of the library. There are less inter-dependencies in the library. I just had a quick look. The DOM parser depends only on the pull parser. The pull parser depends on two functions and one exception. Should be trivial to replace those with the corresponding functions in Phobos if you only want to extract the XML parsing. That might be a practical solution but you can see why that doesn't feel like a good solution and still gives friction. I kind of understand that, but on the other hand, if it gets the job done what's the problem. -- /Jacob Carlborg
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 06:35:38 UTC, Nick Sabalausky wrote: On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote: Let's make this part of 2.068: https://issues.dlang.org/show_bug.cgi?id=14636 It's preapproved. Who would want to work on it? IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not certain exactly what work he had in mind for that though, versus post-1.0. DUB has worked equally well and almost unchanged for me in 2015.
Re: Entry point a la git or go
On 2015-06-01 01:11, Andrei Alexandrescu wrote: There's this recent trend seen with git and go - all tooling is entered by a single command. Are there advantages to doing the same for our toolchain? (Consider it'll include things such as dub, dfix, and dformat in the future.) Something like dc, a program that parses the command line and dispatches it to the appropriate tool(s). How would this add value to our toolchain? I like the idea. Currently there are a couple flags that are kind of namespaced example: -D generate documentation -Dddocdir write documentation file to docdir directory -Dffilenamewrite documentation file to filename I have thought of moving the doc generating to a separate tool/executable, to allow better names for these flags and avoid cluttering the compiler with flags. But making it into an action/command on the compiler instead would be even better. -- /Jacob Carlborg
Re: Make dub part of the standard dmd distribution
On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 Jun 2015 08:45, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) Not sure how serious/joking you are about that, but when has declaring a standard whatever like that ever worked for anything ever? ;) Linux can't even agree with Linux on where things should go, apparently that's why C on linux has pkg-config. Leave it to the distribution is the safe option in my experience. To have something along the lines of what Manu wants, I guess we need something like virtualenv to allow building in a clean/standard environment. Yeah, I think I can see 2 parallel problems here. 1. There is a lib installed from a -dev package managed by the distribution... I just want the complementary .d files. (this is what I actually care about) 2. There is some open-source D code which isn't distributed as a binary, it's just a git repo and you fetch it and build it locally. (I find that I rarely need this, so I don't have much opinion on this case) For case 1, my preference would be a distro managed package alongside the lib itself, and installed into a standard location. If dub could pull the bindings I want and put them in some common location, fine. For case 2... I dunno. What if you offer a lib that falls into case 2; source is available, user can fetch and build against it locally, but it contains C code too? dub isn't exactly a build system which can express a complex build environment. I can't create a dub package for my engine, which might be of interest to D gamedevs.
Re: Make dub part of the standard dmd distribution
On 1 Jun 2015 07:57, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote: On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. I thought it does that. If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker. Andrei dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions. Yeah, but regardless, that's what I want. I don't have version hell with C libs distributed this way...? Is this a problem that people are specifically trying to avoid? That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them. I get it, it sounds great... if your app suits the model. I have no D-only projects, all my programs combine many languages and ecosystems. There are also existing build systems that are well established that I prefer to use, integrate with IDE's, etc. I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically. Just to be clear, libs are source libraries, right? dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. Point is, I don't have to do this with C. I just install the dev package, once, and I'm done. Package manager distributes updates automatically, everything it exactly how I want it. It's just not a wheel I have any interest in reinventing. This is a feature of your distribution, and not the language itself. I'm having talks with the Debian toolchain maintainer, we want to start shipping D programs and libraries with Debian/Ubuntu. Binary libraries are going to be the most interesting problem here because dmd and ldc will be shut out from using them. This is a semi call-out to the ldc devs, we should really align our ABIs together.
Output Range 'put' documentation
There's a tip at the end of the put documentation[1] that reads: put should not be used UFCS-style, e.g. r.put(e). Doing this may call R.put directly, by-passing any transformation feature provided by Range.put. put(r, e) is prefered. Yet every snippet in the section uses the r.put(e) form. For a PR, which is preferred: remove the tip or change the snippets? If the latter, I think the tip should be clarified a bit. It's not quite clear what the issue is. [1] http://dlang.org/phobos/std_range_primitives.html#.put
Re: Output Range 'put' documentation
On Monday, 1 June 2015 at 07:08:31 UTC, Mike Parker wrote: There's a tip at the end of the put documentation[1] that reads: put should not be used UFCS-style, e.g. r.put(e). Doing this may call R.put directly, by-passing any transformation feature provided by Range.put. put(r, e) is prefered. Yet every snippet in the section uses the r.put(e) form. For a PR, which is preferred: remove the tip or change the snippets? If the latter, I think the tip should be clarified a bit. It's not quite clear what the issue is. [1] http://dlang.org/phobos/std_range_primitives.html#.put /s/every snippet/one snippet
Re: Make dub part of the standard dmd distribution
On 1 Jun 2015 09:09, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 Jun 2015 08:45, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) Not sure how serious/joking you are about that, but when has declaring a standard whatever like that ever worked for anything ever? ;) Linux can't even agree with Linux on where things should go, apparently that's why C on linux has pkg-config. Leave it to the distribution is the safe option in my experience. To have something along the lines of what Manu wants, I guess we need something like virtualenv to allow building in a clean/standard environment. Yeah, I think I can see 2 parallel problems here. 1. There is a lib installed from a -dev package managed by the distribution... I just want the complementary .d files. (this is what I actually care about) 2. There is some open-source D code which isn't distributed as a binary, it's just a git repo and you fetch it and build it locally. (I find that I rarely need this, so I don't have much opinion on this case) For case 1, my preference would be a distro managed package alongside the lib itself, and installed into a standard location. If dub could pull the bindings I want and put them in some common location, fine. For case 2... I dunno. What if you offer a lib that falls into case 2; source is available, user can fetch and build against it locally, but it contains C code too? dub isn't exactly a build system which can express a complex build environment. I can't create a dub package for my engine, which might be of interest to D gamedevs. In one sense this can be solved at the distribution level. If dub was provided through your package manager, the package maintainers can ensure that dub was configured to understand where all system sources are located (or will be located). Can all of dubs default settings be dumped to json and be overriden?
[Issue 14321] Unnecessary destructor call with and AA's
https://issues.dlang.org/show_bug.cgi?id=14321 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #5 from Kenji Hara k.hara...@gmail.com --- *** Issue 14595 has been marked as a duplicate of this issue. *** --
Re: Make dub part of the standard dmd distribution
dub as a build tool sux. no need to discuss that, it simply sux. why do you think it sucks ? dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own. Atila
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Monday, 1 June 2015 at 12:39:13 UTC, Dicebot wrote: On Monday, 1 June 2015 at 12:00:53 UTC, extrawurst wrote: Thanks for the chance to be there! Even if I am dissapointed with many decisions being made, the main thing is that D is getting new users and new success stories. And DConf tells those stories :) Out of curiosity, what decisions are you talking about ? I think these are most unpleasant ones for me: - Same hypocrite attitude to language/stdlib breaking changes that neither allows to fix it nor gives stability guarantees. - Going for kitchen sink Phobos (and distributing vibe.d as part of Phobos) - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea) On the other hand, AST macros have been officially rejected and that I like a lot :) To miss on this kind of grapevine when not attending dconf is the most annoying part... I whish more of the attendees would write this stuff down somewhere for us others ;) (looking at Adam and hoping for the next issue of TWID)
Re: stream == range ? [Sliding window]
On Monday, 1 June 2015 at 12:06:39 UTC, w0rp wrote: ... If you are writing code where you just want to grab large chunks of data from a socket at a time, and you don't care about the rest of the code operating on characters, you can do this. someSocket.byChunk(bufferSize).joiner.doSomething; But then many ranges will already use an internal buffer, but present a range of bytes anyway. In a lot of cases 'doSomething` conveniently needs random access to the input data. With byChunk I cannot see how you can do this without copying.
Re: stream == range ? [Sliding window]
I wonder if we even need something like popFrontN. Whenever I have wanted to read chunks at a time, like some data from a TCP socket, I have always specified a buffer size and tried to get as much data as I can fit into my buffer for each iteration. You can accomplish this with a range of chunks of data, like byChunk for a file, and then operate on the chunks instead of individual bytes. If you are writing code where you just want to grab large chunks of data from a socket at a time, and you don't care about the rest of the code operating on characters, you can do this. someSocket.byChunk(bufferSize).joiner.doSomething; But then many ranges will already use an internal buffer, but present a range of bytes anyway.
Re: Make dub part of the standard dmd distribution
Writing to something that requires root is just doing it wrong IMO, unless the user specifically opts in to it. /usr/anything is thus wrong, it should all be done locally. My preference is actually right in the current directory, do it on a per-project level. But if you must go higher, the user's home directory is also acceptable.
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 10:18:35 UTC, Jonathan M Davis wrote: On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu wrote: FYI I just created https://issues.dlang.org/show_bug.cgi?id=14638 as one of possibly several language enhancements to improve usability of noncopyable types (most allocators are not copyable) and to enhance performance of objects that define this(this). -- Andrei On a related note, as was brought up recently (by Ketmar IIRC), ranges currently forbid noncopyable objects thanks to auto h = r.front; // can get the front of the range in isInputRange. If we want to fix that, then we're probably going to need to change isInputRange so that it checks that we can access front but doesn't require copying and then add something like hasCopyableElements for the algorithms that do need to copy front. I'm not a huge fan of that idea given how much code exists which copies front and how that would likely require that a lot of range-based functions add even more checks to their template constraints, but I'm not sure what else we can reasonably do if we want noncopyable elements to work in ranges, and the change wouldn't break existing code, just make it so that much of it would need updated template constraints in order to avoid compilation errors if anyone ever tries to use a range with noncopyable elements with it. - Jonathan M Davis What about auto h = r.front; // can get the front of the range ?
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote: On Mon, 01 Jun 2015 05:05:20 +, Brad Anderson wrote: dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. now you killed dub for normal GNU/Linux programmer. dub as a build tool sux. no need to discuss that, it simply sux. why do you think it sucks ? and now you killed the only sensible way to use it: as package manager. that's why, for example, i never considered adding anything to dub repository: that repository is completely useless for me. and other people who aren't use dub to build their projects will ignore dub repository too.
Re: Chainable template mixin and opCat()
On Monday, 1 June 2015 at 11:47:43 UTC, w0rp wrote: I think my only complaint for this is that it wouldn't work for all ranges, so you'd be able to use the operator some times, I still think the simplicity of mixin Chainable; and it's effect on usability is short enough to be worth the effort :)
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 12:24:18 UTC, Atila Neves wrote: dub as a build tool sux. no need to discuss that, it simply sux. why do you think it sucks ? dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own. Atila Hi Atila, you are talking about cross language builds ? Other than that limitation, what do you miss ? I have a couple of rather sizable projects running with dub without problems and one could argue vibe.d is a pretty big project too which works fine. The D community already suffered enough from not uniting workforces behind at least SOME standards (hint at tango), a plethora of options for newcomers to choose from for basics like building is also daunting IMHO. Stephan
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Monday, 1 June 2015 at 12:44:38 UTC, extrawurst wrote: I whish more of the attendees would write this stuff down somewhere for us others ;) (looking at Adam and hoping for the next issue of TWID) I have about 600 lines of notes to finish wading through and since I'm still in Utah making the rounds of visits I'm a bit behind but you should expect it later today...
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 07:19:28 UTC, Iain Buclaw wrote: In one sense this can be solved at the distribution level. If dub was provided through your package manager, the package maintainers can ensure that dub was configured to understand where all system sources are located (or will be located). Can all of dubs default settings be dumped to json and be overriden? The way I do it right now is simply adding -I/usr/include/dlang -I/usr/include/dlang/compiler to dmd.conf / ldc.conf / patch GDC in a similar way. And surely if dub would ever attempt to write anything in /usr on its own I will simply throw it away from Arch packages.
Re: Uphill
On Monday, 1 June 2015 at 10:37:31 UTC, ketmar wrote: even PC games tend to migrate to Unity. mobile games will stop using home- made engines very soon, as porting it to each platform is simply wasting of time. so there will be old codebases which nobody will convert anyway, and new codebases that using Unity, Cocos or something like it. I don't know, it is hard to stand out if you build on Unity or Cocos unmodified. But I think web browsers are slowly moving towards a situation where you soon can make sensible games in webgl + asm.js using home-made engines using native javascript (basically javascript targetting LLVM IR) or pnacl (LLVM IR). So the distinction between native and non-native is getting blurred. Just take a look at shadertoy and see what people can do in GL shaders that work on the web. And shaders are written to the current hardware if they are to perform well (so native). Realtime javascript programming + WebGL quality is going to become more important than native binaries for games if the payment model issues find a solution. I'd say the payment model that the app-stores provide are more important than distributing native code. A web-based game has a distinct significant marketing advantage. Click on a web ad and instantly find yourself in a game world (free trial). Anything that takes installation is at a disadvantage. Unfortunately, anything that requires entering credit card info is at a disadvantage too... so generating native code for mobile platforms target can be ignored, it's investement that will take alot of time and efforts with very little benefit. I think the focus will shift from generating native code for specific hardware to generating code that effectively translates to native code for specific hardware. Which roughly is the same deal. (Most games are scripty, yes, paper doll, cartoony 2D etc…)
[Issue 14351] [REG2.063] `inout` base class constructor can't be called
https://issues.dlang.org/show_bug.cgi?id=14351 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4705 --
Re: Chainable template mixin and opCat()
On Monday, 1 June 2015 at 11:20:52 UTC, Per Nordlöw wrote:
template Chainable() {
Chain!(typeof(this), Range) opCat(Range)(Range r) {
return chain(this, r);
}
}
Would it suffice to restrict `opCat` as
Chain!(typeof(this), Range) opCat(Range)(Range r)
if (isInputRange!Range is(CommonElementType!(typeof(this),
Range)))
?
given that
template CommonElementType(Rs...)
{
alias CommonElementType = CommonType!(staticMap!(ElementType,
Rs));
}
In general, should we let `Chain` do the error checking or should
we copy its retrictions into `opCat`s restrictions?
Re: Chainable template mixin and opCat()
I think my only complaint for this is that it wouldn't work for all ranges, so you'd be able to use the operator some times, but not others. This is because you have to define the operators inside of the structs or classes, and you can't write operators as free functions. (Which is a good feature in general.)
[Issue 14595] [REG2.066] RefCounted data corrupted when in an AA
https://issues.dlang.org/show_bug.cgi?id=14595 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Hardware|x86_64 |All Resolution|--- |DUPLICATE OS|Linux |All --- Comment #4 from Kenji Hara k.hara...@gmail.com --- The root problem is same with issue 14321, and it's already fixed in git-head (2.068a). *** This issue has been marked as a duplicate of issue 14321 *** --
Re: Why aren't you using D at work?
I'll add in my story. My job is working as part of a team on a small-to-medium scale web application. Our application layer is implemented in Python and Django. This would be the place where D would fit in the most. So I think this comes down to an argument of why we would choose to use Python and Django instead of D and vibe.d. I can think of the following reasons. 1. Obviously, we have already written everything in Python, so we would have to justify the cost of moving to D quite strongly. 2. Django offers more features useful for developing a web application than vibe.d, like an excellent API for building SQL queries with an ORM. The South or first party migrations (ALTER TABLE, etc.) APIs in 1.7 are brilliant, and after you use them, you can't live without them. These APIs work well and save time. 3. Python has greater mind share, so switching to D would incur the cost of training everyone to use D. It's hard enough finding a decent Python programmer. 4. The third party libraries implement many things we need to use, like SSO support. 5. We use Celery a lot for task management, so to use D we would need similar software D could work with. 6. I must mention that the execution model makes the sites easier to develop. When you change a function and save the file, Django reloads the module, (when it doesn't break) so you can test the effects of your modification instantly. I can't compare on testing web pages in Django against vibe.d, as I've never tried it on vibe.d. I will add that Django allows you to send fake HTTP requests to your 'views' for web pages, so you can write automated tests for the pages on your site. This level of testing does wonders for code quality, and catches website regressions quickly. I hope that in the future some clever person could implement an API for generating SQL queries in an RDBMS indepent way for D, with support for creating ALTER TABLE statements automatically. I've thought about it, and it wouldn't even necessarily need to be ORM, as something like the data mapper pattern could work. Just something which lets you build queries for objects you can serialise, and generate queries needed to update the tables for the objects when you change them.
Re: Uphill
On Mon, 01 Jun 2015 13:38:28 +1000, Manu via Digitalmars-d wrote: On 1 June 2015 at 10:56, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 31 May 2015 09:08:27 +, Joakim wrote: Most mobile games are written in C/C++/OpenGL that will fade away soon. it's safe to ignore that in long-time plan. How so? Game dev's aren't moving away from native code any time soon... even PC games tend to migrate to Unity. mobile games will stop using home- made engines very soon, as porting it to each platform is simply wasting of time. so there will be old codebases which nobody will convert anyway, and new codebases that using Unity, Cocos or something like it. so generating native code for mobile platforms target can be ignored, it's investement that will take alot of time and efforts with very little benefit. signature.asc Description: PGP signature
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 07:42:02 UTC, Iain Buclaw wrote: Our druntimes need to be aligned up. The first thing you'd notice is that each may give undefined references to things the other compiler does not include in it's runtime. Unifying GDC/LDC ABI would simplify packager life a lot.
Chainable template mixin and opCat()
I just stumbled upon the following very interested idea:
http://forum.dlang.org/thread/bug-604...@http.d.puremagic.com%2Fissues%2F
1. Add the following (where?)
template Chainable() {
Chain!(typeof(this), Range) opCat(Range)(Range r) {
return chain(this, r);
}
}
2. Then in the body of a lazy range both Phobos ones like map,
filter, zip, iota, and so on, and user-defined ones, you may add:
mixin Chainable;
This allows to write more natural and readable code like:
iota(5) ~ filter!q{a}([1,0,3])
map!abs([1,2,-5]) ~ [10, 20]
instead of more noisy:
chain(iota(5), filter!q{a}([1,0,3]))
chain(map!abs([1,2,-5]), [10, 20])
See also bug 5638 for a useful optimization.
I'd be glad to work on Phobos PR for this :)
[Issue 14556] [REG2.067] can't instantiate struct that has constructor and static array of enum
https://issues.dlang.org/show_bug.cgi?id=14556 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All OS|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4706 --
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Monday, 1 June 2015 at 12:00:53 UTC, extrawurst wrote: Thanks for the chance to be there! Even if I am dissapointed with many decisions being made, the main thing is that D is getting new users and new success stories. And DConf tells those stories :) Out of curiosity, what decisions are you talking about ? I think these are most unpleasant ones for me: - Same hypocrite attitude to language/stdlib breaking changes that neither allows to fix it nor gives stability guarantees. - Going for kitchen sink Phobos (and distributing vibe.d as part of Phobos) - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea) On the other hand, AST macros have been officially rejected and that I like a lot :)
Re: Chainable template mixin and opCat()
On Monday, 1 June 2015 at 12:13:51 UTC, Per Nordlöw wrote: I still think the simplicity of mixin Chainable; and it's effect on usability is short enough to be worth the effort :) https://github.com/D-Programming-Language/phobos/pull/3353 Destroy!
Working on new binary serialization module for phobos (hopefully)
I've been working on a new serialization module for Phobos and its only reliant on 4 Phobos modules it is available at https://github.com/sycam0inc/phobos/blob/master/std/experimental/serialization.d I would like some feedback on it
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu wrote:
FYI I just created
https://issues.dlang.org/show_bug.cgi?id=14638 as one of
possibly several language enhancements to improve usability of
noncopyable types (most allocators are not copyable) and to
enhance performance of objects that define this(this). -- Andrei
What do static use and dynamic use mean here?
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible, or
by remembering whether an object was moved using a hidden
boolean variable. AFAIK the latter is incidentally the solution
Rust chose.
Re: Why aren't you using D at work?
On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d digitalmars-d@puremagic.com wrote: Joakim dl...@joakim.fea.st writes: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: I often wonder if others share the importance of mobile cross-compilers? I wonder that sometimes too, considering it's only two people working on them. They seem to be getting lots of love recently, which is very exciting! I'd like to encourage those working on the Android/iOS toolchains to publish regular binary builds of the toolchains so we with little allocated working time can grab the latest toolchains and try our stuff from time to time. I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds. However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki: http://wiki.dlang.org/Build_DMD_for_Android And for iOS - https://github.com/smolt/ldc-iphone-dev I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far. It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction. Would putting up a binary build help? I can do that. Yes. I basically won't look at anything without a binary build. Call me whatever you like; I am a completely typical Windows developer in this way. If there is no binary, the thought that I should build it myself doesn't cross my mind ;) It would be nice if it were easy to find; present among the other LDC downloads? Possible to work iOS toolchain build into the existing LDC CI solution? I think all these missing cross-compilers need to find themselves into regular build cycles, and maintained alongside the existing releases. Much easier to take them seriously in that context, and gives better visibility; it feels like these efforts are somewhat fragmented until recently. Having toolchain alpha-releases available, even without libraries in working order, makes the bar much lower for people to get in and start hacking on the libraries.
Re: Uphill
On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote: While C++ programmers should try and avoid the preprocessor as much as possible, sometimes it just isn't possible to do so. There's just no other way to generate code sometimes. I know, I've tried. In what case is this true? If it is only to avoid some boiler plate then it is not a good excuse, IMO. You can usually avoid macros by restructuring composition (using multiple layers of templates). I'll take a macro over boilerplate any day of the week and twice on Sundays. Atila
Re: Is there any plans to include vibed in dmd distrib?
On Monday, 1 June 2015 at 04:45:34 UTC, suliman wrote: Subj I think it important step in creation D infrastructure. Also vibed and dmd have simmilar API that are overlaps. For example std.json. Is there any plans to merge them. Many people prefer use vibed's realization. Yes to both: http://wiki.dlang.org/Vision/2015H1 http://forum.dlang.org/thread/mg113r$2nhb$1...@digitalmars.com They're slowly working their way to realization, depending on Ludwig's spare time.
Re: Make dub part of the standard dmd distribution
On Mon, 01 Jun 2015 05:05:20 +, Brad Anderson wrote: dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. now you killed dub for normal GNU/Linux programmer. dub as a build tool sux. no need to discuss that, it simply sux. and now you killed the only sensible way to use it: as package manager. that's why, for example, i never considered adding anything to dub repository: that repository is completely useless for me. and other people who aren't use dub to build their projects will ignore dub repository too. signature.asc Description: PGP signature
Re: Make dub part of the standard dmd distribution
On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 Jun 2015 07:57, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote: On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. I thought it does that. If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker. Andrei dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions. Yeah, but regardless, that's what I want. I don't have version hell with C libs distributed this way...? Is this a problem that people are specifically trying to avoid? That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them. I get it, it sounds great... if your app suits the model. I have no D-only projects, all my programs combine many languages and ecosystems. There are also existing build systems that are well established that I prefer to use, integrate with IDE's, etc. I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically. Just to be clear, libs are source libraries, right? Well, it should support libs that aren't JUST source. Binary libs needs some .d files to declare the API and all that, so at least some source would always present. A lib on its own us no use :) But any solution needs to support closed-source libraries too. Not everything can be conveniently distributed as full-source, and many libs are bindings against binary C libs which would probably be sourced externally. dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. Point is, I don't have to do this with C. I just install the dev package, once, and I'm done. Package manager distributes updates automatically, everything it exactly how I want it. It's just not a wheel I have any interest in reinventing. This is a feature of your distribution, and not the language itself. I'm having talks with the Debian toolchain maintainer, we want to start shipping D programs and libraries with Debian/Ubuntu. Do want! :) Binary libraries are going to be the most interesting problem here because dmd and ldc will be shut out from using them. ? Why is? This is a semi call-out to the ldc devs, we should really align our ABIs together. Oh, are the LDC/GDC ABI's not consistent on linux? Surely many/most libs are just references to C '-dev' packages as dependencies?
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu wrote: FYI I just created https://issues.dlang.org/show_bug.cgi?id=14638 as one of possibly several language enhancements to improve usability of noncopyable types (most allocators are not copyable) and to enhance performance of objects that define this(this). -- Andrei On a related note, as was brought up recently (by Ketmar IIRC), ranges currently forbid noncopyable objects thanks to auto h = r.front; // can get the front of the range in isInputRange. If we want to fix that, then we're probably going to need to change isInputRange so that it checks that we can access front but doesn't require copying and then add something like hasCopyableElements for the algorithms that do need to copy front. I'm not a huge fan of that idea given how much code exists which copies front and how that would likely require that a lot of range-based functions add even more checks to their template constraints, but I'm not sure what else we can reasonably do if we want noncopyable elements to work in ranges, and the change wouldn't break existing code, just make it so that much of it would need updated template constraints in order to avoid compilation errors if anyone ever tries to use a range with noncopyable elements with it. - Jonathan M Davis
Re: Output Range 'put' documentation
On Monday, 1 June 2015 at 07:12:24 UTC, Mike Parker wrote: On Monday, 1 June 2015 at 07:08:31 UTC, Mike Parker wrote: There's a tip at the end of the put documentation[1] that reads: put should not be used UFCS-style, e.g. r.put(e). Doing this may call R.put directly, by-passing any transformation feature provided by Range.put. put(r, e) is prefered. Yet every snippet in the section uses the r.put(e) form. For a PR, which is preferred: remove the tip or change the snippets? If the latter, I think the tip should be clarified a bit. It's not quite clear what the issue is. [1] http://dlang.org/phobos/std_range_primitives.html#.put /s/every snippet/one snippet OK, ignore this post. I see now what I missed.
Re: stream == range ? [Sliding window]
On 01-Jun-2015 02:54, Dragos Carp wrote:
Hardly. In fact, I've spent quite some time trying to figure this out.
2. As it stands it would require first copying into appender which is
slow. The opposite direction is usually a better match - assume
appender (or rather buffer) is filled to its capacity with data from
the file and keeping this invariant true.
This would function differently if the data comes over the socket,
usually you cannot fill the buffer.
Agreed, with sockets it's not going to work like that.
Otherwise it looks quite similar to the sliding window interface and
that is great.
data -- window
popFrontN -- skip
put ~~ extend (probably should be just called 'more')
Sometimes (socket recv) you don't know how much extend.
That's still OK, if extend is try to load at least this much. That is
it attempts a read of max(capacity_left, bytes_to_extend) and adjusts
the visible window.
[snip]
Parser or any other component down the line shouldn't concern itself
with reading, just using some more primitive to auto-magically
extend the window by at least X bytes. That would shrink-extend
buffer and load it behind the scenes.
As I sad, LinearBuffer is meant to be used behind the scenes.
Okay, then we are on the same page.
I think we need to define a set of primitives and semantics that define
a buffer concept, it's seems that 3 primitives outlined is enough
plus/minus some traits.
I find Andrei's bulkRead, maybe combined with a matcher a la boost::asio
read_until, the simplest high level interface.
For unbuffered streams - read_until is probably too much, a bulkRead
would be the minimum.
For buffered streams - should be easily defined as stand-alone:
bool readUntil(alias matcher, BufStream)(BufStream buf){
for(;;){
auto pos = matcher(buf.window);
if(pos 0)
buf.skip(buf.window.length);
if(!buf.more()) return false;
}
else{
buf.skip(pos);
return true;
}
}
}
--
Dmitry Olshansky
Re: Why aren't you using D at work?
Chris wend...@tcd.ie writes: 2. [high priority] Uncertainty regarding ARM (iOS/Android). Deal breaker, show stopper. Was worrying a few years ago, but is just bad now in 2015. It is a little better now :-) Maybe you can help Chris. I don't develop for mobile so I don't know that dev environment and what is needed for D to be useful in that world. So far for iOS we have armv7 support, all of phobos except libcurl. What isn't there yet is iOS sim support (coming soon), arm64 support, and nice Xcode integration. I though it might help if I added a demo app based on Allegro 5. https://github.com/smolt/ldc-iphone-dev There is a list of TODOs at the bottom of the project readme. Want to add anything? Also, issues can be filed, pull requests. -- Dan
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote: DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago. We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic. We'll be back with details. See you there! Andrei Good news!! So I am *definitely* coming to DConf 2016!! :)
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On 1 Jun 2015 10:10, Dejan Lekic via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote: DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago. We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic. We'll be back with details. See you there! Andrei Good news!! So I am *definitely* coming to DConf 2016!! :) About time!
Re: dmd makes D appear slow
On 1 Jun 2015 09:25, Shachar Shemesh via Digitalmars-d digitalmars-d@puremagic.com wrote: On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote: Got any bug reports to back that up? I should probably run the testsuite with optimisations turned on sometime. The latest one (the one that stung my code) is http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs opened by Liran are usually around that area, as he's the one who does the porting of our code to GDC. Shachar OK thanks, I'll try to mentally couple you two together. I'm aware of the bugs Liran has made. There's just some 'very big things' going on which has me away from bug fixing currently.
Re: Make dub part of the standard dmd distribution
On 1 June 2015 at 09:37, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 Jun 2015 07:57, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote: On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. I thought it does that. If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker. Andrei dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions. Yeah, but regardless, that's what I want. I don't have version hell with C libs distributed this way...? Is this a problem that people are specifically trying to avoid? That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries. Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :) With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them. I get it, it sounds great... if your app suits the model. I have no D-only projects, all my programs combine many languages and ecosystems. There are also existing build systems that are well established that I prefer to use, integrate with IDE's, etc. I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically. Just to be clear, libs are source libraries, right? Well, it should support libs that aren't JUST source. Binary libs needs some .d files to declare the API and all that, so at least some source would always present. A lib on its own us no use :) But any solution needs to support closed-source libraries too. Not everything can be conveniently distributed as full-source, and many libs are bindings against binary C libs which would probably be sourced externally. dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system. Point is, I don't have to do this with C. I just install the dev package, once, and I'm done. Package manager distributes updates automatically, everything it exactly how I want it. It's just not a wheel I have any interest in reinventing. This is a feature of your distribution, and not the language itself. I'm having talks with the Debian toolchain maintainer, we want to start shipping D programs and libraries with Debian/Ubuntu. Do want! :) Binary libraries are going to be the most interesting problem here because dmd and ldc will be shut out from using them. ? Why is? This is a semi call-out to the ldc devs, we should really align our ABIs together. Oh, are the LDC/GDC ABI's not consistent on linux? Surely many/most libs are just references to C '-dev' packages as dependencies? Our druntimes need to be aligned up. The first thing you'd notice is that each may give undefined references to things the other compiler does not include in it's runtime.
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #23 from Jonathan M Davis issues.dl...@jmdavisprog.com --- The druntime changes have been pulled, but the Phobos changes - which is what the request is actually for - haven't been pulled yet. I have to finish updating the PR for them based on the druntime changes. --
Re: DMD Symbol Reference Analysis Pass
On Monday, 1 June 2015 at 03:49:39 UTC, Andrei Alexandrescu wrote: Destroyed. -- Andrei Thx
Re: dmd makes D appear slow
On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote: Got any bug reports to back that up? I should probably run the testsuite with optimisations turned on sometime. The latest one (the one that stung my code) is http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs opened by Liran are usually around that area, as he's the one who does the porting of our code to GDC. Shachar
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 02:08:30 UTC, Rikki Cattermole wrote: On 31/05/2015 3:08 a.m., Adam D. Ruppe wrote: On Saturday, 30 May 2015 at 13:35:47 UTC, Rikki Cattermole wrote: What about window creation? Well Devisualization.Window (author) but what would about integration into OSX's menu or Windows notification area? Again you've got a problem. My simpledisplay.d can do the Windows notification area. But there's a lot more that needs to get done that I haven't gotten around to yet. If I can ever quit my day job, I'll start going nuts on this again :) I sorta excluded your work on purpose. Even though it is damn good work! Should any of these be on http://wiki.dlang.org/List_of_Libraries_and_Frameworks?
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On Friday, 29 May 2015 at 23:42:00 UTC, Andrei Alexandrescu wrote: DConf 2015 has been awesome, I'm taking a minute to post this that's been announced a short while ago. We're pleased to announce that DConf 2016 will take place in Berlin, sponsored by Sociomantic. We'll be back with details. See you there! Andrei Thanks for the chance to be there! Even if I am dissapointed with many decisions being made, the main thing is that D is getting new users and new success stories. And DConf tells those stories :)
Re: Working on new binary serialization module for phobos (hopefully)
On Monday, 1 June 2015 at 12:52:45 UTC, Sean Campbell wrote: I've been working on a new serialization module for Phobos and its only reliant on 4 Phobos modules it is available at https://github.com/sycam0inc/phobos/blob/master/std/experimental/serialization.d I would like some feedback on it I'm biased since I wrote this: https://github.com/atilaneves/cerealed. At a glance, I don't like at all that types have to opt-in to be serialised. Why the limitation? You don't need reverseOf, just use std.range.retro. Cerealed has more features than this as well. I'd struggle to write code as short as I did when using it to implement networking protocols. I also only encoded bytes as big-endian since binary serialization is usually followed by sending those bytes over the wire. Given you check the endianess of the system here, how would that work? I liked the union trick, I wonder why I didn't think of that. Well, there's the endianness problem I guess. Atila
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
On 6/1/15 11:40 AM, Dan Olson wrote: Dicebot pub...@dicebot.lv writes: - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea) I am interesting in this one. What was the decision, that Fibers should or should not be allowed to migrate between threads? Is the discussion in one of the recorded talks? Walter said that fibers must be movable between threads, it was part of the AMA I think (day 1 final talk). I will note to those reading this thread, the absolute most phenomenal part of attending the d conference is the live discussion that happens between talks, and afterwards over drinks/dinner. The live streams and recorded talks are no substitute. Just a nudge for anyone who is on the fence for next year :) I hope I can go next year, need to get that passport in order... -Steve
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 15:45:11 UTC, Andrei Alexandrescu wrote:
On 6/1/15 5:50 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu
wrote:
FYI I just created
https://issues.dlang.org/show_bug.cgi?id=14638 as
one of possibly several language enhancements to improve
usability of
noncopyable types (most allocators are not copyable) and to
enhance
performance of objects that define this(this). -- Andrei
What do static use and dynamic use mean here?
static = as you read the code
dynamic = as you run the code
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by
remembering whether an object was moved using a hidden
boolean
variable. AFAIK the latter is incidentally the solution Rust
chose.
This has been solved, we have move which obliterates the source
with .init.
Huh? What does that have to do with the current topic?
The question is not what should happen when someone does a
conditional _explicit_ move, but whether a move should be done
_implicitly_ by the compiler given the above constellation, and
how it deals with the destructor if yes.
Re: Uphill
On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote: Atila Neves atila.ne...@gmail.com writes: On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote: While C++ programmers should try and avoid the preprocessor as much as possible, sometimes it just isn't possible to do so. There's just no other way to generate code sometimes. I know, I've tried. In what case is this true? If it is only to avoid some boiler plate then it is not a good excuse, IMO. You can usually avoid macros by restructuring composition (using multiple layers of templates). I'll take a macro over boilerplate any day of the week and twice on Sundays. Timely! I and stack overflow struggled for a couple hours to find an equivalent C++ template for something that was straightforward with a couple macros. I use macros for stuff like exceptions all the time - e.g. THROW(MyException, (This value is wrong: %d, foo)); The macro handles logging the exception, getting and setting the stacktrace on the exception, setting the file and line number of the exception, as well as constructing the string for the exception's message given the arguments - and of course finally throwing it. You _are_ still forced to call format in D (whereas that macro does it for you), but aside from that, the built-in exception stuff does all of that for you by simply throwing a new exception with a message, whereas C++ doesn't even come close. Without a macro, getting all of the information in C++ - and doing it consistently and correctly - would be a big problem. Yes, macros should be avoided in general, but there are areas where you really don't have much choice, and saying that all macros are unequivocably bad is quite short-sighted. It's when macros are used when they aren't needed that it's a problem. Coming out of college, I actually believed the dogma that all macros are bad, but experience has shown me that that's just not true. Sure, it would be nice if we had a better solution in C++, but sometimes we just don't. - Jonathan M Davis
Re: Uphill
On Monday, 1 June 2015 at 16:09:34 UTC, Dan Olson wrote: Timely! I and stack overflow struggled for a couple hours to find an equivalent C++ template for something that was straightforward with a couple macros. …but without an example it is hard to figure out what macros are needed for.
[Issue 14351] [REG2.063] `inout` base class constructor can't be called
https://issues.dlang.org/show_bug.cgi?id=14351 --- Comment #4 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/e4fd82893f9b2f7ff1bc1580ea5553a2752be9df fix Issue 14351 - `inout` base class constructor can't be called https://github.com/D-Programming-Language/dmd/commit/e801243f6e20fc7dd8a24100433878662e906b17 Merge pull request #4705 from 9rnsr/fix14351 [REG2.063] Issue 14351 - `inout` base class constructor can't be called --
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 16:40:38 UTC, Marc Schütz wrote:
On Monday, 1 June 2015 at 15:45:11 UTC, Andrei Alexandrescu
wrote:
On 6/1/15 5:50 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu
wrote:
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by
remembering whether an object was moved using a hidden
boolean
variable. AFAIK the latter is incidentally the solution Rust
chose.
This has been solved, we have move which obliterates the
source with .init.
Huh? What does that have to do with the current topic?
The question is not what should happen when someone does a
conditional _explicit_ move, but whether a move should be done
_implicitly_ by the compiler given the above constellation, and
how it deals with the destructor if yes.
Obviously, only Andrei can say for sure what he meant, but I
would guess that he was suggesting that in the case of
if(condition)
bar(s);
it would set s to S.init when it's moved for the call to bar so
that the destructor can be run when s exits scope regardless of
which branch was executed - though that does mean that the
destructor is run twice when bar(s) is called (once inside of Bar
for the original value and once for the init value) - so while
that solution is correct and straightforward, I'm not sure that
it's the best one.
- Jonathan M Davis
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 15:25:13 UTC, Wyatt wrote: On Monday, 1 June 2015 at 11:14:43 UTC, Dicebot wrote: The way I do it right now is simply adding -I/usr/include/dlang -I/usr/include/dlang/compiler to dmd.conf / ldc.conf / patch GDC in a similar way. And surely if dub would ever attempt to write anything in /usr on its own I will simply throw it away from Arch packages. This whole conversation reminds me a lot of the perl ecosystem. How does Arch deal with CPAN? -Wyatt Same as pip and gems and all similar kind of crap. Bad. That is why I don't use them. Though it is hard to invent a package management for interpreted language that is not insane. It is much better with native ones because runtime dependencies are separated from development dependencies.
Re: Allow deprecated to accept more than string literals while parsing
On 5/31/15 11:33 PM, Brian Schott wrote: Here's something that I ran into while writing dfix`s implicit string concatenation cleanup code: ``` // accepted deprecated(This function is dumb and you shouldn't use it) void deleteT3hH4rdDisk(); // accepted deprecated(This function is dumb and you shouldn't use it) void deleteT3hH4rdDisk(); // parse error deprecated(This function is dumb and ~ you shouldn't use it) void deleteT3hH4rdDisk(); ``` Am I missing something, or is the trailing quote not required? (missing in all 3 examples). -Steve
Re: Make dub part of the standard dmd distribution
On 5/31/15 7:01 PM, Andrei Alexandrescu wrote: Let's make this part of 2.068: https://issues.dlang.org/show_bug.cgi?id=14636 It's preapproved. Who would want to work on it? Just a reminder to everyone that at one point, we wanted the compiler to do kind of what 'dub' does -- fetch packages as dependencies for a project. Remember this DIP? http://wiki.dlang.org/DIP11 The problem I have with dub is it makes you as a consumer of libraries live within its realm. You have to make a dub file to use it, and that's not a small burden. That being said, can we get a tool that does what DIP11 asked for by using dub? We do have quite a large repository of code that's dub-enabled, and I have no problem requiring extra steps for *libraries* to make them usable with this system. Basically, a builder that says hey, if dmd (or whatever) cannot find an import, see if dub can do it, and then use dub to download the package. -Steve
Re: Make dub part of the standard dmd distribution
Since this thread seems to have turned into a wishlist for dub features, I'm going to add one: Undeprecate dependencies on git branches. They are really not different from dependencies with fuzzy ~ versions. For both, the exact selected version can be stored in dub.selections.json. Use case: Making a fix to a third-party project and sharing that fix with other team members. Having to create a temporary project on code.dlang.org just for that purpose is both a waste of time for developers and a waste of resources of community infrastructure.
Re: Better handling of noncopyable objects and objects with this(this)
On 6/1/15 5:50 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu wrote:
FYI I just created https://issues.dlang.org/show_bug.cgi?id=14638 as
one of possibly several language enhancements to improve usability of
noncopyable types (most allocators are not copyable) and to enhance
performance of objects that define this(this). -- Andrei
What do static use and dynamic use mean here?
static = as you read the code
dynamic = as you run the code
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible, or by
remembering whether an object was moved using a hidden boolean
variable. AFAIK the latter is incidentally the solution Rust chose.
This has been solved, we have move which obliterates the source with .init.
Andrei
Re: Uphill
Atila Neves atila.ne...@gmail.com writes: On Sunday, 31 May 2015 at 09:13:33 UTC, Ola Fosheim Grøstad wrote: On Sunday, 31 May 2015 at 08:51:00 UTC, Atila Neves wrote: While C++ programmers should try and avoid the preprocessor as much as possible, sometimes it just isn't possible to do so. There's just no other way to generate code sometimes. I know, I've tried. In what case is this true? If it is only to avoid some boiler plate then it is not a good excuse, IMO. You can usually avoid macros by restructuring composition (using multiple layers of templates). I'll take a macro over boilerplate any day of the week and twice on Sundays. Timely! I and stack overflow struggled for a couple hours to find an equivalent C++ template for something that was straightforward with a couple macros.
Re: Chainable template mixin and opCat()
On 06/01/2015 01:47 PM, w0rp wrote: you can't write operators as free functions. (Which is a good feature in general.) No, it is a pointless non-uniformity in function call syntax.
Re: dmd makes D appear slow
On 5/30/15 2:38 PM, Shachar Shemesh wrote: On 30/05/15 03:57, Steven Schveighoffer wrote: But I don't see how speed of compiler should sacrifice runtime performance. Our plan was to compile with DMD during the development stage, and then switch to GDC for code intended for deployment. This plan simply cannot work if each time we try and make that switch, Liran has to spend two months, each time yanking a different developer from the work said developer needs to be doing, in order to figure out which line of source gets compiled incorrectly. You're answering a question that was not asked. Obviously, compiler-generated code should match what the source says. That's way more important than speed of compilation or speed of execution. So given that a compiler actually *works* (i.e. produces valid binaries), is speed of compilation better than speed of execution of the resulting binary? How much is too much? And there are thresholds for things that really make the difference between works and not works. For instance, a requirement for 30GB of memory is not feasible for most systems. If you have to have 30GB of memory to compile, then the effective result is that compiler doesn't work. Similarly, if a compiler takes 2 weeks to output a binary, even if it's the fastest binary on the planet, that compiler doesn't work. But if we are talking the difference between a compiler taking 10 minutes to produce a binary that is 20% faster than a compiler that takes 1 minute, what is the threshold of pain you are willing to accept? My preference is for the 10 minute compile time to get the fastest binary. If it's possible to switch the compiler into fast mode that gives me a slower binary, I might use that for development. My original statement was obviously exaggerated, I would not put up with days-long compile times, I'd find another way to do development. But compile time is not as important to me as it is to others. -Steve
[Issue 14638] The last (in lexical order) copy of an object must be a move
https://issues.dlang.org/show_bug.cgi?id=14638 --- Comment #4 from Andrei Alexandrescu and...@erdani.com --- (In reply to Jonathan M Davis from comment #3) However, I don't understand what you mean by dynamic and static uses. Is a dynamic use one that may or may not be the last one hit depending on what occurs after it, whereas a static use is guaranteed to be the last use if it's hit? Static is as you read the code in lexical order, dynamic is as it actually gets executed. --
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 11:14:43 UTC, Dicebot wrote: The way I do it right now is simply adding -I/usr/include/dlang -I/usr/include/dlang/compiler to dmd.conf / ldc.conf / patch GDC in a similar way. And surely if dub would ever attempt to write anything in /usr on its own I will simply throw it away from Arch packages. This whole conversation reminds me a lot of the perl ecosystem. How does Arch deal with CPAN? -Wyatt
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 14:59:38 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 14:43:22 UTC, Marc Schütz wrote:
On Monday, 1 June 2015 at 14:20:46 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 12:50:28 UTC, Marc Schütz wrote:
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by remembering whether an object was moved using a
hidden boolean variable. AFAIK the latter is incidentally
the solution Rust chose.
Wouldn't the compiler just do something like
if(condition)
{
bar(s); // Do a move; the destructor is run inside bar
return;
}
else
{
s.__dtor();
return;
}
In which case, the destructor is always run in the right
spot, and the compiler can guarantee that a move is done
rather than a copy?
When this can be done, it's of course a good solution. But
when there is additional code between the move and the
destruction, it usually doesn't work:
void foo() {
S s;
if(condition)
bar(s);
baz();
// - should we run the destructor here?
}
Then, like you suggested, that would indeed appear to require
either an invisible bool that indicates whether a move was done
or not or disallowing the move. I think that I'd favor the
bool, since moving is likely to save more than the extra bool
is going to cost.
Yes, and I think an optimizer can even eliminate the cost in some
cases, e.g. do the rewrite you suggested.
For reference, here are some discussions the Rust community had
about this topic (didn't read them completely):
https://github.com/rust-lang/rfcs/pull/320
https://github.com/rust-lang/rfcs/blob/master/text/0320-nonzeroing-dynamic-drop.md
https://github.com/pnkfelix/rfcs/blob/a773ba113ba135ddb7f481c4829882733eaa5355/active/-remove-drop-flag-and-zeroing.md#require-explicit-drops-rather-than-injecting-them
Some of the suggested solutions are not applicable for us,
because we don't have to deal with explicit moves like they do.
But we can certainly learn from their discussions.
Re: Better handling of noncopyable objects and objects with this(this)
There is another solution that doesn't require a hidden variable,
at the cost of duplicating generated code:
void foo() {
S s;
if(cond)
bar(s);
some();
more();
code();
}
Can be rewritten as:
void foo() {
S s;
if(cond) {
bar(s);
some();
more();
code();
// don't destroy here
} else {
some();
more();
code();
s.~this(); // destroy here
}
}
But I think this is best left to an optimizer which has more info
about the costs of the additional code vs the hidden var to
decide whether its worth it.
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
Dicebot pub...@dicebot.lv writes: - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea) I am interesting in this one. What was the decision, that Fibers should or should not be allowed to migrate between threads? Is the discussion in one of the recorded talks?
resource structs and default constuction
I have a struct that uses RefCounted internally to manage a
database environment.It’s basically in the same boat as
RefCounted itself in that it requires runtime construction. Two
things set it apart:
1) No-arg construction is required
2) The potential prevalence of this type in application code and
getting default initialized by mistake.
This issue has been discussed before (see link below). It would
be nice if this could be addressed in the language at some point,
but as far as I can tell, the best option I have now is to put
version(assert) checks in all of my member functions to check for
proper construction.
For the default construction issue, a factory function was
suggested as an option. I came up with the following approach:
struct Database {
static Database create() {
return Database();
}
static Database create(A...)(auto ref A args) {
return Database(args);
}
this(string uri) {…}
this(Config config) {…}
...
}
The first static function provides a way to default construct.
The 2nd static function provide uniformity with all of the other
constructors that might be present.
Might this be a good idiom to apply for resource managing structs
in general?
erik
previous forum discussion on default constructors:
http://forum.dlang.org/thread/fgldbozuneoldxjrw...@forum.dlang.org?page=5
Re: std.experimental.testing PR review
I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila
Re: Why aren't you using D at work?
Manu via Digitalmars-d digitalmars-d@puremagic.com writes: On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d And for iOS - https://github.com/smolt/ldc-iphone-dev I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far. It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction. Would putting up a binary build help? I can do that. Yes. I basically won't look at anything without a binary build. Call me whatever you like; I am a completely typical Windows developer in this way. If there is no binary, the thought that I should build it myself doesn't cross my mind ;) In this case you'd have to be an OS X developer, as the binaries will be for a Mac. It would be nice if it were easy to find; present among the other LDC downloads? When ready, I will add a link to the iOS section of http://wiki.dlang.org/LDC Possible to work iOS toolchain build into the existing LDC CI solution? I think all these missing cross-compilers need to find themselves into regular build cycles, and maintained alongside the existing releases. Much easier to take them seriously in that context, and gives better visibility; it feels like these efforts are somewhat fragmented until recently. Having toolchain alpha-releases available, even without libraries in working order, makes the bar much lower for people to get in and start hacking on the libraries. Yeah, we need to work on getting iOS support into LDC main offering. For now there is a stumbling block (at least perceived by me) of requiring a patched LLVM to support TLS on iOS.
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote: and now you killed the only sensible way to use it: as package manager. I don't care for it as a package manager either because it is too complex. As you know, I like to do my things as individual files. I don't go through the pain of making a new github repo with a gigantic folder layout for every little thing. One of the things I really like about D is how modules are encapsulated into individual files. The code is there, the documentation is there, the tests are there. No separate headers or anything else. The only package management scheme I'd even consider using is one that has a per-file option... and even then, I probably wouldn't bother because individual files are so easy to manage anyway that downloading a new program to use them doesn't exceed the existing option is good enough for me threshold. But even if I don't use it myself, it would be kinda nice if the repository could handle my files just so I can toss it up there and not have to answer questions about that anymore. I'd be willing to add them all individually to the repo, even listing the dependencies manually if I had to (tip: make this a web form that I can just submit to add stuff to it, no json upload) but I'm not willing to separate my little repo into 25 other repos and separate my folder into 125 other folders to be added to it.
[Issue 14638] The last (in lexical order) copy of an object must be a move
https://issues.dlang.org/show_bug.cgi?id=14638 --- Comment #2 from Jonathan M Davis issues.dl...@jmdavisprog.com --- Oh, wait. No, this is not just RVO. You're not even returning in the example. Clearly, I paid too much attention to the text and not the example. Not enough sleep, I guess... --
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 05:05:21 UTC, Brad Anderson wrote: On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote: On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote: As for dub, I'd use it if it worked like a package manager; dub get libcurl-d libqt-d zlib-d libsdl2-d etc I have no use for it as a build system, and therefore it's expression of dependencies is no use to me. I just want something that works the same way as '-dev' packages already work perfectly well in linux, that is, they fetch headers and libs, and put them in a standard location that all the tooling can find. I thought it does that. If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker. Andrei dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions. I wonder if essentially hashing a library(ultimately each file) could be used to avoid dll hell. Essentially hash the .d files and then different versions will have different hashes. When you compile your project and it is successful, the compiler/linker can write a configuration file that includes the hashes of the various files used. This then could be used to avoid dll, if one has a proper way to check for versioning(online database) then one can find the proper versions. Obviously small changes to any d file, even if it is non-breaking will change the hash. This is not a bad thing but since there will be no correlation between hashes and versions one must have a database of versions and their hashes. The good thing is that if, say, a project doesn't compile after updating a library to the wrong versions, the configuration file won't be modified since the compiler won't be able to compile the code. One can then easily use the (old) config file, if it exists from a previous (working) build, to deal with the versioning issue. (e.g., hash is different for mylib.d, means wrong version. Get correct version) In fact, maybe the way to go is for the config file essentially to keep a history of several last working builds, e.g., 05/31/15 - mylib.d[3FABABCCC34C3C] - Compiled OK - myotherlib.d[4C934DFFF34C3C] - Compiled OK - myproject.d [FFABC33CCA4367C4EE] - Compiled OK - Project [3493493428439294292] - Compiled OK 06/01/15 - mylib.d[3FABABCCC34C3C] - Compiled OK - myotherlib.d[4C954D5F3F2F434EEC] - Compiled OK - myproject.d [FFABC33CCA4367C4EE] - Failed - Project [3493493428439294292] - Failed In the above case, the myotherlib.d's hash changed. the project did not compile. Hence we have a versioning issue. It is easy to see what the problem is. One then simply needs an online datable to match the hashes to the versions or simply search all versions and hash them. Also, one benefits from simply hashing any file to get it's version. If you had 10 myotherlib.d files from the past but don't know which is which(different copies scattered across different backups, etc), simply hashing them and finding the correct one(in this case, 4C934DFFF34C3C) can be used to get the project working again. Since most of this stuff can be automated, it seems like it would be a better way to deal with versioning than the standard methods which relies on users correctly defining the versions and maintain them.
Re: Working on new binary serialization module for phobos (hopefully)
On 2015-06-01 14:52, Sean Campbell wrote: I've been working on a new serialization module for Phobos and its only reliant on 4 Phobos modules it is available at https://github.com/sycam0inc/phobos/blob/master/std/experimental/serialization.d I would like some feedback on it I had a quick look at the code. Based on that and how short the code is I'm guessing it lacks some features. I've been working on a serialization package for Phobos for a long time. Basically moving Orange [1] in to Phobos. My serialization library supports: * Fully automatic serialization * Serializing non-public fields * Serializing without registering types (except when serialized through a base class reference) * Serializing third party types * Custom serialization, both intrusive and no-intrusive * Tracking of references, pointers and arrays to only serialize the data once * Properly restores arrays and slices * Separate front end (serializer) from back end (archiver/format) * Deserializing of classes without default constructor [1] https://github.com/jacob-carlborg/orange -- /Jacob Carlborg
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 06:20:18 UTC, Nick Sabalausky wrote: Ditto. Dub's great if you let it be your buildsystem, but as soon as you want to use it as a package-manager-only it becomes an uphill battle with dub fighting back every step of the way (I speak from experience). That problem is worse if your project is a library that you want fetchable through dub. And this is when Jacob Carlborg chimes in and says I told you so. ;) His favorite complaint about dub has always been that it combined package management and the build tool into one. dub works fantastically if you want to do everything in the standard way without any funny stuff, but it clearly doesn't have the power of a tool like make, cmake, etc. As soon as you need to do anything funny - like include anything related to other languages in your build, or put things in a specific layout because of some company-specific thing, or anything that wasn't explicitly planned for by the folks writing dub, dub just won't work. Now, to be fair, I don't know how you can be pulling in all kinds of stray libraries with who-knows-what for their build systems and expect it to work very well via a single tool (at minimum, you have the problem that the machine that you're trying to build them on will likely be missing some of those tools), but that's pretty much what we need to handle the general case. Without that, dub will work great for the normal case (which _will_ be plenty for many, many projects), but it won't work in the general case - and corporate folks in particular are probably going to have to skip out on using it because of abnormal requirements on their part. Even simply splitting dub out so that it can pull in packages without necessarily being able to build them would be nice (maybe adding a flag to the dub.json file indicating whether dub can be used as a build tool for the project or whether it's supposed to just act as a package manager for it), though that does add the problem of code.dlang.org becoming more confusing, since you wouldn't be able to rely on all projects on it being built for you by dub as part of the process of grabbing packages. It's a complicate problem, and dub went a route which works in the 90% case, but doesn't work for more complicated cases, which will make dub unusable for some projects - especially corporate ones. I don't know how fixable it is without a major redesign of dub. - Jonathan M Davis
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 14:43:22 UTC, Marc Schütz wrote:
On Monday, 1 June 2015 at 14:20:46 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 12:50:28 UTC, Marc Schütz wrote:
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by remembering whether an object was moved using a
hidden boolean variable. AFAIK the latter is incidentally the
solution Rust chose.
Wouldn't the compiler just do something like
if(condition)
{
bar(s); // Do a move; the destructor is run inside bar
return;
}
else
{
s.__dtor();
return;
}
In which case, the destructor is always run in the right spot,
and the compiler can guarantee that a move is done rather than
a copy?
When this can be done, it's of course a good solution. But when
there is additional code between the move and the destruction,
it usually doesn't work:
void foo() {
S s;
if(condition)
bar(s);
baz();
// - should we run the destructor here?
}
Then, like you suggested, that would indeed appear to require
either an invisible bool that indicates whether a move was done
or not or disallowing the move. I think that I'd favor the bool,
since moving is likely to save more than the extra bool is going
to cost.
- Jonathan M Davis
Re: Make dub part of the standard dmd distribution
On 2/06/2015 1:11 a.m., Adam D. Ruppe wrote: On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote: and now you killed the only sensible way to use it: as package manager. I don't care for it as a package manager either because it is too complex. As you know, I like to do my things as individual files. I don't go through the pain of making a new github repo with a gigantic folder layout for every little thing. One of the things I really like about D is how modules are encapsulated into individual files. The code is there, the documentation is there, the tests are there. No separate headers or anything else. The only package management scheme I'd even consider using is one that has a per-file option... and even then, I probably wouldn't bother because individual files are so easy to manage anyway that downloading a new program to use them doesn't exceed the existing option is good enough for me threshold. But even if I don't use it myself, it would be kinda nice if the repository could handle my files just so I can toss it up there and not have to answer questions about that anymore. I'd be willing to add them all individually to the repo, even listing the dependencies manually if I had to (tip: make this a web form that I can just submit to add stuff to it, no json upload) but I'm not willing to separate my little repo into 25 other repos and separate my folder into 125 other folders to be added to it. Something I've thought about but haven't suggested up to now is making dub-repo to support personal projects. Basically one repo per person preconfigured if e.g. Github/Bitbucket is specified. github.com/rikkimax/dubcode Just as an idea for what I'm meaning url wise. So then when specifying a dependency in dub, its just a matter of saying person:subproject It would also help with people having there own util libraries all listed. Of course then you'd only have to dump your code in there and have a dub file with each file being its own sub package. Seems simple to implement, but idk if it is the answer.
[Issue 14638] The last (in lexical order) copy of an object must be a move
https://issues.dlang.org/show_bug.cgi?id=14638
--- Comment #3 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
It's my understanding (though I could be wrong) that the
void main()
{
fun(S1());
hun(S2());
}
part at least is guaranteed to do a move, since you're dealing with
temporaries. I would have expected the rest of it to do moves as well like
you're requesting, but I don't remember how guaranteed it's supposed to be.
Clearly, the compiler doesn't seem to think that it's guaranteed though, since
it's not doing it.
Regardless, I agree with this. We need to make it so that moves are guaranteed
where we can for both performance reasons and for noncopyable objects (and the
noncopyable objects pretty much throw it in your face when it doesn't do a
move).
However, I don't understand what you mean by dynamic and static uses. Is a
dynamic use one that may or may not be the last one hit depending on what
occurs after it, whereas a static use is guaranteed to be the last use if it's
hit?
--
Re: dlang.org build broken
On 5/30/15 5:29 AM, Steven Schveighoffer wrote: On 5/30/15 4:06 AM, Vladimir Panteleev wrote: On Friday, 29 May 2015 at 21:56:43 UTC, Steven Schveighoffer wrote: And BTW, how can we get the ddoc build to be part of the auto tester? Not as good as testing PRs, but I added an hourly cronjob to the staging site. At least now I'll know if something we merged broke building the website. thanks! For my understanding, where is the staging area? Is it this? http://dlang.org/phobos-prerelease/index.html -Steve
[Issue 14638] The last (in lexical order) copy of an object must be a move
https://issues.dlang.org/show_bug.cgi?id=14638 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com --- So, basically, you want RVO to be guaranteed to occur rather than it being considered an optimization (and thus being optional)? --
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 11:03:30 UTC, Namespace wrote: What about auto h = r.front; // can get the front of the range ? hasLvalueElements checks whether you can pass the return value of r.front by ref and take its address. So, if you want to take the address of r.front, you should be using hasLvalueElements in your template constraint to prevent ranges which won't allow you to take the address of their front from being use with that function and resulting in compilation errors inside of the function. - Jonathan M Davis
Re: Make dub part of the standard dmd distribution
I think the way I'd do it is you still make projects in the repo that are referenced like normally, just it refers to a file in a specific repo instead of a whole repo. Maybe using the subpackage feature it can get close enough. I'll try using an empty source folder then do the others as a single additional file. But actually, the multiple listing on the repo is the most important part to me, these are really individual things, they shouldn't be listed as miscellaneous from me on the listing...
Re: Better handling of noncopyable objects and objects with this(this)
On Monday, 1 June 2015 at 14:20:46 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 12:50:28 UTC, Marc Schütz wrote:
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// - should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by remembering whether an object was moved using a hidden
boolean variable. AFAIK the latter is incidentally the
solution Rust chose.
Wouldn't the compiler just do something like
if(condition)
{
bar(s); // Do a move; the destructor is run inside bar
return;
}
else
{
s.__dtor();
return;
}
In which case, the destructor is always run in the right spot,
and the compiler can guarantee that a move is done rather than
a copy?
When this can be done, it's of course a good solution. But when
there is additional code between the move and the destruction, it
usually doesn't work:
void foo() {
S s;
if(condition)
bar(s);
baz();
// - should we run the destructor here?
}
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 12:34:47 UTC, extrawurst wrote: dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own. Atila Hi Atila, you are talking about cross language builds ? That too. Other than that limitation, what do you miss ? Everything I could do (and have) in cmake. Here are two really simple examples: 1) Automatically run a script to generate the file containing main before doing the build, with proper dependency tracking 2) Concurrently building release and unittest builds I've worked on complicated build systems before, I know the kind of thing I'd need. I have a couple of rather sizable projects running with dub without problems and one could argue vibe.d is a pretty big project too which works fine. I wouldn't consider vibe.d to be a large project. The D community already suffered enough from not uniting workforces behind at least SOME standards (hint at tango), a plethora of options for newcomers to choose from for basics like building is also daunting IMHO. I fully support dub being the default package manager and for most people/projects it is a good enough build system. That's why my build system builds on dub instead of wanting to replace it. It leaves the package dependency part to dub and focusses on build descriptions that can leverage dub's existing knowledge of the build. Atila
Re: Make dub part of the standard dmd distribution
On Monday, 1 June 2015 at 13:11:43 UTC, Adam D. Ruppe wrote: The only package management scheme I'd even consider using is one that has a per-file option... and even then, I probably wouldn't bother because individual files are so easy to manage anyway that downloading a new program to use them doesn't exceed the existing option is good enough for me threshold. What happens when you find a bug in your library? Then every user has new work to do to merge the changes. With DUB you don't do a thing for patch versions in user code. _This provide a way to warn your users and make them upgrade_. This is the main interest of DUB. You could use git submodule for that, but not everyone use git, and not everyone want to search commit logs for the right version.
