- Python for .NET (pythonnet)
- work with Python 2+, Python 3+ for Unicode
- Only Python interactive window in Visual Studio support intellisense.
- only work with Python 2
- Python Tools for Visual Studio supports intellisense in code editor.
Both use the same machnism to read .NET code
from ClassLibrary1 import Class1
c = Class1()
To print Unicode string, set font of console windows:
Admin password: “C:\Program Files (x86)\Jenkins\secrets\initialAdminPassword”
Refer link https://wiki.jenkins.io/display/JENKINS/Git+Plugin
- Use another account to run jenkins service
- SSH enter directly:
- SSH from file:
Plugin Multiple SCMs Plugin https://wiki.jenkins.io/display/JENKINS/Multiple+SCMs+Plugin to checkout many repos into many sub directories.
Nuget: download from https://www.nuget.org/downloads
MSBuild from C:\Program Files (x86)\MSBuild\
Config build section
Let jenkins open web browser, jenkin.war is in C:\Program Files (x86)\Jenkins:
java -jar jenkins.war --httpPort=...
New jenkins password “C:\Users\<user_name>\.jenkins\secrets\initialAdminPassword”
Copy job to new jenkins: https://stackoverflow.com/questions/9038748/how-do-i-copy-a-job-from-one-instance-to-another
The following example illustrates low-level use of IEnumerable and IEnumerator:
string s = "Hello";
// Because string implements IEnumerable, we can call GetEnumerator():
IEnumerator rator = s.GetEnumerator();
char c = (char) rator.Current;
Console.Write (c + ".");
// Output: H.e.l.l.o.
However, it’s rare to call methods on enumerators directly in this manner, because C# provides a syntactic shortcut: the foreach statement. Here’s the same example rewritten using foreach:
string s = "Hello"; // The String class implements IEnumerable
foreach (char c in s)
Console.Write (c + ".");
From “C# 5.0 in a Nutshell”.
Controlling access to data is a primary concern with thread synchronization. However, another important aspect is the ability for threads to coordinate their actions by signaling to each other. So, in addition to providing a mechanism for mutually exclusive access to state, monitors also provide an API for signaling.
The goal of signaling is for one thread to be able to inform one or more other threads that a particular event has occurred. The Monitor class exposes three methods—Wait, Pulse, and PulseAll—for precisely this purpose. All three of these methods can only be invoked when the calling thread owns the monitor. Wait gives up the monitor but leaves the thread in a waiting, alertable state. Pulse wakes up one alertable thread. PulseAll wakes up all threads that have called Wait on the monitor in question.
To illustrate Wait and Pulse, let’s look at an example by implementing the producer/consumer pattern: one thread produces work to be performed and enqueues it; another thread pulls the data off the queue and processes it. The key job that signaling will do is to ensure that the consumer thread consumes resources only when there is actually work available on the queue. Listing 4-13 shows the implementation with a monitor.
Listing 4-13. Producer/Consumer with Monitor
private static void Produce(object obj)
var queue = (Queue)obj;
var rnd = new Random();
private static void Consume(object obj)
var queue = (Queue)obj;
while (queue.Count == 0)
val = queue.Dequeue();
The Produce method generates the work and then acquires the queue’s monitor so it can safely enqueue the work (Queue is not internally thread safe). Once enqueued it calls Pulse on the monitor to wake up a waiting thread, in this case the consumer. Note that at this point the Producer still owns the monitor. Last, the producer releases the monitor and sleeps before enqueuing more work.
Meanwhile the Consume method starts its processing loop. The queue’s Count and Dequeue must be bundled into an atomic operation to avoid a race condition (Count returning 1, then another thread dequeuing before we get to the call to Dequeue), so Consume first acquires the queue’s monitor. However, if there is nothing on the queue then we need to give up the monitor so the producer can enqueue some work. If we simply called Monitor.Exit, then the only way we would know if there was work on the queue would be to poll, which would be inefficient. Therefore, you call Wait to give up the monitor but remain alertable by a Pulse. When Wait returns, the consumer once again owns the monitor and so can Dequeue safely. Once the data is dequeued, Consume releases the monitor so it can process the data without blocking the producer.
One possibly strange detail in Listing 4-13 is the use of a while loop around the Wait in the Consume method; what is that for? Well, there is another subtle race condition: sequencing of operations is nondeterministic, so in theory the producer could end up reacquiring the monitor before the consumer has been rescheduled. The effect of this is that Pulse would be called twice, waking more than one consumer thread. One of the threads could consume both items, so when the second consumer finally comes out of Wait, it will own the monitor but there will be nothing on the queue. Therefore, instead of immediately dequeuing it needs to check that there is still work to do on the queue by checking the Count.
From “Pro asynchronous programming with .net”.