"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).

"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.

I think this might be a cool place to link DVM from: http://prowiki.org/wiki4d/wiki.cgi?action=browse&id=D__Tutorial/StartingWithD/Compiler/DMD&oldid=D__Tutorial/InstallingDCompiler

"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?

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

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

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

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

"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.

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