Re: dmd 2.064 release candidate 1
On 11/4/2013 11:46 PM, Jacob Carlborg wrote: On 2013-11-04 21:01, Walter Bright wrote: The libraries were not built correctly (my old machine runs out of memory building them). FreeBSD users have needed to, for some time now, fork/build to get it. I don't understand, the binaries and Phobos are included in the zip They aren't, actually. The 64 bit stuff isn't, and the 32 bit phobos is old. (I haven't verified that they work). But dmd.conf is not. Can't you include dmd.conf just because your machine runs out of memory? Heck, I had spent considerable time just trying to figure out *which* virtual box to install. Each option came with a long list of caveats and things that didn't work. Some would work with one OS, some with another, the one I did download would kinda sorta work with NetBSD, but not really, etc. Then, of course, was having it all wiped out by upgrading Ubuntu. I'm not sure I understand what you're meaning. If I want to install Ubuntu, I just create a new virtual machine (using VirtualBox), download Ubuntu and makes a default installation. If I want Fedora, I do the same thing but I download and install Fedora instead. NetBSD? We don't even support NetBSD. The reason for that is I could never get NetBSD to run (either in a virtual box or on a spare machine). For FreeBSD, just do the same thing, download FreeBSD. Actually, for FreeBSD I installed PC-BSD instead. That will include a GUI by default, making it basically just as easy to use as Ubuntu. The only thing that I had some trouble with is cross-compiling. That is, building 32bit on a 64bit machine. It's not impossible to do. There's just a significant time sink involved in figuring out which one to get, getting it installed, getting it working, and keeping it working. It's actually easier to just buy another machine. I'm not going to argue. If you have trouble picking which ISO image to download we can help you. What's taking the most time for me is download the ISO and wait for the installation. But I can do other things while waiting. Why not volunteer to handle the FreeBSD package builds?
Re: dmd 2.064 release candidate 1
On 11/4/2013 11:46 PM, Iain Buclaw wrote: For the second time, the license on the readme.txt distributed with the sources is wrong? Which one in which directory and what should it be?
Re: dmd 2.064 release candidate 1
Why not volunteer to handle the FreeBSD package builds? I have access to FreeBSD machine(s) and willing to lend a hand and spend some time on this. What is needed to do the FreeBSD package build? (Currently I just do a git clone/pull of the github dlang stuff and build it to get the master or any other branch I want) Were do I find the build and package instructions? Is running regressions tests required before releasing a build package? What is the packages release (and build) frequency? DMD1 and DMD2 (and GDC) seems to be in the FreeBSD ports collection. Why can't those be used to buid the packages?
Re: dmd 2.064 release candidate 1
On 2013-11-05 10:09, Walter Bright wrote: They aren't, actually. The 64 bit stuff isn't, and the 32 bit phobos is old. Ok, that's quite confusing. Isn't it better to _not_ include the 32bit files instead of including old ones. The reason for that is I could never get NetBSD to run (either in a virtual box or on a spare machine). Ok, I see. Why not volunteer to handle the FreeBSD package builds? I'm quite busy, yes I know, we all are. -- /Jacob Carlborg
Re: dmd 2.064 release candidate 1
On 2013-11-05 10:09, Walter Bright wrote: Why not volunteer to handle the FreeBSD package builds? Actually, I guess I could to a quick build tonight or tomorrow night and just send you the files. But as you have said, it would be better if the autotester could do that. -- /Jacob Carlborg
Re: dmd 2.064 release candidate 1
On 5 November 2013 09:35, Walter Bright newshou...@digitalmars.com wrote: On 11/4/2013 11:46 PM, Iain Buclaw wrote: For the second time, the license on the readme.txt distributed with the sources is wrong? Which one in which directory and what should it be? There's only one file named readme.txt. ;-) See here for the latest file: https://github.com/D-Programming-Language/dmd/blob/master/src/readme.txt -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Introducing vibe.d!
Hi Alexandre, I'll try to answer as good as I can, please excuse if I got part of your question wrong. So I see two parts that can be slow: 1. The application runtime performance. Due to additional debug checks and less optimization, debug builds will run slower than release builds, but this usually gets important only for very high load scenarios for typical vibe.d/D applications. So this is usually nothing to worry about during development. If, however, a release build is required to get acceptable performance, it can easily double the build time. 2. The edit-compile-run-test cycle during development. This will be similar to Java in that it will usually require the whole application to be rebuilt and restarted. Building a vibe.d application currently takes about 12 s for most applications. It can get much slower, though, if the application makes heavy use of templates or compile-time function execution (this is the case for Diet templates [1], for example). Having said that, there are ways to get around this in certain situations. At least on Linux (on DMD 2.064 and up) this is now possible relatively easily using core.runtime.Runtime.loadLibrary. Using that, individual components can be built as small shared libraries and loaded dynamically into the running process. Remedy Entertainment has done something similar before Runtime.loadLibrary was available [2]. Best regards, Sönke [1]: http://vibed.org/docs#html-templates [2]: http://www.youtube.com/watch?v=FKceA691Wcg Am 04.11.2013 17:40, schrieb Alexandre Riveira: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Sunday, 3 November 2013 at 15:16:09 UTC, Andrej Mitrovic wrote: On 11/3/13, simendsjo simend...@gmail.com wrote: Nothing I have the need for, but very cool nontheless. It would be interesting if you wrote about your experience on porting a C codebase this size. Nothing much new compared to the last time I ported C, which I wrote about here: http://forum.dlang.org/thread/mailman.1069.1308629671.14074.digitalmars-d-annou...@puremagic.com?page=2#post-mailman.1084.1308684922.14074.digitalmars-d-announce:40puremagic.com Of course I know much more now than I did back then. Maybe you meant like a blog post? I'll add it to my todo list. :) Here's a little bug report. Don't know if it's my bad. I'm running Ubuntu 12.04 (64-bit), compiler - DMD v2.063.2, DUB v0.9.17-29-g2be278a I cloned the git repo (sha1 96a870e) and ran dub. First-off, it complained about several 'cannot cast ulong to int'. I've fixed that with explicit casts. Second, it complained about undefined reference to dlopen and friends. I've fixed that by adding libs: [ dl ] to package.json And finally, I've got object.Exception@src/rt/minfo.d(243): Aborting: Cycle detected between modules with ctors/dtors: dchip.cpPolyShape - dchip.chipmunk_private - dchip.cpArbiter - dchip.cpSpace - dchip.cpSpaceStep - dchip.cpCollision - dchip.cpPolyShape Which I don't know how to fix. Hope it'll be useful.
Re: Introducing vibe.d!
Am 04.11.2013 18:35, schrieb Dicebot: On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Seconded, some parts are still moving fast and some parts still don't have good enough test coverage. And while it can already be used for many production tasks when used with some care, I wouldn't suggest to start a million+ user service in the next 6 months or so, before a rigorous regression free stabilization process is in effect.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/5/13, Sergei Nosov sergei.no...@gmail.com wrote: Here's a little bug report. Don't know if it's my bad. It's not your fault. And thanks for the report! First-off, it complained about several 'cannot cast ulong to int'. I've fixed that with explicit casts. This is mostly the cause of the old C code which compiled without warnings. I've fixed this now. Second, it complained about undefined reference to dlopen and friends. I've fixed that by adding libs: [ dl ] to package.json I've added it as a Posix flag, however do note that I still don't know whether the demo will work on Posix since I don't know how to load the glu library there. I'll have to investigate this in a virtual machine later. And finally, I've got object.Exception@src/rt/minfo.d(243): Aborting: Cycle detected between modules with ctors/dtors: dchip.cpPolyShape - dchip.chipmunk_private - dchip.cpArbiter - dchip.cpSpace - dchip.cpSpaceStep - dchip.cpCollision - dchip.cpPolyShape I was afraid this was going to happen. As it stands D's module constructors are almost completely useless for real world code since this issue always pops up. Anyway I've replaced them with a single module constructor which calls initialization functions, so this is fixed now. Thanks again for all the reports! And if you have new ones please do report them on the githup page, in the Issues section. Cheers.
Re: Go vs. D [was Re: Rust vs Dlang]
On Sunday, 17 March 2013 at 21:13:48 UTC, Paulo Pinto wrote: If I am not mistaken, Rust makes use of them as well. Rust doesn't anymore: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html The announcement also mentions performance problems related to Go segmented stacks: https://docs.google.com/document/d/1wAaf1rYoM4S4gtnPh0zOlGzWtrZFQ5suE8qr2sD8uWQ/pub
Re: dmd 2.064 release candidate 1
On 11/5/2013 4:02 AM, Iain Buclaw wrote: There's only one file named readme.txt. ;-) See here for the latest file: https://github.com/D-Programming-Language/dmd/blob/master/src/readme.txt Thanks, I'll take care of it.
Re: dmd 2.064 release candidate 1
On 2013-11-05 10:09, Walter Bright wrote: Why not volunteer to handle the FreeBSD package builds? Hmm, turns out it's currently not possible to build C++ code for 32bit on a 64bit FreeBSD machine. This might take a bit longer than I expected. I can still send you 64bit binaries if that is of interest. -- /Jacob Carlborg
Re: dmd 2.064 release candidate 1
On 11/5/2013 1:50 PM, Jacob Carlborg wrote: On 2013-11-05 10:09, Walter Bright wrote: Why not volunteer to handle the FreeBSD package builds? Hmm, turns out it's currently not possible to build C++ code for 32bit on a 64bit FreeBSD machine. This might take a bit longer than I expected. I can still send you 64bit binaries if that is of interest. Yeah, you essentially need both a 32 bit FreeBSD install and a 64 bit one. I suppose what's needed is a one click install package for FreeBSD.
Re: dmd 2.064 release candidate 1
On 11/5/2013 1:52 AM, Arjan wrote: Why not volunteer to handle the FreeBSD package builds? I have access to FreeBSD machine(s) and willing to lend a hand and spend some time on this. What is needed to do the FreeBSD package build? (Currently I just do a git clone/pull of the github dlang stuff and build it to get the master or any other branch I want) Were do I find the build and package instructions? That's part of handling it - figuring out all that stuff :-) I don't know what it is. Is running regressions tests required before releasing a build package? Yes, and the regression suite is part of the github repository. Alternatively, you could talk to Brad and get the actual binaries from the autotester. What is the packages release (and build) frequency? It's a bit erratic, but generally once every 3 months or so. DMD1 and DMD2 (and GDC) seems to be in the FreeBSD ports collection. Why can't those be used to buid the packages? Building it is less of an issue than getting a FreeBSD install.
dmd 2.064.2
Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb
Re: dmd 2.064 release candidate 1
On 11/5/13 2:00 PM, Walter Bright wrote: On 11/5/2013 1:52 AM, Arjan wrote: Why not volunteer to handle the FreeBSD package builds? I have access to FreeBSD machine(s) and willing to lend a hand and spend some time on this. What is needed to do the FreeBSD package build? (Currently I just do a git clone/pull of the github dlang stuff and build it to get the master or any other branch I want) Were do I find the build and package instructions? That's part of handling it - figuring out all that stuff :-) I don't know what it is. Is running regressions tests required before releasing a build package? Yes, and the regression suite is part of the github repository. Alternatively, you could talk to Brad and get the actual binaries from the autotester. What is the packages release (and build) frequency? It's a bit erratic, but generally once every 3 months or so. DMD1 and DMD2 (and GDC) seems to be in the FreeBSD ports collection. Why can't those be used to buid the packages? Building it is less of an issue than getting a FreeBSD install. I really do intend to get the package builder producing bundles (not for every single build, that'd be.. scary). It's on my todo list. Maybe I'll dedicate my christmas vacation to that project.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:10:53 UTC, Joshua Niehus wrote: On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd.2.064.2.dmg Not found :( nvm, just started working... apologies
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd.2.064.2.dmg Not found :( http://d.puremagic.com/issues/show_bug.cgi?id=2 still open :(
Re: dmd 2.064.2
On 11/5/2013 2:10 PM, Joshua Niehus wrote: On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd.2.064.2.dmg Not found :( It's uploading as I type this. Should be up in a minute or two. http://d.puremagic.com/issues/show_bug.cgi?id=2 still open :( Sorry. There are a lot still open - but a vast number were fixed.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb Dear world: DO NOT use the windows installer if you have ANYTHING other than the default installed files in your previous install folder, because it will delete EVERYTHING. (and this isn't an understatement, my C:/D folder is now entirely empty but for a single git index which was locked by my IDE), this means I have now lost my local checkouts of the D repos, my git-head dmd install location, as well as my auto-build-install-test scripts, and my local copy of my JSON work. Thankfully my JSON work wasn't even the latest copy anyways. Deleting everything IS NOT uninstalling.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd-2.064.2.exe What's up with the Windows installer? It appears to be using an old version without all the improvements I've been making but with some new changes added.
Re: dmd 2.064.2
On 11/5/2013 2:21 PM, Brad Anderson wrote: What's up with the Windows installer? It appears to be using an old version without all the improvements I've been making but with some new changes added. It should be using the one on the 2.064 branch on github. Can you check that?
Re: dmd 2.064 release candidate 1
On 11/5/2013 2:10 PM, Brad Roberts wrote: I really do intend to get the package builder producing bundles (not for every single build, that'd be.. scary). It's on my todo list. Maybe I'll dedicate my christmas vacation to that project. That would be awesome, and would be a big step forward in getting a reliable release process.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:36:43 UTC, Brad Anderson wrote: On Tuesday, 5 November 2013 at 22:24:14 UTC, Walter Bright wrote: On 11/5/2013 2:21 PM, Brad Anderson wrote: What's up with the Windows installer? It appears to be using an old version without all the improvements I've been making but with some new changes added. It should be using the one on the 2.064 branch on github. Can you check that? [2.064 branch] is 2 commits ahead and 9 commits behind master So it's definitely missing some stuff in the branch itself but what you put up is also definitely not what is in the 2.064 branch either. There should be several sections: - D2 - cURL Support - Detect MSVC - Add to PATH - D1 - Add to PATH - dmc - Add to PATH - Start Menu Shortcuts - Visual D But in the one you put up there is just: - dmd - cURL support - Add to PATH - dmc - Add to PATH - Start menu items Normally it's an internet installer too but isn't this time (not a bad thing but not normal either). It also uninstalls DMD before it installs which the current installer doesn't do. I have no idea where you got this version. Figured it out. You used linux/win/installer.nsi. I have no idea why that exists and what it is for. Jordi has been making a lot of changes to it but I have no idea what the purpose of it is. Maybe he should start doing pull requests like everyone else so people know what's going on with the repo.
Rust abandons segmented stacks
http://www.reddit.com/r/programming/comments/1pyifh/abandoning_segmented_stacks_in_rust/ Looks like even Go is considering abandoning them, too. Looks like we made the right call :-) though I didn't think of the hot split problem.
Re: dmd 2.064.2
On 11/5/2013 2:41 PM, Brad Anderson wrote: Figured it out. You used linux/win/installer.nsi. I have no idea why that exists and what it is for. It's so you can build the windows installer from a Linux box. I presumed it was the same. Maybe he should start doing pull requests like everyone else so people know what's going on with the repo. It *is* in the repo. That's where I got it. Please issue a pull request to update it.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:46:49 UTC, Walter Bright wrote: On 11/5/2013 2:41 PM, Brad Anderson wrote: Figured it out. You used linux/win/installer.nsi. I have no idea why that exists and what it is for. It's so you can build the windows installer from a Linux box. I presumed it was the same. Maybe he should start doing pull requests like everyone else so people know what's going on with the repo. It *is* in the repo. That's where I got it. I know, what I mean is that Jordi pushes directly to D-Programming-Language when he works so his changes are done largely under the radar. Please issue a pull request to update it. He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box.
Re: dmd 2.064 release candidate 1
On 11/5/13 2:10 PM, Brad Roberts wrote: I really do intend to get the package builder producing bundles (not for every single build, that'd be.. scary). It's on my todo list. Maybe I'll dedicate my christmas vacation to that project. That would be awesome!! Andrei
Re: dunit 0.7.0 released
Am Mon, 21 Oct 2013 21:47:22 +0200 schrieb ilya-stromberg ilya-stromberg-2...@yandex.ru: On Monday, 21 October 2013 at 19:02:45 UTC, Gary Willoughby wrote: On Monday, 21 October 2013 at 11:58:14 UTC, Jonathan M Davis wrote: On Monday, October 21, 2013 13:48:16 Dicebot wrote: On Monday, 21 October 2013 at 11:09:25 UTC, ilya-stromberg wrote: Guys, we have at least 5 (!) different unit test projects! Can you cooperate your efforts to create one, but wonderful? ...and add it to Phobos review queue ;) I confess that I don't understand why anyone is creating any unit test projects for D, and I'd likely vote against any attempt to add such a thing to Phobos. D has built in unit testing functionality, and it works great. Maybe some additional assert-like functions could be useful (similar to assertThrown or assertNotThrown), but we really don't need much beyond what the language provides. - Jonathan m Davis Seriously though, unit testing is a major tool that all languages should have access to. The built-in stuff is adequate for very simple testing on simple types such as asserting something is true, etc. But when you're writing tests for a class that need dependencies then the built-in stuff won't cut it. The framework i'm currently working allows for mocking of dependencies which in itself is a big deal. Replacing dependencies with 'fake' stubs is something which makes unit tests a lot clearer and less complicated. It also means i can override the return value of any method at runtime to pretend returned data is real there too. I've also extended the assert mechanism in the D runtime to create better errors. Instead of just getting: core.exception.AssertError@file(57): Assertion failure You now get: +-- | Failed asserting equal +-- | File: file.d | Line: 57 +-- | ✓ Expected value: (int[]) [1, 2, 3, 4, 5] | ✗ Actual value: (int[]) [1, 2, 4, 5] This is way more clear exactly what and where failed. This is essential when unit testing using structs, arrays, classes, etc.. as you need this information to truly narrow down exactly what failed. Extending stuff like this also helps with overall project reporting, writing to a file or drawing pretty graphs etc.. +1 We had a discussion about verbose contract assertion failures a while ago. I did something similar, with an API like that: ensure!==(x, [1, 2, 3, 4, 5], x isn't the ordered list of integers from 1 to 5); It has its shortcomings though, especially when you need x to be one of a set of values or a power of 2 etc... Btw: Is ✓ and ✗ supported on Windows Vista and XP ? -- Marco
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/3/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: https://github.com/AndrejMitrovic/dchip What is Chipmunk2D? === Btw, I know the documentation and resources for the C library are a little bit scarce at the moment. In particular most tutorials seem to target ObjectiveC bindings and the iPhone. When I get a hang of the library and get some experience going I'll make sure to write up some D tutorials.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 23:51:54 UTC, Walter Bright wrote: On 11/5/2013 2:52 PM, Brad Anderson wrote: He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box. For the moment I just rebuilt dmd-2.064.2.exe with the windows version and uploaded it. Perfect. Thank you.
Re: dmd 2.064.2
On 11/5/2013 2:52 PM, Brad Anderson wrote: He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box. For the moment I just rebuilt dmd-2.064.2.exe with the windows version and uploaded it.
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb How come that we are at 2.064.2 ? Aren't the last number supposed to represent patches after release ? Anyway I want to attract your attention on http://d.puremagic.com/issues/show_bug.cgi?id=11447 . This one is a show stopper for SDC.
Re: Mono-D v0.5.4.7 - Refactoring issue fixes completion fixes
On Monday, 4 November 2013 at 09:50:59 UTC, Alexander Bothe wrote: Hi everyone, not a big release, just a small bump for Mono-D and D_Parser :-) http://mono-d.alexanderbothe.com/internal-refactoring-feature-cleanup-completion-fixes-v0-5-4-7/ Completion issues: https://github.com/aBothe/D_Parser/issues Other issues: https://github.com/aBothe/Mono-D/issues Cheers, Alex I really like the mono-d, the biggest regret is that the windows can not debug. . .
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb haha, using D as the development of more and more, sent a congratulatory message from China, congratulations dmd 2.064.2 released! There is another suggestion, when you can join arm compiler, and now mobile development too fire!
Re: Visual D 0.3.37 released
I just found something surprising. I went into the 0.3.37 options, saw the 32bit/64bit separation, but noticed by default, the lib paths were populated like so: 32bit: $(DevEnvDir)..\..\VC\lib\amd64\ C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 64bit: $(VCInstallDir)\lib\amd64 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64 Should I be surprised that the 32bit lib paths both point to 64bit libs? Shouldn't the 32bit libs point to the DMD OMF libs? On 5 November 2013 15:09, Manu turkey...@gmail.com wrote: Thanks so much. As I've said before, this is an absolutely critical, yet often overlooked piece of the ecosystem. Good to see plenty of life in the project! :) Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) On 3 November 2013 00:40, Rainer Schuetze r.sagita...@gmx.de wrote: Hi, it's been a long time since the last release of Visual D, but I hope it wasn't too long. As Visual D moves closer to the dlang.org website, this is the final release that will be available on http://www.dsource.org/ projects/visuald. Downloads and documentation are also available at http://rainers.github.io/visuald. Major changes include * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8, fixes x64 debugger in VS 2012 Shell * improvements to Compile and Run * improvements to syntax/coverage highlighting * DParser engine now used by default, updated to recent version * single file options now available per project configuration * added global option to display the reason for building a target * added different options for executable and library search paths to be used for Win32/x64 * link dependencies can now also be monitored for the 32-bit MS linker * added commands Collapse unittests and Collapse disabled to the outlining menu The full list of changes can be found here: http://www.dsource.org/projects/visuald/wiki/VersionHistory or: http://rainers.github.io/visuald/visuald/VersionHistory.html Visual D is written in D, source code is available here: https://github.com/D-programming-Language/visuald Best, Rainer
Re: Introducing vibe.d!
Hi Sönke, My concern is actually in development time. Compilation, debugging, etc.. Ruby on rails applications had their reload classes optimized effecting only reload the classes changed instead of the entire environment. Today we have the application of ERP type integrated e-commerce with 342 models, reload wait around this set can be a really time consuming process for development. I appreciate your work, appreciate languagem d, successful community On Tuesday, 5 November 2013 at 15:35:19 UTC, Sönke Ludwig wrote: Am 04.11.2013 18:35, schrieb Dicebot: On Monday, 4 November 2013 at 16:40:25 UTC, Alexandre Riveira wrote: Hi Sönke, Congratulations for your hard work. One question, How do you think your framework running in development mode where a huge amount of models with many business rules exist. A system under development can be slow, like java where a signature change in the method requires reload of the whole application. Alexandre Riveira I might recommend to wait a bit before trying it in production until CI suite is figured out (it is work in progress), there are some concerns with stability/regressions right now because it grows just too fast. Seconded, some parts are still moving fast and some parts still don't have good enough test coverage. And while it can already be used for many production tasks when used with some care, I wouldn't suggest to start a million+ user service in the next 6 months or so, before a rigorous regression free stabilization process is in effect.
Re: dmd 2.064.2
On 6 November 2013 09:54, Brad Anderson e...@gnuk.net wrote: On Tuesday, 5 November 2013 at 23:51:54 UTC, Walter Bright wrote: On 11/5/2013 2:52 PM, Brad Anderson wrote: He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box. For the moment I just rebuilt dmd-2.064.2.exe with the windows version and uploaded it. Perfect. Thank you. Seems to work on my system. Notices: * no 64bit curl.lib :( * gcstub64, phobos64 still have '64' in the name :( Oh well, there's always next time...
Re: dmd 2.064.2
Btw. http://mirror.ftp.digitalmars.acomirei.ru/dmd_2.064.2-0_amd64.deb http://mirror.ftp.digitalmars.acomirei.ru/dmd-2.064.2-0.fedora.i386.rpm http://mirror.ftp.digitalmars.acomirei.ru/dmd-2.064.2-0.fedora.x86_64.rpm http://mirror.ftp.digitalmars.acomirei.ru/dmd_2.064.2-0_i386.deb http://mirror.ftp.digitalmars.acomirei.ru/dmd-2.064.2-0.openSUSE.i386.rpm http://mirror.ftp.digitalmars.acomirei.ru/dmd-2.064.2-0.openSUSE.x86_64.rpm http://mirror.ftp.digitalmars.acomirei.ru/dmd-2.064.2.exe http://mirror.ftp.digitalmars.acomirei.ru/dmd.2.064.2.zip http://mirror.ftp.digitalmars.acomirei.ru/dmd.2.064.2.dmg http://mirror.ftp.digitalmars.acomirei.ru/libphobos2-64_2.064.2-0_amd64.deb http://mirror.ftp.digitalmars.acomirei.ru/libphobos2-64_2.064.2-0_i386.deb One can use my mirror. c:
Re: dmd 2.064.2
Am Tue, 05 Nov 2013 23:24:02 +0100 schrieb Orvid King blah38...@gmail.com: On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb Dear world: DO NOT use the windows installer if you have ANYTHING other than the default installed files in your previous install folder, because it will delete EVERYTHING. (and this isn't an understatement, my C:/D folder is now entirely empty but for a single git index which was locked by my IDE), this means I have now lost my local checkouts of the D repos, my git-head dmd install location, as well as my auto-build-install-test scripts, and my local copy of my JSON work. Thankfully my JSON work wasn't even the latest copy anyways. Deleting everything IS NOT uninstalling. Stunned silence... You seem to have gotten away with only few losses. Thanks for sharing. I can only imagine what that would have done to someone who has no backups or online repositories for their code. I have to say though that I'm sometimes annoyed by accurate uninstallers that keep a directory because of a log file or modified configuration. I doesn't hurt to ask for a recursive deletion of the install directory. -- Marco
Re: dmd 2.064.2
On Tuesday, November 05, 2013 23:24:02 Orvid King wrote: On Tuesday, 5 November 2013 at 22:08:48 UTC, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb Dear world: DO NOT use the windows installer if you have ANYTHING other than the default installed files in your previous install folder, because it will delete EVERYTHING. (and this isn't an understatement, my C:/D folder is now entirely empty but for a single git index which was locked by my IDE), this means I have now lost my local checkouts of the D repos, my git-head dmd install location, as well as my auto-build-install-test scripts, and my local copy of my JSON work. Thankfully my JSON work wasn't even the latest copy anyways. Deleting everything IS NOT uninstalling. Please ile a bug report: http://d.puremagic.com/issues - Jonathan M Davis
Re: dmd 2.064 release candidate 1
On Tuesday, 5 November 2013 at 21:58:38 UTC, Walter Bright wrote: On 11/5/2013 1:50 PM, Jacob Carlborg wrote: On 2013-11-05 10:09, Walter Bright wrote: Why not volunteer to handle the FreeBSD package builds? Hmm, turns out it's currently not possible to build C++ code for 32bit on a 64bit FreeBSD machine. This might take a bit longer than I expected. I can still send you 64bit binaries if that is of interest. Yeah, you essentially need both a 32 bit FreeBSD install and a 64 bit one. I suppose what's needed is a one click install package for FreeBSD. You can compile 32-bit code on a 64-bit FreeBSD machine, as long as you do it inside a 32-bit FreeBSD jail. I've done this many times when compiling 32-bit FreeBSD packages and it works fine. If Jacob is interested, all he needs to do is setup a 32-bit FreeBSD jail, which is pretty straightforward. On Tuesday, 5 November 2013 at 09:52:26 UTC, Arjan wrote: DMD1 and DMD2 (and GDC) seems to be in the FreeBSD ports collection. Why can't those be used to buid the packages? The gdc FreeBSD port is marked as broken and deprecated. I don't think it's been updated in years, back when gdc was still written by the original author. I wrote the original makefiles for dmd1 and dmd2. They still work, but the current maintainer usually doesn't bother doing more than a cursory version number bump, so they'll often uninstall cleanly, as the list of files installed will be wrong (ie the pkg-plist is outdated). I also wrote a ldc1 makefile back then, but nobody maintained it, so it has been removed. It appears that dlang builds their own packages for some platforms, regardless of whether it's in the native package repository or not. Probably a good idea, for instant gratification of those who want to try it out.
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 04:11:52 UTC, Manu wrote: On 6 November 2013 09:54, Brad Anderson e...@gnuk.net wrote: On Tuesday, 5 November 2013 at 23:51:54 UTC, Walter Bright wrote: On 11/5/2013 2:52 PM, Brad Anderson wrote: He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box. For the moment I just rebuilt dmd-2.064.2.exe with the windows version and uploaded it. Perfect. Thank you. Seems to work on my system. Notices: * no 64bit curl.lib :( * gcstub64, phobos64 still have '64' in the name :( Oh well, there's always next time... Can we get rid of the hard dependancy on curl, or ship our own version of it ? It created tremedous problem to me in some environement where it wasn't available in the past.
Re: Visual D 0.3.37 released
On 06.11.2013 03:01, Manu wrote: I just found something surprising. I went into the 0.3.37 options, saw the 32bit/64bit separation, but noticed by default, the lib paths were populated like so: 32bit: $(DevEnvDir)..\..\VC\lib\amd64\ C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64 64bit: $(VCInstallDir)\lib\amd64 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64 Should I be surprised that the 32bit lib paths both point to 64bit libs? Shouldn't the 32bit libs point to the DMD OMF libs? The 32-bit paths don't have a default (settings in sc.ini should usually be enough), but your settings from previous Visual D versions are kept.
Re: dmd 2.064.2
On 06.11.2013 05:11, Manu wrote: On 6 November 2013 09:54, Brad Anderson e...@gnuk.net mailto:e...@gnuk.net wrote: On Tuesday, 5 November 2013 at 23:51:54 UTC, Walter Bright wrote: On 11/5/2013 2:52 PM, Brad Anderson wrote: He's made so many changes I don't even know where to begin to pull them in sync. The one in windows/dinstaller.nsi has always been the one used in the past. I don't see why the file would need to differ between a Windows and Linux box. For the moment I just rebuilt dmd-2.064.2.exe with the windows version and uploaded it. Perfect. Thank you. Seems to work on my system. Notices: * no 64bit curl.lib :( The library used by the auto tester is here: http://downloads.dlang.org/other/curl-7.28.1-devel-rainer.win64.zip * gcstub64, phobos64 still have '64' in the name :( I agree that using identical names is better, but it is not very critical for phobos, because you rarely have to specify it explicitly. Oh well, there's always next time...
