I am designing some reconfigurable logic which, by its nature, could be configured to create a metastable combinational circuit. Chisel compiles my circuit okay but stops me at the start of the run, having detected the potential of a combinational loop.
It is great and appropriate for Chisel to flag this as an error! Since the combinational nature of the circuit is intentional, I now need to turn off the error so that I can proceed to testing the circuit's behavior on a range of valid configurations. How can I do this?
Thanks in advance for your assistance in this matter.
I found out from one of the comments in the bug database at gitHub that there is a command line option for this: --noCombLoop. I will try this option and report back. Thanks to dogngyukim for mentioning this on gitHub.
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 am coding a function which gets called via RFC and I want to find the most simple way to raise an exception with a custom message in ABAP. It would be great, if this could be done as short as possible, if possible on one line.
I want this for debugging, not for running production code.
Background:
In the past I used the Python programming language. I like to debug without a debugger. I put some assert 0, myvar lines in to the code and execute the code. For me this feels faster then tradition debugger with stepping over or into code lines. I am searching for an equivalent to assert 0, mvar in ABAP.
Raising an exception is just the strategy I have on my mind at the moment. Every other strategy to get to the overall goal is welcome.
As you already found out, MESSAGE text TYPE 'E' will let you throw arbitrary messages that abort program execution. You could also choose 'A' as a type. However, do not use this to test your code.
There are several reasons for this:
As the documentation of MESSAGE explicitly states, MESSAGE is intended exclusively to interact with the user and should only be used in the layor of your code closest to the user interface. The exact behaviour of messages is difficult to predict, since it depends on the processing mode in which your code is executed, cf. the documentation of message behavior. If you absolutely must, use ASSERT instead, which has much more consistent behavior.
You should not alter your production code for testing purposes. Test code and production code should be as disjoint as possible, since otherwise you run the risk of accidentally leaving code purely intended for testing in your production code. These days, ABAP offers a powerful unit testing framework in the form of ABAP Unit. The assertion methods of cl_abap_unit_assert all offer a msg parameter with which you can define very specific error messages for failing tests. This allows you to do detailed testing without having to alter production code (if you designed it to be testable).
Both MESSAGE and ASSERT produce short dumps. In development systems, this is usually not seen as that bad, but you should avoid producing short dumps if you can, since it makes it harder for readers of e.g. the ST22 logs to distinguish true unforeseen error situations in mature code from failed tests during active development. A failing unit test does not dump, and is just as useful.
There is ASSERT statement in ABAP that you could use in a similar way to your Python case.
Here is a docu:
ASSERT
I found that this works:
message my_string_var type 'E'.
I add the MESSAGE TYPE 'E' only temporary into the code. I test my ABAP code from outside (via PyRFC).
Back in my (limited) java programming days, I remember this nice feature where if I tried to make a call that could throw an exception, java would require me to handle that exception or pass it off to something that could.
Anyways, I am writing a piece of powershell code that messes around with objects in Active Directory, so I want to be very, very careful. I've gotten occasional remote timeout errors, and that is leading me toward the more general question:
"How can I know ahead of time which of these cmdlets can throw exceptions indicating dangerous conditions, and what is the list of those possible exceptions?"
I am wondering if the list of exceptions, per cmdlet, is way too long to address all possibilities. I also don't want to just write a generic exception handler, as powershell seems to do OK in the general sense of error handling.
What's the best way to determine, per cmdlet, the list of all exceptions that can occur? Is this even possible / feasible?
Thanks!
Heh, I think you started out on the wrong foot there. The jury is very much out on whether Java's checked exceptions are a nice idea.
That said, what you ask is very difficult to answer. In Java, it's clear to the compiler through static analysis what methods throw (or at least what they declare they will throw) what exceptions; this is a closed system existing solely in the process space of the compiler. In the real world of distributed heterogeneous systems, there is no universal checked exception framework. PowerShell cmdlets exist in the domain of a .NET appdomain in a win32 process, but they talk to backing systems on foreign servers using obtuse protocols like Active Directory which are a world apart both in implementation and general conception. Exceptional conditions may "flow" from one domain to the next, but they get warped, wrapped and mushed in all directions before they bubble up to you, the poor user at the console. In short, the answer is no. The general purpose Cmdlets (get-item, get-childitem) do not know about the underlying provider system's propensity to cause errors, and nor can they reliably know this.
However, if you have a dedicated module for Active Directory (like ActiveDirectory module from Microsoft, or Quest's QAD module) then it's possible they have listed the exceptions that their cmdlets will surface in the case of exceptional conditions in the backing system. This help would be found - most likely - in the module (or snapin) help files, or on a per-cmdlet basis. Try running the following command:
ps> get-help do-something -full | more
This will show the full invocation syntax along with any notes the developers have felt good enough to bless you with. Pay particular attention to the footer; it's here you'll usually find a more general help topic like "about_thesecmdlets" that you may view with: get-help about_thesecmdlets
Hope this helps.
i use ifort and gfortran to compile my Fortran program.
However i also use a coworkers source and he has got a lot of unused variables.
How can i suppress these for the compile, seeing as they are not really an error?
However i dont want to disable -pedantic and -stan in the compiler options and thus want all the other warnings.
cheers and thanks for the help
With ifort try -warn [no]unused.
And, while I'm here, I suggest you remove unused variables. The compiler may not regard them as an error, but disciplined software engineering regards all dead and unused code as erroneous; it imposes a maintenance burden.
Yes, as High Performance Mark pointed out, the best way to get rid of those warnings is to tell your coworker to fix his code.
As for easy solutions, with gfortran, have a look at the -Wunused-### options in gcc's manual: Warning Options. Notably, -Wno-unused-variable might do what you want.
[...] why the heck would you use gfortran when you have Intel Fortran ?
When developing, running your code through multiple compilers helps in finding bugs and producing portable code.
Do you use the debugger of the language that you work in to step through code to understand what the code is doing, or do you find it easy to look at code written by someone else to figure out what is going on? I am talking about code written in C#, but it could be any language.
I use the unit tests for this.
Yes, but generally only to investigate bugs that prove resistant to other methods.
I write embedded software, so running a debugger normally involves having to physically plug a debug module into the PCB under test, add/remove links, solder on a debug socket (if not already present), etc - hence why I try to avoid it if possible. Also, some older debugger hardware/software can be a bit flaky.
I will for particularly complex sections of code, but I hope that generally my fellow developers would have written code that is clear enough to follow without it.
Depending on who wrote the code, even a debugger doesn't help to understand how it works: I have a co-worker who prides himself on being able to get as much as possible done in every single line of code. This can lead to code that is often hard to read, let alone understand what it does in the long run.
Personally I always hope to find code as readable as the code I try to write.
I will mostly use debugger to setup breakpoints on exceptions.
That way I can execute any test or unit test I wrote, and still be able to be right where the code fails if any exception should occur.
I won't say I used all the time, but I do use it fairly often. The domain I work in is automation and controls. You often need the debugger to see the various internal states of the system. It is usually difficult to impossible to determine these simply from looking at code.
Yes, but only as a last resort when there's no unit test coverage and the code is particularly hard to follow. Using the debugger to step through code is a time consuming process and one I don't find too fun. I tend to find myself using this technique a lot when trying to follow VBA code.