I am trying to implement breadth-first search algorithm but I am unable to implement , and I am new user of TCL can any one help me to implement this algorithm in tcl.
I think we need a bit more detail before we can help.
So, are we are talking about a graph, if so what type? The simplest would be a undirected graph with no edge weights but is this the case?
Do you have a data structure for the graph, if so what is it?
Finally why are you re-inventing the wheel? Tcllib has the struct::graph package which implements breadth first search, see the walk command. Can you use this or the algorithms in the struct::graph::op package to do what you want.
If you are searching for files instead of generic objects, look up the command for_recursive_glob in the Tclx package. Here is a quick example:
package require Tclx
for_recursive_glob fileName {/path/to/dir1 /to/dir2} {*.txt *.doc} { puts $fileName }
The document said for_recursive_glob use breadth-first algorithm. If you want to exit prematurely (i.e. found what you were looking for), use the 'break' command to exit the for loop:
package require Tclx
for_recursive_glob fileName {/path/to/dir1 /to/dir2} {*.txt *.doc} {
puts $fileName
if {[string match *myfile*]} { break }
}
Related
I'm checkcing binary strip in RPM Packaging and get this:
__spec_install_post:
...
__os_install_post
...
__os_install_post:
...
%{!?_debug_package: /usr/lib/rpm/redhat/brp-strip %
{_strip}
/usr/lib/rpm/redhat/brp-strip-comment-note %{_strip} %{_objdump}
}
...
I didn't find anywhere in use of __spec_install_post.
Is this macro directly invoked by rpmbuild? A Documentation will be great.
It seems there's many a lot 'leaf like' macro in invoke chain. that's confusing.
I only found some references in some bugs and stuff; these seem to be magic undocumented macros that are run at certain stages, e.g. for yours right "post" the "install" stanza of your specfile.
An actual list would be great, but I think you'll only find what you already had by digging in /[usr]/lib/rpm/macros etc.
I wanted to add a check to an existing terraform build and deployment pipeline to check that the configuration being written by devs is properly formatted and in line with company syntax
Specifically I want to check to make sure they are not using plain resource blocks in thier config as opposed to module blocks
For example I want to I want to make sure they are using
Module “eks_dev_wus2_app_cluster”
And not
Resource “aws_kubernetes_cluster” “eks_dev_wus2_App_cluster”
Current approach
As I understand it I would need to first convert to json to parse through it
terraform show -no-color -json output.tfplan > output.json
Then I should use the jq tool to parse through the output per this article
https://linuxconfig.org/how-to-parse-a-json-file-from-linux-command-line-using-jq
A little fuzzy on how I would go about specifically checking the blocks in the terraform config to confirm whether or not they are resource or module.
Can anyone point me in the right direction?
Is there a better way to get output values? Don’t need an entire solution, just looking to clarify some of the fogginess of approaching this problem
Under the output format, there is a list called resource_changes. Each change has an address field. To meet your requirement, each address should start with module. This makes the developer responsible only for the modules that they are changing with this terraform plan.
Assuming you already have output.json in place, you could do it like this:
LIST=$(cat output.json| jq -r ".resource_changes[].address")
for ADDRESS in $LIST
do
if [[ $ADDRESS != "module."* ]]; then
echo "$ADDRESS is outside of a module"
exit 1
fi
done
I would like to redirect the stdout to null when loading package in Windows Tcl. (Redirect the wording of "Quality Windows Audio/Video Experience (qWAVE) support is available." to null)
Is their any way to solve this or any idea for this ?? Thank you so much.
C:\Users\Tester>tclsh
% set ixchariot_installation_dir "C:/Program Files x86)/Ixia/IxChariot"
C:/Program Files (x86)/Ixia/IxChariot
% cd $ixchariot_installation_dir
% load ChariotExt
Quality Windows Audio/Video Experience (qWAVE) support is available.
If the library is using Tcl channels to write its message, and you're using Tcl 8.6, it's pretty easy. You just push a transform on the stdout channel that swallows all bytes.
# Most of this is boiler-plate stuff...
namespace eval swallow {
proc initialize {handle mode} {
return {initialize clear finalize write flush}
}
proc clear {handle} {}
proc finalize {handle} {}
proc flush {handle} {}
# The important one; do nothing to throw away bytes
proc write {handle buffer} {}
# Export as an ensemble
namespace export *
namespace ensemble create
}
# Start dropping output
chan push stdout swallow
load ChariotExt
# Stop dropping output
chan pop stdout
That only works if the library is using Tcl channels to write it's message. If it is using a direct write (the more likely case) it won't. You can instead try a full redirect, but these are not easily undone.
close stdout
open NUL
load ChariotExt
I know that'd work on POSIX systems (except with /dev/null instead of NUL). Not sure on Windows. And it can't be easily undone; the old standard output stream is gone.
And in any case, it's possible that the library is using a direct write to the console; those aren't blockable, and you might just have to live with that irritating message.
I'm trying to draw on a canvas that is in the top level of my Tcl/Tk script, but from inside a call by fileevent like this:
canvas .myCanvas {}
proc plot_Data { myC inp } { $myC create rectangle {} }
fileevent $inp readable [list plot_Data .myCanvas $inp ]
pack .myCanvas
I have found out that the script called by fileevent (plot_Data) lives in a different space.
The script for a file event is executed at global level (outside the context of any Tcl procedure) in the interpreter in which the fileevent command was invoked.
I cannot make the two meet. I have definitely narrowed it down to this: plot_Data just can't access .myCanvas . Question: How can the fileevent script plot on the canvas?
The goal of this is live plotting, by the way. $inp is a pipe to a C-program that reads data from a measurement device. It is imho rightly configured with fconfigure $inp -blocking 0 -buffering none.
Callback scripts (except for traces, which you aren't using) are always called from the context of the global namespace. They cannot see any stack frames above them. This is because they are called at times that aren't closely controlled; there's no telling what the actual stack would be, so it is forced into a known state.
However, canvases (and other widgets) have names in the global namespace as well. Your callbacks most certainly can access them, provided the widget has not been destroyed, and might indeed be working. You just happen to have given it an empty list of coordinates to create, which is not usually legal to use with a canvas item.
Since you are using non-blocking I/O, you need to be aware that gets may return the empty string when reading an incomplete line. Use fblocked to determine if a partial read happened; if it does, the data is in a buffer on the Tcl side waiting for the rest of the line to turn up, and it is usually best to just go to sleep and wait for the next fileevent to fire.
A problem that might bite you overall is if the C program is in fully buffered mode; this is true by default when writing output from C to a pipe. Setting the buffering on the Tcl side won't affect it; you need to use setvbuf on the C side, or insert regular fflush calls, or use Expect (which pretends to be an interactive destination, though at quite a lot of cost of complexity of interaction) or even unbuffer (if you can find a copy).
Is there a ready or idiomatic way of declaring an entry point in a Julia program (i.e. the equivalent of main in C or the if __name__ == "__main__" construct in Python)?
This seems to be an important functionality in order to write larger pieces of structured code that won't be used in interactive mode but I couldn't find any hints as to how this is accomplished in Julia, if at all (a possible escape route could be writing an arbitrary function to serve as main and then calling it once on the top level at the end of the main module but that's not elegant and maybe not even efficient). TIA.
You could write a main function and not call it from the top level of the file. To run the program from the command line you would use julia -L file.jl -e 'main(some,args)'. The -L switch tells Julia to load your file, and then -e tells it to evaluate the following expression. There is also an -E switch that evaluates and prints (I think of it as "evaluating out loud", since capital letters seem "loud").
This has a couple of advantages over C's main or Python's if __name__ == "__main__":
You don't have to have a single entry point! You can evaluate any expression at all after loading your file, so you don't have to cram all your command line functionality into one function.
The calls you write use full Julia syntax, so often you can avoid parsing the arguments. Soemthing like -e main(53) calls main with the integer 53, no need for atoi inside main.
When modules are loaded, if they have a function called __init__ it will be called. Does that help?
If you want to do what the if __name__ == "__main__": idiom in python does, I found that
if !isdefined(Base, :active_repl)
main()
end
does the trick.
I often find myself wanting to be able to load my main file into a REPL and selectively poke at some of the functions without invoking main or staple a CLI onto a module that is mostly intended as a library module, so I really like this trick from python.