So, I am reading the book The elements of computing systems (and doing the course). I am trying to write a hack assembly program to blacken the screen. Here is what I've got.
#16384
D=A
#current
M=D
#24576
D=A
#end
M=D
#current
D=M
(BEGIN)
#end
D=M-D
#END
D;JEQ
#current
D=M
A=M
M=1
A=A+1
D=A
#current
M=D
#BEGIN
0;JMP
(END)
#END
0;JMP
Some pixels are appearing, but a) extremely slowly and b) it doesn't appear like the whole screen is being filled. Is there a way to improve the code?
It's not really appropriate to just give you the answer, but here are a few tips that might help you on your way.
Although HACK symbols are case-sensitive, using #end and #END for two
different things is bad style because it risks confusion.
there is a predefined symbol SCREEN that may prove useful.
You have to set all the bits in each 16-bit word in the screen memory area. M=1 sets only one bit.
You may find it more convenient to keep a counter of how many loops you have remaining as opposed to an ending pointer value.
Remember that you can store the result of an operation in multiple destinations, as in MD=M-1. This is handy.
Review the lecture 4 notes for an example of a loop. http://www.nand2tetris.org/lectures/PDF/lecture%2004%20machine%20language.pdf
Good luck!
Related
I had a random question about fixed effects and I wanted to clarify this with you. Suppose a study is at the individual by state by year level where each individual is followed over time (Panel) and I am adding state fixed effects, year fixed effects as well as state by year fixed effects. Does that mean I might run into multi-collinearity problems? Also will something like this soak up all of the variability and we would not be able to get the correct coefficient estimates?
In Stata I am doing something like reg y x i.year##i.statefip [aw=population], vce(robust)
Or should I rather do something like reg y x i.year i.statefip c.year#i.statefip [aw=population], vce(robust) as in add state specific time trends.
If you have a panel dataset, it would be much better for you to xtset it first, rather than trying to use the regular reg command. If you're using FE with xtreg, then first, the state-level fixed effects are automatically generated (and you wouldn't have to mess with the syntax in the OLS -- not sure why you would be using the regular OLS in the first place if you have panel data). Then you can include your time fixed effects with i.year. At the end, just have i.statefip and i.year, because they are both categorical and not continuous. Let me know if you have any more questions.
For a recent project I've been working on a simple word processor, and because I need fine-grained control have had to implement a lot of the text shaping myself. Most of this is fairly straight-forward and described in detail places like here and here.
It's less obvious how to handle pressing down or up on the keyboard when dealing with non-monospaced text split across many lines. In monospaced text the algorithm is simple: move the text caret down one line and the same number of characters to the right that it was. But what about variable-width fonts? I've tried an algorithm like this (in pseudocode):
; Return text offset into next line after navigating down
function moveCaretDown():
Move text caret to start of next line
targetPixelOffset := previous pixel offset of caret in line above
textOffsetIntoLine := 0
pixelOffsetIntoLine := 0
prevDelta := Infinity
for each char in text of new line:
delta = abs(pixelOffsetIntoLine - targetPixelOffset)
; We are now further from the desired cursor offset than before, this must
; be closest slot to the caret's previous horizontal offset in this line.
if (delta > prevDelta):
return textOffsetIntoLine - 1
prevDelta = delta
pixelOffsetIntoLine += measureWidth(char)
currentOffset++
; Else return the offset of the last character in the line
return length of newline - 1
But I've found its behavior differs from text inputs in major web browsers and/or text editors (I can come up with some specific examples if needed). Is there some standard algorithm for this used by GUI toolkits or text shaping libraries? I was surprised I couldn't find a W3C standard on it, for example, considering this is behavior needed in every web browser.
* Inserting line breaks into a string at the correct places, handling ragged or fully-justified text, etc.
I don't think there's a standard other than to follow the Principle of Least Astonishment. Nowadays, that typically means seeing what the major applications do, since that will likely be familiar behavior to the user.
On the current line, you know the current horizontal offset. Let's call it x. I'm talking about the pixel position, not the number of characters or glyphs since the beginning of that line.
On the destination line, there is a set of horizontal offsets the caret can be placed (e.g., between glyphs). So you want to pick the one of those that's as similar to your current x as possible.
Furthermore, if the user moves the caret vertically several times in a row, you probably want to find the nearest to the original x. The caret may wiggle horizontally a bit as the user moves up and down, but you don't want it to drift. Once the user does something that intentionally changes the horizontal offset (e.g., inserts a character, uses a horizontal arrow, clicks the mouse, etc.) that's the best time to update x.
If you already have code to find the closest caret position to a mouse click, you might be able to re-use it as though the user had clicked the point exactly one line above or below the current x.
I've also seen some editors (including monospace text editors) that treat the end of the line as a special case. So if you move up or down when you're at the end of a line, you move to the end of the preceding or succeeding line. That seems a nice way to handle ragged right text and short lines at the end of a paragraph.
I'm building an HTML webpage that contains the following content:
In order to proceed, please enter this code: GJBQTCXU
"GJBQTCXU" is a code comprised of a string of letters; however, screen readers attempt to pronounce this as a single word. How can I stop them from attempting to pronounce this nonsensical word and instead get it to read one letter at a time: "G J B Q T C X U".
As clarification, I'm building this page so that screen readers automatically do the right thing. I know that users can choose to have their reader pronounce each letter at a time, but I don't want my users to have to take any additional steps.
try using CSS letter-spacing property -
<div>G J B Q T C X U</div>
div {
letter-spacing:-1.9px;
}
example:
http://codepen.io/stevef/pen/grZGBP
There are many screen readers and those readers can also be inconsistent between browsers due to accessibility APIs differences.
With that said here is a good generalization of functionality from WebAIM http://webaim.org/techniques/screenreader/
They note that some screen readers by default won't read punctuation like periods, semi-colons, etc. but rather pause between them. You could try visually hidden versions of these. Now if they have more verbose settings turned on it might read those.
Another reading aspect mentioned is that some screen readers pause at the end of a paragraph. So if you wrapped each letter in a p tag and then made them display inline, there could be pauses.
Since nuances aren't as well documented between the screen readers between browsers it's hard to say either will work in your instance.
Since users can just use left/right arrow keys to read individual letters it wouldn't take much for regular screen reader users to read the word slowly.
I would say the punctuation is more dangerous if their verbosity settings are set high. So try the paragraph tag approach first. Since users can also jump between paragraph tags with screen readers there might be some confusion but it seems like the lesser of the two.
I feel like the real answer to this is:
<div aria-label="G J B Q T C X U">GJBQTCXU</div>
Is there a shortcut for three code hexcodes, example, black can be wrote two ways
.black{color:#000}
.black{color:#000000}
Can #DBDBDB this be wrote shorter? As #DBD does not work.
Also what is faster, does it matter, I notice Firebug spits colors and some other vars in case sensitive format. Does it matter? Is it faster to have everything lowercase so the browser and user can load and render faster?
.webform{color:#dbdbdb}
.WebForm{color:#DBDBDB}
Can #DBDBDB this be wrote shorter? As #DBD does not work.
No. The only things shorter than a 6-hex colour codes are 3-hex codes (which only work for XXYYZZ colours) and (some) named colours (and there isn't one that matches #DBDBDB).
Also what is faster
Stop micro-optimising. If there is a difference it won't be a significant one and will probably vary from browser to browser.
The simple answer is it makes no perceivable difference. This is a classic case of over-thinking optimisation.
There are actually lots of ways of specifying black:
.black{color:#000}
.black{color:#000000}
.black{color:black;}
.black{color:rgb(255,0,0);}
http://www.w3.org/TR/CSS21/syndata.html#color-units
I would be very surprised if there were any measurable speed difference between the accuracies in any browser.
#DBDBDB cannot be written more compactly, it's equivalent to: rgb(219,219,219). In the shorter notation the closest you could come would be #DDD which is equivalent to rgb(221,221,221).
In the three letter abbreviations each letter is duplicated, so #DBD becomes #DDBBDD. You can't shorten codes like #DBDBDB.
There is no performance difference between uppercase and lowercase letters.
#DBDBDB can not be written shorter.
There is no difference in speed.
Lowercase and uppercase have no difference in performance, but it's worth mentioning that shorthand hexadecimal colors could reduce css file size to some tiny extent, which helps save bandwidth more or less.
I just started to use nxhtml, and I opened PHP file, it looks just really awful. I usually set black background-color, but PHP/nxhtml mode, background-color is set to light blue, and I don't know how to change it. How can I change it? Is there any good site to learn nxhtml mode?
Adding this line:
(setq mumamo-background-colors nil)
to your .emacs(or equivalent) will disable all background colors coming from mumamo. I personally use zen-color-theme and the combination with mumamo's background colors was simply unbearable so I disabled them altogether.
A possibly better way is to customize mumamo-chunk-coloring. This is an integer that you can set to only color chunks with depth greater than that. Default is 0 so all chunks are colored.
Another possibility is to use mumamo-no-chunk-coloring. This is a minor mode you can turn on for a buffer to avoid chunk coloring in that particular buffer. (This is in the nXhtml menu under "nXhtml / Multiple Major Modes / Remove Chunk Colors Temporarily.)
Another solution (which I would welcome) is to include the chunk coloring in the color themes so they will not clash with them. Since I think that the coloring provides useful information for most users I think that would be the best.
(PS: If you do not use colors you can show chunk dividing hints in the margins if you want too.)
IIRC, this is inherited from mumamo (multiple major modes). Try customizing the "mumamo-background-chunk-major" face (M-x customize-face mumamo-background-chunk-major RET). Un-tick the over-ridden properties to make it inherit from your default background face.
Or for more details on mumamo display, M-x customize-group mumamo-display RET
This is what i have put on my .emacs to override the blue color:
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(mumamo-background-chunk-major ((((class color) (min-colors 8)) (:background "white")))))