I am creating a kbskit for my tcl executable application as follows on Suse :
./kbs.tcl -builddir=85 -r -mk-bi -bi="itcl3.4 itk3.4 iwidgets4.0.2 img1.4.1" install kbskit8.5
cp 85/bin/kbsmk8.5-bi kbsmk8.5-bi-run
./kbsmk8.5-bi sdx.kit wrap sim -runtime kbsmk8.5-bi-run
The application will be used on several flavours of linux like Redhat,Ubuntu etc. I am trying my best to test it myself under many combinations. Neverthless, i would be like to know someone thinks this would/wouldn’t work seamlessly across different platforms since I wont be able to cover all combinations exhaustively.
A Linux/x86 kbskit is at least reasonable to run on that collection of platforms. Unfortunately, the only way to be sure is to try. It should work, but if your script refers to files in a particular location and another platform (or deployment!) puts them elsewhere, then things will fail. The other thing that might go wrong is if there are significant incompatibilities in the small number of system libraries that Tcl uses, especially the C library; I do not know whether such problems exist, but I suspect they're not a major problem in practice.
You can try using the platform package (a standard part of Tcl since at least 8.5) to report what platform you're dealing with. That's the usual level of granularity you need to pay attention to.
package require platform
puts [platform::identify]
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.
I want to download the mariadb with gzip type ,but I found that it has many files could been downloaded ,such as mariadb-10.2.6-linux-x86_64.tar.gz ,mariadb-10.2.6-linux-glibc_214-x86_64.tar.gz (requires GLIBC_2.14+) ,mariadb-10.2.6-linux-systemd-x86_64.tar.gz (for systems with systemd) .
I don't know what's different between them?
First, please note that tarballs are generic, but not universal. Even though there seems to be many of them, there are still far less than supported systems and flavors. None of tarballs is guaranteed to work on any particular system. The common problem is absence of certain libraries which MariaDB server, client programs or plugins are linked with.
Back to the actual question, the main difference is highlighted in the package names/comments.
mariadb-10.2.6-linux-glibc_214-x86_64.tar.gz (requires GLIBC_2.14+) -- the binaries built on reasonably modern systems. The package most likely contains more plugins/engines, because some of them have requirements for modern compilers and libraries; but it can only be run on systems that have globc 2.14 or higher.
mariadb-10.2.6-linux-systemd-x86_64.tar.gz (for systems with systemd) -- the package with systemd support. It's important if you actually install the service and run it this way. If you just keep the binaries locally and start them manually, it shouldn't matter.
mariadb-10.2.6-linux-x86_64.tar.gz -- the package provided mostly for legacy/compatibility purposes, for older systems which are still not EOL-ed. Generally it has somewhat better chances to be successfully run on an arbitrary system, but you need to check whether it contains everything you need, as it might be not the case.
Are there any particular things to think about when building and installing (globally) a new version of Tcl from source, besides relinking /usr/local/bin/tclsh and wish to the new versions?
I know that the interpreter executables tclsh and wish are installed with different names, but what about the include and library files? When I build eggdrop, will it link with the latest version? How about the man pages - are the old ones overwritten by the new ones?
The usual approach for this case is to configure the build so that it's installed under a single directory (the Windows approach), say, under /opt/tcltk/8.6. You're then guaranteed against clashes with other versions and deinstallation is a matter of running rm -rf on that single directory. This approach has its downsides though:
You'll have to link (some) installed third-party Tcl libraries under your new hierarchy. This is because Tcl derives the set of paths to look for libraries from its own location.
/opt/tcltk/8.6/bin won't be listed in $PATH.
With certain OSes, another (possibly more sensible) approach is to do a "backport", that is, to take the source package of the required Tcl/Tk version and make it build for the installed version of the OS; then install the resulting packages in a normal way. On systems where various versions of Tcl/Tk are co-installable (for instance, Debian and its derivatives), this possibly provides the most sensible solution.
As to manual pages in the latter case, in Debian, they just end up being packaged in a separate package, installation of which is not required; so you just select one of the available documentation packages and install it.
In terms of having multiple versions present, this is a normal thing to do (do this by setting the --prefix option to configure when building) and has been so for quite a while. You'll probably want to avoid having multiple patchlevels of a single version if you can, but having, say, 8.4, 8.5 and 8.6 co-installed is entirely OK. You'll want to have the different installations in different directories too, and you're right about linking the unversioned tclsh name to the one you want normally (though I just use the versioned executable name instead).
The only way to have the manpages coexist nicely is to have them installed in separate directory trees and to update the MANPATH environment variable to point to the right one (unless you've got a man executable that will take paths to manpages directly — some do, some don't — and that is hardly as convenient). If you can bear being online, we've got official HTML builds of the documentation hosted at http://www.tcl.tk/man/ which includes all significant versions going back quite a long way.
I am in the process of building interactive front-ends to a
distributed application which to date has been used to run workloads
that had a batch-job like structures and needed no UI at all. The application is mostly written in Perl and C and runs on a mix of Unix and Windows machines, but I think this isn't relevant to the UI.
The first such frontend is going have a command-line user interface --
currently, I envision something similar to the CLIs of the Procurve
switches and Cisco routers that I have worked with.
Like modern network gear CLIs, commands are going to resemble
simple sentences, (i.e. show vlans ports 1-4) and the CLI will
have some implicit state, much in the way that Unix shells and
cmd.exe in Windows have environment variables and current working
directories. Moreover, I'd like to implement great tab completion that
is aware of the application's state as much as possible and I want to be able to do that with as
little application-specific code as possible.
The low-level functionality (terminal I/O) seems easy to implement on
top of GNU Readline or similar libraries, but that's only where the
real fun starts. So far I have looked at the Perl modules
Term::Shell
and
Term::ShellUI,
but I'm not convinced that I want to use either of them. I am still
considering rolling my own solution and at the moment I am primarily looking for
inspiration.
Can you recommend any application or library, regardless of
implementation language, that implements a good CLI from which I can
borrow ideas?
I suggest you take a look at the philosophy underlying Microsoft PowerShell. From the idea of piping typed objects between commands to the consistency of its commands and argument syntax, I think it can be a source of inspiration.
You could try having a look at libcli :
"Libcli provides a shared library for
including a Cisco-like command-line
interface into other software."
http://code.google.com/p/libcli/
BTW - I forgot to mention that it is GNU Lesser GPL and actually used by Cisco in some products.
As for your last sentence/question, I'm particularly fond of zsh completion and line editing (zle).
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.