I understand that the "alpine" images don't contain locale, we need to use IronPython for scripting in one of our microservices, though (reason being that the scripts are supposed to be written by domain experts, not developers - we use IronPython as a DSL here, which is perfectly fine for everyone involved).
I just have one question:
If I don't set the locale (which I can't, because locale.setlocale(...) always fails with the alpine image), am I guaranteed that I can always parse numbers (the only thing we care about) in the "English" format (. being decimal point)?
The Python code will use numbers with decimal points a lot in our project.
If we can drop the following line from our code:
scope.Engine.Execute("import locale\nlocale.setlocale(locale.LC_ALL, 'en_US')");
we can instantly switch from the huge base image to alpine.
Additional info: we run our containers on a K3S cluster in Germany and Finnland, also on Raspberry Pis (IoT scenario). Just don't want to have the terribad "," and "." confusion that tortures the world for centuries now in our company.
Related
Example:
version: ‘2’
services:
mysql:
image: mysql:8.0
I see two parts in the image value, Example: flask-redis:1.0 or mysql:8.0. This is understood that the second part is the Version. However, in one tutorial I just found the image section is written as
Image: tut:php_img
What does this indicate, because there is no mention of version.
An image name is made up of slash-separated name components, optionally prefixed by a registry hostname.
A tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes. A tag name may not start with a period or a dash and may contain a maximum of 128 characters.
So technically, if the two rules above are followed, the [IMAGE]:[TAG] is valid. Further on, it is just a matter of preference.
I believe the most popular convention is Semantic Versioning. In some cases, semver is enhanced by adding other relevant metadata about architecture or the base-image used (nginx:1.19.1-alpine-perl).
Conversely, any convention can be ignored and the images can be tagged conveniently with the build-number or other identifiers that can be handy in a CI/CD pipeline for example.
The second part (the one after :) is not version. While it can indicate a version, it is just a tag that can contain numbers as well as letters, in this case php_img (it just needs to comply with standard DNS naming rules).
So mysql:8.0 is exactly the same as tut:php_img, where tut is equivalent to mysql and php_img is equivalent to 8.0 as long as you are working with them locally (there is a difference between them if you want to push them to a repository though).
I don't know how it happens that the option named "Restrict where this project can be run" from Jenkins seems to allow only a single value inside "Label Expression" field.
I tried lots of combinations in order to add more than one label and I wasn't able to find any way to put two.
I need to mention that I need AND between these labels.
The irony is that this option even has an Info button which loads some documentations, which is missing to say how an expression is supposed to look like. Another small nail in the Jenkins UX coffin. On this one neither Google helped.
There is a Jenkins bug causing the help text not to be shown. It is present since 1.585 and fixed since 1.621 (or 1.609.3 respectively).
Here is the help text:
If you want to always run this project on a specific node/slave, just specify its name. This works well when you have a small number of nodes.
As the size of the cluster grows, it becomes useful not to tie projects to specific slaves, as it hurts resource utilization when slaves may come and go. For such situation, assign labels to slaves to classify their capabilities and characteristics, and specify a boolean expression over those labels to decide where to run.
Valid Operators
The following operators are supported, in the order of precedence.
(expr) parenthesis
!expr negation
expr&&expr and
expr||expr or
a -> b "implies" operator. Equivalent to !a|b. For example, windows->x64 could be thought of as "if run on a Windows slave, that slave must be 64bit." It still allows Jenkins to run this build on linux.
a <-> b "if and only if" operator. Equivalent to a&&b || !a&&!b. For example, windows<->sfbay could be thought of as "if run on a Windows slave, that slave must be in the SF bay area, but if not on Windows, it must not be in the bay area."
All operators are left-associative (i.e., a->b->c <-> (a->b)->c ) An expression can contain whitespace for better readability, and it'll be ignored.
Label names or slave names can be quoted if they contain unsafe characters. For example, "jenkins-solaris (Solaris)" || "Windows 2008"
Some command options are with one dash e.g. ruby -c (check syntax) and ruby --copyright (print copyright). Is there any pattern to this?
These are known as short and long options. Which name/format a developer uses for options of his program is totally up to him.
However, there are some widespread conventions. Like -v/--version for printing version number, -h/--help for printing usage instructions, etc.
Sadly, most commandline tools on OSX seem not to conform to -v/-h.
Good CLI (command-line interface) design dictates that options of a program that are most useful should have two formats, short and long. You use short format in your everyday life (because it's faster to type).
ps aux | grep ruby
Long ones are for scripts that you write and rarely touch (they're easier to read and understand).
mongod --logpath /path/to/logs --dbpath /path/to/db --fork --smallfiles
Many less used options may have only the long version (because, you know, there are only 26 letters in latin alphabet).
On many rails commands there is a pattern. One dash is an abbreviation for a two dash option, e.g. rspec -o FILE is a synonym for rspec --out FILE.
I have a program that generates random pin codes. These pins are generated in Java, then stored in the mainframe, via a NATURAL program. From there, they are eventually physically printed by a batch JCL job that calls an MVS SCRIPT to print the form, with the pin code on it.
I've come across some issues with special characters before such as: |{}![]^~<>; that for one reason or another do not print properly. I've also removed 0OQ1l for OCR reasons.
Recently, an error came to my attention with another character that doesn't print properly, . but the . character only fails when it is the first character of the PIN Code.
So since I've run into this issue I thought I would see if I could find other special jcl, Natural or MVS Script characters that might interfere with my programs operation so that I can test them now and hopefully not run into this issue later or have to fallback to only using OCR'ed AlphaNumeric characters.
EDIT
Java - Web Application Runs Under Tomcat 6.x on a Solaris Server.
Natural - The Natural Program is called using webmethods Broker generated classes (POJOs).
My understanding is it uses RPC for actual communication.
The program verifies some data and stores the Pin in combination with a GUID on a record, in ADABAS.
There is a batch job that runs to print the forms. The Batch job is written in JCL.
My Understanding from the maintainer of the Batch Job, and the Forms stuff is the actual language to describe the forms themselves and how they get printed is an outdated/unsupported language called MVS SCRIPT.
the Bottom section of the script looks like this:
//**********************************************************************
//* PRINT SORTED FORMS TO #### USING MVS SCRIPT
//**********************************************************************
PRINTALL EXEC PGM=DSMSPEXEC,PARM='LIST'
//* less 'interesting' lines omitted
SYSPRINT DD SYSOUT=*
PRINT1 DD SYSOUT=A, OUTPUT=*.C####,
RECFM=VBM,LRECL=####,BLKSIZE=####
//* less 'interesting' lines omitted
//SYSIN DD *
AUTH /* redacted */
SCRIPT FROM(MYFORMS) (MESSAGE(ID TRACE) CONT -
FILE(PRINT1) PROFILE(redacted) -
NOSEGLIB DEVICE(PG4A) CHARS(X0A055BC))
.C#### is an actual number and is a variable that points to the chosen printer.
NOTE: I'm a Web Programmer, I don't speak mainframe, JCL, MVS, etc.
I think you will find the program (pgm=) is DSMSPEXC and not DSMSPEXEC.
I am guessing (could be wrong) we are talking about Script/DCF (which later became IBM Bookmaster / Bookmanager on other platforms).
Script/DCF is basically a GML based language. It was from GML that SGML was derived (HTML and XML are prominent examples of SGML languages).
In Script : starts a tag, . ends a tag. There are also macro's which have a . in column 1
.* ".*" in column 1 starts a line comment
.* .fo off is Format off (like <pre> in html)
.fo off
.* Starting an ordered list
:ol.
:li.Item in orded list
:eol.
i.e.
Script HTML
: < - Starts tag
. > - end of tag Script/DCF is generally pretty tolerant of .
& & - Starts a variable
There are variables (&gml. = :) for most of the special characters.
Characters to worry about are
: - always
& - always
. - in column one or after a :.
Other characters should be ok provided there are no translation errors. There charset X0A055BC (Mainframe SONORAN SANS SERIF ??) might not have all the special chars in it.
There are manuals around for Script/DCF tags.
Your data is not going to affect the JCL in any way.
I don't know about ADABAS or NATURAL. If you ask here, http://www.ibmmainframeforum.com/viewforum.php?f=25, specifically about that part, with as much detail as you can provide, there is a very expert guy, RDZbrog, who can probably answer that for you.
For the SCRIPT/VS itself, as Bruce Martin has pointed out, there may be some issues. With .xx and :xx there is not a clash with normal text. But you don't have normal text. With the &, which indicates a SCRIPT variable, it is more likely to be problematic and at any location.
I would fire some test data through: Your PINs with position one being all available punctuation preceding "fo" and "ol", and the same with those sequences "embedded" in your PINs. Also include a double & and a triple &.
Your query should be resolved in your specification. It is not, but I'm sure you'll get all the documentation updated when you get a resolution.
In Rebol 2, it is possible to get the full path of a file by using get-modes, e.g.
>> get-modes %foo.r 'full-path
== %/home/hostilefork/foo.r
The function get-modes is not in Rebol 3. How do you get the equivalent behavior?
Note that `full-path doesn't even seem to be mentioned as a known parameter in the Rebol 2 documentation.
The new function clean-path does that specific thing:
>> clean-path %foo.r
== %/home/hostilefork/foo.r
As for the rest of the functionality offered by get-modes, the port model in Rebol 3 seems to be still in flux (or at least has little documentation, besides a wiki page of examples). In describing the motivations behind changes to Rebol 3, Carl Sassenrath cited Rebol 2 ports as flawed:
I believe that some of the main design principles of REBOL ports were flawed. Second-order features (such as port field auto-inheritance or even the port-as-a-series concept) were placed above first-order features (like easy I/O access methods) and too many variations of external devices were squeezed into a single port definition, resulting in a large bloated port object.
So if any other get-modes functionality is needed, it will probably require some hunting and experimentation for the moment.