Re: Visual D 0.3.37 released
On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. What do you think about this?
Re: DirectX bindings
i have added dub package to this bindings, need testing. i don't have an idea how it works since dub lacks documentation.
Re: dmd 2.064.2
El 05/11/13 23:46, Walter Bright ha escrit: 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. It is not the same. The linux/windows/dinstaller.nsi is a fork of windows/dinstaller.nsi. Mainly differs as it includes everything on itself, removing the need to download dmd/dmc/libcurl every time dmd is installed. There are some other minor changes. -- Jordi Sayol
Re: dmd 2.064.2
El 06/11/13 10:55, Jordi Sayol ha escrit: El 05/11/13 23:46, Walter Bright ha escrit: 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. It is not the same. The linux/windows/dinstaller.nsi is a fork of windows/dinstaller.nsi. Mainly differs as it includes everything on itself, removing the need to download dmd/dmc/libcurl every time dmd is installed. There are some other minor changes. Errata: s:linux/windows/dinstaller.nsi:linux/win/installer.nsi: BTW. Changes on this fork: - Built in all the needed components. No downloads during installation. - Checks if another dmd version is already installed, and force to uninstall it before proceed. If uninstaller fails, installation can be forced by the command dmd-2.064.2.exe /f. - Changes on the Windows system registry fields and values. - Remove the dmd version 1. - Not allowed to go ahead if nothing is selected. - Changed default path to C:\dmd. If previous dmd installation is set to another path, installer uses it instead the default. It is prepared to be built by the linux/dmd_win.sh, which is included on linux/build_all.sh as well. -- Jordi Sayol
Re: dmd 2.064.2
Arch Linux package has been updated. Was awaiting for some of good stuff from this release for a long time :) There are two extremely disappointing things though: 1) We still can't get versioning right. Walter has treated release candidate as a release which is why we have 2.064.2 right now as first actual release. This is not intended approach. 2) -allinst switch introduced as a workaround for incomplete implementation of new template instance emitting scheme. Now we have essentially 3 different symbol emitting strategies, all of them are legal, none is documented/guaranteed and those may work in some situations but fail in others (experiments, yay!) This is exactly the opposite of what I have meant when speaking that symbol emitting are needs more attention.
Re: dmd 2.064.2
El 05/11/13 23:08, Walter Bright ha escrit: 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 Linux libraries libphobos2.so.0.64.0 still include libcurl versioned symbols. These libraries can only be used on Linux systems based on Debian. -- Jordi Sayol
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 12:02:48 UTC, Gary Willoughby wrote: Release notes? http://dlang.org/changelog
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 12:44:09 UTC, Dicebot wrote:
On Wednesday, 6 November 2013 at 12:02:48 UTC, Gary Willoughby
wrote:
Release notes?
http://dlang.org/changelog
There is a a bug in the new eponymous syntax example in the
changelog:
template isIntOrFloat(T)
{
static if (is(T == int) || is(T == float))
enum isIntOrFloat = true;
else
enum isIntOrFloat = true; // BUG
}
I am just learning D but those change-logs are awesome! Don't
think I ever seen anything like this.
Re: dmd 2.064.2
Dicebot, el 6 de November a las 12:43 me escribiste: Arch Linux package has been updated. Was awaiting for some of good stuff from this release for a long time :) There are two extremely disappointing things though: 1) We still can't get versioning right. Walter has treated release candidate as a release which is why we have 2.064.2 right now as first actual release. This is not intended approach. Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- DETIENEN A PADRE, MADRE, TIOS Y ABUELOS: TODOS DEPRAVADOS -- Crónica TV
Re: dmd 2.064.2
El 05/11/13 23:08, Walter Bright ha escrit: 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 In dmd.2.064.2.zip, src/VERSION contains 2.064. Should be 2.064.2 -- Jordi Sayol
Re: DirectX bindings
On 11/6/2013 6:29 PM, evilrat wrote: i have added dub package to this bindings, need testing. i don't have an idea how it works since dub lacks documentation. http://code.dlang.org/about http://code.dlang.org/package-format
Re: Visual D 0.3.37 released
On 6 November 2013 18:25, Alexander Bothe i...@alexanderbothe.com wrote: On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. What do you think about this? I've often wondered if there's room for greater sharing of effort between VisualD and Mono-D. For instance, it seems a shame to have .visualdproj, and .dproj files separate and incompatible. .csproj files are the same between VS and MD, I wonder if the same is possible for D with collaboration? Also things like the refactor engine? Are those things separated into self-contained libs so any IDE can make use of them? The semantic analysis really seems like a job for the DMD front end, built as a lib, rather than re-inventing the wheel. Clang seems to provide that sort of service for C tooling. Shame DMD doesn't seem to offer anything similar. I have no idea what the actual state of any of this actually is mind you, just thoughts I often ponder.
Re: DirectX bindings
On Wednesday, 6 November 2013 at 14:25:46 UTC, Mike Parker wrote: On 11/6/2013 6:29 PM, evilrat wrote: i have added dub package to this bindings, need testing. i don't have an idea how it works since dub lacks documentation. http://code.dlang.org/about http://code.dlang.org/package-format i know about this, i mean there is no such info like dub .lib search paths for testing - i don't want to modify sc.ini every time. there was some other things too, but i can't remember anything else atm. also if you look at my repo u can see it has examples subfolder, should i put package.json there too or it would be simpler to add custom build script for building all this examples?
Re: Visual D 0.3.37 released
Regarding project files - I like Mono-D attempt to support dub package.json as project description file. Regarding semantical analysis - both Mono-D and VisualD should just merged efforts with DCD, problem solved :)
Re: DirectX bindings
On Wednesday, 6 November 2013 at 14:35:07 UTC, evilrat wrote: also if you look at my repo u can see it has examples subfolder, should i put package.json there too or it would be simpler to add custom build script for building all this examples? I think former is expected as it is how Sonke (dub author) does it for vibe.d : https://github.com/rejectedsoftware/vibe.d/tree/master/examples
Re: DirectX bindings
On Wednesday, 6 November 2013 at 14:44:59 UTC, Dicebot wrote: On Wednesday, 6 November 2013 at 14:35:07 UTC, evilrat wrote: also if you look at my repo u can see it has examples subfolder, should i put package.json there too or it would be simpler to add custom build script for building all this examples? I think former is expected as it is how Sonke (dub author) does it for vibe.d : https://github.com/rejectedsoftware/vibe.d/tree/master/examples ah ok, thats fine, thanks.
Re: Visual D 0.3.37 released
On Wednesday, 6 November 2013 at 14:43:35 UTC, Dicebot wrote: Regarding project files - I like Mono-D attempt to support dub package.json as project description file. Regarding semantical analysis - both Mono-D and VisualD should just merged efforts with DCD, problem solved :) I dunno, there's probably just a small read method required in order to read .visualdproj files..gonna have a look at it.
Re: Visual D 0.3.37 released
On 06/11/2013 14:39, Manu wrote: For instance, it seems a shame to have .visualdproj, and .dproj files separate and incompatible. .csproj files are the same between VS and MD, I wonder if the same is possible for D with collaboration? The best approach here is to support an IDE-independent project configuration standard. And Dub is a good choice to go with this approach. -- Bruno Medeiros - Software Engineer
Re: dmd 2.064.2
06-Nov-2013 02:08, Walter Bright пишет: 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 Bah... did I miss 2.064 and 2.064.1 ? :) As others noted - please do not use patch level before the release has actually happened. All in all there are: betas RCs and release itself with subsequent patch-versions All should have their own numbers and never intersect or affect one another. -- Dmitry Olshansky
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/6/13, Sergei Nosov sergei.no...@gmail.com wrote: It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup. Merged. And thanks!
Re: dmd 2.064.2
On 11/6/13, Szymon Gatner noem...@gmail.com wrote: There is a a bug in the new eponymous syntax example in the changelog This was fixed, the website hasn't been updated.
Re: Visual D 0.3.37 released
On 7 November 2013 02:05, Bruno Medeiros brunodomedeiros+...@gmail.comwrote: On 06/11/2013 14:39, Manu wrote: For instance, it seems a shame to have .visualdproj, and .dproj files separate and incompatible. .csproj files are the same between VS and MD, I wonder if the same is possible for D with collaboration? The best approach here is to support an IDE-independent project configuration standard. And Dub is a good choice to go with this approach. I use premake, but that's not the point. The point here is that MonoDevelop is a blatant VisualStudio clone, and it supports VS .sln and .csproj files, it would seem nice to continue that compatibility between VS and MD for D too. The compilers are the same with the same features and options, so there's no good reason for the project's to differ, which are both just xml files, but structured slightly differently while containing the same settings.
Let them break the site!
http://www.reddit.com/r/programming/comments/1q1dct/d_release_2064_is_out_with_35_enhancements_and/ Andrei
Re: Visual D 0.3.37 released
Picking common standard for all possible IDE's scales better than cloning approach of a single one (especially if this one is closed and known of forcing closed ecosystems)
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 :( Sorry. Couldn't find the time. The installer can be updated independently of dmd releases to have it but I'm not sure how willing Walter will be to do a mid-release update. * gcstub64, phobos64 still have '64' in the name :( Oh well, there's always next time...
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/6/13, Sergei Nosov sergei.no...@gmail.com wrote: It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup. Btw, which compiler are you using? Could you try running on LDC/GDC if you have that installed and see if there's any performance difference? I would have tried this myself on Windows, but LDC produces crashing apps, and the last version of a packaged GDC zip file doesn't work either.
Re: Let them break the site!
On 11/6/13 9:41 AM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1q1dct/d_release_2064_is_out_with_35_enhancements_and/ Hackernews: https://news.ycombinator.com/item?id=6684003 Twitter: https://twitter.com/D_Programming/status/398144005478707200 Andrei
Re: dmd 2.064.2
On Tuesday, 5 November 2013 at 22:24:03 UTC, 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. The Windows installer has been replaced with the correct version which does not do this.
Re: dmd 2.064.2
I'm confused. The changelog pages links to http://ftp.digitalmars.com/dmd.2.064.zip, while the download page links to http://downloads.dlang.org/releases/2013/dmd.2.064.2.zip. Which is the correct file/version? Also, at least on OS X (with both versions) I get a link error in the wrap examples: $ rdmd main.d Undefined symbols for architecture x86_64: _D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv1302__T7forwardS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_1iS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657! 475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_2iS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_3iZ8__T3fwdZ3fwdMFNbNdNfZi, referenced from: _D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv in main.o _D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv1732__T7forwardS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_0iS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657! 475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_1iS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c6521285461726765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_2iS426_D3std8typecons26__T4wrapTC4main9IDrawableZ26__T4wrapTC4main9ImageDrawZ4Impl320__T8mixinAllVAyaa149_6f766572726964652052657475726e5479706521285461726765744d656d626572735b305d2e747970652920647261774c696e6528506172616d65746572547970655475706c65212854617! 26765744d656d626572735b305d2e7479706529206172677329207b2072657475726e205f777261705f736f757263652e647261774c696e6528666f72776172642161726773293b207dZ8drawLineMFZv8_param_3iZ8__T3fwdZ3fwdMFNbNdNfZi ... etc.
Re: dmd 2.064.2
On 11/6/2013 5:16 AM, Jordi Sayol wrote: In dmd.2.064.2.zip, src/VERSION contains 2.064. Should be 2.064.2 I deliberately didn't do that because it would have required rebuilding all the binaries just for that.
Re: dmd 2.064.2
On 11/6/2013 4:34 AM, Leandro Lucarella wrote: Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2
Re: dmd 2.064.2
On 11/6/2013 11:22 AM, Andrei Alexandrescu wrote: I confirm that. Walter, could this have something to do with the new approach to compiling templates? It might. You can confirm by seeing if it works with -allinst switch.
Re: dmd 2.064.2
On 11/6/13 11:56 AM, Walter Bright wrote: On 11/6/2013 11:22 AM, Andrei Alexandrescu wrote: I confirm that. Walter, could this have something to do with the new approach to compiling templates? It might. You can confirm by seeing if it works with -allinst switch. I confirm it works when compiled with -allinst. Andrei
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 19:57:40 UTC, Walter Bright wrote: On 11/6/2013 4:34 AM, Leandro Lucarella wrote: Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 But were there 2.064 and 2.064.1 releases? If I'm not mistaken the last release was 2.063.2 (at least judging by the website), next major release should be 2.064, not 2.064.1 or 2.064.2 (those are patch releases, not major ones). If 2.064.1 was a RC then it was badly named. As IMHO RC versions must be marked with rc, as betas are marked with b flag. Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ... This (-rc.xx) is how RC versions should be marked as per SEMVER standard (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard. Other than this thing with versioning I must say that I'm very pleased with changes in this version, so congrats to all people involved! :)
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 20:06:54 UTC, Andrei Alexandrescu wrote: On 11/6/13 11:56 AM, Walter Bright wrote: It might. You can confirm by seeing if it works with -allinst switch. I confirm it works when compiled with -allinst. Is that switch new? It is not documented in the changelog.
Re: dmd 2.064.2
On Tue, 05 Nov 2013 14:08:50 -0800, 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 First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs. Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release. Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064. Many thanks again for a great programming language, Jonathan from EMSI
Re: dmd 2.064.2
On Wed, 06 Nov 2013 20:27:01 +, Jonathan Crapuchettes wrote: On Tue, 05 Nov 2013 14:08:50 -0800, 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 First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs. Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release. Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064. Many thanks again for a great programming language, Jonathan from EMSI I just double checked the code in issue 10690 and it works just fine. I had assumed that my code was similar enough to not have been worth an additional bug report. I was wrong. I'll log a bug report and try to work around the assertion failure in std.algorithm. Thanks again, Jonathan
Re: Visual D 0.3.37 released
On Wednesday, 6 November 2013 at 17:49:57 UTC, Dicebot wrote: Picking common standard for all possible IDE's scales better than cloning approach of a single one (especially if this one is closed and known of forcing closed ecosystems) Essentially, dub. I'm okay with that decision :-P
Re: dmd 2.064.2
Is it possible to build something like wrap, so that it can be given a wrapping class instead of a wrapping interface? I was trying to build something very similar to wrap, and at first glance it seems like wrap might suit me, except that I wanted to wrap the wolf in the class Sheeps clothes, not in an ISheep. (typecons.d(2864): Error: class std.typecons.wrap!(B).wrap!(A).Impl base type must be interface, not main.B)
Re: dmd 2.064.2
On Wed, 06 Nov 2013 20:37:56 +, Jonathan Crapuchettes wrote: On Wed, 06 Nov 2013 20:27:01 +, Jonathan Crapuchettes wrote: On Tue, 05 Nov 2013 14:08:50 -0800, 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 First, I would like to thank everyone who has put hard work into the latest release and am really excited about the enhancements and fixed bugs. Second, I agree with others that this should have been 2.064, not 2.064.2. This is an initial release not a patch/minor release. Third, the fix for the issue at https://d.puremagic.com/issues/ show_bug.cgi?id=10690 was not included in the release and is a blocking bug for my company's code base. Till there is a new release with that fix included, we will not be able to use 2.064. Many thanks again for a great programming language, Jonathan from EMSI I just double checked the code in issue 10690 and it works just fine. I had assumed that my code was similar enough to not have been worth an additional bug report. I was wrong. I'll log a bug report and try to work around the assertion failure in std.algorithm. Thanks again, Jonathan Disregard the last post. The issue still exists; I was just looking at the wrong file.
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 20:11:13 UTC, Aleksandar Ruzicic wrote: versions must be marked with rc, as betas are marked with b flag. Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ... This (-rc.xx) is how RC versions should be marked as per SEMVER standard (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard. The D version numbers fail requirement 2 of semantic versioning: 2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. I know that was discussed somewhere, but I don't know/recall why there is a leading zero in the minor version number.
Re: dmd 2.064.2
On 2013-11-06 20:57, Walter Bright wrote: It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's what's happening if you start to add new digits. The first release should have possibly been 2.064.0. BTW, there was a 2.063.1, if I recall correctly. -- /Jacob Carlborg
Re: dmd 2.064.2
On Wednesday, 6 November 2013 at 20:46:23 UTC, Luís Marques wrote: Is it possible to build something like wrap, so that it can be given a wrapping class instead of a wrapping interface? I was trying to build something very similar to wrap, and at first glance it seems like wrap might suit me, except that I wanted to wrap the wolf in the class Sheeps clothes, not in an ISheep. (typecons.d(2864): Error: class std.typecons.wrap!(B).wrap!(A).Impl base type must be interface, not main.B) classes have implementations and state you need to initialize. It's possible to implement that in wrap but more problematic.
dmd package numbering scheme - Build Master wanted
There have been a lot of comments about the package naming scheme and numbering scheme. I confess that these issues do not seem that important to me, as the user just clicks on a url, but I recognize that they are very important to others. This is why I believe that D needs a Build Master. This person needs to be someone who ensures that the packages are all properly built, the build scripts work, the versions are done right, the git tags are done, etc., and takes pride in it being done to perfection. (Note that because dmd changes constantly, and the operating system targets also change constantly, the package build scripts constantly break.) Eventually, I'd like at least the package builds to be done automatically by Brad's autotester. But someone still needs to make sure it is working properly and keeps working properly.
Re: dmd package numbering scheme - Build Master wanted
On Wednesday, 6 November 2013 at 21:25:46 UTC, Walter Bright wrote: There have been a lot of comments about the package naming scheme and numbering scheme. I confess that these issues do not seem that important to me, as the user just clicks on a url, but I recognize that they are very important to others. This is why I believe that D needs a Build Master. This person needs to be someone who ensures that the packages are all properly built, the build scripts work, the versions are done right, the git tags are done, etc., and takes pride in it being done to perfection. (Note that because dmd changes constantly, and the operating system targets also change constantly, the package build scripts constantly break.) Eventually, I'd like at least the package builds to be done automatically by Brad's autotester. But someone still needs to make sure it is working properly and keeps working properly. It might need to be multiple people because very few people are experts in every platform supported. Maybe a release manager with more platform lieutenants to help. In any case, I think this is a good idea. Nick's tool should help whomever takes on this job until the autotester stuff is in place: https://github.com/D-Programming-Language/installer/pull/24
Re: dmd package numbering scheme - Build Master wanted
On 11/6/2013 1:43 PM, Brad Anderson wrote: It might need to be multiple people because very few people are experts in every platform supported. Maybe a release manager with more platform lieutenants to help. Of course. Being in charge of something doesn't mean being expert at all of it or doing all the work - help from others will be necessary.
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 Good job everyone! DPaste is already using it
Re: dmd 2.064.2
Walter Bright, el 6 de November a las 12:01 me escribiste: On 11/6/2013 5:16 AM, Jordi Sayol wrote: In dmd.2.064.2.zip, src/VERSION contains 2.064. Should be 2.064.2 I deliberately didn't do that because it would have required rebuilding all the binaries just for that. And that's bad because ? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- The Guinness Book of Records holds the record for being the most stolen book in public libraries
Re: dmd 2.064.2
Walter Bright, el 6 de November a las 11:57 me escribiste: On 11/6/2013 4:34 AM, Leandro Lucarella wrote: Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's funny, I find it very confusing to jump from 2.064 to 2.064.2. 2.064 is implied to be 2.064.0, as version 1 is implied to be 1.0 (and as a floating point number 1 is 1.0, not 1.1). Every other project out there uses this convention. So I wonder why do you find 2.064 = 2.064.1 confusing. Looking at previous versions I just noticed you did the same with 2.063, I didn't notice then. But please, could you consider changing that naming scheme and using 2.0XX.1 as the 1st patchlevel (see the relation? :). Thanks. And I would also want to thanks for another great release, with a great changelog despite the protests! :D -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- A lo que Peperino respondióles: aquel que tenga sabañones que se los moje, aquel que padece calvicie no padece un osito, no es bueno comer lechón en día de gastritis, no mezcleis el vino con la sandía, sacad la basura después de las ocho, en caso de emergencia rompa el vidrio con el martillo, a cien metros desvio por Pavón. -- Peperino Pómoro
Re: dmd 2.064.2
Jacob Carlborg, el 6 de November a las 22:06 me escribiste: On 2013-11-06 20:57, Walter Bright wrote: It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's what's happening if you start to add new digits. The first release should have possibly been 2.064.0. BTW, there was a 2.063.1, if I recall correctly. I also have the impression I saw a 2.063.1. There are certainly posts in the devel list about that version, there is none with that version in the download directory: http://downloads.dlang.org/releases/2013/ Maybe the discussion was about 2.063.1 but then Walter name it 2.063.2, or maybe it was removed from the web server? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Software is like sex: it's better when it's free. -- Linus Torvalds
Re: dmd 2.064.2
, el 6 de November a las 21:53 me escribiste: On Wednesday, 6 November 2013 at 20:11:13 UTC, Aleksandar Ruzicic wrote: versions must be marked with rc, as betas are marked with b flag. Something like 2.064-rc.1, 2.064-rc.2, ... 2.064 (stable/major release), 2.064.1 (patch release), ... This (-rc.xx) is how RC versions should be marked as per SEMVER standard (http://semver.org), although I know that D doesn't follow semantic versioning as defined in that standard. The D version numbers fail requirement 2 of semantic versioning: 2. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. I know that was discussed somewhere, but I don't know/recall why there is a leading zero in the minor version number. I think because back in the stone age, it was hard to sort versions like this: 1.5 and 1.15. Lexicographically speaking 1.5 1.15. I don't think there is any reason now for leading zero, just historical reasons. It would be awesome to get DMD follow semantic versioning as much as possible. Even when is not really a library, I guess the language specification can be taken as the API. The only problem is from time to time some tiny non backwards compatible changes are made and I don't anyone would like to bump the major version because of that. But I think an exception could be made for that, and I think those changes appear less and less frequently, so it shouldn't be a big issue. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- All men are born equal But quite a few get over it
Re: dmd 2.064.2
On Thursday, November 07, 2013 00:11:37 Leandro Lucarella wrote: Walter Bright, el 6 de November a las 11:57 me escribiste: On 11/6/2013 4:34 AM, Leandro Lucarella wrote: Also I find strange that the first patchlevel version is 2 and not 1. Was that intended or just an error? It was intended. I felt that 2.064 = 2.064.1 would have been confusing, hence 2.064 = 2.064.2 That's funny, I find it very confusing to jump from 2.064 to 2.064.2. 2.064 is implied to be 2.064.0, as version 1 is implied to be 1.0 (and as a floating point number 1 is 1.0, not 1.1). Every other project out there uses this convention. So I wonder why do you find 2.064 = 2.064.1 confusing. Yeah. Going from 2.064 or 2.064.0 to 2.064.1 would be pretty standard. Jumping straight from 2.064 to 2.064.2 is what's likely to confuse most people. Looking at previous versions I just noticed you did the same with 2.063, I didn't notice then. But please, could you consider changing that naming scheme and using 2.0XX.1 as the 1st patchlevel (see the relation? I had assumed that there was a 2.063.1 prior to 2.063.2 but clearly wasn't paying enough attention. - Jonathan M Davis
Re: dmd 2.064.2
On 11/6/2013 3:43 PM, nazriel wrote: Good job everyone! DPaste is already using it Nice!
Re: dmd 2.064.2
On 11/6/2013 3:20 PM, Leandro Lucarella wrote: Walter Bright, el 6 de November a las 12:01 me escribiste: On 11/6/2013 5:16 AM, Jordi Sayol wrote: In dmd.2.064.2.zip, src/VERSION contains 2.064. Should be 2.064.2 I deliberately didn't do that because it would have required rebuilding all the binaries just for that. And that's bad because ? Time, and then wondering what is different when it isn't different
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Wednesday, 6 November 2013 at 18:15:58 UTC, Andrej Mitrovic wrote: On 11/6/13, Sergei Nosov sergei.no...@gmail.com wrote: It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup. Btw, which compiler are you using? Could you try running on LDC/GDC if you have that installed and see if there's any performance difference? I would have tried this myself on Windows, but LDC produces crashing apps, and the last version of a packaged GDC zip file doesn't work either. It gets me some errors when building with LDC: Error: ~/dchip/.dub/build/demo-debug-x86_64-ldmd2-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/new_demo: No such file or directory But it produces cpConstraint executable, which runs, and shows the demos. The heaviest I found was on the letter G (you have a screenshot of this demo on github). I don't have the numbers (I didn't find where to look for the FPS), but it hinders exactly the same as dmd. I didn't have a chance to look more closely, maybe it's just me.
Re: Visual D 0.3.37 released
On 06.11.2013 09:25, Alexander Bothe wrote: On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Yeah, being able to get releases out more often, and having bug fixes being tested in the field would be nice. But I think we should not over-engineer things here. Do you have a web-server that could do the compilation? Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. The component being used by Visual D is a local COM server, I'm not sure if it is good to have that in a user folder. What do you think about this?
Re: Visual D 0.3.37 released
On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze wrote: On 06.11.2013 09:25, Alexander Bothe wrote: On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote: Note: I saw Alexander Bothe released an update to the parser one day after your release... ;) Sure, there have been a couple of critical regression bugs in the parser engine. Furthermore, I re-enabled the ufcs completion. Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup. An automated build system which simply calls git pull and xbuild DParser2/DParser2.csproj already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild. It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed. Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc. Yeah, being able to get releases out more often, and having bug fixes being tested in the field would be nice. But I think we should not over-engineer things here. Do you have a web-server that could do the compilation? No - I just have got a normal dedicated web-server thingy for phpmysql ^_^ But well, just a very small infrastructure that allows us to update software more often - a couple of hours ago I implemented this new eponymous template syntax..and now you had to release another VisualD to have it in there, right? Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update. The component being used by Visual D is a local COM server, I'm not sure if it is good to have that in a user folder. Okay, it's probably safer to let the user decide when to update only.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
The C library is relatively small, clocking in at about ~11.000 lines Do I right understand that rewriting code from C to D did not make it's more compact? I tried to calculate D source lines, and get ~11.000
Re: Let them break the site!
On 2013-11-06 18:41, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1q1dct/d_release_2064_is_out_with_35_enhancements_and/ Are we even ready to announce this yet? I though we were in the release candidate phase. -- /Jacob Carlborg
Re: dmd 2.064.2
On 2013-11-05 23:08, 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 The changelog is missing issue 10700. I though that part was automatically generated. -- /Jacob Carlborg
Re: dmd package numbering scheme - Build Master wanted
Good to have a thread on it, thank you for taking this step Walter ! Although, it looks to me that the numbering scheme and the git tags are not related to the build, but rather related to the release. So you might consider a release master, not just build. This will involve doing (or delegating to the proper person) the changelog, define a release cycle, which will include pre-release (rc / sanity check), release (communication / building / test / upload ...), and possibly post-release (be sure the security fixes are being backported to the supported versions, ie) actions. IMO that would be very beneficial for D to have someone holding that role. 2013/11/7 Walter Bright newshou...@digitalmars.com On 11/6/2013 1:43 PM, Brad Anderson wrote: It might need to be multiple people because very few people are experts in every platform supported. Maybe a release manager with more platform lieutenants to help. Of course. Being in charge of something doesn't mean being expert at all of it or doing all the work - help from others will be necessary.
