For years since I started using PhpStorm I had a very subtle, vertical line in the middle of the editor that was indicating the line length limit of 120 characters.
That was great and all the jazz, until recently I started having a secondary line, that's indicating the 80 chars limit.
My issue is: where does this line come from and how do I disable it? My linting rules are (and have been) always the same and those are limited at 120 chars. But the new line, the one for 80 characters... well, I don't know where it's coming from or how I disable it
Open up Settings, then type Visual Guides into the search box.
I bet you see 80, 120 or something like that.
And, I'm shocked, shocked, that you don't want to be able to store your program on 80-column Hollerith punch cards.
Related
I'm trying to create a calculator(real calculator), from scratch, with only simple parts (relay, diode, etc.). But I got to a chronic problem, how the hell do I convert binary numbers, ex:00101110 to decimal? so that I can make my display show 46 for example. Making the display translate a 0000...1001 (0...9) is easy, but what about after that? when a number comes with two or more decimal places (ex:10000000 =128). I know it can be tricky to explain, so is there somewhere I can find the answer, maybe a schematic?
This isn't a programming language, it's literally a relay computer (remember the old IBM, Harvard Mark I?). I just want to make a relay calculator that does binary calculations (the calculation part is theoretically finished. For now only sum.)
What I can't do is make the result in binary become something that can be shown on a 7segment display.
An easy example is: "0000 0111" this I can make the display show the number 7, because it has only one decimal place. Now with "0011 0100" the situation changes, the number would be 52, simply making the "52" appear on a display is not a challenge, the problem here is: how does a processor translate binary numbers from 0000 to infinity, in a way that can you put it on a display?
I don't necessarily need a definitive answer, whatever, even if a website, a book, a light at the end of the tunnel.
I've been working on an RFID project to produce our own RFID cards to work on our existing timeclocks and readers.
I've got most of the work done, and have been able to successfully write a Hitag2 card using the value of page 4 & 5 from another card (so basically copying the card) then changing the config bit which makes it act like an EM4x02 which allows our readers to read it.
What I'm struggling with is trying to relate the hex code on page4/5 to the output you get when scanning as an EM4x..
The values of the hitag page 4/5 are FF800000/003EDF10. This translates to 0000001EBC when read as an EM4x.
Does anybody have an idea on how this translation is done? I've tried using the methods in RFIDIOT but that doesn't seem to work for this.
I've managed to find how this is done after finding a hitag2 datasheet from 1999 (the only one I could find that explains the bits when hitag is in public mode A)
Firstly, convert the number you want on the EM4 card to hex.
Convert that hex into binary.
Split the binary into 4 bit chunks, then work out the even parity for each section and add it to the end of each chunk. (So you'll end up with 5 bits per chunk)
Then, work out the even parity of each column in the data (i.e first character of all chunks, then second etc. But ignoring the parity bit you added) and add these 4 bytes to the binary string.
Then add the correct amount of zeros at the start to ensure the data section has 50 bits.
Once you have the data section sorted, add 9 bits of 1 to the beginning (header) and a final 0 to the very end of the binary.
Your whole binary string should be 64 bits long.
Convert this to hex and split it in half. You can then write these onto pages 4/5 of a Hitag2 card.
You then need to change the configuration bit to 0x02 for the tag to work in public mode a.
Just thought I would send you the diagram of how this works.Em4X tag data
I'm writing an application to scan numbers from an image.
The numbers are using the OCR-B font and may also contain + and > characters.
This is my source image:
The scans using Tesseract weren't very good, even when limiting the character set to the mentioned characters. As I didn't find any OCRB training files for Tesseract, I decided to train it myself.
I created this training image and made a box file from it. The box file is correct, all letters are matched correctly.
Then I did all steps described here to create the other necessary files.
Using this newly trained OCR-B tessdata-set, I get pretty good results on the source image, with one little bug: All 1s are mistaken for 8s and vice-versa. The command used to process the image was
$ tesseract esr2c.tif ocrb-esr2c -l ocrb
and the output for the source image was
0800000001456>8 00000195731208 8 01050008 023+ 08 0301226>20
If you swap all 1s and 8s and compare it to the source image, the output would be correct (except for the last two letters which I can ignore).
How could this happen? Did I do some mistake in the training process? How can I fix it?
It's likely that somewhere in your box file has incorrect values (characters) for 1 and 8. You can verify using jTessBoxEditor program. If so, correct, regenerate the language data file, and try again.
I have trained tesseract 2.04 after 1 month efforts for OCR A extended font. Its working very well and showing above 90 Accuracy with font size 14.
Training image should be high Contrast image.
Use "GIMP" image editor and do following
Menu Colors->Info->Histgram- Read Std Deviation value
colors-> Threshould -> Write "Std Deviation value" as Threshould value
Save image
Use it for training.
Check and edit your box file using "qt-box-editor-1.06.exe".It is very easy to use.
Check All boxes and characters in it.
It is very important. Somewhere in your box file has incorrect characters for 1 and 8.
Run other cmds.
Was wondering if we could print from right to left, bottom to top... I got this thought when trying to write a program to print the following square (for an input 'n', here n=4 )
1 2 3 4
12 13 14 5
11 16 15 6
10 9 8 7
This could be solved many ways, by storing into a 2D array and printing the array... (Any language: Perl, C, C++, Java).
The long answer is that you can do whatever the terminal supports. There are many kinds of terminals (or “character output devices”), many of them support cursor motions. (You can see the Termcap Library project to create a picture what different terminal types do.) There is a terminal command for moving up a line, so esentially yes, you should be able to do that. After poking in the termcap database, I came up with the following:
$ printf "\n"; printf '\e[A'; echo Foo
Foo
In other words, the \e[A string has a non-zero chance to get you one line up. On some terminals :)
Baiscly this is possible. But not on an traditional line-based terminal. When accessing the screen pixel based, it's quite easy to solve this problem. At least there is no real counterpart to \n defined in ASCII.
Or maybe this could be archived by changing the input method of the terminal to some culture which reads left to right and bottom to up.
I understand the reasons for and against ROT13, but I'm wondering why specifically people have chosen 13 places to shift the alphabet? I understand it's halfway around, but is there an elegant reason to go -that- far, but not 12 or 14 spots?
It seems to me like making each letter "as far away" as possible from its starting position only is meaningful to a human who might recognize "close" characters (although I doubt this is possible/probable).
Anyone know the answer to this?
Because it has the nice property of being involutive, that is to say, ROT13(ROT13(alphaOnlyString)) = alphaOnlyString.
According to Wikipedia:
A shift of thirteen was chosen over other values, such as three as in the original Caesar cipher, because thirteen is the value for which encoding and decoding are equivalent, thereby allowing the convenience of a single command for both.
Probably cause it is its own inverse. The same algorithm can be used for "encryption" as well as "decryption".
Because shifting by 13 moves the characters half way around the alphabet (which has 26 places). So, to get back to plaintext you only need to shift it 13 moves again. This way, you don't have to have separate functions for encoding or decoding because the same operation will be encode or decode.