Re: DVM - D Version Manager 0.4.0
On 2012-01-07 21:39, Nick Sabalausky wrote: Nick Sabalauskya@a.a wrote in message news:jeaaae$304r$1...@digitalmars.com... Jacob Carlborgd...@me.com wrote in message news:je9fbv$1heb$2...@digitalmars.com... I would really like to do a complete rewrite of the tool, the internals. Well actually more of a complete refactoring so DVM can be built as a library and the tool uses the library. This would make things like the above much easier to integrate. Interesting. Do you have any sort of idea on when, or a rough roadmap? Or is it one of those One of things days if I get around to it sort of thing (that I'm all too familiar with myself!)? I guess what I'm really getting at is: Is the refactoring you have in mind something that should ideally come before other new features? Or would that not really matter? Ideally it should come before other new features. I mean, the more stuff we put in there the more mess it will be. The point of the refactoring is of course to make it easier to add new features and to understand the code. I'm not really sure about the road map. I'm currently focusing on Orbit, the package manager I'm developing. Also the main goal of DVM is already done. Hopefully I can squeeze in some time to work on DVM before the first release of Orbit. About the refactoring, what to you think about these: * Move to git * Move to github * Port to D2, still using Tango -- /Jacob Carlborg
Re: Visual D 0.3.30 released: Code completion from semantic analysis on the horizon
On Sat, Jan 7, 2012 at 8:41 AM, Rainer Schuetze r.sagita...@gmx.de wrote: Hi, I'd like to announce the release of a new version of Visual D. Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-2010 and 11 as well as the free Visual Studio Shells. Highlights of this version 0.3.30 include - syntax highlighting improvements regarding scope(guard), __ctfe, is, in and predefined versions - added checkbox for options -gs and -property to project configuration - debugger and build improvements - experimental: code completion and tool tips from semantic analysis of source code See http://www.dsource.org/projects/visuald/wiki/VersionHistory for a full list of changes. The code completion from semantic analysis is not complete yet, but I think it can already be very helpful. You'll have to enable it explicitly in the D Language options due to it's experimental status. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Have fun, Rainer Exciting! I just installed it, and I'll try it out with my latest project.
Re: DVM - D Version Manager 0.4.0
Jacob Carlborg d...@me.com wrote in message news:jec1j6$2rbu$1...@digitalmars.com... Ideally it should come before other new features. I mean, the more stuff we put in there the more mess it will be. The point of the refactoring is of course to make it easier to add new features and to understand the code. Yea, that makes sense. I guess I just wasn't sure how deep the refactoring you were envisioning was going to be. Something possibly releated I've been meaning to bring up: I've been thinking that DVM's commands and options should work more like, say, git or svn. By that I mean: Right now DVM has a set of commands, and a set of global DVM options. Problem is, some of the options only apply to some of the commands. This sugegsts a few changes: 1. dvm --help should only show globally-applicable options. (--verbose and --help are probably only ones right now.) 2. dvm [command] --help (and maybe dvm --help [command], too) should show a command-specific help screen. This isn't a *huge* need right now, but I think it'll only become more and more important as DVM progresses. I don't know if this is something that should be taken into account in the refactoring, or just left until after. Another thing that might need to be considered in the refactoring: On Linux, DVM doesn't currently work inside a shell script. It's just not recognized. I'm sure it probably has something to do with the dvm shell-function. Maybe it's because it's set to only be defined on interactive prompts? I don't really know for certain what the problem or the solution is, so depending on whatever the right solution is, this might be a take into account in the refactoring matter. About the refactoring, what to you think about these: * Move to git I don't have a really strong opinion on that. While I kind of like Hg a little better, I normally use the Tortoise tools, and I like TortoiseGit much better than TortoiseHg. Also branching is built into Git rather than being a grafted-on extra, which is nice. (And of course, DVM goes hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards Git, but either way works. * Move to github It's ultimately up to you, but personally I can't stand Github. My vote would be to stick with Bitbucket. Granted, I haven't actually tried Bitbucket's Git support yet. But just yesterday I started the process of converting a couple of my projects from SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you know. * Port to D2, still using Tango I'm definitely in favor of switching to D2. In fact, I took the leap from D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so I have some experience in that (and D2's only gotten better since), and I'd be happy to take the lead converting it to D2. I found that the vast majority of changes I needed to make were Tango-Phobos because, while there are some breaking changes from D1-D2, most of the changes are additive, and D1-style code works fine in D2 with only very little change. As far as Tango: I have no idea what the state of D2's Tango is, and personally I'd prefer Phobos. But if you have reason to believe D2's Tango is ready to use and you'd prefer that, then I'm perfectly fine with it. Actually, heck, if we're going to switch to D2, we may as well at least give D2's Tango a try along the way. If it works, it works, if it doesn't we can help out D2's Tango or just do Phobos (especially since 2.058 will have that new curl module).
Re: DVM - D Version Manager 0.4.0
Nick Sabalausky a@a.a wrote in message news:jecuno$18e6$1...@digitalmars.com... Something possibly releated I've been meaning to bring up: I've been thinking that DVM's commands and options should work more like, say, git or svn. By that I mean: Right now DVM has a set of commands, and a set of global DVM options. Problem is, some of the options only apply to some of the commands. This sugegsts a few changes: 1. dvm --help should only show globally-applicable options. (--verbose and --help are probably only ones right now.) 2. dvm [command] --help (and maybe dvm --help [command], too) should show a command-specific help screen. 3. Use of inapplicable options, like dvm --default fetch 2.057, should be an error. This isn't a *huge* need right now, but I think it'll only become more and more important as DVM progresses. I don't know if this is something that should be taken into account in the refactoring, or just left until after.
Re: cl4d OpenCL wrapper moved to Github
On Fri 30-Dec 10:00, Stephan wrote:
On 29.12.2011 13:31, Trass3r wrote:
On Thursday, 29 December 2011 at 10:32:49 UTC, Extrawurst wrote:
nice work. why moved to github ?
I'm sick of having to switch from git to hg commands every time I work
on cl4d.
So I converted it to git, cleaned up the history and just put it on
Github cause it has nicer features.
btw. with dmd2057 and the -property flag it does not build anymore.
I see, haven't used that switch yet.
ok i can just use the c header ports, the wrapper just makes dmd choke
Stack Overflow with this simple cmd line:
dmd opencl\c\cl.d opencl\c\cl_ext.d opencl\c\cl_gl.d
opencl\c\cl_gl_ext.d opencl\c\cl_platform.d opencl\c\opencl.d
opencl\all.d opencl\buffer.d opencl\commandqueue.d opencl\context.d
opencl\device.d opencl\error.d opencl\event.d opencl\host.d
opencl\image.d opencl\kernel.d opencl\memory.d opencl\platform.d
opencl\program.d opencl\sampler.d opencl\wrapper.d
Heh, I was just going to post about that too, guess I'll post it here:
(using dmd 2.057, eclipse+DDT, win7 x64)
Hi,
I'm trying to use cl4d, but when I compile I get a stack overflow..
This happens on the CLGLInterop.d example in the cl4d source.
After some stripping down, it seems just an empty module with an empty
main() and an import opencl.all is enough to trigger the overflow:
--
module CLGLInterop;
import opencl.all;
void main(){}
--
Here's the verbose compile output:
Build Commands:
-odbin
-ofbin\test.exe
-Isrc
src\CLGLInterop.d
-v
-d
-IC:\_prog\D\custom2\derelict\import\
-IC:\_prog\D\custom2\cl4d\import\
binaryC:\_prog\D\dmd2\windows\bin\dmd.exe
version v2.057
configC:\_prog\D\dmd2\windows\bin\sc.ini
parse CLGLInterop
importall CLGLInterop
importobject
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\object.di)
importopencl.all(C:\_prog\D\custom2\cl4d\import\opencl\all.d)
importopencl.c.opencl
(C:\_prog\D\custom2\cl4d\import\opencl\c\opencl.d)
importopencl.c.cl (C:\_prog\D\custom2\cl4d\import\opencl\c\cl.d)
importopencl.c.cl_platform
(C:\_prog\D\custom2\cl4d\import\opencl\c\cl_platform.d)
importstd.conv
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d)
importcore.stdc.math
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\math.di)
importcore.stdc.config
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\config.di)
importcore.stdc.string
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\string.di)
importcore.stdc.stddef
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\stddef.di)
importstd.algorithm
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d)
importstd.c.string
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\c\string.d)
importstd.array
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\array.d)
importcore.memory
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\memory.di)
importcore.bitop
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\bitop.di)
importstd.ascii
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\ascii.d)
importstd.exception
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\exception.d)
importstd.range
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\range.d)
importstd.functional
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\functional.d)
importstd.metastrings
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\metastrings.d)
importstd.traits
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\traits.d)
importstd.typetuple
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\typetuple.d)
importstd.typecons
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\typecons.d)
importcore.stdc.stdlib
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\stdlib.di)
importstd.format
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\format.d)
importcore.stdc.stdio
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\stdio.di)
importcore.stdc.stdarg
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\stdc\stdarg.di)
importcore.vararg
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\vararg.di)
importstd.bitmanip
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\bitmanip.d)
importstd.math
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\math.d)
importstd.string
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\string.d)
importcore.exception
(C:\_prog\D\dmd2\windows\bin\..\..\src\druntime\import\core\exception.di)
importstd.regex
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\regex.d)
importstd.internal.uni
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\internal\uni.d)
importstd.uni (C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d)
importstd.internal.uni_tab
(C:\_prog\D\dmd2\windows\bin\..\..\src\phobos\std\internal\uni_tab.d)
importstd.utf
Re: cl4d OpenCL wrapper moved to Github
I'm trying to use cl4d, but when I compile I get a stack overflow.. Sigh. As I stated in the announcement you need a HEAD dmd. Or use a cl4d revision prior to the mentioned bugfix.
Re: cl4d OpenCL wrapper moved to Github
On Sun 08-Jan 22:53, Trass3r wrote: I'm trying to use cl4d, but when I compile I get a stack overflow.. Sigh. As I stated in the announcement you need a HEAD dmd. Or use a cl4d revision prior to the mentioned bugfix. Oh I think I now get what you mean by HEAD dmd: the latest version on github. I've never compiled dmd myself so that didn't even occur to me.. About the 'mentioned bugfix', I assume you're referring to bug 6473 has been fixed = so let's fix that memory leak?
Re: cl4d OpenCL wrapper moved to Github
About the 'mentioned bugfix', I assume you're referring to bug 6473 has been fixed = so let's fix that memory leak? Yep, just git checkout the revision before that one.
Re: cl4d OpenCL wrapper moved to Github
On Mon 09-Jan 0:05, Trass3r wrote: About the 'mentioned bugfix', I assume you're referring to bug 6473 has been fixed = so let's fix that memory leak? Yep, just git checkout the revision before that one. Ok, so when i try to compile it says src\opencl\c\cl_d3d10.d(88): Error: undefined identifier UINT src\opencl\c\cl_d3d10.d(96): Error: undefined identifier UINT and upon changing those to uint I get src\opencl\c\cl_d3d11.d(77): Error: undefined identifier ID3D11Buffer src\opencl\c\cl_d3d11.d(84): Error: undefined identifier ID3D11Texture2D src\opencl\c\cl_d3d11.d(91): Error: undefined identifier ID3D11Texture3D What am I missing?
Re: cl4d OpenCL wrapper moved to Github
Ok, so when i try to compile it says src\opencl\c\cl_d3d10.d(88): Error: undefined identifier UINT src\opencl\c\cl_d3d10.d(96): Error: undefined identifier UINT and upon changing those to uint I get src\opencl\c\cl_d3d11.d(77): Error: undefined identifier ID3D11Buffer src\opencl\c\cl_d3d11.d(84): Error: undefined identifier ID3D11Texture2D src\opencl\c\cl_d3d11.d(91): Error: undefined identifier ID3D11Texture3D What am I missing? Well the DirectX stuff isn't tested at all. I always compile with rdmd so these modules aren't compiled. The uint errors are small cases I overlooked. The rest is obvious: cl4d knows nothing about DirectX, so you need a binding. Maybe I should just turn these into void* to get rid of the errors, but then you loose type safety, hmm.
Re: DVM - D Version Manager 0.4.0
On 2012-01-08 21:34, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:jec1j6$2rbu$1...@digitalmars.com... Ideally it should come before other new features. I mean, the more stuff we put in there the more mess it will be. The point of the refactoring is of course to make it easier to add new features and to understand the code. Yea, that makes sense. I guess I just wasn't sure how deep the refactoring you were envisioning was going to be. Quite deep. I want to have it look more like Orbit: https://github.com/jacob-carlborg/orbit Instead of having all code in the commands I want to have a single class for a single task. The commands would then basically just create a new instance of the needed classes. Something possibly releated I've been meaning to bring up: I've been thinking that DVM's commands and options should work more like, say, git or svn. By that I mean: Right now DVM has a set of commands, and a set of global DVM options. Problem is, some of the options only apply to some of the commands. This sugegsts a few changes: 1. dvm --help should only show globally-applicable options. (--verbose and --help are probably only ones right now.) 2. dvm [command] --help (and maybe dvm --help [command], too) should show a command-specific help screen. This isn't a *huge* need right now, but I think it'll only become more and more important as DVM progresses. I don't know if this is something that should be taken into account in the refactoring, or just left until after. Yeah, I know. That would be another reason to do the refactoring. Another thing that might need to be considered in the refactoring: On Linux, DVM doesn't currently work inside a shell script. It's just not recognized. I'm sure it probably has something to do with the dvm shell-function. Maybe it's because it's set to only be defined on interactive prompts? I don't really know for certain what the problem or the solution is, so depending on whatever the right solution is, this might be a take into account in the refactoring matter. I didn't know about that. I'll take a look at that. About the refactoring, what to you think about these: * Move to git I don't have a really strong opinion on that. While I kind of like Hg a little better, I normally use the Tortoise tools, and I like TortoiseGit much better than TortoiseHg. Also branching is built into Git rather than being a grafted-on extra, which is nice. (And of course, DVM goes hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards Git, but either way works. I've moved all my projects to git, use it at work, so I prefer it over mercurial. * Move to github It's ultimately up to you, but personally I can't stand Github. My vote would be to stick with Bitbucket. Granted, I haven't actually tried Bitbucket's Git support yet. But just yesterday I started the process of converting a couple of my projects from SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you know. I'm asking you since you're the main contributor next to me. I prefer Github, many D project are moving to Github, DMD, Phobos and druntime are already there. But certainly don't want to push you away, that wouldn't be good for the Windows port :) * Port to D2, still using Tango I'm definitely in favor of switching to D2. In fact, I took the leap from D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so I have some experience in that (and D2's only gotten better since), and I'd be happy to take the lead converting it to D2. I found that the vast majority of changes I needed to make were Tango-Phobos because, while there are some breaking changes from D1-D2, most of the changes are additive, and D1-style code works fine in D2 with only very little change. As far as Tango: I have no idea what the state of D2's Tango is, and personally I'd prefer Phobos. But if you have reason to believe D2's Tango is ready to use and you'd prefer that, then I'm perfectly fine with it. Actually, heck, if we're going to switch to D2, we may as well at least give D2's Tango a try along the way. If it works, it works, if it doesn't we can help out D2's Tango or just do Phobos (especially since 2.058 will have that new curl module). I'm pretty sure Tango for D2 is ready enough. I got help porting my package manager, Orbit, to D2 using Tango. Everything compiles but not everything works, probably something D2 and Ruby related (TLS or something like that). But it was surprisingly few changes that needed to be done and that is all to Tango working with D2. The biggest problem would be to port the tool to use Phobos instead of Tango. I guess it would be best to start by adding some high level tests to DVM. You probably won't like this but there's a great Ruby tool for testing these kind of things called Cucumber. I'm already using it in Orbit: https://github.com/jacob-carlborg/orbit/tree/master/features -- /Jacob
