I'm getting some surprising errors when I try to input a string using (read). Context: I'm building a mini language, with inputs deliminated using characters like {, }, :, etc.
Here's what happens, I run (read) and enter {9.I:{8.II:hello}{8.III:hi}} (an example input string from my mini language).
I then get 2 errors:
1:
too many colons in "{8.II"
2:
Package HELLO}{8.III does not exist.
It seems as though there's something extra going on in the (read) function that's tripping me up. Can someone point me in the right direction?
read is designed to read a valid Lisp S-expression. It's going to use Common Lisp's parser. If your language is sufficiently Lisp-like, you may be able to make it work for you, but given the example input you've shown, I doubt it's what you want.
You're probably looking for read-line, which reads a single line of text as a string and does not perform any additional parsing on it.
fname = dir('*sir');
dayH = zeros(length(fname),1360,3600);
for i=1:length(fname)
dayH(i,:,:) = loadsir(fname(i).name);
end
fname = dir('*sir');
dayH = cell(1,length(fname));
for i=1:2
dayH{i} = loadsir(fname(i).name);
end
Basically it loads all my files. I have a separate .m file called loadsir that loads those specialized files. The output of the .sir files will be an array 1360x3600.
Right now that code is crashing saying, "Cannot display summaries of variables with more than 524288 elements." I guess it's because 1360X3600 = 5,000,000 about?
Putting Serg's comment as an answer:
Most likely you missed a semicolon (;) somewhere in loadsir. Matlab then thinks you want to print the output, which it won't do due to the large number of elements.
Additionally, to prevent such things from happening in the future:
Matlab is an interpreted language, meaning, no compilation is necessary. Any and all code can be parsed while you type it, which allows for things like auto-correct. Of course, this sort of thing is included already in standard Matlab. If you don't already, code in Matlab's own editor every now and then. It warns you of such silly mistakes/errors (and a lot more), including but not limited to, via the right vertical bar in the editor. The little square at the top right of the window should always be green. If it's orange or red, there's things to be improved or corrected, respectively.
The right vertical bar is an overview of all the lines in your file that leave room for improvement. If a small orange/red bar appears somewhere, a mouseover will tell you what's wrong with what line. Clicking it will navigate the editor to the line, which will likely be wavy-underlined in either orange or red. Mouse-over the line often gives useful suggestions, and <alt>+<enter> is often enough to fix the simple mistakes. I find it an indispensable tool when developing larger applications in Matlab.
You can of course configure which errors/warnings this tool ("code analyzer", formerly "mlint") displays. Sometimes, there will be a warning about an inefficiency that you simply cannot work around. Add an OK-directive behind the line to suppress it (%#ok), but don't make a habit of suppressing anything and everything "annoying" because that will of course completely beat the purpose of the code analyzer :)
When I use == to compare the strings it works on all but some strings that have a space added... (added with [NSString stringWithFormat:#"%# %#",self.title,collectionName])
But when I compare with isEqualToString, it returns True/YES every time. The comparison in the image goes into the condition and hits the return... Should be impossible for this to hit line 640, but it does.
Can anyone explain this?
There is a ";" after the ")" on line 637 that why it always went into the condition... damn I suck... seems like that would throw an error somehow
If you use the LLVM compiler in Debug project setting, (not quite stable enough for release yet I think), you'll get warnings about issues like the one you had.
In your case it would issue a warning than an "if" statement had an empty body.
Used in conjunction with turning on the static analyzer for every build, you can catch a ton of problems early, especially the stupid ones that are hard to debug because they are so stupid they are easy to overlook (and here I am not criticizing you, as I have made the same mistake countless times!)
Longtime Eclipse user here; I recently discovered the "Block Selection Mode" (Alt-Shift-A) that was added into Eclipse 3.5. I tried it out, it's pretty neat--I can select a rectangle of text in my source code instead of selecting things a line at a time like I usually do.
Apparently this feature is common in other editors too, under other names like "column edit mode", etc. A lot of people seem to really love it, but I've got by without for a long time.
So my question is: What kinds of things is this feature useful for?
The only one I can think of is inserting a comment characters (like // or #) in front of a chunk of text. Also, I supposed if I had a bunch of variables names that were all lined up and I wanted to change the first characters for all of them at once. But surely there's more to it than that? I mean, when it comes to choosing an editor, this feature is apparently a deal-breaker for some people!
I find it is very useful when working with fixed-position field data files, and you only want to select a few fields for search-replace or copy-paste. It is also good for things like this:
call_foo('A',123);
call_foo('B',143);
call_foo('C',331);
call_foo('A',113);
call_foo('R',789);
The code is all the same except for some characters in some columns. You could select a block around the second parameter and search for the line containing 113. Useful when you have more than just a few lines all together in this format.
A colleague of mine told me of a project where they wrote JDBC code like this:
String query =
"select question, answer, accepted " +
"from so_answers " +
"where poster = 'Jon Skeet' " +
"order by upvotes ";
So that they could block-select the SQL in order to paste it into a database tool and run it by hand. Seems a bit barmy to me, but it evidently worked for them.
If you arn't using a block cut/copy/paste operation at least four or five times a day then I would suggest you're just doing a lot of extra typing.
If you are looking at a file with fixed width fields, sometimes you only want to select one column.
The perlstyle pod states
No space before the semicolon
and I can see no reason for that. I know that in English there should not be any space before characters made of 2 parts ( like '?',';','!' ), but I don't see why this should be a rule when writing Perl code.
I confess I personally use spaces before semicolons. My reason is that it makes the statement stands up a bit more clearer. I know it's not a very strong reason, but at least it's a reason.
print "Something\n with : some ; chars"; # good
print "Something\n with : some ; chars" ; # bad??
What's the reason for the second being bad?
From the first paragraph of the Description section:
Each programmer will, of course, have his or her own preferences in regards to formatting, but there are some general guidelines that will make your programs easier to read, understand, and maintain.
And from the third paragraph of the Description section:
Regarding aesthetics of code lay out, about the only thing Larry cares strongly about is that the closing curly bracket of a multi-line BLOCK should line up with the keyword that started the construct. Beyond that, he has other preferences that aren't so strong:
It's just a convention among Perl programmers for style. If you don't like it, you can choose to ignore it. I would compare it to Sun's Java Style guidelines or the suggestions for indenting in the K&R C book. Some environments have their own guidelines. These just happen to be the suggestions for Perl.
As Jon Skeet said in a deleted answer to this question:
If you're happy to be inconsistent with what some other people like, then just write in the most readable form for you. If you're likely to be sharing your code with others - and particularly if they'll be contributing code too - then it's worth trying to agree some consistent style.
This is only my opinion, but I also realize that people read code in different ways so "bad' is relative. If you are the only person who ever looks at your code, you can do whatever you like. However, having looked at a lot of Perl code, I've only seen a couple of people put spaces before statement separators.
When you are doing something that is very different from what the rest of the world is doing, the difference stands out to other people because their brain don't see it in the same way it. Conversely, doing things differently makes it harder for you to read other people's code for the same reason: you don't see the visual patterns you expect.
My standard is to avoid visual clutter, and that I should see islands of context. Anything that stands out draws attention, (as you say you want), but I don't need to draw attention to my statement separators because I usually only have one statement per line. Anything that I don't really need to see should fade into the visual background. I don't like semi-colons to stand out. To me, a semicolon is a minor issue, and I want to reduce the number of things my eyes see as distinct groups.
There are times where the punctuation is important, and I want those to stand out, and in that case the semicolon needs to get out of the way. I often do this with the conditional operator, for instance:
my $foo = $boolean ?
$some_long_value
:
$some_other_value
;
If you are a new coder, typing that damned statement separator might be a big pain in your life, but your pains will change over time. Later on, the style fad you choose to mitigate one pain becomes the pain. You'll get used to the syntax eventually. The better question might be, why don't they already stand out? If you're using a good programmer font that has heavier and bigger punctuation faces, you might have an easier time seeing them.
Even if you decide to do that in your code, I find it odd that people do it in their writing. I never really noticed it before Stackoverflow, but a lot of programmers here put spaces before most punctuation.
It's not a rule, it's one of Larry Wall's style preferences. Style preferences are about what help you and the others who will maintain your code visually absorb information quickly and accurately.
I agree with Larry in this case, and find the space before the semicolon ugly and disruptive to my reading process, but others such as yourself may find the exact opposite. I would, of course, prefer that you use the sort of style I like, but there aren't any laws on the books about it.
Yet.
Like others have said, this is a matter of style, not a hard and fast rule. For instance, I don't like four spaces for indentation. I am a real tab for block level indentation/spaces for lining things up sort of programmer, so I ignore that section of perlstyle.
I also require a reason for style. If you cannot clearly state why you prefer a given style then the rule is pointless. In this case the reason is fairly easy to see. Whitespace that is not required is used to call attention to something or make something easier to read. So, does a semicolon deserve extra attention? Every expression (barring control structures) will end with a semicolon, and most expressions fit on one line. So calling attention to the expected case seems to be a waste of a programmers time and attention. This is why most programmers indent a line that is a continuation of an expression to call attention to the fact that it didn't end on one line:
open my $fh, "<", $file
or die "could not open '$file': $!";
Now, the second reason we use whitespace is make something easier to read. Is
foo("bar") ;
easier to read than
foo("bar");
I would make the claim that is harder to read because it is calling my attention to the semicolon, and I, for the most part, don't care about semicolons if the file is formatted correctly. Sure Perl cares, and if I am missing one it will tell me about it.
Feel free to put a space. The important thing is that you be consistent; consistency allows you to more readily spot errors.
There's one interesting coding style that places , and ; at the beginning of the following line (after indentation). While that's not to my taste, it works so long as it is consistent.
Update: an example of that coding style (which I do not advocate):
; sub capture (&;*)
{ my $code = shift
; my $fh = shift || select
; local $output
; no strict 'refs'
; if ( my $to = tied *$fh )
{ my $tc = ref $to
; bless $to, __PACKAGE__
; &{$code}()
; bless $to, $tc
}
else
{ tie *$fh , __PACKAGE__
; &{$code}()
; untie *$fh
}
; \$output
}
A defense can be found here: http://perl.4pro.net/pcs.html.
(2011 Update: that page seems to have gone AWOL; a rescued copy can be seen here: http://ysth.info/pcs.html)
Well, it's style, not a rule. Style rules are by definition fairly arbitrary. As for why you shouldn't put spaces before semicolons, it's simply because that's The Way It's Done. Not just with Perl, but with C and all the other curlies-and-semicolons languages going back to C and newer C-influenced ones like C++, C#, Objective C, Javascript, Java, PHP, etc.
Because people don't expect it . It looks strange when you do it .
The reason I would cite is to be consistent within a project. I have been in a project where the majority of programmers would not insert the space but one programmer does. If he works on a defect he may routinely add the space in the lines of code he is examining as that is what he likes and there is nothing in the style guide to say otherwise.
The visual diff tools in use can't determine this so show a mass of line changes when only one may have changed and becomes difficult to review. (OK this could be an argument for a better diff tools but embedded work tends to restrict tool choice more).
Maybe a suitable guide for this would be to choose whichever format you want for you semicolon but don't change others unless you modify the statement itself.
I really don't like it. But it's 100% a personal decision and group convention you must make.
Code style is just a set of rules to make reading and maintaining code easier.
There is no real bad style, but some are more accepted than others. And they are of course the source for some "religious battles" (to call curly braces style ;-) ).
To make a real life comparison, we have trafic lights with red, yellow/orange and green. Despite the psychological effects of the colors, it is not wrong to use Purple, Brown and Pink, but just because we are all used to the colors there are less trafic accidents.