www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Unofficial DVM Windows Beta

reply "Nick Sabalausky" <a a.a> writes:
I've been working on a fork of Jacob Carlborg's excellent DVM tool (D 
Version Manager) to add Windows support. It should now be fully-usable on 
Windows, with the exception of installing Tango and any post-v0.2.0 features 
(I haven't yet merged in any changes from upstream since I originally forked 
v0.2.0.) I figure I'll submit a pull request after I've gotten those 
features merged in and working.

Main page: https://bitbucket.org/Abscissa256/dvm/wiki/Home

A precompiled Windows binary is on the downloads page:

https://bitbucket.org/Abscissa256/dvm/downloads

As with the Linux version, download the precompiled binary, and then install 
it by running:

dvm-0.2.0-win-beta1 install dvm

Then you should be able to use dvm just like on Linux:

dvm --help
dvm install 2.053
dvm --default use 2.053

Etc...
Jun 04 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Some notes:

Calling dvm regardless of arguments always prints out this string at
the bottom after any info before it:
"The system cannot find the file specified."

Calling with -h or --help doesn't print out anything.
Calling dvm install or dvm fetch or dvm use without arguments throws
an out of bounds exception.

It might be useful to document where dvm installs DMD to (in appdata).
Also, I'm thinking about any problems vista/win7 users might have with
UAC, e.g. if UAC will attempt to block writing to the appdata folder.
I'm just second-guessing though, I'm not too familiar with how it
works.

If I run:

 dvm --default use 2.052


and close and start a new command shell, 2.053 will still be used.
What exactly is the use case for "dvm --default use"?

I didn't really know how to use dvm install without looking at the
linux dvm page. I attempted to just run 'dvm install' after installing
dvm, but it threw an out of bounds exception. Maybe the app should
instead print out: "install needs an argument like 'dvm install
2.053'". The same goes for other commands.

Other than that, it seems to work my system. Nice work!
Jun 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-04 17:38, Andrej Mitrovic wrote:

 Some notes:

 Calling dvm regardless of arguments always prints out this string at
 the bottom after any info before it:
 "The system cannot find the file specified."

 Calling with -h or --help doesn't print out anything.
 Calling dvm install or dvm fetch or dvm use without arguments throws
 an out of bounds exception.

 It might be useful to document where dvm installs DMD to (in appdata).
 Also, I'm thinking about any problems vista/win7 users might have with
 UAC, e.g. if UAC will attempt to block writing to the appdata folder.
 I'm just second-guessing though, I'm not too familiar with how it
 works.


Maybe it should be installed in the users home directory instead. The 
user should always be able to write to that directory. This is also 
where it's installed on Posix platforms.


 If I run:

 dvm --default use 2.052


 and close and start a new command shell, 2.053 will still be used.
 What exactly is the use case for "dvm --default use"?

 I didn't really know how to use dvm install without looking at the
 linux dvm page. I attempted to just run 'dvm install' after installing
 dvm, but it threw an out of bounds exception. Maybe the app should
 instead print out: "install needs an argument like 'dvm install
 2.053'". The same goes for other commands.

 Other than that, it seems to work my system. Nice work!



-- 
/Jacob Carlborg
Jun 04 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm ok with appdata as long as it works for everyone. I guess it
should, maybe I'm just being paranoid that it won't. (I'll test it out
soon on win7 and report). Otherwise polluting home on Windows is kind
of ugly, I'm sure Nick will agree. :)
Jun 04 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I get the same "The system cannot find the file specified." on Win7 at
the end of invoking dvm.

UAC seems to be ok with installing in appdata.

Btw, is there a shortcut for getting the latest DMD release? E.g.
something like:
dvm install 2.x, for the latest 2.x release?

Also I still can't get --default to work, neither XP or Win7.
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.628.1307208393.14074.digitalmars-d-announce puremagic.com...

 Btw, is there a shortcut for getting the latest DMD release? E.g.
 something like:
 dvm install 2.x, for the latest 2.x release?


There currently isn't, but that's a very good idea. One of the great things 
about DVM is that it's fantastic for first-time D users, but we shouldn't 
expect such newbies to know what version they want or what the latest 
version is.

Just brainstorming here: I think the best way to handle this would involve 
somehow finding out the latest version from digitalmars.com. It definitely 
wouldn't be good if a DVM developer needed to manually update something 
every time Walter issues a release. But we also wouldn't want to try to 
force another TODO onto Walter's plate whenever he pushes a DMD update. DVM 
could try different download URLs and see which is the highest version 
number that doesn't 404, but that's obviously an ugly resource-intensive 
kludge.

The best thing I can think of right now would be to download the changelog 
page on digitalmars.com and scrape that to find the latest version. Maybe we 
could have some web server automatically do it at regular intervals (twice 
daily?) and provide a simple "latest-dmd2" and "latest-dmd1" URL which would 
just return the right version number.

Jacob: Your thoughts?
Jun 05 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-06-05 09:39, Nick Sabalausky wrote:

 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.628.1307208393.14074.digitalmars-d-announce puremagic.com...

 Btw, is there a shortcut for getting the latest DMD release? E.g.
 something like:
 dvm install 2.x, for the latest 2.x release?


 There currently isn't, but that's a very good idea. One of the great things
 about DVM is that it's fantastic for first-time D users, but we shouldn't
 expect such newbies to know what version they want or what the latest
 version is.

 Just brainstorming here: I think the best way to handle this would involve
 somehow finding out the latest version from digitalmars.com. It definitely
 wouldn't be good if a DVM developer needed to manually update something
 every time Walter issues a release. But we also wouldn't want to try to
 force another TODO onto Walter's plate whenever he pushes a DMD update. DVM
 could try different download URLs and see which is the highest version
 number that doesn't 404, but that's obviously an ugly resource-intensive
 kludge.

 The best thing I can think of right now would be to download the changelog
 page on digitalmars.com and scrape that to find the latest version. Maybe we
 could have some web server automatically do it at regular intervals (twice
 daily?) and provide a simple "latest-dmd2" and "latest-dmd1" URL which would
 just return the right version number.

 Jacob: Your thoughts?


I have previously asked about a symlink on the digitalmars ftp to point 
to the latest release. That didn't happen, but I got a reply with a 
shell script finding the latest release. Here's the thread:

http://www.digitalmars.com/d/archives/digitalmars/D/Symlink_to_Latest_dmd_on_the_Digital_Mars_FTP_126791.html

I guess this can be ported to D and incorporated with DVM.

-- 
/Jacob Carlborg
Jun 05 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:isdk9m$t7p$2 digitalmars.com...

 On 2011-06-04 17:38, Andrej Mitrovic wrote:

 Some notes:

 Calling dvm regardless of arguments always prints out this string at
 the bottom after any info before it:
 "The system cannot find the file specified."

 Calling with -h or --help doesn't print out anything.
 Calling dvm install or dvm fetch or dvm use without arguments throws
 an out of bounds exception.

 It might be useful to document where dvm installs DMD to (in appdata).
 Also, I'm thinking about any problems vista/win7 users might have with
 UAC, e.g. if UAC will attempt to block writing to the appdata folder.
 I'm just second-guessing though, I'm not too familiar with how it
 works.


 Maybe it should be installed in the users home directory instead. The user 
 should always be able to write to that directory. This is also where it's 
 installed on Posix platforms.


%APPDATA% *is* inside the user's home directory. It's typically something 
like:

C:\Users\{User Name}\Application Data

(Of course, with "Documents and Settings" instead of "Users" on XP. And 
possibly a different drive on different computers, etc...)

The Unix concept of "home directory" has a few different equivalents on 
Windows, depending on the nature of the data:

C:\Users\{User Name}  aka %USERPROFILE%:
The "root" home directory, so to speak. This is only supposed to be for 
Windows to store it's own user-specific stuff (user-specific system 
settings, the desktop, start menu entries, etc), as well as all the other 
"home directories" for the user. Ie, it's for stuff that's actually part of 
Windows.

C:\Users\{User Name}\Application Data aka %APPDATA%:
This is equivalent to "~/.*" on Unix. It's where misc applications are 
supposed to store their user-specific data. Unfortunately, there are a *lot* 
of programs that misbehave and instead of using this directory when they 
should, they misuse either the previous directory or the following one:

C:\Users\{User Name}\My Documents:
This is (supposed to be) exclusively for data the user actually creates (or 
downloads, etc). Such as *DOCUMENTS*, for example. Etc.

And then just for fun, there's also:
C:\Users\{User Name}\Local Settings\Application Data:
I'm not certain, but I *think* this is for when a single user account is 
usable on multiple computers, then this is like %APPDATA% but for things 
that are specific to just the local machine.

As long as I'm talking about all this, I may as well also point out FWIW 
that Windows stores *both* the system environment variables and the user's 
environment variables in the registry. I don't remember what key the system 
environment vars are in, but the user's environment vars are in: 
"KHEY_CURRENT_USER\Environment"


 If I run:

 dvm --default use 2.052


 and close and start a new command shell, 2.053 will still be used.
 What exactly is the use case for "dvm --default use"?




Hmm, I'll have to look into it. That's the last thing I added, and it was 
really late and I really should have been asleep ;) Maybe I managed to screw 
it up...

Can you try one thing for me though? In the new shell, when it's not using 
the default it's supposed to be using, what do you get when you do "echo 
%DVM%"?

It *should* have two things (separated by semicolon):
%APPDATA%\dvm\compilers\dmd-{default dmd version}\bin
%APPDATA%\dvm\bin

(%APPDATA% will actually be expanded, I only wrote it there for brevity.)


 I didn't really know how to use dvm install without looking at the
 linux dvm page. I attempted to just run 'dvm install' after installing
 dvm, but it threw an out of bounds exception. Maybe the app should
 instead print out: "install needs an argument like 'dvm install
 2.053'". The same goes for other commands.




At the moment, the upstream DVM doesn't do much cmdline param validation 
either. See this ticket:
https://bitbucket.org/doob/dvm/issue/7/no-error-on-invalid-command

You're right that needs to be done, but my top priority with this right now 
is to bring it in sync with the Linux DVM. Then I'll be better able to help 
out with cross-platform enhancements like this.

Regarding the message "The system cannot find the file specified.", I'll 
check, but I'm pretty sure that's just the part where the batch wrapper 
tries to delete DVM's "tmp" directory after running the dvm binary (which 
doesn't always create/use the tmp dir). I don't know why I wasn't getting 
that message too, but regardless, it's an easy fix (assuming it's what I 
think it is).


 Other than that, it seems to work my system. Nice work!




Thanks! :)
Jun 04 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ise6ef$1pbt$1 digitalmars.com...

 "Jacob Carlborg" <doob me.com> wrote in message 
 news:isdk9m$t7p$2 digitalmars.com...

 If I run:

 dvm --default use 2.052


 and close and start a new command shell, 2.053 will still be used.
 What exactly is the use case for "dvm --default use"?




 Hmm, I'll have to look into it. That's the last thing I added, and it was 
 really late and I really should have been asleep ;) Maybe I managed to 
 screw it up...

 Can you try one thing for me though? In the new shell, when it's not using 
 the default it's supposed to be using, what do you get when you do "echo 
 %DVM%"?

 It *should* have two things (separated by semicolon):
 %APPDATA%\dvm\compilers\dmd-{default dmd version}\bin
 %APPDATA%\dvm\bin

 (%APPDATA% will actually be expanded, I only wrote it there for brevity.)


Something I just thought of: When you start a new command prompt, Windows 
puts the system PATH ahead of the user's PATH. DVM currently only installs 
things for the local user (that's the way it currently does it on Linux, 
too). So if you already have 2.053 in your *system* path, then Windows will 
find and use that before it ever gets to the path DVM installs.

Could you see if that's maybe what's happening for you?

I'll have to think about how to handle that situation. Not sure if I should 
just tell the user about it, or try to find/remove dmd from the system path 
(maybe with prompting?), etc...
Jun 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-04 22:57, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isdk9m$t7p$2 digitalmars.com...

 On 2011-06-04 17:38, Andrej Mitrovic wrote:

 Some notes:

 Calling dvm regardless of arguments always prints out this string at
 the bottom after any info before it:
 "The system cannot find the file specified."

 Calling with -h or --help doesn't print out anything.
 Calling dvm install or dvm fetch or dvm use without arguments throws
 an out of bounds exception.

 It might be useful to document where dvm installs DMD to (in appdata).
 Also, I'm thinking about any problems vista/win7 users might have with
 UAC, e.g. if UAC will attempt to block writing to the appdata folder.
 I'm just second-guessing though, I'm not too familiar with how it
 works.


 Maybe it should be installed in the users home directory instead. The user
 should always be able to write to that directory. This is also where it's
 installed on Posix platforms.


 %APPDATA% *is* inside the user's home directory. It's typically something
 like:

 C:\Users\{User Name}\Application Data

 (Of course, with "Documents and Settings" instead of "Users" on XP. And
 possibly a different drive on different computers, etc...)


Ah, Ok.

-- 
/Jacob Carlborg
Jun 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
P.S. Turns out I'm a little silly for not realizing that I can use
'dvm install 2.053', since it was mentioned in your post.
Jun 04 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-04 12:44, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable on
 Windows, with the exception of installing Tango and any post-v0.2.0 features
 (I haven't yet merged in any changes from upstream since I originally forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.


This is great news, I'll merge your changes as soon as you are ready for 
a pull request. I'm interested in knowing how the "use" command works. 
I've quickly skimmed through your code and noticed some references to 
the registry that I suspect has something to do with it. This was the 
biggest obstacle for me to implement a Windows version.

-- 
/Jacob Carlborg
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:isdk4u$t7p$1 digitalmars.com...

 On 2011-06-04 12:44, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable on
 Windows, with the exception of installing Tango and any post-v0.2.0 
 features
 (I haven't yet merged in any changes from upstream since I originally 
 forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.


 This is great news, I'll merge your changes as soon as you are ready for a 
 pull request. I'm interested in knowing how the "use" command works. I've 
 quickly skimmed through your code and noticed some references to the 
 registry that I suspect has something to do with it. This was the biggest 
 obstacle for me to implement a Windows version.


Yea, I intended to explain all of that on the wiki down in the "Technical 
Differences From Linux Version" section, but I couldn't think anymore and 
needed to go to bed ;) I'll fill that in today.
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ise6jf$1pfj$1 digitalmars.com...

 "Jacob Carlborg" <doob me.com> wrote in message 
 news:isdk4u$t7p$1 digitalmars.com...

 On 2011-06-04 12:44, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable 
 on
 Windows, with the exception of installing Tango and any post-v0.2.0 
 features
 (I haven't yet merged in any changes from upstream since I originally 
 forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.


 This is great news, I'll merge your changes as soon as you are ready for 
 a pull request. I'm interested in knowing how the "use" command works. 
 I've quickly skimmed through your code and noticed some references to the 
 registry that I suspect has something to do with it. This was the biggest 
 obstacle for me to implement a Windows version.


 Yea, I intended to explain all of that on the wiki down in the "Technical 
 Differences From Linux Version" section, but I couldn't think anymore and 
 needed to go to bed ;) I'll fill that in today.


All the technical details you should need to know are up on the Wiki now:
https://bitbucket.org/Abscissa256/dvm/wiki/Home

Let me know if anything's missing or you're unclear on something (or have 
any other questions).
Jun 04 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:isekt3$2e96$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:ise6jf$1pfj$1 digitalmars.com...

 "Jacob Carlborg" <doob me.com> wrote in message 
 news:isdk4u$t7p$1 digitalmars.com...

 I'm interested in knowing how the "use" command works. I've quickly 
 skimmed through your code and noticed some references to the registry 
 that I suspect has something to do with it. This was the biggest 
 obstacle for me to implement a Windows version.




 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have 
 any other questions).


Just as a quick summary of the "use" command:

Setting the default compiler with "--default" works by setting the user's 
environment vars in the registry. That's just simply how they're stored on 
Windows. (Then it broadcasts the change so you don't have to logout and back 
in again.)

Setting the current compiler (ie not the default one) works pretty much like 
the Linux version: A shell wrapper actually runs the DVM binary, which 
writes a "result" script. The shell wrapper then runs the result script, 
which invokes one of the "dvm/env/..." scripts, which sets the current cmd 
line session's path via "SET var=...blah...". Some of the details are 
slightly different, though. For instance, instead of being a shell function, 
the DVM shell wrapper is just an ordinary batch file.
Jun 04 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I think this might be a cool place to link DVM from:
http://prowiki.org/wiki4d/wiki.cgi?action=browse&amp;id=D__Tutorial/StartingWithD/Compiler/DMD&amp;oldid=D__Tutorial/InstallingDCompiler
Jun 04 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-05 03:03, Nick Sabalausky wrote:

 "Nick Sabalausky"<a a.a>  wrote in message
 news:ise6jf$1pfj$1 digitalmars.com...

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isdk4u$t7p$1 digitalmars.com...

 On 2011-06-04 12:44, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable
 on
 Windows, with the exception of installing Tango and any post-v0.2.0
 features
 (I haven't yet merged in any changes from upstream since I originally
 forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.


 This is great news, I'll merge your changes as soon as you are ready for
 a pull request. I'm interested in knowing how the "use" command works.
 I've quickly skimmed through your code and noticed some references to the
 registry that I suspect has something to do with it. This was the biggest
 obstacle for me to implement a Windows version.


 Yea, I intended to explain all of that on the wiki down in the "Technical
 Differences From Linux Version" section, but I couldn't think anymore and
 needed to go to bed ;) I'll fill that in today.


 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).


Thanks, I'll have a look.

-- 
/Jacob Carlborg
Jun 05 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-05 03:03, Nick Sabalausky wrote:

 "Nick Sabalausky"<a a.a>  wrote in message
 news:ise6jf$1pfj$1 digitalmars.com...

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isdk4u$t7p$1 digitalmars.com...

 On 2011-06-04 12:44, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable
 on
 Windows, with the exception of installing Tango and any post-v0.2.0
 features
 (I haven't yet merged in any changes from upstream since I originally
 forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.


 This is great news, I'll merge your changes as soon as you are ready for
 a pull request. I'm interested in knowing how the "use" command works.
 I've quickly skimmed through your code and noticed some references to the
 registry that I suspect has something to do with it. This was the biggest
 obstacle for me to implement a Windows version.


 Yea, I intended to explain all of that on the wiki down in the "Technical
 Differences From Linux Version" section, but I couldn't think anymore and
 needed to go to bed ;) I'll fill that in today.


 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).


I'm still having trouble understanding how the "use" command works, this 
may just be because I don't know the differences between Posix and 
Windows in this case. On Posix it behaves like this:

When I run, on the command line, an application or a shell script and it 
sets environment variables, i.e. PATH, they won't be available to the 
shell that run the app/script. This is the whole reason for the shell 
function and "sourcing" a result file on Posix.

Is this not the case when running an application or a batch script on 
Windows?

Another thing, about the dvm-default-dc and dvm-current-dc scripts. 
They're actually not really necessary on Posix for DVM to work but they 
can be used by other applications, like GUI applications.

For example, if you set the current D compiler using "dvm use 2.053" and 
want to run DMD from your editor. If you just run "dmd" it won't use 
2.053, it will use the default D compiler or it won't find DMD. Instead 
you can refer to the full path of "dvm-current-dc" which will always 
point to the current D compiler. Similar "dvm-default-dc" will always 
point the default D compiler. I don't know if Windows has this problem.

-- 
/Jacob Carlborg
Jun 05 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:isfqme$17bl$1 digitalmars.com...

 On 2011-06-05 03:03, Nick Sabalausky wrote:

 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).


 I'm still having trouble understanding how the "use" command works, this 
 may just be because I don't know the differences between Posix and Windows 
 in this case. On Posix it behaves like this:

 When I run, on the command line, an application or a shell script and it 
 sets environment variables, i.e. PATH, they won't be available to the 
 shell that run the app/script. This is the whole reason for the shell 
 function and "sourcing" a result file on Posix.

 Is this not the case when running an application or a batch script on 
 Windows?


Ok, just to be clear: My understanding of Posix is that there are two ways 
of running a shell script:

Normally:
./foo.sh

Sourcing it:
. ./foo.sh

The difference between the two is that if the script sets environment vars, 
the "normal" way will keep the env changes private to within the script 
itself, and the "sourcing" way makes them affect the shell that ran the 
script. Right?

On Windows, running a batch file is *always* equivalent to "sourcing" it. 
Batch files do not run in a new instance of the shell. (There is an 
"official" way to write the batch file to make env changes private to within 
the batch itself, but it's really screwy and not really worth bothering 
unless absolutely necessary). Although, if you just simply launch the batch 
file from the GUI, then it'll run in a temporary cmd prompt which closes as 
soon as the batch file finishes, and so naturally, any env changes won't 
outlive that temporary cmd prompt.

Now, running an *executable binary* from the Windows command prompt, I'm 
fairly sure any changes that makes to the environment are *not* visible from 
the command prompt that ran it. (Although I admit I haven't tested that.) 
Therefore, when DVM wants to set the current compiler, it has to use the 
same trick as Posix: launch the DVM binary from a batch file, and then if 
the DVM binary creates a "tmp/result.bat", the batch file will run it and 
the current environment variables will get set for the user's command 
prompt.

The only difference from Posix when setting the current compiler is that 
Windows doesn't support two things:

1. Shell functions. Where you have a "dvm" shell funtion on posix, I just 
simply have a plain old "dvm.bat" (placed inside "[dvm_install_dir]\bin\" so 
that the PATH can find it. And the DVM binary is named _dvm.exe to guarantee 
the batch file gets run instead).

2. Shell startup script. Because of this, Windows can't and doesn't have an 
equivalent of "[dvm_install_dir]/scripts/dvm.sh". Fortunately it's not 
needed, because all of the default paths (ie, the paths to DVM itself and to 
the default compiler) are set in the registry. (Technically, Windows does 
support a shell startup script, but it's really hackish and just not a good 
way to go.)

Does that help?


 Another thing, about the dvm-default-dc and dvm-current-dc scripts. 
 They're actually not really necessary on Posix for DVM to work but they 
 can be used by other applications, like GUI applications.


Ahh, I see.


 For example, if you set the current D compiler using "dvm use 2.053" and 
 want to run DMD from your editor. If you just run "dmd" it won't use 
 2.053, it will use the default D compiler or it won't find DMD. Instead 
 you can refer to the full path of "dvm-current-dc" which will always point 
 to the current D compiler. Similar "dvm-default-dc" will always point the 
 default D compiler. I don't know if Windows has this problem.


Sounds like "dvm-current-dc" would be useful on Windows, too, then. I'll add 
it in. Of course, it would always point to the most recent "dvm use xxx" 
from *any* command prompt, but I assume that's the same on Posix, too. I 
can't imagine there'd be any realistic way around that on either OS.

The "dvm-default-dc", however, shouldn't be needed on Windows. Since Windows 
stores the user's PATH and other env vars in the registry instead of a 
shell-specific script like ~/.bashrc, I'm pretty sure that the default 
compiler will work fine even from a GUI app just by running "dmd". 
(Although, come to think of it, I'm going to have to test that...) It should 
pick up the correct path from the user's PATH environment variable just like 
the command prompt would. Although, if the user changes the default compiler 
while the GUI app is running, then to pick up the new changes, the GUI app 
would have to handle the WM_SETTINGCHANGED/"Environment" message: And I 
don't know how common that is (maybe it's automatically handled by the Win 
API?) If that can't be relied on, then maybe "dvm-default-dc" would still be 
useful on Windows too. I'll look into it.
Jun 05 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-05 22:48, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isfqme$17bl$1 digitalmars.com...

 On 2011-06-05 03:03, Nick Sabalausky wrote:

 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).


 I'm still having trouble understanding how the "use" command works, this
 may just be because I don't know the differences between Posix and Windows
 in this case. On Posix it behaves like this:

 When I run, on the command line, an application or a shell script and it
 sets environment variables, i.e. PATH, they won't be available to the
 shell that run the app/script. This is the whole reason for the shell
 function and "sourcing" a result file on Posix.

 Is this not the case when running an application or a batch script on
 Windows?


 Ok, just to be clear: My understanding of Posix is that there are two ways
 of running a shell script:

 Normally:
 ./foo.sh

 Sourcing it:
 . ./foo.sh

 The difference between the two is that if the script sets environment vars,
 the "normal" way will keep the env changes private to within the script
 itself, and the "sourcing" way makes them affect the shell that ran the
 script. Right?


Yes.


 On Windows, running a batch file is *always* equivalent to "sourcing" it.
 Batch files do not run in a new instance of the shell. (There is an
 "official" way to write the batch file to make env changes private to within
 the batch itself, but it's really screwy and not really worth bothering
 unless absolutely necessary). Although, if you just simply launch the batch
 file from the GUI, then it'll run in a temporary cmd prompt which closes as
 soon as the batch file finishes, and so naturally, any env changes won't
 outlive that temporary cmd prompt.

 Now, running an *executable binary* from the Windows command prompt, I'm
 fairly sure any changes that makes to the environment are *not* visible from
 the command prompt that ran it. (Although I admit I haven't tested that.)
 Therefore, when DVM wants to set the current compiler, it has to use the
 same trick as Posix: launch the DVM binary from a batch file, and then if
 the DVM binary creates a "tmp/result.bat", the batch file will run it and
 the current environment variables will get set for the user's command
 prompt.


Ok, now I understand.


 The only difference from Posix when setting the current compiler is that
 Windows doesn't support two things:

 1. Shell functions. Where you have a "dvm" shell funtion on posix, I just
 simply have a plain old "dvm.bat" (placed inside "[dvm_install_dir]\bin\" so
 that the PATH can find it. And the DVM binary is named _dvm.exe to guarantee
 the batch file gets run instead).

 2. Shell startup script. Because of this, Windows can't and doesn't have an
 equivalent of "[dvm_install_dir]/scripts/dvm.sh". Fortunately it's not
 needed, because all of the default paths (ie, the paths to DVM itself and to
 the default compiler) are set in the registry. (Technically, Windows does
 support a shell startup script, but it's really hackish and just not a good
 way to go.)

 Does that help?


That helps, thanks.


 Another thing, about the dvm-default-dc and dvm-current-dc scripts.
 They're actually not really necessary on Posix for DVM to work but they
 can be used by other applications, like GUI applications.


 Ahh, I see.


 For example, if you set the current D compiler using "dvm use 2.053" and
 want to run DMD from your editor. If you just run "dmd" it won't use
 2.053, it will use the default D compiler or it won't find DMD. Instead
 you can refer to the full path of "dvm-current-dc" which will always point
 to the current D compiler. Similar "dvm-default-dc" will always point the
 default D compiler. I don't know if Windows has this problem.


 Sounds like "dvm-current-dc" would be useful on Windows, too, then. I'll add
 it in. Of course, it would always point to the most recent "dvm use xxx"
 from *any* command prompt, but I assume that's the same on Posix, too. I
 can't imagine there'd be any realistic way around that on either OS.


Yes, that's how it works on Posix, always points to the most recent "dvm 
use xxx".


 The "dvm-default-dc", however, shouldn't be needed on Windows. Since Windows
 stores the user's PATH and other env vars in the registry instead of a
 shell-specific script like ~/.bashrc, I'm pretty sure that the default
 compiler will work fine even from a GUI app just by running "dmd".
 (Although, come to think of it, I'm going to have to test that...) It should
 pick up the correct path from the user's PATH environment variable just like
 the command prompt would. Although, if the user changes the default compiler
 while the GUI app is running, then to pick up the new changes, the GUI app
 would have to handle the WM_SETTINGCHANGED/"Environment" message: And I
 don't know how common that is (maybe it's automatically handled by the Win
 API?) If that can't be relied on, then maybe "dvm-default-dc" would still be
 useful on Windows too. I'll look into it.


That would be great, thanks.

-- 
/Jacob Carlborg
Jun 06 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:isib2k$8h4$1 digitalmars.com...

 On 2011-06-05 22:48, Nick Sabalausky wrote:

 The "dvm-default-dc", however, shouldn't be needed on Windows. Since 
 Windows
 stores the user's PATH and other env vars in the registry instead of a
 shell-specific script like ~/.bashrc, I'm pretty sure that the default
 compiler will work fine even from a GUI app just by running "dmd".
 (Although, come to think of it, I'm going to have to test that...) It 
 should
 pick up the correct path from the user's PATH environment variable just 
 like
 the command prompt would. Although, if the user changes the default 
 compiler
 while the GUI app is running, then to pick up the new changes, the GUI 
 app
 would have to handle the WM_SETTINGCHANGED/"Environment" message: And I
 don't know how common that is (maybe it's automatically handled by the 
 Win
 API?) If that can't be relied on, then maybe "dvm-default-dc" would still 
 be
 useful on Windows too. I'll look into it.


 That would be great, thanks.



methods. It did *not* automatically pick up the changes to the env vars 
while it was running (and at at one point it even stopped picking up the 
changes at all, even after restarting the little test app. Which was weird.) 
So they need to be specifically coded to pick up env changes. I didn't test 
it from D, but something as major as .NET doesn't do it by default, then 
"dvm-default-dc" is definitely useful on Windows.

So I've added both "dvm-default-dc" and "dvm-current-dc" to my windows fork.
Jun 06 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-06-07 01:55, Nick Sabalausky wrote:

 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isib2k$8h4$1 digitalmars.com...

 On 2011-06-05 22:48, Nick Sabalausky wrote:

 The "dvm-default-dc", however, shouldn't be needed on Windows. Since
 Windows
 stores the user's PATH and other env vars in the registry instead of a
 shell-specific script like ~/.bashrc, I'm pretty sure that the default
 compiler will work fine even from a GUI app just by running "dmd".
 (Although, come to think of it, I'm going to have to test that...) It
 should
 pick up the correct path from the user's PATH environment variable just
 like
 the command prompt would. Although, if the user changes the default
 compiler
 while the GUI app is running, then to pick up the new changes, the GUI
 app
 would have to handle the WM_SETTINGCHANGED/"Environment" message: And I
 don't know how common that is (maybe it's automatically handled by the
 Win
 API?) If that can't be relied on, then maybe "dvm-default-dc" would still
 be
 useful on Windows too. I'll look into it.


 That would be great, thanks.



 methods. It did *not* automatically pick up the changes to the env vars
 while it was running (and at at one point it even stopped picking up the
 changes at all, even after restarting the little test app. Which was weird.)
 So they need to be specifically coded to pick up env changes. I didn't test
 it from D, but something as major as .NET doesn't do it by default, then
 "dvm-default-dc" is definitely useful on Windows.

 So I've added both "dvm-default-dc" and "dvm-current-dc" to my windows fork.


Thanks.

-- 
/Jacob Carlborg
Jun 07 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
I'm not sure if this message got through a few days ago, so I'm 
reposting it:

———

Wouldn't the DMD installations currently be part of your synced profile 
in Active Directory setups? It might be a good idea to move them to 
AppData/Local instead. But as it has been long since I last actively 
worked with an AD, you'd better double-check that…

David


On 6/4/11 12:44 PM, Nick Sabalausky wrote:

 I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
 Version Manager) to add Windows support. It should now be fully-usable on
 Windows, with the exception of installing Tango and any post-v0.2.0 features
 (I haven't yet merged in any changes from upstream since I originally forked
 v0.2.0.) I figure I'll submit a pull request after I've gotten those
 features merged in and working.

 Main page: https://bitbucket.org/Abscissa256/dvm/wiki/Home

 A precompiled Windows binary is on the downloads page:

 https://bitbucket.org/Abscissa256/dvm/downloads

 As with the Linux version, download the precompiled binary, and then install
 it by running:

 dvm-0.2.0-win-beta1 install dvm

 Then you should be able to use dvm just like on Linux:

 dvm --help
 dvm install 2.053
 dvm --default use 2.053

 Etc...
Jun 07 2011
parent "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:isl5rm$2q5i$1 digitalmars.com...

 I'm not sure if this message got through a few days ago, so I'm reposting 
 it:

 ---

 Wouldn't the DMD installations currently be part of your synced profile in 
 Active Directory setups? It might be a good idea to move them to 
 AppData/Local instead. But as it has been long since I last actively 
 worked with an AD, you'd better double-check that.


*Shrug* I don't know anything about Active Directory.

And I assume you mean Local/AppData. I have that on my system, but don't 
have one the other way around.

If I'm correct in my assumption that %APPDATA% is accessable to the same 
user account on multiple computers, and "Local Settings/Appliation Data" is 
user-specific *and* machine-specific, and assuming that's even what you're 
talking about (again, I don't know anything about Active Directory) then I 
would think %APPDATA% would be the better place for it.
Jun 07 2011