I have to understand an existing code in prolog which is written for win-prolog 4.800, and then build my work on that. The problem is the ide supplied along with win-prolog is very clumsy. I searched internet, but did not find better substitue for that. So i want someway (ide or something) that lets me
Understand (trace through) the code. Atleast, something like ctags will be helpful.
Have proper syntax color highlighting facility.
Have some sort of debugger if possible.
Have some interface where i can readily fire predicates and see output.
Note:- I can use Vim, if it is configurable for Win-prolog. Please let me know if using the default ide supplied along with win-prolog is the only best available way and you too could not discover better way.
Unless the existing code is very simple, it's quite likely that it will contain e.g. calls to WinProlog proprietary predicates and use WinProlog proprietary control constructs, not to mention syntax differences between WinProlog and de facto and official Prolog standards. Thus, it's unlikely that you will be able to use a Prolog implementation other than WinProlog to debug and trace through the code.
For syntax highlight, you have plenty of choices besides Vim. Several other text editors either include support for Prolog syntax highlighting or some plug-in is available that provide that service. See the Prolog FAQ for more information.
Likely only after porting the code or making it portable to other Prolog implementations you will be able to use IDEs written for those Prolog implementations. If that's not your goal, you're likely restricted to IDE provided by WinProlog.
Related
I was reading about how people were having trouble finding people to work with COBOL when working government systems that still use it. I was also reading about how Fortran, a language made two years before COBOL, is interoperable with C, C++, R, and Python with the right libraries.
This allows Fortran scripts to work with modern programming languages to some degree and even create scripts in modern programming languages that can work alongside Fortran code, making it easier for novices of Fortran to work with it. Are there any particular issues that prevent COBOL from having similar interoperability with other programming languages like SQL (which is used for databases similar to COBOL) that would make it easier for modern programmers who might not normally learn COBOL to work with it?
Q1: Does anything prevents interoperability between modern languages and COBOL?
A1: Short answer similar to those above: No, it is actually often done.
But that may depends on what "modern language" is defined for the reader.
Even with "real" COBOL (not some "shiny" [may be read as "blending"] "managed COBOL") you are in most cases free to directly call any C functions so more or less can call anything (at least with a C wrapper) and also can call binaries as you can do on the operating system (`CALL 'SYSTEM' USING 'some-executabe-or-script "param1" "param2"' is a common extension).
For calling into any "native code" directly (like Win32 or POSIX) you obviously have to ensure you are using the correct parameter definitions, but COBOL 2002+ have stuff like USAGE SIGNED-LONG, USAGE POINTER and similar (the extension USAGE COMP-5 is also common in this place).
Additional there are often direct ways to inter-operate with socket servers, HTTP(S), XML, JSON, ... ; and many COBOL implementations also allow to ASSIGN a (line-)sequential file to a pipe, allowing to interact with other programs in this way, too.
Q2: Are there any particular issues that prevent COBOL from having [...] interoperability with [...] SQL?
A2: No, and SQL is a very common directly used in COBOL: EXEC SQL
Many people will say that SQL is no "programming language". It is a query language and may be used in different environments, including COBOL.
Depending on the environment used, EXEC SQL may be directly integrated into the COBOL environment or with a pre-parser that adjusts the code to be plain COBOL (normally CALLing some "native" code, see Q1).
Q3: [... stuff] that would make it easier for modern programmers who might not normally learn COBOL to work with it?
... this is a completely different question, whatever a "modern programmer" is.
For a programmer to get to know a programming language it all depends on the programmer and the resources (like time, manuals, tutorials, mentors) - and the will of the programmer. Many people actually don't "want" to learn COBOL (for reasons I've heard but don't understand or disagree), other miss some of the resources (a free compiler is available with GnuCOBOL, nearly all COBOL compiler have their manuals available online and the ISO working group for COBOL publish the draft standards online, too; you often can find mentors in COBOL discussion forums or mailing lists, along with many samples).
One thing that often is special with COBOL is not the language itself, but the environment it is used on ("mainframe" with job control language "jcl" instead of a GUI to click or a shell to use) and/or the software that is actually coded in COBOL; every software that is maintained over decades has "special ways" here and there, and if you get to "decade old code that wasn't actually maintained for years" you get into even more troubles/fun (this is not something COBOL specific, but with COBOL you may encounter this software more often).
No, there is nothing preventing interoperability.
The main reason (this is an opinion, not based on known facts) that Fortran seems to have more interop out-of-the-box was that there was a free software GNU/Fortran for interested parties to work with. COBOL was very late in the game getting a viable free software compiler. That is no longer an issue with GnuCOBOL and people are finally starting to write the code needed to catch up.
Adding to Simon's answer; proof of concept for direct embedding is in a branch for GnuCOBOL; intrinsic functions added to support FUNCTION TCL, FUNCTION PYTHON, FUNCTION REXX, FUNCION LUA and FUNCTION JVM, so far. With FUNCTION JVM tests for Scala, Groovy, Java, Frink, all worked. This allows data transfer between COBOL working storage and the other language engine using simple COBOL syntax. Including setups for callbacks to and from. Those functions are embedded into the compiler and libcob run-time, when using that branch.
For other interface trials, not built into the compiler, but still allowing interop; the GnuCOBOL FAQ has dozens of examples. Shakespeare? Yep. Falcon? Yep. C, well, GnuCOBOL emits intermediate C so that's covered in spades. There is also a C++ edition of the compiler, so C++ is also covered, in spades. Javascript; Jsish, Duktape, Spidermonkey, Quickjs to name a few of the trials.
Ada, D, Vala, Genie, S-Lang, ROOT/CINT, J, Gambas, Forth, Perl, Postscript, Pure, Icon and Unicon, Nim, BaCon, SWIG (which opens up many multiples), PARI/GP, Gretl, R, Red, Ruby, Haxe/Neko, Pascal, Erlang, Elixir, SQLite, Rust, Go, more..., including a fair number of esolangs, and GNU Lightning for on the fly assembly modules. Trials documented in the GnuCOBOL FAQ.
Framework interfacing for AWT/Swing, GTK, Agar, and things like ZeroMQ, CGI and websockets also proved successful and are in productive use. Along with at least 7 EXEC SQL preprocessors successfully tested, and in use.
It comes down to someone caring to try, and writing some glue or properly aligning call frames. No attempts I've tried have failed to produce satisfactory results, although Perl 5 was a hair pull of unraveling macro layers. (Ok, I just lied, while attempting to embed jq, which relies on using C call and return by struct features, I would have had to leave pure COBOL interface coding, and didn't bother with the C middleware that would have made it easy). ;-) Will do that someday though, as jq is quite the powerful little JSON handler.
Use the search engine you mistrust the least and look for "gnu-cobol-builtin-script" and "GnuCOBOL FAQ", and visit the hits on SourceForge.
In my particular explorations I usually focus on languages with a C Application Binary Interface, but other ABIs would be along a similar vein. It only takes sitting down and writing some middleware or figuring out how to properly synch the call frames.
Are these current samples perfect? Not always, there are edge and corner cases with some datatypes and COBOL PICTURE data that would require more work, but that is all; a little bit of work and testing to smooth over the bumps. When exploring, I don't always go that far until an actual need arises. These seed work experiments are just to get some proof in the pudding, all done for the simple joy of it.
One of the lead developers for GnuCOBOL just added uni and bi-directional piping using simple filenames, which provides access to whatever the base OS offers, using basic COBOL OPEN/READ/WRITE/CLOSE (and other file IO) statements. Code was committed to trunk just a few hours before I started typing this response.
Basically, the answer to the titular question is a resounding No.
The scenario involved in the governmental systems is most likely IBM mainframe hardware with a flavor of z/OS, z/VSE, or z/VM operating system.
It somewhat depends on what is meant by interoperability in the sense that most any modern mainframe supports TCP/IP and that pretty much opens up the whole networked computing ecosystem to networked interoperability.
My guess is when all is said and done, the reason there is a problem is that the state refuses to pay a market rate for experienced mainframe developers and has kicked the maintenance can down the road as cost-saving measures.
It most likely is not a matter of there being no mainframe COBOL professionals able to make the systems work; it's most likely the state won't pay the price.
But this is speculation on my part since all I know is that the governor blames inanimate objects for appropriations and management failures within the state IT administration.
As a 40-year mainframe veteran, I'm dying to know details as to how this perfectly good technology is at fault for problems dealing with (again, I assume) unprecedented volumes of processing demand.
We found an interoperability problem between C and GnuCOBOL.
Our problem was addressed so this answer is just for educational purposes so you can understand what kind of problems you may have.
The problem manifests when C calls COBOL(a, b) calls C(c) calls COBOL(a, b).
And specifically when the number of arguments varies.
A recent change to GnuCOBOL assumed that COBOL called COBOL so it passed meta data about the arguments in some global area. Then the called COBOL program cleared out the second argument because is falsely thought it was being called with one argument. That is, the intermediate C call was transparent to COBOL.
This is under the guise of making it more compatible with IBM mainframe but it caused me a lot of grief. It was quick addressed with runtime changes. I would like to see it addressed with a compile time option:
Make .so file a stand alone .so file called from any language but programmer has to be vigilant.
Make .so file assume it will be called from COBOL and has the additional protections afforded by mainframe COBOL.
BTW: GnuCOBOL is great and has a great community behind it. If you are experiencing problems report it and you will get better response than commercial products.
EDIT:
I found that doxygen can generate call graphs for classes, but I could not find any options or examples where the call(er) graph is generated for public/private members of the class(es) such as fields, methods, etc.? See the example that I provided below.
Is it possible to find links/relationships between 2 variables/objects in the code using some IDE tools and code editors, i.e. in Visual Studio, Sublime, etc.
e.g.
a=func(b,c);
w=func(a,c);
Here w and b are indirectly related to each other.
In convoluted code it is very difficult to manually find such relationships.
I understand that reflection and dynamic nature of some languages can limit such analysis.
You need to provide the language you are looking to use. If I take a guess and say C/C++ you can use CCTree and Cscope in general for this functionality. Most open source developers use Cscope extensively for this purpose.
Eclipse CDT also has call graph's. It is a bit of a pain to work outside of VisualStudio for this purpose I know. But cost is part of the reason to use open source instead.
Your best bet to cover all languages for the purpose of browsing is Exuberant Ctags. This works with a fair amount of editors and all the languages you listed. With that large a list of languages and use cases its probably worth your time to learn either vim or emacs and the integrations supported here.
For Python you can also take a look at pyscope with cscope. Another excellent alternative for Python is Rope. Rope supports finding definitions and usages as part of its standard set of tools.
Most developers do not need CCTree as browsing code bases with cscope is relatively straightforward. I have used exuberant ctags + emacs on a huge variety of language for years. It takes a touch of time to learn, but the upsides are
it's free, portable, and powerful. Another alternative to CCTree is codegraph for some of your target languages.
Found a list of tools and comparison:
https://github.com/OpenGrok/OpenGrok/wiki/Comparison-with-Similar-Tools
EDIT
possible in doxygen, but only for classes and their relationships
I found it, this is code map in VS Ultimate:
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/12/announcing-visual-studio-2015-preview-availability.aspx
I was searching for a SWI-Prolog editor for Mac OS X but i could not find one, so is there one or do I have to use another editor to build Prolog files?
Thanks
I do not use mac OS-X myself, but there are two very good SWI-Prolog editors that are cross-platform (thus also work on OS-X):
PDT works with the Eclipse IDE. It has good syntax coloring, an in-IDE Prolog console, a dynamically generated visualization of the call graph, to name only a few of the many features it has. See http://sewiki.iai.uni-bonn.de/research/pdt/docs/v2.1/start I believe refactoring of Prolog code is not there yet, but the developers plan to add that cool feature in the future as well.
PCE Emacs, an Emacs implementation by Jan Wielemaker that uses SWI-Prolog's graphical library XPCE. The UI elements look very Windows '95-ish, but don't be fooled by mere appearances here. PCE Emacs is completely tuned to SWI-Prolog and is probably the most versatile editor for SWI-Prolog out there. You can simply run it from within the SWI-Prolog console by typing emacs.
Hope this helps!
Assuming that you're considering not only IDEs but also text editors, the Logtalk distribution includes support for a large number of text editors that is also usable for editing Prolog source code. See https://github.com/LogtalkDotOrg/logtalk3/tree/master/coding for a list of all supported text editors.
I use OS X and work in Emacs with prolog-mode.
This version has all the features one would expect, including syntax highlighting, auto indent, and full interaction with an inferior Prolog process. The mode supports in principle any Prolog system, though it is primarily maintained with SWI Prolog in mind.
It lacks many of the features of PCE Emacs, but has all of the features of GNU Emacs, and I'm pretty happy with it.
I want to add multiple language support to my application which is written in Python using PyQt4. I was looking for information on how to add multiple languages and would like to see how other people do this.
Here i read:
The PyQt behaviour is unsatisfactory and may be changed in the future.
It is recommended that QCoreApplication.translate() be used in
preference to tr() (and trUtf8()). This is guaranteed to work with
current and future versions of PyQt and makes it much easier to share
message files between Python and C++ code.
In files generated by pyuic4 i see something like:
WPopupCalendar.setWindowTitle(QtGui.QApplication.translate("WPopupCalendar", "Календарь", None, QtGui.QApplication.UnicodeUTF8))
This looks too long for me. I was thinking to make my own tr helper function which somehow would automate the process.
Also i could not find articles describing a workflow and specifics for developing multilingual apps in python with pyqt4.
Would you please advice me with some good and convenient techniques on this?
Just use tr (or trUtf8) everywhere to start with. Only bother with translate when you identify code that is affected by the issue with multiple inheritance (which could easily be never).
I would suggest you have a look at Qt's i18n overview, and the Qt Linguist Manual. They are obviously both oriented towards C++ projects, but it should give you a pretty clear idea of what's required.
For a working example, you could also download the source code of the Eric Python IDE - it's written in PyQt4, and has support for a half dozen or more languages.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I need to start learning Prolog for my job.
I haven't used Prolog before and my company needs to build a program that will use Prolog.
So the program will be used commercially.
So some questions:
1) Does Prolog use a compiler to compile the programs. Like gcc does for c?
2) Is there commercial standard of Prolog? I have only heard of SWI Prolog.
3) I have been using GNU Emacs with Linux for many years. I am thinking of using the Prolog.el package? Any comments on that?
Many thanks for any answers,
The most elaborate Prolog IDE I'm familiar with is the Eclipse-based IDE for Amzi! Prolog. This is a commercial product, but the IDE can be downloaded and used for free in the Student Edition. It might be ideal for a beginning Prolog programmer. Disclaimer: I may be biased because I supply a lot of free advice at Amzi!'s support forum. I think there's an open source Eclipse plugin that supports some of the open source Prolog implementations as well. Update (May, 2016) Amzi! Prolog v. 10 has now become open source using an MIT-like license.
Although SWI-Prolog is open source (GPL), it is possible to develop commercial applications with it, as with several other open source Prolog implementations like GNU Prolog and YAP. Besides Amzi! Prolog there are several other commercial products. Visual Prolog is different enough from the ISO standard for Prolog that most Prolog programmers do not consider it "real prolog". SICStus Prolog is an ISO compliant commercial Prolog implementation. There are some others that are Prolog-like but with substantial extensions, such as ECLiPSe (not to be confused with the IDE) and Mercury. A number of commercial implementations of Prolog have become obsolete over the years, as when IF Prolog was superseded by MINERVA. Here's a list of implementations from 2006.
I know many programmers who speak highly of the Prolog mode for GNU EMACS. However I'd think a beginner would benefit from an integrated debugger/editor such as Amzi! Prolog offers. SWI-Prolog has a graphical IDE under construction based on XPCE, which is the graphical interface library SWI-Prolog has chosen for cross-platform development. Almost all programmer editors will supply syntax highlighting for Prolog, with the right definitions file installed.
SICStus Prolog has an IDE based on Eclipse. The SICStus IDE has many advanced features not found in competing products, free or commercial. Among other things it detects syntax errors and other common mistakes as you type, which can be especially valuable for a beginner.
SICStus also has an Emacs mode but it does not offer all of the functionality of the Eclipse-based IDE.
You can download an evaluation of SICStus Prolog from the home page.
I am biased, I am one of the SICStus Prolog developers and the developer of the SICStus Prolog IDE.
You can generally compile your prolog project. However, depending on the prolog environment you are using, it might be an intermediate code and not directly executable code.
SWI Prolog and Sicstus prolog both allow to generate an executable of this form (embedding the interpreter along with you compiled intermediate code).
Other prologs like Arity Prolog/32 compiles directly to an x86 executable. There is a page on Wikipedia that compares various prolog systems.
There is an ISO standard for prolog. However almost every prolog system will be mostly compatible with each other, requiring minor changes to port the code from one prolog system to another.
In addition to what gusbro already said: SWI-Prolog is, I think, the best Prolog for learning. It may not be the fastest implementation, but is has quite a few bells & whistles such as command line editing and a built-in Emacs-like editor, it's free software and it's easy to install on both Windows and Linux (and Mac OS X, too, I reckon). It's implemented as a bytecode compiler for a virtual machine, like most Prologs; even the ones that produce native code often use a virtual machine at some point.
The basics of Prolog are much the same among implementations; non-standard extensions such as extra libraries, OS interfaces, constraint programming etc. tend to be a little different.
Various Prolog-Java and Prolog-C# interfaces interfaces exist. SWI has extensions that allow it to function as a web server.
I'm using the swi-prolog built in ide for commercial development.
Depending on your os, you might need to start with swipl-win.exe or xpce
to get the graphic environment
I am using an eclipse IDE plug-in called PDT. The installation is fairly easy and I think it is a nice environment. After installation, you can follow the instructions at the "getting started page" to finish your installation and get you up and running.
if you are used to work in an emacs environment you should try using the Ciao distribution. It has many interesting and powerful features, libraries, and is also GNU LGPL license. Highly documented and supported.
Go to http://ciaohome.org/