As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to learn Tcl programming, but I`m having trouble with compile source code. I need good compiler tool. Can you help me? What compiler should I use or the best one?
Thank you !!!!
Tcl is a programming language. It has a number of implementations, but the one you are most likely to be able to get hold of is tclsh. Linux-based systems often have one already installed (if not, there'll certainly be a way to get it from your distribution's package repository). On Windows, the ActiveTcl distribution from ActiveState is highly recommended. I don't know if all MacOS X systems have it (mine did) but you are recommend to get ActiveTcl anyway as that also includes many extra useful packages for things you can do with Tcl, and is also more likely to be up-to-date.
You might also encounter the wish and expect programs; these are actually little more than tclsh with an extra library loaded into them and pre-activated for you. (For wish, that library is Tk which does GUIs, for expect that library is Expect which does terminal interaction.) The Tcl they include is the same as in tclsh, but has some extra commands.
When asking future questions here about Tcl, it helps a lot if you mention the exact version (as reported by Tcl's info patchlevel command) that is being used.
In terms of compilers, you don't normally need one. The implementation engine used by tclsh actually does dynamic compilation of your Tcl program (to a bytecode) as necessary, and is so fast that it is actually slower to load bytecodes than to recompile from scratch. (We did some tests and decided that, whatever speedups we should do, saving bytecodes were not going to be a part of the strategy as there was no point.) The only real case for using a compiler with Tcl is where you are using it to obscure the code, to make it hard for a user to look at and change. But the only sane scenario for that is when doing commercial apps (it's against the basic principle of Open Source Software) so if you need it, you are going to be directed to a commercial solution. (ActiveState sell such a product.) OTOH, if you're really thinking more about packaging — putting your code together in a neat parcel — then we have a different technology for that, the starkit, which is very neat indeed. But that's getting a bit further off the topic…
If you are using linux, you probably have Tcl already installed in your system. Type tclsh in the console and see if it works, or look for Tcl in the software installation tool.
If you are using Windows or MacOSX, you can download it from ActiveState here.
tcl is a scripting language (and, IMHO, not a particularly good one; Ruby, Python, Ocaml, Lua are better in my opinion). Its implementation is usually not compiled (perhaps some experimental implementations might use JIT techniques). Tk is a graphical toolkit built above the Tcl interpreter.
In particular, there is no "compilation" step to use Tcl (because you don't need any "compiler" to use -i.e. code some scripts in- Tcl); you just need its interpreter. (You may need a C compiler to build the tcl interpreter from its source code, you usually can install the interpreter binary; details depend upon your system).
So you just need to use your editor (e.g. Emacs, Gedit or even Notepad if you are restricted to Windows) to begin coding some Tcl scripts.
If you are learning to code, I strongly suggest to learn some better programming languages (e.g. Scheme or Ocaml or Python) before learning Tcl. The lack of modularity in Tcl will bite you quite soon!
Related
I have a couple questions about adding options/switches (with and without parameters) to procedures/commands. I see that tcllib has cmdline and Ashok Nadkarni's book on Tcl recommends the parse_args package and states that using Tcl to handle the arguments is much slower than this package using C. The Nov. 2016 paper on parse_args states that Tcl script methods are or can be 50 times slower.
Are Tcl methods really signicantly slower? Is there some minimum threshold number of options to be reached before using a package?
Is there any reason to use parse_args (not in tcllib) over cmdline (in tcllib)?
Can both be easily included in a starkit?
Is this included in 8.7a now? (I'd like to use 8.7a but I'm using Manjaro Linux and am afraid that adding it outside the package manager will cause issues that I won't know how to resolve or even just "undo").
Thank you for considering my questions.
Are Tcl methods really signicantly slower? Is there some minimum threshold number of options to be reached before using a package?
Potentially. Procedures have overhead to do with managing the stack frame and so on, and code implemented in C can avoid a number of overheads due to the way values are managed in current Tcl implementations. The difference is much more profound for numeric code than for string-based code, as the cost of boxing and unboxing numeric values is quite significant (strings are always boxed in all languages).
As for which is the one to use, it really depends on the details as you are trading off flexibility for speed. I've never known it be a problem for command line parsing.
(If you ask me, fifty options isn't really that many, except that it's quite a lot to pass on an actual command line. It might be easier to design a configuration file format — perhaps a simple Tcl script! — and then to just pass the name of that in as the actual argument.)
Is there any reason to use parse_args (not in tcllib) over cmdline (in tcllib)?
Performance? Details of how you describe things to the parser?
Can both be easily included in a starkit?
As long as any C code is built with Tcl stubs enabled (typically not much more than define USE_TCL_STUBS and link against the stub library) then it can go in a starkit as a loadable library. Using the stubbed build means that the compiled code doesn't assume exactly which version of the Tcl library is present or what its path is; those are assumptions that are usually wrong with a starkit.
Tcl-implemented packages can always go in a starkit. Hybrid packages need a little care for their C parts, but are otherwise pretty easy.
Many packages either always build in stubbed mode or have a build configuration option to do so.
Is this included in 8.7a now? (I'd like to use 8.7a but I'm using Manjaro Linux and am afraid that adding it outside the package manager will cause issues that I won't know how to resolve or even just "undo").
We think we're about a month from the feature freeze for 8.7, and builds seem stable in automated testing so the beta phase will probably be fairly short. The list of what's in can be found here (filter for 8.7 and Final). However, bear in mind that we tend to feel that if code can be done in an extension then there's usually no desperate need for it to be in Tcl itself.
Since active tcl will be charged, I want to change to a free interpreter like tclkit,
what is the main difference between these two interpreters, do I need to modify my source in a large scale or simple just modify some modules.
Both are Tcl interpreters, and if you have the same version (as reported by info patchlevel) then you have the same version. There are very few differences indeed. Those differences:
ActiveTcl comes with more third-party packages than Tclkit (though you can use kit-built libraries or build your own packages with both). This is what you'd expect from the kind of full-service Tcl distribution that it is.
Tclkit tends to come with support for fewer character sets and timezones; you can add these back in if you need them. This is because the Tclkit distribution was designed to be used in much more embedded situations (and, originally, to fit on a floppy disk; that's mostly irrelevant now that nobody has floppies any more).
There are differences in startup, library locations, etc. Of course.
That said, the commercial tools built on top of the ActiveTcl platform (notably the ActiveState TDK) can actually produce packaged software using what they term basekits, which are effectively tclkits. They use the same packaging technology, the same file format. (The name is different for branding reasons, and they might have slightly different sets of default-packaged goodies.)
Myself, I use ActiveTcl and Tclkit on the same system. (I also compile my own builds of Tcl direct from source, but then you'd expect that as I'm a developer of Tcl itself.) ActiveTcl is very convenient for when I just want to write code, and Tclkit is nice for when I'm distributing an app to other people in my organization.
I do not know what language a program was written in, but I'd like to find a decompiler that can decompile its source code and find it out what language it was written in.
If it is made in pascal, c, bas, vb, qb or something this way and decode/save as a readable .src
Something like exe2bin or exe2src
I have a coupple DOS-programs, I think were made in pascal. I need to decompile these programs so I can make them a Win32 application.
Hexrays http://www.hex-rays.com/decompiler.shtml is a product that decompiles any Windows executable to C source code. More than any other decompiler, it does not achieve a roundtrip decompilation -- depending on the language, it may be more or less impossible to reconstruct the program from the decompiled source.
For some languages this is easier than for others. E.g. .NET languages have Reflector, and I believe I've seen something similar for VB6.
You seem to be looking for some sort of "theory of everything" decompiler. There is no such thing. If you have any doubts, give a thought to this:
Why is closed source software different than open source software?
The answer is, of course, that you cannot see the source code of a closed source program ;) You may try with existing decompilers, but there is no guarantee you will succeed, which you seem to expect.
You can write a decompiler that takes any type of binary and translates it to a single higher-level language, albeit impractical in many cases.
A skilled human can look at the .exe with a hex file viewer. Most compilers leave their identity pretty clearly in the strings in the program.
A program to do that, now that's harder.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Languages like Ruby and Python are usually referred-to as open source, but what makes them so?
Is it an open-source compiler?, or interpreter or execution virtual machine?
If we're talking about the compiler, then would C++ be open source?
At the core, as others have observed, there really is no such thing as an "open source language". Only code can be open source in the strictest sense. So there can be open source compilers, runtimes, libraries, etc.
With many languages, however, the implementation (compiler/runtime) is almost inseparable from the language itself. This is the case with Ruby, Python, etc., where the language is effectively defined by its primary/original implementation. While there are other implementations of these languages, the primary implementation and the language are virtually interchangable. In such cases where the primary implementation is also open source, it makes some sense to refer to it as an open source languages, especially since such languages tend to have a community that is also almost entirely built around and friendly to open source software.
I don't think languages are generally considered to be open source, but rather the software implementing the language (whether it's a compiler or a virtual machine or whatever). It follows that a given language can have both open-source and non-open-source implementations. For example, there are many closed-source C++ compilers, as well as open source ones.
Perhaps one could make a distinction between a language that is controlled by a single entity (eg. C#) versus a language that is grown through community contributions (eg. Python or even Java).
I usually hear "open source language" applied to languages which are modified according to the wishes of the community. For example, Python has the PEP process, which allows anybody interested to alter the syntax / semantics of the language itself.
C and C++ are community-driven as well, though due to their age and ubiquity any changes require an incredible standardization effort. C++0x has been under design for years, and C has seen only 3 major versions (K&R, C89, C99).
Languages which are controlled by a single entity with very little community input, such as Java or C#, are usually considered "closed" regardless of the available implementations. There are GPL'd implementations of both the Java and .NET VMs available, but the language's evolution isn't community-driven. For an example of the grief this can cause, see efforts to add closures to Java.
I must admit I've never heard of a language being referred to as open source but I guess one way of viewing it is that the two examples you have given, Ruby and Python, are (AFAIK and I'm not an expert at all in either) both non-compiled languages whereas C and C++ are compiled.
So for client-side Ruby and Python applications you have to make the code available to the user since it gets interpreted at run-time whereas for compiled languages this is optional since only the compiled executable is required.
Of course on the other hand many Ruby and Python applications will be server-side, as part of the implementation of a website for example, and so the code is interpreted on the server and therefore never visible by the end user.
People often use the term "language" synonymously with the entire programming environment encompassing IDE, actual language, runtime environment/architecture and code libraries/frameworks. So when you say "open" I immediately think of Sun Microsystems releasing the code for the Java framework and VM as open source.
Then you have the likes of C#/.Net where the language, the core framework classes and the CLR spec are submitted to ECMA as a standard. Third parties such as Mono can implement those open, standardized components without having to license the technology and it could therefore be described as being open to an extent even though Microsoft's implementation is closed source (or only partially open anyway) and a commercial product. In Mono's case they implement some of the periphery framework classes that aren't standardised/open which is potentially a legal grey area.
Can we consider Open source language mainly in terms of GNU licences? Or should that be only the entity [comunity, company, etc.] driven criteria?
I've started a project(developer text editor) in a interpreted language(Tcl/Tk) and another with Perl(both are open-source), but with some time, when it gets in a Beta version, I will need to distribute it for the users(developers of course), but I want to know some things about this:
It's possible to compile it to a executable?
How?
Can I compile for other platforms?
Or in this case it's better to use a compiled language or a interpreted?
Is usual things like this?
In the users machine, he will need to have Tcl/Tk or Perl?
Both Tcl and Perl can be compiled into executables. For windows, there's perl2exe and perlcc for systems running UNIX style operating systems. As for Tcl, there is freewrap and starpacks.
If you're just doing this for the benefit of a single executable, and eliminating the need for installing Perl and other dependencies, then there's no real reason you can't do this. It's quite a nice method for testing your application without having to constantly compile, though defeats the point of using an interpreted language in the first place.
Also take a look at The Simplest Steps to Converting TCL TK to a Stand Alone Application, this page is also useful, How can I compile Tcl type scripts into binary code
The usual and common way for such scripts is to distribute the source. A binary would only work on some very specific systems but Tcl/Tk/Perl runs on so many systems, so that would be a really big restriction for no real reason. It also helps other developers more to reuse your scripts in some good way. In most cases, even when somebody could execute your binary, it wouldn't be of much help without the source.