I haven't experienced the downtime. However, I would like to use it on my Android, but the Enter key does not seem to end the input line. Any ideas on how to handle that?
Hi Steve, have you had a chance to try this on your Android since yesterday? I think the update I made to fix copy-paste may have also fixed this.
The reason I say this is that I just tried it on my Android - a Samsung/Google Nexus S - and it worked (the Enter key did successfully end the input line). But it may also be due to us having different phones, so when you get a chance to try it out again, please let me know.
Also, thanks for your patience and for reminding me about this issue. I remember you first raising it a long time ago.
It's interesting to compare this to the solution in my workday language. One of the reasons that M is shorter is because its functions are more tolerant. For arc, I had to make sure that the index to the string was not too large. In M, it simply returns an empty string if you attempt to access a string position beyond the length. And I used iteration with M. Perhaps the arc solution would have been shorter had I done the same there.
Are you concatenating strings? Is that where returning "" is useful? In wart concatenating strings is tolerant of non-strings, so I think returning nil should be ok.
If the string X = the string Y, print 0 (to indicate there are no differences / MUMPS uses 1-based indexing of strings)
Otherwise, go through each character of the strings and at the point where they differ, print that index and quit looping.
MUMPS does not error out on attempting to extract a character beyond the string's length. So in that event, 1 string's extract will return the empty string, which will differ from the other string's extract and will cause you to print the index and quit. Not generating such an error, of course, cuts down on the code needed.
So if we enter the for loop, we know there is a difference between the two sequences.
So we just need to find an index position i where (isnt seq1.i seq2.i) is true. If indexing off the end of a string causes an error, we need to put in code to prevent that. If indexing off the end of a string returns anything that can't be an element of the string, we can compare each index i until we find a difference, knowing that we'll eventually find one.
I'm wondering about something which might have high document storage requirements. I guess it would have to be web-based (don't know how exactly one would integrate arc with another GUI environment).
I know I've seen comments here about integrating it with a db. Anyone remember the article # or URL?
Option 4. Get the FFI working to access MySql and other more traditional database systems.
Some people had been working on the FFI interface, but so far I've yet to see anything that works. You can read my noob entry about this here: http://arclanguage.com/item?id=10839 and there were recent attempts by others as well.
That worked for me with Try Arc. It's really not a large program, the portion that I wrote. On the backend, all the heavy lifting is done by Racket's sandbox library and srv.arc. On the front-end, it's Chris Done's jQuery console (and to some extent now, WordPress).
So, I was thinking of using arc for an easy task. I have a file with a line of text, a blank line, a line of text, etc. I wanted to rewrite it without the blank lines.
Looking into the link below I found code for reading a file:
arc> dev
"c:\\Users\\Steve\\Desktop\\mbrm.txt"
arc> (w/instring ins dev
(whiler l (readline ins) nil
(prn "{" l "}")))
{c:\Users\Steve\Desktop\mbrm.txt}
nil
arc>
WDER Wangiella dermatitidis Wangiella dermatitidis W. dermatitidis
WESP Weeksella species Weeksella species Weeksella sp.
WEVI Weeksella virosa Weeksella virosa W. virosa
WEZO Weeksella zoohelcum Weeksella zoohelcum W. zoohelcum
WHITE White White
WNF Normal flora also recovered Normal flora also recovered
WOO The specimen was collected The specimen was collected with a wooden shafted swab. Wood components may inhibit virus isolation. Interpret
these negative results with caution.
The "read" procedure will read only a single Arc expression at a time. If you want to read a line, there is a "readline" procedure.
Also, it is correct that you make code look like code by putting two spaces before each line of code.
After "code." in the above paragraph, there is a newline, then
another newline, then two spaces, then "After [...] newline, then",
then another newline, then two spaces, then "another", and so on.
They had an interesting reason to use/discard Lisp:
"The real reason we stuck with the LISP-ish syntax is that we didn't want to be fiddling with the parser while designing the language, and (to a lesser degree) because we didn't want to encourage programmers until we thought the language was ready. We are now preparing a more sensible surface syntax, whereupon we will receive rotten egg and tomato complaints from the LISP community. You can't please everyone. Using the LISP syntax for so long let us focus on what was really important."
