According to a std_files.e that I have found, read_character requires not end_of_file, but it doesn't specify any post-condition; and last_character has no preconditions. Therefore, what happens if you call last_character before calling read_character?
last_character will give a default value '%U' unless there is some unusual code around, e.g. the code that redefines this feature or accesses an object input on STD_FILES and reads something without using STD_FILES, etc.
Related
I've been searching the documentation for a long time and still can't figure this out.
In the SCons documentation, there is discussion about adding a PreAction or PostAction. In the examples, they call an example method:
foo = Program('foo.c')
AddPreAction(foo, 'pre_action')
This calls 'pre_action' before 'foo.c' is compiled and linked. However, there is no explanation about what format 'pre_action' must take.
I have discovered that there are several pre-built actions, such as 'Copy'. However, I cannot find the source of 'Copy' to reverse-engineer it and write my own.
Can anyone point me to a guide as to how to create my own Actions? I either need an interface for calling my own method such as 'pre_action' above, or a guide for writing an Action class.
Really, even just some example code that is actually complete enough to use would be helpful...
The manpage section Action Objects lists the types of things that can be passed to the Action factory function to create an action; that is also what you pass to AddPostAction and AddPreAction as the second argument - that is, either an Action already made by a previous call to Action, or something that can be converted into one like a command string, or a list of such, or a function with appropriate signature. Pre/Post will simply call the Action function with that argument. So in that section, where there's an example with a call to Action, you could just plug that argument into AddPreAction, or you could save the result of calling Action and give that as the argument to AddPreAction.
The amount of flexibility here makes it a little tricky to document concisely.
(btw the source to Copy is a function called copy_func but you probably don't want to use that form because it's a couple of extra levels of abstraction you won't need)
I'm new to JMeter so this question may sound absolutely dumb...
I have a loop in which a variable (let's say it is called "raw") is being changed and written to file every iteration. The variable contains HTML encoded text so it has to be converted into plain text. I found out this can be done using __unescapeHtml function. When I tried using it worked but I ended up always receiving the same text as on the first iteration. Then I learned that I have to use vars.get instead of ${} to access a variable. So I changed ${__unescapeHtml("${raw}")} to ${__unescapeHtml(vars.get("raw")} which kind of helped: vars.get is getting the new value of raw each iteration but __unescapeHtml didn't work at all now - it just returns the encoded text from raw. I didn't succeded finding anything about this exact problem so I'm kind of stuck.
Ended up using
import org.apache.commons.lang3.StringEscapeUtils
...
StringEscapeUtils.unescapeHtml4(vars.get("raw"))
Don't know if it is a good way to do this but at least it works.
I assume, that you are using the expression ${...} inside a JSR-223 sampler or similar context. The user manual for JSR-223 Sampler states, that those scripts can be cached by JMeter. That is why you only get the values from the first time the context gets created.
The same is true for simple variable evaluations as ${varname}, as for function calls like ${__unescapeHtml(...)}.
The solution here is:
don't use ${...} inside of JSR-223 contexts, that might be cached.
you can however pass those expressions (${...}) into the context by using them as parameters through the input labeled Parameters on the JSR-223 Sampler – again assuming, that you are using it.
you can use the features, that your chosen JSR-223 context gives you, as you have done, by using the StringEscapeUtils#unescapeHtml4
My program, PKGDAYMONR has the control option:
ctl-opt Main( CheckDailyPackages )
The CheckDailyPackages procedure has the following PI:
dcl-pi *n ExtPgm( 'PGMNAME' );
As you can see the ExtPgm parameter is not the name of the program. In fact, it’s what came over in the template source and I forgot to change it. Despite the wrong name in ExtPgm, the program runs without a problem.
If I remove that parameter and leave the keyword as just ExtPgm, I get the following message:
RNF3573: A parameter is required for the EXTPGM keyword when the
procedure name is longer than 10.
If I drop ExtPgm from the Procedure Interface altogether, it also complains:
RNF3834: EXTPGM must be specified on the prototype for the MAIN()
procedure.
So why is it that I have to specify a parameter if it doesn't matter what value I enter?
O/S level: IBM i 7.2
Probably worth pursuing as a defect with the service provider; presumably for most, that would be IBM rather than a third-party, as they would have to contact IBM anyhow, given the perceived issue is clearly with their compiler. Beyond that, as my "Answer", I offer some thoughts:
IMO, and in apparent agreement with the OP, naming the ExtPgm seems pointless in the given scenario. I think the compiler is confused while trying to enforce some requirements in validations of the implicitly generated Prototype for the linear-main for which only a Procedure Interface is supplied; i.e. enforcing requirements that are appropriate for an explicit Prototype, but requirements that could be overlooked [thus are no longer requirements] in the given scenario.? I am suggesting that while the RNF3573 would seem appropriate for diagnosing EXTPGM specifications of an explicit Prototype, IMO that same effect is inappropriate [i.e. the validation should not be performed] for an implicit prototype that was generated by the compiler.
FWiW: Was the fixed-format equivalent of that free-form code tested, to see if the same or a different error was the effect? The following source code currently includes the EXTPGM specification with 'PGMNAME' as the argument [i.e. supplying any bogus value of 10-byte naming to supplicate the compiler, just as is being done in the scenario of the OP, solely to effect a successful compile], but could be compiled with the other variations with changes to the source, mimicking what was done with free-form variations, to test if the same\consistent validations and errors are the effect:
- just EXTPGM keyword coded (w/out argument); is RNF3573 the effect?
- the EXTPGM keyword could be omitted; is RNF3834 the effect?
- the D-spec removed entirely (if there are no parameters defined); ¿that was not one of the variations noted in the OP as being tried, so... the effect?
H MAIN(CheckDailyPackages)
*--------------------------------------------------
* Program name: CheckDailyPackages (PGMNAME)
*--------------------------------------------------
P CheckDailyPackages...
P B
D PI EXTPGM('PGMNAME')
/free
// Work is done here
/end-free
P CheckDailyPackages...
P E
I got a response from IBM and essentially Biswa was on to something, it simply wasn't clear (in my opinion) about the answer.
Essentially the EXTPGM is required on long Main procedure names in order to support recursive program calls.
This is the response I received from IBM explaining the reason for the scenario:
The incorrect EXTPGM would only matter if there was a call to the main
procedure (the program) within the module.
When the compiler processes the procedure interface, it doesn't know
whether there might be a call that appears later in the module.
EXTPGM keyword is used to define the external name of the program which you want to prototype. If you mention the EXTPGM then the program will be called dynamically.
Let us take an example in order to explain your query.
PGMA
D cmdExc PR ExtPgm('QSYS/QCMDEXC')
D 200A const
D 15P05 const
c callp cmdExc('CLRPFM LIB1/PF1':200)
C Eval *INLR = *ON
In the above example CmdExc used for the dynamic call to QSYS/QCMDEXC.
When we use the same program name as the EXTPGM parameter it acts as an entry point to the program when called from other programs or procedure.
But in any case when we mention any name as the sample parameter the EXTPGM will not give any error in compilation, but it gives the error during run time as it tries to resolve the name during run time.
NOTE: The scenario is using 2 entity framework models to sync data between 2 databases, but I'd imagine this is applicable to other scenarios. One could try tackling this on the EF side as well (like in this SO question) but I wanted to see if AutoMapper could handle it out-of-the-box
I'm trying to figure out if AutoMapper can (easily :) compare the source and dest values (when using it to sync to an existing object) and do the copy only if the values are different (based on Equals by default, potentially passing in a Func, like if I decided to do String.Equals with StringComparison.OrdinalIgnoreCase for some particular pair of values). At least for my scenario, I'm fine if it's restricted to just the TSource == TDest case (I'll be syncing over int's, string's, etc, so I don't think I'll need any type converters involved)
Looking through the samples and tests, the closest thing seems to be conditional mapping (src\UnitTests\ConditionalMapping.cs), and I would use the Condition overload that takes the Func (since the other overload isn't sufficient, as we need the dest information too). That certainly looks on the surface like it would work fine (I haven't actually used it yet), but I would end up with specifying this for every member (although I'm guessing I could define a small number of actions/methods and at least reuse them instead of having N different lambdas).
Is this the simplest available route (outside of changing AutoMapper) for getting a 'only copy if source and dest values are different' or is there another way I'm not seeing? If it is the simplest route, has this already been done before elsewhere? It certainly feels like I'm likely reinventing a wheel here. :)
Chuck Norris (formerly known as Omu? :) already answered this, but via comments, so just answering and accepting to repeat what he said.
#James Manning you would have to inherit ConventionInjection, override
the Match method and write there return c.SourceProp.Name =
c.TargetProp.Name && c.SourceProp.Value != c.TargetProp.Value and
after use it target.InjectFrom(source);
In my particular case, since I had a couple of other needs for it anyway, I just customized the EF4 code generation to include the check for whether the new value is the same as the current value (for scalars) which takes care of the issue with doing a 'conditional' copy - now I can use Automapper or ValueInject or whatever as-is. :)
For anyone interested in the change, when you get the default *.tt file, the simplest way to make this change (at least that I could tell) was to find the 2 lines like:
if (ef.IsKey(primitiveProperty))
and change both to be something like:
if (ef.IsKey(primitiveProperty) || true) // we always want the setter to include checking for the target value already being set
Is it possible to turn off abbreviation in getopt_long()? From the man page:
Long option names may be abbreviated if the abbreviation is unique or is an exact match for >some defined option.
I want to do this because the specification I have received for a piece of code requires full-length exact match of the flags, and there are many flags.
Codeape,
It appears there isn't a way to disable the abbreviation feature. You aren't alone in wishing for this feature. See: http://sourceware.org/bugzilla/show_bug.cgi?id=6863
Unfortunately, It seems the glibc developers don't want the option as the bug report linked above was resolved with "WONTFIX". You may be out of luck here :-\
If you use argp_parse() instead of getopt() (highly reccommended, BTW), you can access the exact flag entered by the user through
state->argv[ state->next - 2 ]
It's a bit of a hack, but should work.
This is not perfect solution but you can check exact arg given by a user after calling getopt_long() (normally within switch) like below:
if (strcmp(argv[optind-1], "--longoption") == 0)
optind points a next argument that you need to process. Thus, you can access the original arg using optind-1.