How can I print a date/time without leading zeros? For example, Jul 5, 9:15.
According to the docs it uses the same syntax as strftime, however suppressing leading zeros
time::strftime("%b %-d, %-I:%M", &time::now()).unwrap()
leads to an error:
thread '' panicked at 'called Result::unwrap() on an Err value: InvalidFormatSpecifier('-')', ../src/libcore/result.rs:746
I suspect Rust doesn't support the glibc extensions that provide this flag (and several others); however there is no syntax for non-prefixed date/time; the alternative (%l) just prefixes with blank space which is equally useless.
I could create the string by hand, but that defeats the purpose of the function.
Looking the code we can confirm that time crate does not support the flag -. Also note that time crate is on rust-lang-deprecated user, so it is being deprecated.
That said, I recommend you use the chrono crate. In addition to supporting the format specifiers you want, the chrono crate also has support for timezones and much more.
let now = chrono::Utc::now();
println!("{}", now.format("%b %-d, %-I:%M").to_string());
In the "Apple LLVM 7.0 - Preprocessing" section under the "Build Settings" tab, I've defined a Preprocessor Macros as:
STR(arg)=#arg
HUBNAME=STR("myhub")
HUBLISTENACCESS=STR("Endpoint=sb://abc-xyz.servicebus.windows.net/;SharedAccessKeyName=DefaultListenSharedAccessSignature;SharedAccessKey=JKLMNOP=")
In my code, I'm trying to refer to the value of HUBLISTENACCESS as a string:
SBNotificationHub* hub = [[SBNotificationHub alloc] initWithConnectionString:#HUBLISTENACCESS notificationHubPath:#HUBNAME];
But I'm getting errors from Xcode for the initialization of "hub":
Expected ';' at end of declaration
Unterminated function-like macro invocation
Unexpected '#' in program
I suspect that the definition of HUBLISTENACCESS in the Preprocessor Macros needs to be properly escaped but I've tried a few things and can't seem to get it right. Can somebody help me understand what I'm doing wrong?
There's one very obvious reason why you were trying to do failed: you use // in the HUBLISTENACCESS. As in C, things after // were commented out so in the aspect of the compiler, the last line of yours is actually:
HUBLISTENACCESS=STR("Endpoint=sb:
To test it, just remove one slash and it will work again. What you were doing like trying to define things as such:
#define FOO //
which I don't think it's possible. I honestly have no idea how you can do that within the Build Settings, but there are other ways to do it globally via a PCH file (prefix header).
A simple line within the PCH will will save all those troubles:
#define HUBLISTENACCESS #"Endpoint=sb://abc-xyz.servicebus.windows.net/;SharedAccessKeyName=DefaultListenSharedAccessSignature;SharedAccessKey=JKLMNOP="
Then use it as below: (no more # needed!)
NSLog(#"%#", HUBLISTENACCESS);
It says there's an error operator expected. I know this syntax error is in line 5 but I can't figure it out. I have highlighted that line with ** thx.
action(X : Y,0 : Y):-X>0.
action(X : Y,X : 0):-Y>0.
action(X : Y,4:Y):-X<4.
action(X : Y,X : 3):-Y<3.
**action(X : Y,4 : Z):- X<4, Z is Y−(4−X), Z>=0.**
Path(X):-
path(0 : 0,[0 : 0],X).
Prolog predicate names must begin with a lower case letter. So as #CapelliC points out, Path(X) :0-... is going to be a problem.
But your syntax error on line 5 is because you copy/pasted this code from something online or from an eBook perhaps. In your expression, Y−(4−X) those − symbols are not minuses but something else that look like minuses (perhaps EM dashes). Try retyping line 5 manually, and the problem will go away.
This one is a problem:
Y−(4−X)
And this one is correct:
Y-(4-X)
There is actually a subtle difference in length of the dash you can see if you look closely. The second example is an actual dash or minus (ASCII code hex 2d). The first example of a dash is a special character (a hex dump shows a character code of 59 88 92). This is an issue with copy/pasting code from an eBook or other electronic document, since there are several characters used for visual convenience that aren't the specific one required by the language.
the error is the clause following
Path(X):-
...
should be
path(X):-
...
I have an old Fortran 77 code, which I would like to run in a F90-Compiler, and my goal is to change the code as less as possible. It works quite well, but I have some problem with format statements in the code. And I don't understand what's the problem. I work with Eclipse, and gfortran. I use free form.
Question 1
This compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5)
end program
This doesn't compile
program HelloWorld
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1
end program
The Error is
P descriptor needs leading scale factor in format string at (1)
(the error is translated from german, might not be exactly the same words in english) What is wrong?
Question 2
This also compiles fine:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0, &
2X,G13.5,6H A1,2X,G13.5)
end program
If I add more code to the last code:
program HelloWorld
400 FORMAT(7HK GAMMA,2X,G13.5,7H P0,2X,G13.5,6H A1,2X,G13.5, &
2X,7HK,ALPHA-1,2X,G13.5,7H BETA-4,2X,G13.5 )
end program
it doesn't compile anymore. The error is:
P Edit descriptor expected in the format string* at (1)
whereas the (1) is placed at the third line after the closing bracket.
*I'm not sure about the translation of "format string", as my console is in german.
What is the problem there?
Your format statements have an H (for Hollerith) edit descriptors - the things in the format statements that have a number followed immediate by a H. The descriptor results in the characters (including blanks) following the H and counted by the leading number being output to the file.
This language feature was made obsolescent in Fortran 90 and removed completely from the language in Fortran 95.
They are very error prone. Since Fortran 77 a far better way of achieving the same result has been to use character constant edit descriptors.
The problem is that you have (or are creating) a mismatch between the number of characters indicated by the leading number and the actual count of characters that apparently were in the descriptor. For example, your second FORMAT statement is copied below, showing the seven characters that would be in the descriptor. You can see how that appears to end in the middle of a "string". This then confuses what the compiler sees for the remainder of the format specification.
400 FORMAT(7HK 'GAMMA',2X,G13.5,7H 'P0',2X,G13.5,6H 'A1',2X,G13.5)
1234567
As I write in the comment it looks more like FORTRAN66 than 77 because the Hollerith H descriptor and data type was used before introducing the CHARACTER data type to the language. It was also used to assign character data to integer variables, but fortunately that is very rare to encounter. The use as an edit descriptor is however more common, although very obsolete.
It is not clear what you want to achieve, good example of the desired output would be helpful.
Do you meant:
400 FORMAT(7HK GAMMA,2X,G13.5,3H P0,2X,G13.5,3H A1,2X,G13.5)
so that
print 400, 1. ,2. ,3.
outputs
K GAMMA 1.0000 P0 2.0000 A1 3.0000
Or should the P0 and A1 serve as edit descriptors?
What was the original code in the legacy software?
The nH Hollerith descriptor just outputs n next characters so it can unintentionally "eat" some of your descriptors and just print them.
That is the problem that causes that your examples do not compile, because the n before H is too large and the rest of the format then has no sense.
The next one could be
400 FORMAT(8H 'GAMMA',2X,G13.5,5H 'P0',2X,G13.5,5H 'A1',2X,G13.5)
to print
'GAMMA' 1.0000 'P0' 2.0000 'A1' 3.0000
The effect of the above in Fortran 95 and above is better achieved by
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', " 'GAMMA'",1.," 'P0'", 2.0, " 'A1'", 3.0
and maybe you would rather use just:
print '(A0,2X,G13.5,A0,2X,G13.5,A0,2X,G13.5)', "GAMMA",1.,"P0", 2.0, "A1", 3.0
for printing
GAMMA 1.0000 P0 2.0000 A1 3.0000
or even
print *, "GAMMA",1.,"P0", 2.0, "A1", 3.0
This is my code:
select max(vhis_data.C0432_SAMPL_VALUE1_R), vhis_data.C0401_aid
from vhis_data, T0401_accounts
where vhis_data.C0401_aid = T0401_accounts.C0401_aid
and (
vhis_data.c0401_aid between 1179 and 1291 or
vhis_data.c0401_aid between 1382 and 1402 or
vhis_data.c0401_aid between 1462 and 1620 or
# and so on until...
vhis_data.c0401_aid between 5450 and 5485 or
vhis_data.c0401_aid between 5503 and 5495 or
)
(these numbers represent various points in the system)
The program displayed an error:
vhis_data.c0401_aid between 1179 and 1291 or
*
ERROR at line 5:
ORA-00936: missing expression
What I've noticed is that the first part of the error references the first line in the
and ( ... ) part of my code.
I have also noticed that there is an extra or on the last line of my code. I can take it out, but is this extra or the only reason that the whole and (...) part does not work? Or is there another reason that my code is not working?
(I guess a sub-question of mine, then, is, if there is a missing expression, where does the code stop executing properly?)
For example, here, the missing expression is potentially the last line (because it is expecting something after the "or"). However, the code does not even go through the first line of the and (...) part of the code.
I have combed the net for explanations dealing with the error ORA-00936: missing expression but have not found anything relevant enough to help me in this particular situation.
I welcome any criticism or advice you may have, and thank you so much in advance for any contributions that you give me!
you should not end the whole thing with an or
5495 or
)
this makes the entire parenthetical phrase invalid - everything in the ()... so thats why the line number is flagged up top.
Could this extra or be the only reason that the whole and (...) part does not work?
It's the reason the whole query does not work.
A SQL query does not "execute" in order like a string of commands. The entire query is compiled, a plan built, and the plan executed. For that reason any syntax errors are often shown to point to lines that do not have the actual error.
So the "code" does not "execute" at all. The compilation fails, so there's nothing to execute.