I'm working on implementation of a simple SCPI parser for an instrument that will support VISA API. I wonder if there are any restrictions to support commands that may be called with different set of arguments, like overloaded functions in C++?
Example:
SOURCE:POWER <SIGNAL_ID>, <VALUE>
SOURCE:POWER <SIGNAL_GROUP_ID>, <VALUE>
SOURCE:POWER <VALUE>
SOURCE:POWER <CHANNEL_N>, <ON|OFF>
Is this allowed? I have read SCPI-99 standard but can't find any direct prohibition to do this.
On the other side if this is allowed then it is not clear what should be returned by SOUR:POWER? query.
Related
I am trying to take advantage of Exposed's type-safe DSL on top of Vert.x SQL Client to have both type-safety and throughput. I know currently Exposed doesn't support any reactive/async/non-blocking database clients yet (see #456, #732, etc.), but a simple workaround is to generate SQLs for them.
Q: How to get a plain SQL query which will be executed? provides a solution using fun prepareSQL(builder: QueryBuilder): String for Querys, and for DeleteStatements, InsertStatements, and UpdateStatments, etc., I can use fun prepareSQL(transaction: Transaction): String and adapt the original library code a little bit to make it generate both plain SQLs and prepared SQLs. However, when I execute the code directly I get the following exception:
Exception in thread "main" java.lang.IllegalStateException: Please call Database.connect() before using this code
Since I don't use Exposed's API but use Vert.x SQL Client's to connect to the database, calling Database.connect and transaction would mean a waste of resources. So how do I do this without calling Database.connect or having a Transaction? I couldn't figure this out myself since it seems Exposed is too tightly coupled with JDBC and a lot of code's visibility is quite restricted. For example, I also tried creating a dummy no-op Database but couldn't succeed because it has a private constructor.
In addition, can I also generate SQLs using the DAO API?
The ABAP documentation lists three kinds of modularization structures:
Methods. Problem: methods don't accept parameters.
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Forms. Problem: are marked as "obsolete".
Is there a newer structure that replaces the obsolete FORM structure, that is:
Local to our program.
Accepts parameters.
Doesn't require ABAP Objects syntax ?
Methods. Problem: methods don't accept parameters.
I am not sure how you came to that conclusion, because methods support parameters very well. The only limitation compared to FORMs is that they don't support TABLES parameters to take a TABLE WITH HEADER LINE. But they support CHANGING parameters with internal tables, which covers any case where you don't actually need the header-line. And in the rare case that you are indeed forced to deal with a TABLE WITH HEADER LINE and the method actually needs the header-line (I pity you), you can pass the header-line as a separate parameter.
You declare a method with parameters like this:
CLASS lcl_main DEFINITION.
METHODS foo
IMPORTING iv_bar TYPE i
EXPORTING es_last_message TYPE bapiret2
CHANGING ct_all_messages TYPE bapiret2_t.
ENDCLASS.
And you call it either like that:
main->foo( IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[] ).
or with the more classic syntax like that:
CALL METHOD main->foo
IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[].
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Yes, function modules are supposed to be global while FORM's are supposed to be local (supposed to: You can actually call a FORM in another program with PERFORM formname IN PROGRAM programname).
But classes can be local or global, depending on how you created them. A global class can be used by any program in the system. So function groups can be substituted by global classes in most cases.
The one use-case where function modules can not be substituted by methods of classes is for RFC-enabled function modules. RFC is the Remote Function Call protocol which allows external systems to execute a function module in another system via network. However, if you do need some other system to communicate with your SAP system, then you might want to consider to use webservices instead, which can be implemented with pure ABAP-OO. And they also offer much better interoperability with non-SAP systems because they don't require a proprietary protocol.
Is there a newer structure that replaces the obsolete FORM structure, that [...] Doesn't require ABAP Objects syntax ?
Here is where you got a problem. ABAP Objects syntax is the way we are supposed to program ABAP now. There is currently a pretty hard push to forget all the non-OO ways to write ABAP and fully embrace the ABAP-OO styles of writing code. With every new release, more classic syntax which can be substituted by ABAP-OO syntax gets declared obsolete.
However, so far SAP follows the philosophy of 100% backward compatibility. While they might try their best to compel people to not use certain obsolete language constructs (including adding scary-sounding warnings to the syntax check), they very rarely actually remove any language features. They hardly can, because they themselves got tons of legacy code which uses them and which would be far too expensive and risky to rewrite. The only case I can think of when they actually removed language features was when they introduced Unicode which made certain direct assignments between now incompatible types syntactically illegal.
You are having some wrong information there. Don't know what system version are you in, but this info could help you out:
Methods: They actually accept parameters (should be crazy if they wouldn't). In fact, they accept IMPORTING, EXPORTING, CHANGING and RETURNING parameters.
Forms: Indeed they are obsolete, but in my opinion there is no risk in using then, almost every standard component relies in programs made out of FORMS. FORMS are a core concept in ABAP programming. They are the "function" or "def" of many other languages. They accept USING, CHANGING and TABLES parameters.
I would like to have a C++ client application that maintains a cache of objects that come from a Java server. The objects need to be compatible. I understand that Gemfire maintains them in a serializable format. This means the Java class needs to be equivalent to the C++ class.
Is there a common practice for defining the class structure in common place in a language-independent specifcation and generating the equivalent Java and C++ classes that are serializable to PDX or any other form that Gemfire uses?
Regards,
Yash
Before PDX I used to create a language-neutral representation of my domain and simultaneously generate Java, C++ and .Net classes using DataSerializable. However, PDX makes this unnecessary for the most part. I enclose the sample config below.
If you encounter types that you are using that Java does not support, you still do not have to resort to generating serializers but you can focus in on serializing that one type (see page 564 of http://gemfire.docs.pivotal.io/pdf/pivotal-gemfire-ug.pdf
Consider generating your own serializers when you have an insane need for speed since the auto-serializer can produce a drag. This is usually not needed but if you do, here are the instructions: http://data-docs-samples.cfapps.io/docs-gemfire/latest/javadocs/japi/com/gemstone/gemfire/DataSerializer.html
Here is the configuration for using the pdx auto serializer:
<!-- Cache configuration configuring auto serialization behavior -->
<cache>
<pdx>
<pdx-serializer>
<class-name>com.gemstone.gemfire.pdx.ReflectionBasedAutoSerializer
</class-name>
<parameter name="classes">
<string>com.company.domain.DomainObject</string>
</parameter>
</pdx-serializer>
</pdx>
...
</cache>
If I answered your question, please give check "Answered". Thanks.
When I port a NDepend CQLinq query to C# I must allways start defining a codeBase to query to, so this CQLinq query
from m in Methods
where m.ILCyclomaticComplexity > 10
select new {m}
using NDepend API in C# I must port to:
ICodeBase codeBase
from m in codeBase.Application.Methods
where m.ILCyclomaticComplexity > 10
select m
I see there is a ICQLinqExecutionContext. Can I define the context for the queries so I can directly use Assemblies, Methods, JustMyCode, ...etc?
Thanks!
As explaine in the ICQLinqExecutionContext doc: This interface is reserved for CQLinq implementation usage and is not intended to be used in your code.
But as you noticed, with just a little bit of rewritten, you can access 100% of CQLinq features (like using codeBase.Application.Methods intead of just Methods)
Also by reading the CQLinq syntax doc about predefined domain, you can see that a domain like Methods in CQLinq gets translated to context.CodeBase.Methods at CQLinq post-compilation time. What you are really missing is not the interface ICQLinqExecutionContext but CQLinq post-compilation time that is not available in C#.
I'm new in building corba application. Presently I'm developping a corba application in java. The problem I have is that I should write a method that receive the name of the class, the method and the arguments to pass to the corba server as a string.
Before invoking the remote method, I have to parse the string and obtain all the necessary information (class, method, arguments)
There is no problem here. But now concerning the arguments i do not now in advance the type of the arguments, so I should be able to convert an argument by getting its type and insert it into a Any bject to be sent, is it possible?
If Know in advance the type such as seq.insert_string("bum") it works but I want to do it dynamically.
Use the DynAny interfaces, if your ORB supports them. They can do exactly what you want. From CORBA Explained Simply:
If an application wants to manipulate data embedded inside an any
without being compiled with the relevant stub code then the
application must convert the any into a DynAny. There are sub-types
of DynAny for each IDL construct. For example, there are types called
DynStruct, DynUnion, DynSequence and so on.
The operations on the DynAny interfaces allow a programmer to
recursively drill down into a compound data-structure that is
contained within the DynAny and, in so doing, decompose the compound
type into its individual components that are built-in types.
Operations on the DynAny interface can also be used to recursively
build up a compound data-structure from built-in types.