Node Webkit - Getting Data from a text field and writing to a text file - node-webkit

I'm having problems doing something I thought was straight forward. Read the value of a input field and then write the value to a text file. I got it to work but only partially and inconsistently. What happens is, text a) gets cut off (not all the data entered in the field is written to the file) and b) spaces get added between each character so the line ends up looking like this "T H I S IS W H A T Y O U R T E X T V A L U E"
I'm GUESSING this is an issue with text being 'chunked' but never writing all the chunks to the file and I can't explain the spacing issue, encoding maybe? Anyway heres my code:
//(obviously there is an html field called "a1Agent" and an object called PI)
PI.Name = document.getElementById("a1Agent").value;
fs.writeFile("c:\\Users\\Me\\Desktop\\values.txt", PI.Name);

The encoding of string you get from a input widget (after you edit it) is actually utf16le, see more here:
https://github.com/rogerwang/node-webkit/issues/1669#issuecomment-42515857

Related

Kotlin: Printing string with array elements that cuts off left side of answers

I am writing a small text based game to familiarize myself with Kotlin. I am creating two strings that print out the multiple choice options. I have confirmed that all four array elements are captured appropriately, but when the string prints it cuts off the a) and c) options. I have used \t, spaces, etc. and it does the same thing. I have also tried to just use print() and then use a \n at the end
println(menuList[0])
println(menuList[1])
println(menuList[2])
println(menuList[3])
println("a) ${menuList[0]} b) ${menuList[1]}")
println("c) ${menuList[2]} d) ${menuList[3]}")
Output:
erroneous output of multiple choice text
The source text came from a file which was separating each line with \r\n, but the code reading it was splitting it with \n. The result was that each entry ended with \r. When printed out, this caused the first value to be overwritten.
The solution is, when reading the file, to split by \r\n rather than \n.

LESS: Unrecognised input w/ strange characters

Something is corrupting my .LESS files. They look fine in a text editor (VS2013 or Sublime) but when I try and compile them they have extra strange characters in them.
I get the same error if I try to compile using grunt or web essentials.
Why is this what the LESS compiler is reading?
��/ / C o r e v a r i a b l e s a n d m i x i n s
What is happening here? I'm guessing it has something to do with file encoding??? See screen shot above.
Toggle show whitespace characters (Edit / Advanced / View White Space);
Remove first two chars;
Save file;

change display format for all string variables to as short as possible

After compressing my data, I have several string variables with storage type str4 or str1 and format %9s. I would like to revert them all to the default display format, which help dformat reports should be %#s for str#. Is there a quick way to do this?
This is the structure of my best guess:
ds, has(type string)
foreach v of varlist `r(varlist)' {
format `v'
}
This does not work because, instead of reformatting to the default value with this command, the format function just displays the format.
A reproducible example:
clear
input str50 mystr
"b"
"a"
end
compress
format myst
This is the situation I was confronted with. I am not sure if it applies beyond strL formatted variables. (Roberto suspects that it does not; see comments.)
Addendum. My goal here was to make browse-ing my data easier. It seems that format is respected in the browser (truncating to length of one for %1s, say), while it is overridden by the actual length of the string when printing to the console.
I am surprised that you seem surprised, as with your syntax the format command (not function) does indeed just display the format, as is documented. Incidentally, you don't need a loop to do that as format will take a varlist as argument:
. clear
. set obs 1
obs was 0, now 1
. foreach t in a b c {
2. gen `t' = "`t'"
3. }
. format a b c
variable name display format
-----------------------------
a %9s
b %9s
c %9s
-----------------------------
Joshing apart, I think you need just one line here, which is something like
. format a b c %1s
or
. format a b c %-1s
to signal which justification. Stata doesn't truncate displayed strings just because they don't match the string display format; it might well truncate strings because there isn't space to show them, but (I'm naturally open to counter-examples) the above display formats for variables will do well for most purposes.
EDIT: The following device may help.
gen length = 0
ds, has(type string)
quietly foreach v in `r(varlist)' {
replace length = length(`v')
su length, meanonly
format `v' %`r(max)'s
}
drop length

Fortran runtime error: Bad integer for item 0 in list input?

How do I fix the Fortran runtime error: Bad integer for item 0 in list input?
Below is the Fortran program which generates a runtime error.
CHARACTER CNFILE*(*)
REAL BOX
INTEGER CNUNIT
PARAMETER ( CNUNIT = 10 )
INTEGER NN
OPEN ( UNIT = CNUNIT, FILE = CNFILE, STATUS = 'OLD' )
READ ( CNUNIT,* ) NN, BOX
The error message received from gdb is :
At line 688 of file MCNPT.f (unit = 10, file = 'LATTICE-256.txt')
Fortran runtime error: Bad integer for item 0 in list input
[Inferior 1 (process 3052) exited with code 02]
(gdb)
I am not sure what options must be specified for READ() to read to numbers from the text file. Does it matter if the two numbers on the same line are specified as either an integer or a real in the text file?
Below is the gdb execution of the program using a break point at the open call
Breakpoint 1, readcn (
cnfile=<error reading variable: Cannot access memory at address 0x7fffffffdff0>,
box=-3.37898272e+33, _cnfile=30) at MCNPT.f:686
Since you did not specify form="unformatted" on the open statement, the unit / file is opened for formatted IO. This is appropriate for a human-readable text file. ("unformatted" would be used for a non-human readable file in computer-native format, sometimes called "binary".) Therefore you should provide a format on the read, or use list-directed read, i.e., read(unit, *). To advise on a particular format we would have to know the layout of the numbers in the file. A possible read with format is: read (CNUINT, '(I4, 2X, F6.2)' ) NN, BOX
P.S. I'm answering the question in your question and not the title, which seems unrelated.
EDIT: now that you are show the text data file, a list-directed read looks easier. That is because the data doesn't line up in columns. It seems that the file has two integers on the first line, then three real numbers on each of the following lines. Most likely you need a different read for the first line. Is the code sample that you are showing us trying to read the first line, or one of the later lines? If the first line, it would seem plausible to read into two integer variables. If a later line, into two or three real variables. Two if you wish to skip the third data item on the line.
EDIT 2: the question has been substantially altered several times, which is very confusing. The first line of the text file that was shown in one version of the question contained integers, with later lines having reals. Since the listed-directed read is reading into an integer and a floating variable, it will have problems if you attempt to use it on the later lines that have two real values.

Read input from line in J

I am very new to J (learning it for fun) and I am trying to read data from keyboard. I have tried to make a tiny script which reads in a string and reverses it:
|.(1!:1 3)
When I run it, I get a rank error. (I'm using 1!:1 3 instead of defining a verb because codegolf...)
Is there a command that can check the rank of 1!:1 3?
That's a common mistake with foreigns.
The definition for foreign 1!:1 doesn't help, because it really reads:
1!:1 y Read. y is a file name or a file number (produced by 1!:21); the
result is a string of the file contents., e.g. 1!:1 <'abc.q'. The following
values for y are also permitted:
1 read from the keyboard (does not work within a script)
3 read from standard input (stdin)
And so replacing y with 3 should work, right? Well, not quite, because what you're really giving as an argument in writing:
1!:1 3
is an array made of 1 3. Sort of like giving it:
1!:(1 3)
when you want:
1!:1 (3)
For code golf purposes, use a right bracket:
1!:1]3