发表于   |   分类于   |  

起因

https://github-atom-io-herokuapp-com.global.ssl.fastly.net/assets/application-ba07c5c2889a34307a4b7d49410451d9.css
不能使用https访问，使用chrome-redirector(商店已经下架，以防万一，已经备份了一个到百度云盘)重定向到http

Refused to load the script 'http://github-atom-io-herokuapp-com.global.ssl.fastly.net/assets/application-3db62b578ebfc39ee871abc91b175302.js'
because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'
https://ssl.google-analytics.com
https://www.google-analytics.com
https://platform.twitter.com https://github-atom-io-herokuapp-com.global.ssl.fastly.net".
阅读全文 »

发表于   |   分类于   |  

使用atom编辑markdown,大概了解一下怎么使用,参考Atom 使用教程

常用快捷键

快捷键 效果
cmd + comma open preferences
cmd + shift + p toggle command palette
cmd + \ toggle tree view
cmd + shift + k delete whole line(eclipse:cmd + d,和markdown-writer热键冲突)
cmd + shift + d duplicate whole line
阅读全文 »

发表于   |   分类于   |  

不添加Node到queue

  • tryAcquire 可以获得锁
  • tryAcquireShared 可以获得锁

进入queue

pred.waitStatus == SIGNAL ==> park
pred.waitStatus == CANCELED ==> 更新祖先节点,直到祖先节点不为CANCELED的节点
其他 => 更新祖先节点为SIGNAL , park

acquireQueued

setHead(node),原先的head被移除

waitStatus

enq : 0
被下一个enq:更新为SINGAL
被unparkSuccessor:更新为:0
cancelAcquire:当超时或interrept,更新为CANCELLED

发表于   |   分类于   |  

Classes, fields, and methods

The way you make members public in Scala is by not explicitly specifyingany access modifier. Put another way, where you’d say “public” in Java,you simply say nothing in Scala. Public is Scala’s default access level.

Semicolon inference

  • single line
    one statement on a single line,semicolon is optional
    multiple statement on a single line,semicolone is require
  • multiple lines
    one statement on multiple lines,most of the time,is treated as one multiple lines statement

The rules of semicolon inference
The precise rules for statement separation are surprisingly simple for how well they work.
In short, a line ending is treated as a semicolon unless one of the following conditions is true:

  1. The line in question ends in a word that would not be legal as theend of a statement, such as a period or an infix operator.
  2. The next line begins with a word that cannot start a statement.
  3. The line ends while inside parentheses (...) or brackets [...],because these cannot contain multiple statements anyway.

Singleton objects

Scala cannot have static members. Instead, Scala has singleton objects.
A singleton object definition looks like a class definition, except instead of the keyword class you use the keyword object.
When a singleton object shares the same name with a class, it is called that class’s companion object. You must define both the class and its companion object in the same source file. The class is called the companion class of the singleton object. A class and its companion object can access each other’s private members.
However, singleton objects extend a superclass and can mix in traits. Given each singleton object is an instance of its superclasses and mixed-in traits, you can invoke its methods via these types, refer to it from variables of these types, and pass it to methods expecting these types.
A singleton object that does not share the same name with a companion class is called a standalone object. You can use standalone objects for many purposes, including collecting related utility methods together, or defining an entry point to a Scala application

A Scala application

To run a Scala program, you must supply the name of a standalone singleton object with a main method that takes one parameter, an Array[String], and has a result type of Unit.

Scala implicitly imports members of packages java.lang and scala, as well as the members of a singleton object named Predef, into every Scala source file. Predef, which resides in package scala, contains many useful methods. For example, when you say println in a Scala source file, you’re actually invoking println on Predef. (Predef.println turns around and invokes Console.println, which does the real work.) When you say assert, you’re invoking Predef.assert.

Neither ChecksumAccumulator.scala nor Summer.scala are scripts, because they end in a definition. A script, by contrast, must end in a result expression.
**fsc：**This compiles your source files, but there may be a perceptible delay before the compilation finishes. The reason is that every time the compiler starts up, it spends time scanning the contents of jar files and doing other initial work before it even looks at the fresh source files you submit to it. For this reason, the Scala distribution also includes a Scala compiler daemon called fsc (for fast Scala compiler). You use it like this:

$ fsc ChecksumAccumulator.scala Summer.scala

The Application trait

Scala provides a trait, scala.Application, that can save you some finger typing.
To use the trait, you first write “extends Application” after the name of your singleton object. Then instead of writing a main method, you place the code you would have put in the main method directly between the curly braces of the singleton object. That’s it. You can compile and run this application just like any other.
Inheriting from Application is shorter than writing an explicit main method, but it also has some shortcomings. First, you can’t use this trait if you need to access command-line arguments, because the args array isn’t available. For example, because the Summer application uses command-line arguments, it must be written with an explicit main method, as shown in Listing 4.3. Second, because of some restrictions in the JVM threading model, you need an explicit main method if your program is multi-threaded. Finally, some implementations of the JVM do not optimize the initialization code of an object which is executed by the Application trait. So you should inherit from Application only when your program is relatively simple and single-threaded

发表于   |   分类于   |  
  • https://hc.apache.org/httpcomponents-core-ga/tutorial/html/
  • https://hc.apache.org/httpcomponents-client-ga/tutorial/html/

发表于   |   分类于   |  

Constructing a Rational

class Rational(n: Int, d: Int)

this line of code is that if a class doesn’t have a body, you don’t need to specify empty curly braces (though you could, of course, if you wanted to).

primary constructor

Immutable object trade-offs
Immutable objects offer several advantages over mutable objects, and one potential disadvantage. First, immutable objects are often easier to reason about than mutable ones, because they do not have complex state spaces that change over time. Second, you can pass immutable objects around quite freely, whereas you may need to make defensive copies of mutable objects before passing them to other code. Third, there is no way for two threads concurrently accessing an immutable to corrupt its state once it has been properly constructed, because no thread can change the state of an immutable. Fourth, immutable objects make safe hash table keys. If a mutable object is mutated after it is placed into a HashSet, for example, that object may not be found the next time you look into the HashSet.
The main disadvantage of immutable objects is that they sometimes require that a large object graph be copied where otherwise an update could be done in place. In some cases this can be awkward to express and might also cause a performance bottleneck. As a result, it is not uncommon for libraries to provide mutable alternatives to immutable classes. For example, class StringBuilder is a mutable alternative to the immutable String. We’ll give you more information on designing mutable objects in Scala in Chapter 18.

NOTE:
This initial Rational example highlights a difference between Java and Scala. In Java, classes have constructors, which can take parameters, whereas in Scala, classes can take parameters directly. The Scala notation is more concise—class parameters can be used directly in the body of the class; there’s no need to define fields and write assignments that copy constructor parameters into fields. This can yield substantial savings in boilerplate code, especially for small classes.

class Rational(n: Int, d: Int) {
	println("Created "+ n +"/"+ d)
}

The Scala compiler will compile any code you place in the class body, which isn’t part of a field or a method definition, into the primary constructor

Reimplementing the toString method

class Rational(n: Int, d: Int) {
	override def toString = n +"/"+ d
}

The override modifier in front of a method definition signals that a previous method definition is overridden

Checking preconditions

A precondition is a constraint on values passed into a method or constructor, a requirement which callers must fulfill

class Rational(n: Int, d: Int) {
	require(d != 0)
	override def toString = n +"/"+ d
}

Adding fields

class Rational(n: Int, d: Int) { // This won’t compile
	require(d != 0)
	override def toString = n +"/"+ d
	def add(that: Rational): Rational = new Rational(n * that.d + that.n * d, d * that.d)
}

Although class parameters n and d are in scope in the code of your add method, you can only access their value on the object on which add was invoked. Thus, when you say n or d in add’s implementation, the compiler is happy to provide you with the values for these class parameters. But it won’t let you say that.n or that.d, because that does not refer to the Rational object on which add was invoked

class Rational(n: Int, d: Int) {
	require(d != 0)
	val numer: Int = n
	val denom: Int = d
	override def toString = numer +"/"+ denom
	def add(that: Rational): Rational =
		new Rational(
			numer * that.denom + that.numer * denom,
			denom * that.denom
		)
}

Self references

The keyword this refers to the object instance on which the currently executing method was invoked, or if used in a constructor, the object instance being constructed

Auxiliary constructors

Auxiliary constructors in Scala start with def this(...).

class Rational(n: Int, d: Int) {
	require(d != 0)
	val numer: Int = n
	val denom: Int = d
	def this(n: Int) = this(n, 1) // auxiliary constructor
...
}

The primary constructor is thus the single point of entry of a class.
In Scala, every auxiliary constructor must invoke another constructor of the same class as its first action. In other words, the first statement in every auxiliary constructor in every Scala class will have the form “this(. . . )”. The invoked constructor is either the primary constructor (as in the Rational example), or another auxiliary constructor that comes textually before the calling constructor. The net effect of this rule is that every constructor invocation in Scala will end up eventually calling the primary constructor of the class.

NOTE
If you’re familiar with Java, you may wonder why Scala’s rules for constructors are a bit more restrictive than Java’s. In Java, a constructor must either invoke another constructor of the same class, or directly invoke a constructor of the superclass, as its first action. In a Scala class, only the primary constructor can invoke a superclass constructor. The increased restriction in Scala is really a design trade-off that needed to be paid in exchange for the greater conciseness and simplicity of Scala’s constructors compared to Java’s.

Private fields and methods

make a field or method private you simply place the private keyword in front of its definition.

Defining operators

The first step is to replace add by the usual mathematical symbol

class Rational(n: Int, d: Int) {
	require(d != 0)
	private val g = gcd(n.abs, d.abs)
	val numer = n / g
	val denom = d / g
	def this(n: Int) = this(n, 1)
	def + (that: Rational): Rational =
		new Rational(
			numer * that.denom + that.numer * denom,
			denom * that.denom
		)
	def * (that: Rational): Rational =
	new Rational(numer * that.numer, denom * that.denom)
	override def toString = numer +"/"+ denom
	private def gcd(a: Int, b: Int): Int =
	if (b == 0) a else gcd(b, a % b)
}

Identifiers in Scala

alphanumeric identifier

An alphanumeric identifier starts with a letter or underscore, which can be followed by further letters, digits, or underscores. The ‘$’ character also counts as a letter, however it is reserved for identifiers generated by the Scala compiler. Identifiers in user programs should not contain ‘$’ characters, even though it will compile; if they do this might lead to name clashes with identifiers generated by the Scala compiler
Scala follows Java’s convention of using camel-case identifiers.Although underscores are legal in identifiers, they are not used that often in Scala programs, in part to be consistent with Java,but also because underscores have many other non-identifier uses in Scala code. As a result, it is best to avoid identifiers like to_string, __init__, or name_.

Note
One consequence of using a trailing underscore in an identifier is that if you attempt, for example, to write a declaration like this, “val name_: Int = 1”, you’ll get a compiler error. The compiler will think you are trying to declare a val named “name_:”. To get this to compile, you would need to insert an extra space before the colon, as in: “val name_ : Int = 1”.

One way in which Scala’s conventions depart from Java’s involves constant names.
In Java, the convention is to give constants names that are all upper case, with underscores separating the words, such as MAX_VALUE or PI.
In Scala, the convention is merely that the first character should be upper case.
Thus, constants named in the Java style, such as X_OFFSET, will work as Scala constants, but the Scala convention is to use camel case for constants, such as XOffset.

operator identifier

An operator identifier consists of one or more operator characters. Operator characters are printable ASCII characters such as +, :, ?, ~ or #. Here are some examples of operator identifiers:+ ++ ::: <?> :->
The Scala compiler will internally “mangle” operator identifiers to turn them into legal Java identifiers with embedded $ characters. For instance, the identifier :-> would be represented internally as $colon$minus$greater.
Because operator identifiers in Scala can become arbitrarily long, there is a small difference between Java and Scala
In Java, the input x<-y would be parsed as four lexical symbols, so it would be equivalent to x < - y. In Scala, <- would be parsed as a single identifier, giving x <- y. If you want the first interpretation, you need to separate the < and the - characters by a space.

mixed identifier

A mixed identifier consists of an alphanumeric identifier, which is followed by an underscore and an operator identifier. For example, unary_+ used as a method name defines a unary + operator. Or, myvar_= used as method name defines an assignment operator.

literal identifier

A literal identifier is an arbitrary string enclosed in back ticks (. . .). Some examples of literal identifiers are:
`x` `` `yield`
The idea is that you can put any string that’s accepted by the runtime as an identifier between back ticks. The result is always a Scala identifier. This works even if the name contained in the back ticks would be a Scala reserved word.

Method overloading

Note:
Scala’s process of overloaded method resolution is very similar to Java’s. In every case, the chosen overloaded version is the one that best matches the static types of the arguments. Sometimes there is no unique best matching version; in that case the compiler will give you an “ambiguous reference” error.

Implicit conversions

You can create an implicit conversion that automatically converts integers to rational numbers when needed. Try adding this line in the interpreter:

implicit def intToRational(x: Int) = new Rational(x)

Note that for an implicit conversion to work, it needs to be in scope. If you place the implicit method definition inside class Rational, it won’t be in scope in the interpreter. For now, you’ll need to define it directly in the interpreter.

A word of caution

As this chapter has demonstrated, creating methods with operator names and defining implicit conversions can help you design libraries for which client code is concise and easy to understand. Scala gives you a great deal of power to design such easy-to-use libraries, but please bear in mind that with power comes responsibility
If used unartfully, both operator methods and implicit conversions can give rise to client code that is hard to read and understand. Because implicit conversions are applied implicitly by the compiler, not explicitly written down in the source code, it can be non-obvious to client programmers what implicit conversions are being applied. And although operator methods will usually make client code more concise, they will only make it more readable to the extent client programmers will be able to recognize and remember the meaning of each operator.
The goal you should keep in mind as you design libraries is not merely enabling concise client code, but readable, understandable client code. Conciseness will often be a big part of that readability, but you can take conciseness too far. By designing libraries that enable tastefully concise and at the same time understandable client code, you can help those client programmers work productively.