Menu
▾
▴
iverilog-devel
|
From: Martin W. <mai...@ma...> - 2015-05-05 23:18:44
|
When running natively in Windows, iverilog-vpi stores a couple of keys in the
registry. Currently it stores these in
HKEY_LOCAL_MACHINE\Software\Icarus Verilog
With typical Microsoft consistency, a 32-bit application running with normal
user privileges can add these keys to the registry, but, on the same Windows
machine, a 64-bit application must be running with administrator privileges.
Currently iverilog-vpi silently fails to store the keys when built as a 64-bit
application. I could fix this in two ways:
- output a warning message to inform the user they need to run with
administrator privileges
- change the key location to HKEY_CURRENT_USER
I'm inclined to go for the second option. Does anyone wish to argue otherwise?
|
|
From: Martin W. <mai...@ma...> - 2015-05-06 07:46:53
|
Having slept on this, I'm questioning why iverilog-vpi needs to store anything in the registry. The two things it stores there are - the path to the iverilog root directory - the path to the installed MinGW compiler The first of these it could work out for itself, in the same way vvp does. The second is just added to the PATH environment variable - surely it is easier to ask the user to add this to PATH themselves. After all, any user capable of writing VPI modules is surely capable of setting up their PATH variable. Martin Whitaker wrote: > When running natively in Windows, iverilog-vpi stores a couple of keys in the > registry. Currently it stores these in > > HKEY_LOCAL_MACHINE\Software\Icarus Verilog > > With typical Microsoft consistency, a 32-bit application running with normal > user privileges can add these keys to the registry, but, on the same Windows > machine, a 64-bit application must be running with administrator privileges. > > Currently iverilog-vpi silently fails to store the keys when built as a 64-bit > application. I could fix this in two ways: > > - output a warning message to inform the user they need to run with > administrator privileges > > - change the key location to HKEY_CURRENT_USER > > I'm inclined to go for the second option. Does anyone wish to argue otherwise? |
|
From: Stephen W. <st...@ic...> - 2015-05-06 14:39:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is absolutely NOT realistic to expect users to add the mingw directory to the path on windows systems. Yes it would work and yes that is kinda what the path is for, but that is not really the user experience/expectation on Windows, even for command line tools. I'm also a little uneasy about changing the key from LOCAL_MACHINE to CURRENT_USER. Doesn't the latter only apply to the currently logged on user? Can we insist that install is done by an admin user that can set HKEY_LOCAL_MACHINE? On 05/06/2015 12:46 AM, Martin Whitaker wrote: > Having slept on this, I'm questioning why iverilog-vpi needs to > store anything in the registry. The two things it stores there are > > - the path to the iverilog root directory - the path to the > installed MinGW compiler > > The first of these it could work out for itself, in the same way > vvp does. The second is just added to the PATH environment variable > - surely it is easier to ask the user to add this to PATH > themselves. After all, any user capable of writing VPI modules is > surely capable of setting up their PATH variable. > > Martin Whitaker wrote: >> When running natively in Windows, iverilog-vpi stores a couple of >> keys in the registry. Currently it stores these in >> >> HKEY_LOCAL_MACHINE\Software\Icarus Verilog >> >> With typical Microsoft consistency, a 32-bit application running >> with normal user privileges can add these keys to the registry, >> but, on the same Windows machine, a 64-bit application must be >> running with administrator privileges. >> >> Currently iverilog-vpi silently fails to store the keys when >> built as a 64-bit application. I could fix this in two ways: >> >> - output a warning message to inform the user they need to run >> with administrator privileges >> >> - change the key location to HKEY_CURRENT_USER >> >> I'm inclined to go for the second option. Does anyone wish to >> argue otherwise? > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ Iverilog-devel > mailing list Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVKJ5IACgkQrPt1Sc2b3inqrwCdHNl4Rv1rBlM4774kdEwBd/8b MgkAoI+hvehDBhRqdiqO7//tbyhB4rud =WrYG -----END PGP SIGNATURE----- |
|
From: Stephen W. <st...@ic...> - 2015-05-06 15:57:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ironically, after re-reading this post, I realized that setting the path is exactly what we expect of users in order to get access to the iverilog-vpi tool in the first place. So, logic fail on my part. Still, it was my choice in the first place to locate the mingw tools via the registry (not that I ever really use Windows) and my thinking was to simplify the experience as much as possible, and also to not pollute the users path any more then necessary. So if not a registry entry, perhaps a .ini file in the iverilog install directory? On 05/06/2015 07:39 AM, Stephen Williams wrote: > > It is absolutely NOT realistic to expect users to add the mingw > directory to the path on windows systems. Yes it would work and yes > that is kinda what the path is for, but that is not really the user > experience/expectation on Windows, even for command line tools. > > I'm also a little uneasy about changing the key from LOCAL_MACHINE > to CURRENT_USER. Doesn't the latter only apply to the currently > logged on user? > > Can we insist that install is done by an admin user that can set > HKEY_LOCAL_MACHINE? > > On 05/06/2015 12:46 AM, Martin Whitaker wrote: >> Having slept on this, I'm questioning why iverilog-vpi needs to >> store anything in the registry. The two things it stores there >> are > >> - the path to the iverilog root directory - the path to the >> installed MinGW compiler > >> The first of these it could work out for itself, in the same way >> vvp does. The second is just added to the PATH environment >> variable - surely it is easier to ask the user to add this to >> PATH themselves. After all, any user capable of writing VPI >> modules is surely capable of setting up their PATH variable. > >> Martin Whitaker wrote: >>> When running natively in Windows, iverilog-vpi stores a couple >>> of keys in the registry. Currently it stores these in >>> >>> HKEY_LOCAL_MACHINE\Software\Icarus Verilog >>> >>> With typical Microsoft consistency, a 32-bit application >>> running with normal user privileges can add these keys to the >>> registry, but, on the same Windows machine, a 64-bit >>> application must be running with administrator privileges. >>> >>> Currently iverilog-vpi silently fails to store the keys when >>> built as a 64-bit application. I could fix this in two ways: >>> >>> - output a warning message to inform the user they need to run >>> with administrator privileges >>> >>> - change the key location to HKEY_CURRENT_USER >>> >>> I'm inclined to go for the second option. Does anyone wish to >>> argue otherwise? > > >> ------------------------------------------------------------------------------ > >> > > One dashboard for servers and applications across > Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable >> Insights Deep dive visibility with transaction tracing using APM >> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ Iverilog-devel >> mailing list Ive...@li... >> https://lists.sourceforge.net/lists/listinfo/iverilog-devel > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ Iverilog-devel > mailing list Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVKOdkACgkQrPt1Sc2b3ikbhACfTSMPaMTxajM6tuzvCHYNhdHx 7EUAn0il8tuNGWhAivukxk96u+Gi5MBj =ZprX -----END PGP SIGNATURE----- |
|
From: Michael S. <mic...@gm...> - 2015-05-06 23:49:42
|
I'm not sure about storing in .ini file is a good idea either. Sometimes this path can be changed and user will have a hard time wondering why simulations stopped working. Best regards, Michael Strelnikov On 7 May 2015 at 09:46, Martin Whitaker <mai...@ma...> wrote: > Stephen Williams wrote: > > Ironically, after re-reading this post, I realized that setting the > > path is exactly what we expect of users in order to get access to > > the iverilog-vpi tool in the first place. So, logic fail on my part. > > > > Still, it was my choice in the first place to locate the mingw tools > > via the registry (not that I ever really use Windows) and my thinking > > was to simplify the experience as much as possible, and also to not > > pollute the users path any more then necessary. So if not a registry > > entry, perhaps a .ini file in the iverilog install directory? > > > Users who have installed the MinGW compiler will most likely have added it > to > their path already - otherwise they won't be able to use it to compile C > programs. In this case the current procedure complicates the user > experience, > because they have to run iverilog-vpi to set a path that is already known > to > the system. So I suggest a better solution is to first search the current > path > for the MinGW compiler, and if it is not found, prompt the user to enter a > path and store it in a .ini file for future use. > > Martin > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Martin W. <mai...@ma...> - 2015-05-08 07:33:42
|
Michael Strelnikov wrote:
> I'm not sure about storing in .ini file is a good idea either.
> Sometimes this path can be changed and user will have a hard time wondering
> why simulations stopped working.
>
iverilog-vpi does check whether the C compiler can be found on the currently
stored path, and outputs an informative message if not.
The logic I've implemented is:
- If -mingw=path is supplied alone on the command line, the
path is stored in the registry as before. If access is
denied, a message is output that suggests running as
administrator.
- If -mingw=path is supplied with a list of source files, it
is used as the path for that run only and not stored in the
registry.
- If -mingw=path is not supplied, iverilog-vpi first looks in
the registry, and if a path is stored there, uses that. If
there is no entry in the registry, it seaches the system path.
If the C compiler is not found on the system path, it outputs
an informative message and quits.
Hopefully this will satisfy all parties.
I've removed the -ivl option, and made iverilog-vpi automatically extract the
IVL root directory from the location of the .exe file, exactly as vvp does.
Martin
|
|
From: Martin W. <mai...@ma...> - 2015-05-06 23:46:15
|
Stephen Williams wrote: > Ironically, after re-reading this post, I realized that setting the > path is exactly what we expect of users in order to get access to > the iverilog-vpi tool in the first place. So, logic fail on my part. > > Still, it was my choice in the first place to locate the mingw tools > via the registry (not that I ever really use Windows) and my thinking > was to simplify the experience as much as possible, and also to not > pollute the users path any more then necessary. So if not a registry > entry, perhaps a .ini file in the iverilog install directory? > Users who have installed the MinGW compiler will most likely have added it to their path already - otherwise they won't be able to use it to compile C programs. In this case the current procedure complicates the user experience, because they have to run iverilog-vpi to set a path that is already known to the system. So I suggest a better solution is to first search the current path for the MinGW compiler, and if it is not found, prompt the user to enter a path and store it in a .ini file for future use. Martin |
Thanks for helping keep SourceForge clean.
X