After trying to get jinc compiled under windows and quickly running into hundreds of compiler errors I'm looking for a quality BDD library that will build for windows. Preferably in C or C++ but as long as I can bind to it I'm happy.
I recently wrestled with installing the CUDD v2.4.2 in a Windows / Visual Studio environment.
There is documentation out there, but in my opinion none of it gives the complete picture of how to install the thing and get it working in non-Unix environments. For example, how to address the issues with the Makefile, how to link to the *.a C archive files in your project, minor issues with the cpu_stats.c file, etc. This is a shame because CUDD seems to be quite a powerful means of reducing complexity for many problems, such as integer programming.
I recently managed to get it going in VS 2010. My blog details here.
Cudd is is good : http://vlsi.colorado.edu/~fabio/CUDD/ I have compiled it in Visual Studio 2005.
There seems to exist pre compiled binaries : http://web.cecs.pdx.edu/~alanmi/research/soft/softPorts.htm
As an ex researcher, I can tell you that two years ago, Cudd was the best in class regarding efficiency.
Biddy is becoming better and better.. http://biddy.meolic.com/
OK, this is a subjective claim, because I am the main author of Biddy. However, while Biddy does not have so many functions and it does not
have so robust and improved memory management and it has not
been tested in so many projects as CUDD, it is a viable library.
By using it, you can help to improve it. My group is active and flexible
and we can implement any function you need.
Related
I'm new in Fortran and I need your help.
I'm a space engineering student and I'm used to code in MATLAB.
Right now I'm writing my MSc thesis and I have to deal with a code written in fortran77 (I'm guessing it by its extension ".for"). The code has already been tested and used in other occasions.
I use Windows 10 as an operating system and I know that sometimes an old code could show problems depending on the system in which it is run (for instance I've heard about the need of running old versions of an operating system through emulators to solve some problems).
I hope I can still use Win10 for the purpose.
So, I have done the following steps (based on what I have found on internet) in order to configure my system:
I have installed the last version of Microsoft Visual Studio Community 2019
I have installed Intel OneApi Basic Toolkit and then Intel OneApi HPC Toolkit (the last one is an add-on that contains the fortran compiler).
It seems that both are well configured/integrated and I think they are working properly.
Now, when I try to open the project from Visual Studio, the .for extension isn't apparently recognized.
So I've tried to open it as a simple file, and in doing so, I can visualize it on VS.
I don't know If It is the right procedure, and I don't know if it works as it should.
How can I prove it?
I try to run it, but nothing seems to happen (no error flag by the way).
I'm totally new in this field, so any "obvious" suggestions will be really appreciated.
I'm open to any tips, even If it is better to change compiler (I've heard about gfortran) or use other kinds of softwares. I would be also grateful if someone could suggest me a beginner useful guide.
Thanks to whoever wants to help me out.
I've been using Qt Creator for about a year. Because I was new to it and was trying to get things up and running as quick as possible, I opted for the MinGW compiler. My projects have worked well enough, but I am working on one that processes a lot of data but is nonetheless processing much slower than hoped.
Before I undertake the task of installing MSVS, are there any thoughts on whether a switch to the MSVS compiler on Windows 7 generally produces a "faster" exe?
I realize there are subjective elements to this question, but I just want some general ideas.
Ages ago, the Qt-msvc2010 builds were faster than MinGW.
It depends which Qt version, which MSVC version etc you're comparing, how you include headers, etc.
I am converting several modules from OCaml to F#. To hunt bugs and verify some of the finer differences I am running both versions against the same test case at the same time.
For F# I am using the Visual Studio debugger and for OCaml I am using ocamldebug. Since Visual Studio is a GUI and ocamldebug is a command line, making the comparisons requires more attention than back and forth visual scanning.
I was wondering if there is any OCaml IDE that supports a GUI debugger with stepping while showing the source line highlighted and separate window to display values.
EDIT
I did some more looking after Jack posted an answer and then remembered why I didn't pick one a few months ago when I did this.
The reasons I am passing on the ones I find and staying with the OCaml command line tools are
The command line tools come with the compiler, so they are current and work. There is some documentation on the tools, but honestly I did have to spend a few hours writing my own ocamldebug manual with examples to become proficient with ocamldebug.
They rely on EMACS. It's not EMACS but me; I just hate the way it works. Also all of the tools working with EMACS I found they are just wrappers around ocamldebug. So nothing gained but more memorization of commands. Note: EMACS is actively maintained and updated.
They rely on Eclipse. I have used Eclipse a lot for working with ANTLR, but I only make a system every few years and have very good notes on it so it is worth my time. Once I get Eclipse working for a major ANTLR release, I don't update it again for years. For the small amount of time I plan on debugging OCaml, the cost is too high. Note: Eclipse is actively maintained and updated.
They don't do debugging. Since there are so few GUI tools for OCaml, even an enhanced editor is a benefit for some. Not for me at this time.
The tool/plug-in has not been maintained for some years.
This not a put down of OCaml, just the details as I find them. I don't have a problem with OCaml, I just wish I was more productive with it.
I think most people are just using the OCaml debugger (ocamldebug) from within emacs (see the bottom of that page for details).
I don't know if it supports debugging (yet), but the TypeRex OCaml Programming Studio looks like an interesting project.
Finally, there are some old, unmaintained Eclipse plugins you could try (e.g., Camelia), though I suspect they've bit-rotted for too long to be of much use at this point.
I was unable to find an OCaml GUI debugger with the same ability as Visual Studio using F# that meet my requirements.
If someone does find one or creates one and post that as an answer I will gladly give them them accept vote.
I was wondering if there is any OCaml IDE that supports a GUI debugger with stepping while showing the source line highlighted and separate window to display values.
I'm only just getting back into OCaml and Linux now after a 4 year break but, last I looked, Linux had very poor GUI libraries and OCaml had very poor interoperability so nobody ever got very far writing non-trivial GUI applications in OCaml.
Which programming language and tools can i use, to develope a complete stand-alone gui-application? This application will be burned on a cd and should run on every windows-pc without any installations.
Questions like what your application and what your capabilities are need to be considered.
There are many solutions to your problem. From 'Visual Studio Ultimate' to a HTML file which contains javascript.
Win32 API.. a similar question was asked today...
Use Visual Studio (you can use express edition) and build whatever you like.
This is the most powerful language, yet development time is very very slow, but the results are:
a. independent.
b. if you a good programmer - small and fast.
one thing - you got to know what you're doing when programming win32...
one Petzold book will get you where you want to go.
similar question
Well, if you really have the time and don't need to deploy on 16-bit Windows, you could always write in Win32 assembly -see MASM32 and Iczelion's Win32 tutorials. There's even a IDE for Win32 ASM -WinAsm Studio :)
The only dependencies you'll need are the Windows system DLLs which are already there on every Win32 system.
However, if you need to build something quick, something like Visual Basic 6 will do nicely - it only needs the VB6 runtime by default (1 ~ 2 MB) and that definitely fits into a CD together with your VB6 EXE.
I'd go for C++ with MFC. Reasonable development times and with static linking it could all be one standalone exe file.
If you are just looking to make one of those interactive splash screens, might want to look into Demoshield. I know its old and not supported any longer, but can be of real use for something great looking.
http://www.componentsource.com/products/509937/12838/index.html
You can find copies of it free by google-ing it. Don't think the company is around any longer so not sure if this is legit or not.
But not the right choice if you need to do some serious programming stuff.
Delphi also may be a good choice.
I'm trying/thinking of making CppCMS - C++ Web Framework project little bit more cross platform.
Today I can easily support Linux, OpenSolaris, FreeBSD and even Cygwin. But when it comes to Native Windows it becomes really painful:
The overview of the situation:
I'm POSIX/Linux developer and I'm barely familiar with Native Windows development tools like Visual Studio and Win32 API. However I do some work for this platform so I understand the limitations and the fact that Windows is totally different world.
This is web project that uses APIs that popular in Unix world, like: CGI, FastCGI and SCGI that implemented in most UNIX web servers; but I understand that I would not be able to use it with IIS because it does not support FastCGI over TCP/IP (only Windows pipes).
So even when it would work it would probably run only with Windows port of Apache.
I relay heavily on POSIX API:
Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
I use some file-locking facilities (but I can probably give them up without forking)
I have intensive use of native pthreads, even I can replace them with Boost.Thread
I probably would never be able to support Visual Studio (maybe 2010 with C++0x support), because I relay on C++0x decltype/auto feature or typeof/__typeof__ extension that is supported by most compilers I worked with: gcc, intel, sun studio. (To be honest: I can work without them but it makes the life much easier to framework user.
I relay heavily on autotools and I can't replace them with CMake, bjam or friends, because when it comes to support of internationalization, cross copiling, package management, they just does not give me a solution.
There are many annoying points like missing gmtime_r, or localtime_r under windows and many others that just require from me to rewrite them or replace them with 3rd part libraries.
There are still many "UNIX like" libraries that ported to Win32 like: iconv, gcrypt and some others that are barely ported like libdbi that have many limitations on windows.
Bottom line:
There is lots of non-trivial work to do, and even when it would be complete, it would probably work only with MingW tools and not "native" tools that Windows programmers are
familiar with.
So, my questions are:
Does such MingW port worth an effort? Would this help to build bigger community?
Does anybody have experience on how painful porting big projects from POSIX environment to
Win32 API is?
Would it be useful for Windows developers at all?
Edit:
It is also important for me to understand, how many of windows developers prefer to use
Open source development tools, MingW over Microsoft development solutions like VS.
Edit #2: Clearification about "native" windows solusions and IIS.
In fact, running framework with IIS is really hard problem. I explain:
The project relates to standard web server API as FastCGI or SCGI that allows to accept many requests over sinlge socket. Thus, on application side, I accept new request proceed it and returns the answer. Sometimes several threads process several requests.
Thus, implementing one or two standard protocols I open communication with any existing server: Apache, lighttpd, nginx, cherokee... or any other servers; with small exception of IIS
IIS has implementation of FastCGI, but... It supports only 1 connection per local process only that controlled by web server...
So... there is absolutely no standard way to connect my application to IIS.
Please note, I implement standard Web server API, I do not implement Neither IIS proprietary ISAPI nor Apache proprietary API, even the second is more important as for targeting UNIX world.
So, just Windows IIS Web world is just not really ready for cooperation for such project, so if anybody would use it under Windows it would use it with more open web servers.
You should base your decision on user demand. Have users ever requested using the framework on Windows? If so, did they explain why they wanted to use Windows (e.g. what additional constraints they had, what webserver they wanted to use, etc.)?
Typically, Windows users do expect that things work the Windows way. That means Visual Studio support, IIS support, MSI installer, and so on. If something still feels like being Unix, I would rather use Unix proper, instead of fighting with a half-working port.
As a windows client app developer it sort of hurts me that the development environment division currently is essentially Win32 and everything else and that they are mostly incompatible. That's why I'm preparing to move to MinGW for my personal windows app projects and to try to make them cross-platform.
I would suggest gradually moving to more cross-platform libraries like, as you suggested, refactoring pthreads to boost::thread, or going from fork() to multi-process with IPC, probably also using boost's facilities. Date/time stuff can be dealt with Boost libs as well. As for database support, there are
Microsoft compiler support is not that important I think, as MinGW provides a decent build environment with all the IDEs that support it, Eclipse CDT and Dev-C++ being among the most popular. But if you are going to make your project msvc-compatible, make sure users will be able to use Express editions of Visual Studio 2010 (as soon as thay come out) - that way no one will have to fork out for a Visual Studio 2010 (upgrade) just to use your project and there will be no problem for you to require the latest in Microsoft technology.
Most likely you won't avoid some amount of ifdefs for a code base of your project's size, but surely the effort might be worth it, if not only for gaining valuable experience and expanding the community with a few new happy and grateful members.
Your saying that you can support Cygwin quite easily reminds me that I've seen commercial Windows software that simply bundled in cygwin1.dll to support some originally-Unix code. If adding cygwin1.dll to your installer is all it takes, try it out.
I think you only have to look at the questions asked on SO to work out that MinGW users on Windows (of which I am one) are in a minority in the development community - the vast majority of Windows developers are using MS tools. Anyway, the compiler is only half (or less) of the issue - if your architecture depends on forking lots of processes, using MinGW is not going to help you. My advice is, if you really want to do cross platform development:
look at how Apache do it
consider using the Apache libraries as your base
don't use very new or compiler-specific language features
use multi-threading rather than multi-process
Does such MingW port worth an effort? Would this help to build bigger community?
I am still working myself on this issue with my own large POSIX project and my conclusion is that if you need to later interface with Microsoft products, then its worth while, however then I would only use MingW if project is medium small, if it is very large, then I would go all the way with MSDN Microsoft development tools - Huge amount of help will be available there - however it will cost
Does anybody have experience on how painful porting big projects from POSIX environment to Win32 API is?
sofar my own conversion of my POSIX project have been constantly put on hold, because of the amount of time each issue takes to handle is enormous - not finished converting yet - If I ever will be
Would it be useful for Windows developers at all?
Sure working inside the Microsoft IDE using tools from MSDN will definately decrease development time, however it will increase your dependence on Microsoft libraries - something you need to decide from beginning if that is an issue
**
Actually you could just add the necessary cygwin dlls to your projects make and then you would beable to run it in windows
I managed to make my POSIX project run when I added following dlls
cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll
Probably your project will have different dependencies, however if you think conversion is not worth it, then perhaps this is a solution for you
You could also add your libs as static, then you would end up with only having to provide the last cygwin1.dll