draluy / chocoratage Goto Github PK

The goal is to make the program faster and easier to run for everyone by compiling it under GraalVM.

USe Command + control + q

I'm reading AIX 7.1 supports JDK8, so "Chocoratage" could in theory run on it.
https://wiki.openjdk.java.net/pages/viewpage.action?pageId=25329853

Though pretty much nothing modern runs on AIX, and certainly not workstations.

I'm reading on wikipedia it runs on CDE by default, so I4m suspecting the same locking mechanism as Solaris might do the job.
Testing would require getting our hands on a PowerPC machine, running AIX 7.1/7.2 on it, installing openjdk8 on it. I see some crazy folks have managed to emulate AIX on qemu, why not, but cleearly not a priority.
https://www.youtube.com/watch?v=e9hohbgO0Vs

Since 2dc9ea7 on OSX 10.14 Mojave with JDK 13.0.1+9 2019-10-15

Exception in thread "main" java.nio.file.FileSystemNotFoundException
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:172)
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:158)
at java.base/java.nio.file.Path.of(Path.java:208)
at java.base/java.nio.file.Paths.get(Paths.java:98)
at fr.raluy.chocoratage.Config.readForbiddenPhrases(Config.java:103)
at fr.raluy.chocoratage.Config.parse(Config.java:95)
at fr.raluy.chocoratage.Main.main(Main.java:17)

There's a few similar reports on StackOverflow.

The previous method worked though.

• In English and French
• With command line options
• Mentionning the dreadful page https://www.chocoblast.fr/
• making it clear this app cannot run in docker, cause we cannot correctly tell which OS we are in unless we pass a bunch of env, neither lock the host from the guest.

Someone who knows you are using this app and finally accessing the workstation might be templed to kill the process before typing this message.
Maybe try to conceal it.

A quick Google search popped those:

• https://wrapper.tanukisoftware.com/doc/english/download.jsp
• https://sourceforge.net/projects/wrapper/
• http://yajsw.sourceforge.net/
• https://github.com/tananaev/simple-service-wrapper

When typying é on a french keyboard (2 being on the same key using shift)

• expected: capture "é"
• actual: capturing "2"
  The same will happen with all accents and with other keyboards and accented languages too.

• provide a more user friendly experience
• install the program as a process, with root permissions, so it cannot be killed by a chocoblaster?

Replace OS.ods with a text format if possible (MD?) to allow for git integration

Those https://en.wikipedia.org/wiki/Supplemental_Symbols_and_Pictographs
Range: [U+1F900 - U+1F9FF]
And those in particular: 🥐🍫🍪🍩🥞 (UTF-16: \uD83E\uDD50 \uD83C\uDF6B \uD83C\uDF6A \uD83C\uDF69 \uD83E\uDD5E )
Enchancement request spun from #3

The current coverage (see OS.ods) is pretty wide across distributions and window managers, but most versions are recent. Could be worthwhile testig on:

• Ubuntu 14, 17
• Fedora older version (like from 3-4 years ago)
• Mandriva
• FreeBSD 10 if there is anOpenJDK port for it.
• Solaris 11 (required a Spectre-patched CPU)
• OSX, older, newer
• Windows 7

2 examples:

• someone typing "cho co"
• someone typing "c.h.o.c.o"
  We should be able to detect those without resorting to complicated algorithms.

I propose to rework the KeyBuffer#containsIgnoreCase() and matching predicates:

• work from a stripped down version of what's typed, without spaces or punctuation or accents (might be related to #3 btw)
• not only work on the same amount of input words as those of the ForbiddenPhrases instances, but work on the sufficient amount of words to get a similar size (hence we may have to make a second try with one extra word if the letter count is not exact to this of the ForbiddenPhrase).

Usecase: someone typing "cocho" then cutting "cho" and putting it before "co" to rebuild "choco".
I don't think we can track that because we can't get hold of the actual text input, just what passes through the keyboard.