I've a compiled tcl version 8.4 and want to check if --enable-threads was set when it was compiled or not ?
or if there is any another way to get the list of all passed flags.
Thanks
IMPORTANT NOTE!
Tcl 8.4 is out of long-term support. Absolutely no further changes will be forthcoming to it, not even if a catastrophic security error is discovered; if your issue isn't fixed by 8.4.20, you'll need to go to 8.5 or later. We don't know of any such security issues, but we aren't looking and won't fix them if they're found.
Support here is only on a “because we feel nice” basis. You should not create new work based on 8.4.
The global array element tcl_platform(threaded) is defined and set to 1 when the currently-used Tcl library is built with thread support. This is true from at least Tcl 8.4 onwards. Here's how to reliably get a nice boolean value you can check:
set isThreaded [expr {
[info exist tcl_platform(threaded)] && $tcl_platform(threaded)
}]
NB: Some platforms are virtually always threaded anyway (because of how they work internally; this is the case with Windows and OSX if I remember right). Future versions of Tcl (8.7 onwards) will default to threaded everywhere; this will be the only supported build mode from 9.0 on. You'll still need the Thread package to work with threads in your script, but that's a standard extension these days.
Starting with 8.5 (TIP 59), one can retrieve details about the build configuration using tcl::pkgconfig:
% tcl::pkgconfig get threaded
1
Note that this is not available in Tcl 8.4; if available, one does not have to protect against requesting an inexistent array entry tcl_platform(threaded).
Related
My tcl platform(osVersion) is v6.2
% puts $tcl_platform(osVersion)
6.2
How to downgrade tcl_platform(osVersion) to v6.1?
Thank you.
I try to find activetcl v8.5 on internet but the old version all links are invalid...
That value, which describes the version of the operating system that is running the script, is read out of a platform-specific location in your OS during the initialisation of an interpreter (technically, it is copied from data determined during startup of the first Tcl interpreter in a process, where that data is held in a location invisible to you). It is then free to be read or altered by your code... with whatever consequences that may entail.
Permanently changing that value is done by changing what OS is installed. That's totally out of scope for what an ordinary user script can do!
Tcl's implementation mostly doesn't use the OS version. It cares far more about whether API capabilities are exposed to it, and those are almost always at the more granular level of general platform (or transparently adapted around).
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 wanted to read generated opt codes for my simple program:
function test() {
const i = 2845884;
const k = 3;
return i == 2845884 ? k : 7;
}
test();
I found this gist that says that I need to build d8 from sources and run it with --trace-opt-verbose flag.
https://gist.github.com/kevincennis/0cd2138c78a07412ef21
That approach doesn't work for me neither other approaches I found on the web. Looks like all current solutions are outdated.
How can I see what opt codes will be generated for this program?
How can I see what opt codes will be generated for this program?
For this program, you are already seeing all optimized code, because no optimized code will be generated for it, because it doesn't run anywhere near long enough for optimized compilation to be worth the effort.
In general, to print optimized code that V8 generates, you need three things:
(1) A binary that has disassembler support. This is on-by-default in Debug and "optdebug" builds; for Release builds you need the GN arg v8_enable_disassembler = true.
(2) The command-line flag --print-opt-code.
(3) A function that runs hot enough to get optimized.
Try calling your test() in a loop. If you still don't see anything, run the loop more often.
(The threshold varies depending on V8 version, test program size and behavior, and due to background compilation possibly also your hardware, so there is no general rule-of-thumb number I could state here. For one-liner functions, expect to need several thousand calls.)
To answer your other question: yes, V8's optimizing compiler supports constant folding, and your test program will be folded to just return 3.
Side notes:
I found this gist that says that I need to build d8 from sources and run it with --trace-opt-verbose flag.
--trace-opt-verbose has never printed optimized code, and the gist you linked doesn't claim that it does. (That said, that gist makes a bunch of rather dubious claims, so it's not a particularly good source to begin with.)
Looks like all current solutions are outdated.
Or slightly more accurately: that one gist didn't solve your problem.
On SO alone, you could have found How to print the compiled instructions in V8 engine? or V8 will not print out disassembly or Are there ways to see the assembly code for the code generated by any of the JavaScript jits, especially V8's?, all dealing with variations of this question.
None of this has changed recently; the build flag is a requirement since at least 2014, the command-line flag as well as the fact that optimization only kicks in after a while have been unchanged since at least 2011.
FWIW, the easiest way to build V8 yourself is to follow the official documentation. The gm.py helper script used by that flow even sets the v8_enable_disassembler flag for you automatically.
CMake's global property, FIND_LIBRARY_USE_LIB64_PATHS, has the following documentation:
FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the
FIND_LIBRARY command should automatically search the lib64 variant of
directories called lib in the search path when building 64-bit
binaries.
Reading "when building 64-bit binaries" implies CMake somehow knows my target architecture, and automatically toggles the behavior on/off depending. Am I just reading too far into this, or does CMake have a higher-level abstraction for dealing with 32-bit/64-bit compilation?
If there is, how do I configure whatever mechanism is used by FIND_LIBRARY_USE_LIB64_PATHS, to force a 32-bit/64-bit compiliation?
I realize there are existing questions dealing with forcing 32-bit/64-bit, but they deal with CMAKE_C_FLAGS and the like. If CMake has a higher level abstraction, I'd prefer it to messing with CFLAGS.
tl;dr; CMake does not have a general mechanism for forcing 32- or 64-bit compilation. You do that with selection of compilers or compilation switches.
But CMake can actually find out if the compilation is for 64- or 32-bit (or probably many other word lengths too) target. As described in this answer and the CMake docs you should use:
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
message (STATUS "Compiling for 64-bit")
endif()
That is probably the underlying mechanism for "when building 64-bit binaries". But there are no variables explicitly for this.
NOTE that the variable CMAKE_SIZEOF_VOID_P is cached so that if you alter compiler options, say CMAKE_C_FLAGS to use '-m32' for a 32-bit compile it won't affect CMAKE_SIZEOF_VOID_P unless you clean your build directory.
So, in a way there seems to be a somewhat general mechanism for 32/64-bit handling. It is used in some situations, but to use it more extensively you have to handle that in your CMakeLists, which is not great.
In order to distribute a function I've written that depends on other functions I've written that have their own dependencies and so on without distributing every m-file I have ever written, I need to figure out what the full list of dependencies is for a given m-file. Is there a built-in/freely downloadable way to do this?
Specifically I am interested in solutions for MATLAB 7.4.0 (R2007a), but if there is a different way to do it in older versions, by all means please add them here.
For newer releases of Matlab (eg 2007 or 2008) you could use the built in functions:
mlint
dependency report and
coverage report
Another option is to use Matlab's profiler. The command is profile, it can also be used to track dependencies. To use profile, you could do
>> profile on % turn profiling on
>> foo; % entry point to your matlab function or script
>> profile off % turn profiling off
>> profview % view the report
If profiler is not available, then perhaps the following two functions are (for pre-MATLAB 2015a):
depfun
depdir
For example,
>> deps = depfun('foo');
gives a structure, deps, that contains all the dependencies of foo.m.
From answers 2, and 3, newer versions of MATLAB (post 2015a) use matlab.codetools.requiredFilesAndProducts instead.
See answers
EDIT:
Caveats thanks to #Mike Katz comments
Remember that the Profiler will only
show you files that were actually used
in those runs, so if you don't go
through every branch, you may have
additional dependencies. The
dependency report is a good tool, but
only resolves static dependencies on
the path and just for the files in a
single directory.
Depfun is more reliable but gives you
every possible thing it can think of,
and still misses LOAD's and EVAL's.
For MATLAB 2015a and later you should preferably look at matlab.codetools.requiredFilesAndProducts
or doc matlab.codetools.requiredFilesAndProducts
because depfun is marked to be removed in a future release.