In plantuml, I got a strange warning. I have tracked down the source problem to: when creating a sequence diagram with broken arrow from one item back to itself.
The minimal example
#startuml
self ->x self:
#enduml
yields this warning:
$ plantuml minimal.plantuml
WARNING : CROSSX
WARNING : CROSSX
But is still able to generate the image I expect.
What is plantuml complaining about? What is the meaning of this warning?
$ plantuml -version
PlantUML version 1.2018.13 (Tue Nov 27 02:11:51 JST 2018)
(GPL source distribution)
Java Runtime: OpenJDK Runtime Environment
JVM: OpenJDK 64-Bit Server VM
Java Version: 11.0.11+9-Ubuntu-0ubuntu2.20.04
Operating System: Linux
OS Version: 5.8.0-48-generic
Default Encoding: UTF-8
Language: en
This warning exists in older versions still included in by major linux distributions.
the warning was generated in src/net/sourceforge/plantuml/sequencediagram/graphic/Step1Message.java
if (m.getArrowConfiguration().getDressing2().getHead() == ArrowHead.CROSSX) {
result = result.withHead2(m.getArrowConfiguration().getDressing2().getHead());
System.err.println("WARNING : CROSSX");
}
result = result.withPart(m.getArrowConfiguration().getPart());
}
Without any clue in the commit message it was removed from upstream in September 2019
Related
I'm attempting to make a Lisp package with uiop/package:define-package. I'm using SBCL, and have confirmed that package-local nicknaming ought to be supported:
* *features*
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
:NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
:COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
:PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
:SB-THREAD :SB-UNICODE :SBCL :UNIX)
* (uiop:featurep :package-local-nicknames)
T
Nevertheless, when I try to define a package that has local nicknames, it doesn't work:
(uiop/package:define-package #:foo
(:use #:cl)
(:local-nicknames (#:b #:binparse)))
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {1001878103}>:
unrecognized define-package keyword :LOCAL-NICKNAMES
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(UIOP/PACKAGE:PARSE-DEFINE-PACKAGE-FORM #:FOO ((:USE #:CL) (:LOCAL-NICKNAMES (#:B #:BINPARSE))))
source: (ERROR "unrecognized define-package keyword ~S" KW)
0] 0
(binparse being another package I've made, which worked fine, but which did not happen to use local nicknaming).
What I've found of the uiop/package source seems to indicate that this shouldn't happen? Going by that, it should either work, or have a specific error message indicating the non-supported-ness of local nicknames (if somehow uiop:featurep is inaccurate or changing), but it shouldn't give a generic unknown-keyword error. At this point I'm not sure what I could be getting wrong.
The version of asdf that's included in releases of sbcl is based on asdf version 3.3.1 (November 2017), except bundled into only two (larger) lisp files (one for asdf and one for uiop) rather than breaking them up by purpose as is done in official releases of asdf. asdf added #+sbcl support for package-local nicknames in 3.3.3.2 (August 2019), and switched to the more general #+package-local-nicknames in 3.3.4.1 (April 2020) (the latest release version is 3.3.4, though, so that wouldn't be in yet anyway). So it's "just" a delay in pulling from upstream. Following the instructions on upgrading ASDF did the trick – extract the latest release tarball into ~/common-lisp/asdf and run (load (compile-file #P"~/common-lisp/asdf/build/asdf.lisp")) once, and future shells will use the updated version.
I have a Mac and just installed LaTeX and the editor Texmaker. To use the Arial font I installed it via MiKTeX Console. I also found out that by doing so, the files for the installed packages lay here:
"/Users/Mirko/Library/Application Support/MiKTeX/texmfs/install/tex/latex"
My problem is that the Editor (TeXMaker) still doesn't find the Arial-Font.
Here is my Code:
\documentclass[pdftex,openany,11pt,twoside,a4dutch]{report}
\usepackage{uarial}
\usepackage{csquotes}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{csquotes} % Setzen von Anführungsstrichen
\begin{document}
This is a test.
\end{document}
and here is the Error:
! LaTeX Error: File `uarial.sty' not found.Type X to quit or <RETURN> to proceed,or enter new name. (Default extension: sty)Enter file name:! Emergency stop.<read > \usepackage
But the folder arial and the file arial.sty are in the above mentioned folder.
In the MikTeX-Console I already entered the folder to Directories > Settings
I thankful for every help!
Thanks and greetings!
Here is the log-file from TexMaker:
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded format=pdflatex 2019.10.27) 27 OCT 2019 13:34
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**test.tex
(./test.tex
LaTeX2e <2018-12-01>
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/size11.clo
File: size11.clo 2018/09/03 v1.4i Standard LaTeX file (size option)
)
\c#part=\count80
\c#chapter=\count81
\c#section=\count82
\c#subsection=\count83
\c#subsubsection=\count84
\c#paragraph=\count85
\c#subparagraph=\count86
\c#figure=\count87
\c#table=\count88
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
)
! LaTeX Error: File `uarial.sty' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
<read *>
l.5 \usepackage
{csquotes}^^M
*** (cannot \read from terminal in nonstop modes)
Here is how much of TeX's memory you used:
221 strings out of 492616
2365 string characters out of 6129480
60608 words of memory out of 5000000
4231 multiletter control sequences out of 15000+600000
3940 words of font info for 15 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
21i,0n,22p,110b,36s stack positions out of 5000i,500n,10000p,200000b,80000s
! ==> Fatal error occurred, no output PDF file produced!
As you can see from the first line of the log file
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019)
texmaker is not using the miktex distribution for which you installed the uarial package, but a texlive distribution which seems to be also installed on your computer. In the long run it would be best to only have a single tex distribution on your computer to avoid such problems. For mac I would suggest to keep the texlive distribution and get rid of miktex, because texlive is used by most mac users and therefore well tested compared to miktex for mac.
Now you could force texmaker to use your miktex installation by modifying the texmaker preferences, but the easier way to use Arial in your document is to switch from pdflatex to xelatex or lualatex and directly use the arial font installed on your computer
% !TeX TS-program = xelatex
\documentclass[openany,11pt,twoside,a4dutch]{report}
\usepackage{fontspec}
\setmainfont{Arial}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage{csquotes}
\begin{document}
This is a test.
\end{document}
The RFC from May 2015 Y. Nir et al, ChaCha20 and Poly1305 for IETF Protocols
(https://www.rfc-editor.org/rfc/rfc7539) contains a reference to the MIT/Public domain C library https://github.com/floodyberry/poly1305-donna.
I am just porting the C code to Pascal. The 8 bit code works OK (self-test, example, and RFC test vectors).
The port from poly1305-donna-16.h using 16->32 bit multiples and 32 bit additions failed. After some testing I compiled the original source with DJGPP GCC 4.7.3, MS VC 6.0 and BC 3.1 and all three failed too (poly1305 self-test).
Questions: Does this C version (build with -DPOLY1305_16BIT) fail for other compilers too? Is there a known fix available? (The blog of the author Andrew Moon at https://floodyberry.wordpress.com/ is inactive since 6 years)
I can confirm a build failure on a pretty vanilla Fedora 22 system:
% gcc poly1305-donna.c -c -DPOLY1305_16BIT
% gcc example-poly1305.c -o ex poly1305-donna.o -DPOLY1305_16BIT
% ./ex
poly1305 self test: failed
Notice that the test succeeds when I omit -DPOLY1305_16BIT.
Also notice:
% uname -rmp
4.0.8-300.fc22.x86_64 x86_64 x86_64
% gcc --version
gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
I suggest you submit a bug report. Andrew has been responsive in the past.
EDIT:
Compiling with clang version 3.5.0 yields the same results as the above gcc test.
I am looking through the Internet trying to find the source of the PK11_GenerateRandom() function to see why would the function fail. I have a program that perfectly uses this function but when we moved to a new flavor of Linux, it fails after forking (fork())
Since I do not believe there is a problem with NSS, I suspect that we are doing something incorrectly which was disregarded in the older versions of Linux but with the new one there is an issue.
The OpenSSL package is the same on the 'good' and the 'bad' server:
OpenSSL 0.9.8e-fips-rhel5 01 Jul
NSS rpm differs though.
The 'good' has
nss-3.12.2.0-2.el5
and the bas has this version
nss-3.15.3-4.el5_10
The 'good' server uses quite obsolete Linux:
Linux GOOD 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
The 'bad' server is newer:
Linux BAD 2.6.18-371.4.1.el5 #1 SMP Wed Jan 29 11:05:49 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
Oracle Linux Server release 5.10
Red Hat Enterprise Linux Server release 5.10 (Tikanga)
Any clue as to where could I find the source or what could be the reason for failure (like side effect coming from fork()) would be greatly appreciated.
Greg
Edit
Here is the code, which is so simple, that I did not think it is needed.
/* random points to properly allocated memory, let=32 */
SECStatus rv = PK11_GenerateRandom((unsigned char *)random, (int)len);
if ( rv != SECSuccess )
printf( "PK11_GenerateRandom error = %d\n", PR_GetError()) ;
and the output message is, of course:
PK11_GenerateRandom error = -8023
Greg
The source of the PK11_GenerateRandom() function: http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11slot.c#2285
Based on my calculation the -8023 corresponds error SEC_ERROR_PKCS11_DEVICE_ERROR
The reason (thanks to jariq's hints) is described here: https://bugzilla.mozilla.org/show_bug.cgi?id=331096
It is that in the past, it was okay to fork and continue using PKCS11 functions. They decided that it cannot be like that, and now, conclusion is that the parent should not initialize these functions if a child after forking is expected to use them.
PKCS11 internal functions are checking if there was forking (they use various methods dependently on what platform the code is built.) For example, they stored pid of the process in an internal memory, and in some expensive functions or called not so often they compare this preserved pid with current getpid().
The fix for our problem will require redesigning the code.
I have configured a private APT repository (using resources on internet like http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/) and I'm uploading for the first time my package containing the sources of my C++ application.
So reprepro repository is empty.
I use the following command in order to start the build:
sudo reprepro -V -b /srv/reprepro processincoming incoming
Then the build start, a lot of output is genearated and I can see that pbuilder is compiling the project source code and everything is fine. I can even find in the result/ folder debian packages etc...
But the build failed with a POST_BUILD_FAILED because it seems that pbuilder has changed the douane-testing_0.8.1-apt1.debian.tar.gz file and the md5 sum is now different as shown here:
File "pool/main/d/douane-testing/douane-testing_0.8.1-apt1.debian.tar.gz" is already registered with different checksums!
md5 expected: 97257ae2c5790b84ed7bb1b412f1d518, got: df78f88b97cadc10bc0a73bf86442838
sha1 expected: ae93c44593e821696f72bee4d91ce4b6f261e529, got: d6f910ca5707ec92cb71601a4f4c72db0e5f18d9
sha256 expected: c3fac5ed112f89a8ed8d4137b34f173990d8a4b82b6212d1e0ada1cddc869b0e, got: ebdcc9ead44ea0dd99f2dc87decffcc5e3efaee64a8f62f54aec556ac19d579c
size expected: 2334, got: 2344
There have been errors!
I don't understand why it is failing as when I compare the 2 packages (having those md5 sums) the content is strictly the same (I used a diff tool but no differences and no new or removed files).
The only thing I can see is that the archive from pbuild is bigger of 10 Bytes than the orginal one I have uploaded:
On my development machine, the file with the md5 97257ae2c5790b84ed7bb1b412f1d518 :
-rw-r--r-- 1 zedtux zedtux 2334 Feb 3 23:38 douane-testing_0.8.1-apt1.debian.tar.gz
On my server, the file with the md5 df78f88b97cadc10bc0a73bf86442838 :
-rw-r--r-- 1 root root 2344 Feb 5 00:58 douane-testing_0.8.1-apt1.debian.tar.gz
I have pbuild version 0.213 on my server.
What could be the reason of this behavior and how can I fix it ?
Edit
I'm suspecting an issue with the GPG key which looks missing and then files aren't signed so md5sum is different.
During the build process I have the following lines:
I: Extracting source
gpgv: Signature made Wed Feb 5 22:04:37 2014 UTC using RSA key ID 9474CF36
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./douane-testing_0.8.1-apt1.dsc
Edit 2
I have tried to find the command to create manually the .debian.tar.gz file.
The best I've found is the following:
tar cv debian | gzip --no-name --rsyncable -9 > douane-testing_0.8.1-apt1.debian.tar.gz
I don't get the same result than dpkg-source but I tried the same command on my server (I should at least have the same size) but it's not matching...
Could it be that Debian and Ubuntu aren't compressing the same way ?
Finally after some evenings of research I found the solution on launchpad.net !
Found the solution. By default pbuilder calls dpkg-buildpackage like so:
DEBBUILDOPTS="$DEBBUILDOPTS -rfakeroot"
dpkg-buildpackage -us -uc $DEBBUILDOPTS
That causes dpkg-buildpackage to rebuild the diff.gz and .dsc files. Add a -b in there, and it won't. It also means the resulting .changes file will only reference the .deb file. Which is what you want, I think.
The easy solution is to add a line to your .pbuilderrc:
DEBBUILDOPTS="-b"
My previous answer is alright but is not complete.
Then I had the issue that reprepro complains about the source tarball (.orig.tar.xz).
But it was normal as I wasn't doing the packages correctly.
I have written a bash script which I'm executing in VM for each Ubuntu series.
This script was always doing everything from scratch, and was using dh_make --createorig argument and here is the issue.
The correct way is to generate once (for example on Ubuntu precise) and then re-use the .orig.tar.xz file and no more use the --createorig argument of dh_make.
I hope this could help someone :-)