I'm also leaking some memory according to valgrind, but that is only a minor concern for my use case.

Hmm, I don't really agree. Leaking memory is harmless only if you know the cause (*), and simply choose to not spend time in fixing it. In your case, the cause (for one part, see below) is the print loop at the end of the main:

while(*strings){
    printf("%s\n", *(strings));
    free(*(strings++));  // incrementing strings here
}

free(strings); // string no longer points to the initially allocated bloc: UB

Whether it matters is your problem, but you should not reproduce this code. BTW, it caused a crash on my VS2017...

Now for the function itself:

char** strings = malloc(0); Nothing really bad here because it will be reallocated later, but as it is more of a trick, it really deserves a comment explaining the reason for that line
Your naming convention for local variables (int i = 0, j = 0, k = 0, l = 0, stringCount = 0;) does not help to understand their meaning. After analysis I would prefer:

i -> buflen
j -> seplen
k -> buf_ix  // or whatever you want saying it is intended to be an index of buf
l -> sep_ix

the strings in strings are not null-terminated. This is really bad because there is no way to find the used length: you really should add that terminating null - anyway, you have reserved memory for it...
An additional memory leak when setting last element of strings to NULL:

/* Append NULL to array of strings */
strings = realloc(strings, (stringCount+1) * sizeof (char *));
strings[stringCount] = malloc(sizeof NULL);    // hmm... a dynamic allocation...
strings[stringCount] = NULL;                   // immediately and definitively lost !

this code should become:

/* Append NULL to array of strings */
strings = realloc(strings, (stringCount+1) * sizeof (char *));
strings[stringCount] = NULL;

you should test malloc and realloc return values. Allocation error are uncommon nowadays, but if this code was to run under stressed condition very bad things would occur, because you would be using a null pointer which is Undefined Behaviour (other details on @TobySpeight's answer).

(*) Even if you had identified that the code in main caused a memory leak, it could have masked the other memory leak inside the function the deserved to be fixed. That's the reason why it is bad to leave a memory leak in a program, and even in a test only one!


I am not sure about the Private/Public scope of this method, someone else will have to talk about that.  but you can return inside a using statement, so instead of this:

private String GetString(long index)
{
  String output;
  using (SqlCommand command = new SqlCommand(CommandText, Connection))
  {
    command.Connection.Open();
    output = command.ExecuteScalar() as String;
    command.Connection.Close();
  }
  return output;
}

you would just return like this

private String GetString(long index)
{
  using (SqlCommand command = new SqlCommand(CommandText, Connection))
  {
    return (command.ExecuteScalar()).ToString();
  }
}

The Command is automatically taken care of so you don't have to worry about explicitly disposing of it.

I assume that the connection is opened and closed by the piece of code that calls this private method, so I left out the connection open and close.

I am kind of on edge about doing it that way, but it seems like you would only want to open one connection for all the SqlCommands that you need to run during the course of the application run.


Writing an excel doc with a subset of my data in R. Currently the code is excessively long

@Duck from Stack overflow provided the answer. Pasting it here. Its is essentially writing a function:
library(r2excel)
#Data
sample_prime1 <- 1:4
sample_prime2 <- 10:14
sample_prime3 <- 22:26
#Store in a list
List <- list(sample_prime1,sample_prime2,sample_prime3)
#Function
myfun <- function(wb,name,df) {
  # Create object
  sheet <- createSheet(wb, sheetName = name)
  # Add headers
  xlsx.addHeader(wb, sheet, value=paste0('Validty for prime ',name))
  xlsx.addLineBreak(sheet, 1)
  xlsx.addTable(wb, sheet, data.frame(df),
                fontColor="darkblue", fontSize=14,
                rowFill=c("white", "lightblue"),
                startCol=2,
                row.names=FALSE,
                col.names = FALSE)
}
#Create workbook
filename <- "validitycheck.xlsx"
wb <- createWorkbook(type="xlsx")
#Loop
#Vector for names
vnames <- paste0('prime',1:length(List))
#Code
for(i in 1:length(List))
{
  myfun(wb,vnames[i],List[i])
}


Your code uses a number of things seldom if ever seen in idiomatic Scala:

return
null
throw
var

the land of no return

The final statement in a code block is the return value of that block, so the keyword return isn't needed. If you structure your code so that each block/method/function has only one exit point, at the end, then your code is easier to read and understand, and less prone to unexpected results.

Also, under some circumstances (I won't detail here) using return will do unexpected things. Easier to just avoid it altogether.

failure is an option

Code that might fail to complete correctly usually does one of two things: return a nonsense value, like null, which the calling code will test for (hopefully), or throw an exception, indicating the source of the problem, which some routine somewhere will catch (hopefully) and process.

Scala offers a third and better option: put the failure in the type system. If a routine might fail, put that in its return type, not its return value. That way the calling code can't ignore the possibility of failure.

In this case, instead of returning a Document, return a Try[Document]. Much like an Option, which is Some(value) or None, a Try is expressed as Success(value) or Failure(exception).

iteration without mutation

Functional Programming avoids data structures with mutable state. Scala has vars but they are discouraged. There are a number of different ways to iterate without using a var. In this case here's what I'd do.

Seq.iterate(Try(browser get page), 5)(_ orElse Try(browser get page))

This is a sequence of 5 results from the page requests, but a new attempt is made only if the previous one failed. The first Success is passed down the line to all subsequent positions in the sequence.

putting it all together

import util.Try

def getPage(browser :Browser, page :String) :Try[Document] =
  Seq.iterate(Try(browser get page), 5)(_ orElse Try(browser get page))
     .last


Deleting a table row in JavaScript with OOP

The trick is linking a row to its item object and vice-versa, so both are removed/added in lockstep.

There are a lot of ways of going about that, but given your original code, the following should be a pretty good way to go.

I'd suggest using a closure when defining the event handler to make things simpler. Here's a simple demo and here's the code

function ShoppingList() {
    var that  = this, // keep a scope reference
        table = document.getElementById("shoppingList"); // find this once (only works if the page has been loaded already)

    this.items = [];

    // this adds an item to the array and a row to the table
    this.addItem = function (product, price) {
        var item = new Item(product, price);
        this.items.push(item);
        table.appendChild(buildRow(item));
    };

    // this removes the given item from the array and the table
    this.removeItem = function (item) {
        for(var i = 0 ; i < this.items.length ; i++) {
            if(this.items[i] === item) {
                this.items.splice(i, 1);
                break; // skip the rest of the loop, since we've found what we need
            }
        }
        table.removeChild(item.row); // remove the row
    }

    // this isn't actually needed as rows get added by addItem,
    // but it'll work just fine regardless
    this.render = function(){
        table.innerHTML = "";
        for(var i = 0; i < this.items.length; i++){
            table.appendChild(buildRow(this.items[i]));
        }
    };

    // an internal helper. This can be moved to the Item prototype
    // since it's not actually dependent on anything in ShoppingList
    function buildRow(item) {
        // an internal, internal helper
        function buildCell(text) {
            var td = document.createElement("td");
            td.innerHTML = text;
            return td;
        }

        // store the table row object on the item itself
        item.row = document.createElement("tr");

        item.row.appendChild(buildCell(item.product));
        item.row.appendChild(buildCell(item.price));

        var deleteCell = buildCell("Verwijder");
        item.row.appendChild(deleteCell);

        // set the event listener here, where we can access `item` and `tr`
        deleteCell.addEventListener("click", function () {
            that.removeItem(item); // remove the item. Here we need the `that` var
        }, false);

        return item.row;
    }
}


The running time is O(n3).  You have three nested loops:

Approximately n iterations of i
For each i, approximately n iterations of j
For each (i, j) pair, up to about n iterations of k.  On average, it take just 0.5 * n iterations of k, but the constant factor doesn't matter.

Quicksort is generally O(n log n).  So the total is O(n log n + 0.5 n × n × n), which is O(n3).

Since you took the trouble to sort the array, the innermost loop could be replaced by a binary search, which is O(log n).  Therefore, an improved algorithm could work in O(n2 log n).


Short and sweet is best.
Your statement

"The main benefit I see here is that anybody reading the code can skim to the last line and know the overall purpose"

That makes no sense at all, you say all that is needed to understand the functions is
$scope.emailList = emailListUpdate;

Nobody jumping into someone else code will just skim, the only people that skim code are those that know the code.
You can make a few assumptions.

All that read your code are competent coders.
All that read your code have read the project specs.
Every line of code will be read by a coder new to the code.

Example
The best code is brief as possible without being a code golf entrant.
Notes

Why innerHTML, should it not be textContent????
This function is not a toggle. It is based on selection value.
The ternary expression is too long, break the line so it does need to be scrolled
The ternary has a syntax error. Misplaced ;
the ; on the last line after "}" is redundant.

Code, best option.
$scope.selectEmailUsers = event => {
  $scope.selection = event.target.textContent;
  $scope.emailList = $scope.selection === "Select All" ?
       $scope.users.filter(user => !user.report.emailed); : [];
  //                                                    ^ remove syntax error
}; // << remove the ;


You should definitely rely on a library to achieve this. The flag package from standard library is nice, but go-flags is even better

With this library, the equivalent code is:

package main

import (
    "fmt"
    "os"

    "github.com/jessevdk/go-flags"
)

type options struct {
    Help     bool     `short:"h" long:"help" description:"show help message"`
    Requests int      `short:"n" long:"requests" default:"1"`
    Clients  int      `short:"c" long:"clients" default:"1"`
    Tests    []string `short:"t" long:"tests" env-delim:","`
    Port     int      `short:"p" long:"port" default:"9000"`
}

func main() {
    var opts options
    p := flags.NewParser(&opts, flags.Default&^flags.HelpFlag)
    _, err := p.Parse()
    if err != nil {
        fmt.Printf("fail to parse args: %v", err)
        os.Exit(1)
    }
    if opts.Help {
        p.WriteHelp(os.Stdout)
        os.Exit(0)
    }
    fmt.Printf("tests: %v\n", opts)
}

All errors (type error, required flag missing ect...) are handle directly by the library

Now the complexity of the function is 3


Initialize and sum an array in Java using threads

In this answer I want to take a look at what your code is doing, and why it doesn't really make sense to use threads like this.

One of the main point of using threads is to do long-running things at the same time (more details here). Some examples:

keeping a GUI responsive while doing other work in the background.
Spreading long calculations over multiple cores.
Doing long-running tasks like waiting for incoming connections or collecting statistics.

If you do them on the same thread, they have to wait for each other. Keep each one on a separate thread, and they'll happily run side-by-side.

In your code, this doesn't really happen.

     for (int i = 0; i < threadsArray.length; i++) {
        threadsArray[i] = new Thread(new Runnable() {
            public void run() {
                synchronize(lock1) {
                    processedArray[numberOfValues - 1] = numberOfValues;
                    numberOfValues--;
                }

            }
        });
        threadsArray[i].start();
    }

Here you're creating your first set of threads, to set the values of the array. However, all of the code inside the thread is synchronized over one object.

static Object lock1 = new Object();

Only one thread can hold a lock at a time. So while one thread is doing its thing, the others are just waiting. This means that all the threads you've created are waiting for each other. They're not running at the same time at all!

But think about why threads are useful: they allows you to do long running tasks at the same time. Except these threads aren't doing anything long. They're just setting a value in an array. That's super fast. It probably takes longer to make the thread than to set the value.

So the same code could have been written like this, without threads:

for (int i = 0; i < processedArray.length; i++) {
    processedArray[i] = i;
}

And it would have been more readable, shorter and faster.

Addendum

As I've said before, this problem should not be solved using threads. However as an exersize let's look at why you need a lock, and how to get rid of it.

public void run() {
    synchronize(lock1) {
        processedArray[numberOfValues - 1] = numberOfValues;
        numberOfValues--;
    }
}

You're sharing the variable numberOfValues between threads. This means that without lock:

One thread could excecute the first line.
Another thread could execute the same line.

Because numberOfValues hasn't been decremented, both proccessArray[] values are now set to the same value.

Instead of using a normal integer as a counter you could use an AtomicInteger.

static AtomicInteger numberOfValues = new AtomicInteger(17);

Your code will look like this:

public void run() {
    int index = numberOfValues.decrementAndGet();
    processedArray[index] = index;
}

You won't need a lock now, since all access to the AtomicInteger is atomic. There's no way to set a proccessArray value without also decrementing the counter.

But we can do better. Instead of using a counter, why don't we just use the index of the loop you're using to create the threads? The code will look like this:

for (int i = 0; i < threadsArray.length; i++) {
    final int index = i;
    threadsArray[i] = new Thread(new Runnable() {
        @Override
        public void run() {
            processedArray[index] = index;
        }
    });
}

Now you don't need a shared counter, and you wont't need a lock.


Knowing the time limit helps determine what kind of effort is needed to make the code fast enough:

simple trial division
trial division with wheeled striding through candidates and divisors
trial division with memoised divisor primes and wheeled striding through candidates
Sieve of Eratosthenes
odds-only Sieve of Eratosthenes
segmented odds-only Sieve of Eratosthenes
segmented odds-only Sieve of Eratosthenes with presieving

Each complication makes the code significantly faster, but also more complex. So how fast is fast enough?

Generally speaking, the primes up to any given k should only be computed once total instead of twice for each query. Also, given the fact that the query count limit is much higher than the piddling small numbers of primes involved (10000) it makes sense to compute all of them in one go, which is much more efficient and much less complicated than writing some logic that can extend the current list of prime-indexed primes up to some number k when it is too short.

The high number on queries also makes it imperative to benchmark the code for parsing inputs and producing outputs, since that can easily dominate the total program runtime. SPOJ's INOUTEST - and the same or similar tasks at other sites - can be a good guide there.

I've had several such tasks where my submissions clocked times of several seconds or even TLE, even though the raw problem-solving part took only a few milliseconds to run. Writing a dedicated input parser and (batched) output converter cut runtime by two orders of magnitude or more.

Based on my experience recently solving problems of similar structure and magnitude (SPOJ's TDPRIMES and TDKPRIME) I would recommend using a segmented odds-only Sieve of Eratosthenes for building the list of prime-indexed primes in one go. That gives you the best performance for the least amount of complications. It would be possible to speed up your trial division by several orders of magnitude but then it would be more complex than the sieving solution, and the sieve would still blow it out of the water despite using simpler code.

I tried quite a few approaches and strategies, and perhaps my experiences can help you avoid going down some blind alleys.

Recommendation: use an odds-only sieve with bool array that is the same size as your CPU's L1 cache, e.g. 32 KiByte.

Using packed bits in a byte array would allow sieving eight times as much per cache-sized window, and extraction of primes from the sieve would be much more efficient. However, the overhead of indexing (sieve[j>>3] |= 1 << (j&7) instead of a simple sieve[j] = true) means that the sieving using byte[] took slightly longer overall in my tests than sieving plus extraction using bool[], even though the bool code had to sieve eight times as many windows. I was able to make byte[] 30% faster than bool[] but the effort required was essentially the same as that for a modulo 30 wheel, tripling the total size of the source code. Using the stock bitsets of C# (BitArray) and C++ (std::vector<bool>) was an unmitigated performance disaster; the whole program took several times as long to run just because of their mind-boggling inefficiency.

Recommendation: use functions that focus on a specific part of the job and that do whole batches at a time with maximum efficiency.

For example, I found it much faster to extract all primes from a sieved window and then pick out every hundredth from that, instead of integrating the 'take only every 100th prime' bit into the code that extracts primes from the sieve. The reason is focus and simplified looping/branching structures. Modern CPU don't like unpredictable branches at all and levy heavy taxes on them in the form of wait cycles. Better factoring also makes it easier to try different approaches for different sub tasks, for example via function pointers or delegates that can be switched at runtime. And it makes it easier to compose new, completely different solutions from the existing bits and pieces.

For example, instead of complicating - and thus slowing down - the sieve code by the logic for memoising the small handful of primes needed for sieving, I used a separate function for that purpose. Here is the pseudocode (of a hashish persuasion):

internal static List<ushort> small_odd_primes_up_to (int n)
{
    Trace.Assert(3 <= n && n <= ushort.MaxValue + 1);

    // the '- 1' comes straight from the reversing the conversion formula n = (b << 1) + 1;
    // it ensures that even n get treated the same as the immediately preceding odd number
    // instead of tagging an unnecessary bit onto the end of the array
    int max_bit = (n - 1) >> 1;

    // the '- 1' comes from the number-to-bit conversion again and is not related to the sqrt
    int sqrt_n_bit = (int)(Math.Sqrt(n) - 1) >> 1;
    var sieve = new bool[max_bit + 1];

    for (int i = 3 >> 1; i <= sqrt_n_bit; ++i)
        if (!sieve[i])
            for (int p = (i << 1) + 1, j = p * p >> 1; j <= max_bit; j += p)
                sieve[j] = true;

    // 3 needs to be handled separately because of the mod 3 stepping in the for loop
    var result = new List<ushort>()  {  3  };

    for (int i = 5 >> 1, d = 1; i <= max_bit; i += d, d ^= 3)
        if (!sieve[i])
            result.Add((ushort)((i << 1) + 1));

    return result;
}

In your case it would have to deliver only the 1168 odd sieve primes, i.e. those not greater than sqrt(1366661) where 1366661 is the 104729th prime and the 10000th prime-indexed prime. This means that the optimisations it contains - odds-only sieving, plus skipping multiples of 3 when reading out the sieved primes - are not really necessary for the problem at hand. However, I've used that function unchanged in almost all code challenges related to primes, and there's no reason to fiddle with tried and trusted code. Basically, it's about the simplest possible code that can do the job, with only a few sleight-of-hand optimisations. I've shown it to provide a contrast to the design of the main sieving logic, which adds quite a few complications.

For example, here's the hashish pseudocode of a function that gets handed a sieved window by the segmented sieve function, extracts all primes from it into a cache, and then adds every Kth prime from the cache to the list of results (which is a property of the class):

// phase and result[] are static class fields

internal static int[] cache = new int[MAX_PRIMES_PER_SIEVE];

internal static void sieve_to_array_post_filtered (bool[] sieve, int window_base, int window_bits)
{
    // get things into step for the mod 3 loop stepping on top of the mod 2 wheel
    // (the loop is anchored at residue 1)

    int i = 0, k = 0;

    switch (window_base % 3)
    {
        case 0:
        {
            i = 1;  goto case 2;
        }

        case 2:
        {
            if (!sieve[i])
                if (i < window_bits)
                    cache[k++] = window_base + (i << 1);

            ++i;  break;
        }
    }

    for (int e = window_bits - 5; i < e; i += 6)
    {
        if (!sieve[i])
            cache[k++] = window_base + (i << 1);

        if (!sieve[i + 2])
            cache[k++] = window_base + (i << 1) + 4;

        if (!sieve[i + 3])
            cache[k++] = window_base + (i << 1) + 6;

        if (!sieve[i + 5])
            cache[k++] = window_base + (i << 1) + 10;
    }

    for ( ; i < window_bits; ++i)
        if (!sieve[i])
            cache[k++] = window_base + (i << 1);

    for (i = K - phase - 1; i < k; i += K)
        result[result_size++] = cache[i];

    phase = (phase + k) % K;
}

Most of this does the exactly same job as the 2nd for loop in the earlier function, but much faster. The main loop uses mod 3 stepping on top of the odds-only sieve, twice unrolled. The loop after that cleans up leftovers, and the final loop extracts every Kth prime, with phase coordinating the correct counting from one sieve window to the next. This is from the TDPRIMES task where every 100th prime was to be printed; adapting the logic to the requirements of finding prime-indexed primes is trivial.

This example shows how the tiny 2nd loop of the first function got blown up quite lot by the tricks required for achieving performance goals. The code is significantly faster than all other variations I tried, and I tried an awful lot of them (because I'm currently learning the hashish language). The speed is made possible by batched operation, focussing on a single job, and reusing buffers; the loop for extracting the Kth prime was essentially tacked on to the end of the function without disturbing anything. That was required because the sieving function simply invokes this via a process_sieve delegate that is supposed to do whatever is necessary with the freshly sieved primes.

To complete the picture, here's the pseudo code of the segmented sieving logic. It's essentially a normal Sieve of Eratosthenes that sieves the target range in cache-sized increments, remembering the working offsets for each prime from one iteration to the next and pumping the sieved primes out via the process_sieve delegate to make place for a new batch.

internal static void process ()
{
    const int N = 100000000;
    var small_odd_primes = small_odd_primes_up_to((int)Math.Sqrt(N)).ToArray();
    var offset = new int[small_odd_primes.Length];

    // ... some preparatory stuff elided (e.g. setting presieve_pattern and presieve_modulus) ...

    int window_base = 3, n = N - (~N & 1), last_prime_index = small_odd_primes.Length - 1;

    for (int i = first_sieve_prime_index; i <= last_prime_index; ++i)
    {
        int prime = small_odd_primes[i], start = prime * prime;

        offset[i] = (start - window_base) >> 1;
    }

    var sieve = new bool[1 << 15];

    for (int bits_to_sieve = ((n - window_base) >> 1) + 1; bits_to_sieve > 0; )
    {
        int window_bits = Math.Min(bits_to_sieve, sieve.Length);

        Buffer.BlockCopy(presieve_pattern, (window_base >> 1) % presieve_modulus, sieve, 0, window_bits);

        for (int i = first_sieve_prime_index; i <= last_prime_index; ++i)
        {
            int p = small_odd_primes[i], j = offset[i];

            for ( ; j < window_bits; j += p)
                sieve[j] = true;

            offset[i] = j - window_bits;
        }

        process_sieve(sieve, window_base, window_bits);

        window_base += window_bits << 1;
        bits_to_sieve -= window_bits;
    }
}

Obviously you'd use N = 1366661 instead of 10^8, and the logic for copying the presieved pattern would be replaced by a simple call to Array.Clear. However, I left the presieve logic in place to show where it fits into the overall scheme, because this simple trick can add quite a performance boost. The reason is that the smallest few primes have the shortest strides and thus have to make many more hops in any window than the rest taken together, and blasting a suitable bit pattern over the sieve is much faster. Without presieving you'd use 0 as first_sieve_prime_index, naturally.

In any case this should make clear that the logic of a segmented sieve can be very simple indeed.

Using a delegate like process_sieve instead of fixed-function code has the added advantage that it simplifies unit testing. I.e. write a delegate that extracts and stores all primes, which can then be checked against any other prime source.

To put things into perspective: my SPOJ TDPRIMES submission from which the pseudo code was taken (printing every 100th prime up to 100,000,000) clocked 190 milliseconds on SPOJ (C#). The time for sieving the first 10,000 prime-indexed primes with this approach should be on the order of a millisecond.


Read numbers until a prime is entered then print non-primes

I am no C# programmer, so I can't tell you much about the "C# way" to code. But I'll try to help you with your algorithm.

First things first, if I'm not mistaken your for-loop may fill the list of non-primes multiple times for a given number if it has more than one divisor. I'd suggest using the break; statement to exit the loop after you found the first, i.e.

for (int i = 2; i <= number / 2; i++)
        {
            if (number % i == 0){
                prime = false;
            }
            if (prime == false){
                nones.Add(number);
                break;
            }
        }

This will also save time by skipping unnecessary iterations. You should also increment by two instead of one, because all even numbers - and their multiples - will be divisible by two.

Since all numbers are either primes or multiples of primes you could further reduce compute time by skipping over numbers that are not prime. For example, fill an array with prime numbers below 100, then first try to divide the input by numbers in the array.
If it can't be divided by any of them, go back to the for-loop you already wrote and start from the highest prime you used.


How to make my backtraching sudoku solving algorithm in Python faster?

Your sudoku solver is missing a crucial part: the one that fills all obvious cells without backtracking.

In your example sudoku, in row 1 column 7 there must be a 1 because that's the only place in row 1 where a 1 is possible. That's because the blocks to the left already contain a 1, and columns 8 and 9 also contain a 1 further down.

With that improvement, the algorithm should get quite fast. That's probably how every other sudoku solver attacks the complexity, therefore you should have a look at the answers of related code reviews.

In 2006 I wrote a sudoku solver in C using exactly this improvement. You may have a look at it, it should be pretty fast, even when you translate it back to Python.

Since sudokus are popular, several people have already documented how they wrote a sudoku solver. I found this one via Rosetta Code.


The terminology is a bit sloppy - I would call the operation of going from digits back to alphabetic characters decoding rather than encoding - and our function isn't really either of those: it's counting.  (I'm guessing that you're not a native English speaker, so don't take this criticism too harshly!).

The interface is surprising: accepting an integer type greatly limits the maximum length of input, and we could return an unsigned type as result:
unsigned int count_decodings(const char *input);

As a hint, it is safe to convert a character to digit by subtracting '0' (C guarantees that the digits 0..9 have consecutive encodings, regardless of the host environment's character coding).

The algorithm produces incorrect results:
This comment is not justified:
//extra count for the single digit encoding since all digits are non-zero
return ++count;

Some digits may indeed be zero - for example, 10 and 201 can each be decoded exactly one way.  That should suggest some extra testing you could (and should) do.

It's good that we have some tests in main(); I would go further and make the tests self-checking.  Instead of merely printing the results, we should compare against the expected values, and return EXIT_SUCCESS only if all the tests pass.  There are several libraries available to help with unit testing like this, or you could could do it quite simply:
int failures = 0;
failures += count_decodings("10") != 1;
failures += count_decodings("11") != 2;
// more tests here

We don't have any indication of which tests have failed, and what their expected and actual results were.  We could create macros to help here (which is exactly what the unit-testing frameworks provide for us).


Implementation of Multiparental Sorting Crossover

Parsing a line of space separated integers is repeated 4 times you can replace those with the method below:

private static int[] parseLineOfInts(String s) {
    String[] tokens = s.split(" ");
    int[] arr = new int[tokens.length];
    for (int j = 0; j < tokens.length; j++)
       arr[j] = Integer.parseInt(tokens[j]);
    return arr;
}

You can use arrays of arrays to hold 2D data. Parsing the parents becomes as below:

int nParents = 3;
int[][] parents = new int[nParents][];
for (int i = 0; i < nParents; i++) {
    parents[i] = parseLineOfInts(Input[i + 1]);
}

Note parent1 is now parent[0] and so on.

You can use parseLineOfInts method to calculate mask_elements as below:

int[] maskElements = parseLineOfInts(Input[0]);

parameters and local variables should be camelcase: first word starts with lowercase, subsequent words start with upper case:

Input should be input
parent_x should be parentX
parent_y should be parentY

Separate parsing and actual algorithm. Separation of concerns improves readability, testability, many other ...abilities. As a first step you can extract not string manipulation related code into a new function such that its signature becomes as below:

int[] solve(int[] mask, int[][] parents)


What would be the optimal way to address these arrays

You should almost never be using np.append, numpy arrays are designed to be used as fixed size arrays. np.append creates a whole new array each time and will thus fairly expensive.

The first thing is that you should create the array at its full size. Then assign to the elements:

y = np.empty(10+len(wavelength)-2, int) # I don't know the type, guessing here
for i in xrange(10+len(wavelength)-2):#2 repeats
    y[i] = model[MN][i]

The second thing is that you should look for numpy operations to do the same thing your loop does. In this case, I can actually replace that code by:

y = model[MN, :10 + len(wavelength) - 2]

This assumes that model is a numpy array. If it is isn't, you should make it one.

Let's look at the code for fmod

for i in xrange(10,10+len(wavelength)-2): #2 repeats
     Alambda=Ak/wavelength[i-10]
     fmod=np.append(fmod,convertStr(y[i])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel[i-10]))
     if i== 11:
      fmod=np.append(fmod,convertStr(y[i])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel[i-10]))
     if i== 13:
      fmod=np.append(fmod,convertStr(y[i])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel[i-10]))

It is not as obvious how to vectorize this code. Firstly, we can clean up the code a bit. Eliminate the unused Alambda, eliminate duplicate pieces of code, and change the loop to start with zero. (When trying to vectorize you pretty much always want to start by changing your loops to start with 0).

for i in xrange(len(wavelength)-2): #2 repeats
     value = convertStr(y[i+ 10])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel[i])
     fmod=np.append(fmod, value)
     if i == 11 or i == 13:
          fmod = np.append(fmod, value)

It is still not clear how to break up this loop, so we apply a general strategy of breaking up a loop. If a loop does multiple things, we break the loop up so that the loop only does one thing. Here is the first loop.

value = numpy.empty( len(wavelength) - 2)
for i in xrange(len(wavelength) - 2):
    value[i] = convertStr(y[i+10])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel[i])

Once we have the loop down to the simple level of assigning to each element, we want to vectorize it. I don't know what convertStr does, but I'll assume it can be adapted to vectorize whatever I pass into it. So I can replace this loop by:

value = convertStr(y[10:])*Fbol*scale*1e+023*1e+03/(c/wavelengthmodel)

Let's move onto the second loop

for i in xrange(len(wavelength)-2): #2 repeats
     fmod=np.append(fmod, value[i])
     if i == 11 or i == 13:
          fmod = np.append(fmod, value[i])

This essentially copies value, but introduces repeats. There are  few ways this could be accomplished. Probability the simplest would be:

fmod = np.empty( len(wavelength), int)
fmod[0:11] = value[0:11]
fmod[11:13] = value[11]
fmod[13] = value[12]
fmod[14:17] = value[13]
fmod[17:] = value[14:]

Hopefully that gives you an idea of how to approach improving the performance.


Find the nth prime between 1 and 1,000,000 in under 3 minutes - follow-up

Trial division is entirely the wrong algorithm to use when you want to find many primes. The Sieve of Eratosthenes is much more efficient. It seems that you know that too, but have chosen a slower algorithm anyway, and now you are unhappy that it exceeds your expected running time.

Division is slower than multiplication and addition. Square root are even more work to compute. The Sieve involves neither of those expensive operations.

Nevertheless, I'll play along. If you want to do trial division, you could at least write the code better:

Eliminate special cases. You have hard-coded 2, 3, 5, 7 twice. The output format for small primes is inconsistent as well.
Eliminate redundant bookkeeping. Since primes is just the length of lst, why not use len(lst)? That frees up the variable name primes, which would be a more appropriate name for the list itself.
Name your variables better. Use candidate instead of chk. Since n is always prime, call it p instead.

import time
goal = int(input("Enter a number n, 1-1,000,000 to find the nth prime number."))
start = time.time()

primes = [2, 3, 5, 7]
candidate = 11
while goal >= len(primes):
    limit = candidate ** 0.5
    for p in primes:
        if p > limit:
            primes.append(candidate)
            break
        if candidate % p == 0:
            break
    candidate += 2

print("Prime", str(goal), "is", str(primes[goal - 1]))
elapsed = (time.time() - start)
print(elapsed, "\n")

This isn't going to change the performance, but at least you would have more readable code, and less of it to manage.


Checking for balanced brackets in Python

Review

Your implementation is quite good, but ofcourse there are always some things that can be improved upon.

Use a if __name__ == '__main__' guard, see what they do.
opening closing and mapping could be done a bit simpler

You may use list over the values, to create a list,
And you may zip those in a dictionary with the zip keyword.

If you need to add alot of corner cases, your algorithm is likely off somewhere else.
Consider adding Testcases, Docstrings, or both in the form of Doctest. To make it easier to Test your algorithm.

Alternative code

def is_matched(expression):
    """
    Finds out how balanced an expression is.
    With a string containing only brackets.

    >>> is_matched('[]()()(((([])))')
    False
    >>> is_matched('[](){{{[]}}}')
    True
    """
    opening = tuple('({[')
    closing = tuple(')}]')
    mapping = dict(zip(opening, closing))
    queue = []

    for letter in expression:
        if letter in opening:
            queue.append(mapping[letter])
        elif letter in closing:
            if not queue or letter != queue.pop():
                return False
    return not queue

if __name__ == '__main__':
    import doctest
    doctest.testmod()


Problem: Remove duplicates from a given array of integers.

An important part of programming interviews is asking clarifying questions,
and try to not assume anything.
For example:

What kind of values are we talking about?
What is the range of possible values?
Is the array sorted?
How many values are there?
How many duplicate values are there?
Do you need to preserve the order of the elements that are not removed?

Depending on the answers, you may have a very different problem to solve.
For example if the range of values is limited to [1:100], or if the array is sorted.

My gut reaction is to assume that the values are in the full range of valid integers, the array is not sorted, and there may be any number of duplicate values. However, during an interview it's important to not assume anything. Whether the candidate asks clarifying questions or just quietly makes assumptions can make a big difference.
(How many times do programmers think they know what system they are supposed to build but they don't really know? Lots of times!)

  My main goal in writing this code was in the mindset that I am in an interview and that I am given only 20 minutes to solve this problem.

It's usually ok to make something work the easiest possible way and then gradually make it better. In this example the easiest solution seems to be to iterate into a set and then convert that to an array.

public int[] removeDuplicate(int[] arr) {
    return toIntArray(toSet(arr));
}

private Set<Integer> toSet(int[] arr) {
    Set<Integer> set = new LinkedHashSet<>();
    for (int num : arr) {
        set.add(num);
    }
    return set;
}

private int[] toIntArray(Set<Integer> set) {
    int[] result = new int[set.size()];
    int i = 0;
    for (int num : set) {
        result[i++] = num;
    }
    return result;
}

Code review

Using the boolean literals true and false in conditions like this can be a red flag:

if (check[i] != true)

Use boolean expressions directly:

if (!check[i])

This is manual array copy:

    int returnArray[] = new int[index];

    for(int i = 0; i < returnArray.length; i++)
        returnArray[i] = temp[i];

    return returnArray;

It's recommended to use System.arraycopy or Arrays.copyOf instead.
In this example you can replace the above lines with this one:

    return Arrays.copyOf(temp, index);

temp is a very poor name. Almost anything would be better, how about unique. With index renamed to uniqueCount, you end up with something quite natural:

    return Arrays.copyOf(unique, uniqueCount);


Inserting text file rows into an Access DB

OK, thought I might get a quick win if you were using a version of Access old enough to be using the Jet engine (in that case DAO is inherently much faster).

First thing: Don't go down the road of your "Logic 2".  The fact that you realized you have to escape any quotes in the input file should be a great reminder as to why using parameters is good practice - it sanitizes input and avoids SQL injection.

Second, and this is the main one.  You are looping over code that should always execute with the same results.  Pull these out of you loop so you only do them once:

            'Create the parameters
            Dim Prams As String = "@p1"
            For i = 2 To fullRow.Count
                Prams = Prams & " ,@p" & i
            Next

            Dim insertQuery As String = "INSERT INTO " & sAccessTableName & " VALUES (" & Prams & ");"
            Dim cmd2 = New OleDbCommand(insertQuery, conn)

The dynamic parameter generation isn't ideal, but isn't really avoidable if you need a general purpose function.  I'm guessing that a large amount of the inefficiency is repeatedly creating new OleDbCommand objects (as well as the SQL string) when they can be re-used.  In fact, parameterized OleDbCommand objects are optimized for looping over with multiple inserts. Add your parameter list without values before you go into the main loop, and then assign to them by index.

This should speed you up quite a bit. If that doesn't get you into the ballpark of where you need to be performance-wise, the Access object model will let you automate a bulk insert from a tab delimited file.  You may want to benchmark how long it takes Access to import the file and explore this possibility too, especially if you control the datafile generation.

One last note:  Don't forget to "'TODO: Write the row and the exception somewhere" and keep swallowing the exceptions.

EDIT:

Good starting place for Access automation is here - there are some community links at the bottom of the page that are pretty good. I'd only use this as a last resort as it pulls in lots of dependencies and requires starting an Access process.  I'm fairly sure managing the OleDbCommand outside the loop is going to give the best performance.


Saving web search results for EANs to CSV

There are multiple things to tackle and improve, let's summarize.

Code Style

In general, try to follow the PEP8 style guide, you have multiple violations, like:

use of spaces around operators and blank lines
organizing imports

There are tools like flake8 or pylint which can analyze your code statically and report existing violations, make sure to give them a try.

Variable naming is also a huge issue in the presented code - variables like i or my_dictionary are meaningless - make sure to give your variables meaningful names to improve readability. Remember: code is much more often read than written.

Code Organization

Currently, you are putting everything into a single program without any organization - think about logically splitting it into functions. You should also put your main execution logic into the if __name__ == '__main__': to avoid the code being executed on import.

Making the code Pythonic

you can use a dictionary comprehension with enumerate() to define your new_dictionary dictionary:

with open('EAN.txt') as f:
    new_dictionary = {
        'sequence_{}'.format(line_number): line
        for line_number, line in enumerate(f)
    }

On the second though, you don't actually even need a dictionary here - the keys are useless in the main execution logic of the program. A list of search queries should be sufficient enough.
you don't need read().splitlines() and can directly iterate over the file object lines - this will avoid having an extra list of lines created in memory and allow to get every next line in a "lazy" fashion
use print() as a function for Python-3.x compatibility

Performance and Web-Scraping related Improvements

First of all, you don't need to save the page source into a file and then reading that file to parse with BeautifulSoup - you can avoid that step altogether by feeding mechanize Browser's page source into BeautifulSoup directly.
You should also be able to initialize the Browser once and re-use for all the subsequent requests.
Also, you may improve on HTML parsing speed by using lxml as an underlying parser for BeautifulSoup - this requires lxml to be installed though.
I would also use a .product-title CSS selector to match product titles.
I would just collect the results and then write at the end instead of dealing with re-opening the resulting CSV file in the loop.
Performance-wise, this is also a good use case for a SoupStrainer which will make BeautifulSoup parse only the desired parts of a document - in your case the product links

Here is the code with some of the improvements applied:

import csv

from bs4 import BeautifulSoup, SoupStrainer
import mechanize

URL = "https://mysite"

if __name__ == '__main__':
    print("Running...")

    results = []
    with open('EAN.txt') as f, mechanize.Browser() as browser:
        browser.set_handle_robots(False)

        for search_query in f:
            browser.open(URL)

            browser.select_form(id="searchForm")
            browser["q"] = search_query
            response = browser.submit()

            soup = BeautifulSoup(response, 'lxml', parse_only=SoupStrainer(class_='product_title'))

            product_title = soup.select_one('.product-title')
            product_title_text = product_title.get_text(strip=True) if product_title else None
            results.append([search_query, product_title_text])

    # dump results
    with open('Results.csv', 'ab') as csvfile:
        writer = csv.writer(csvfile, delimiter='|', quotechar='|', quoting=csv.QUOTE_MINIMAL)

        for search_query, product_title in results:
            result_label = "Approved" if product_title else "Rejected"
            writer.writerow([search_query, result_label, product_title])

Might not work as is, since I don't have a way to test it. There are also some assumptions there - like the presence of a only one "product title" on a search result page per form query. But, at least, I hope that will give you something to start with.

And, I am not sure you need that np.genfromtxt() since currently you don't even read the results of this function call - hence removed that part in the posted code above.


Programs for different language learning - Python

You should use len rather than hard-code the length of choices.
You should use str.format to add lang into the string. 'there are {} languages'.format(lang).
You mix print '' and print(''). Pick one or the other. The former is preferred in Python2, the latter in Python3.
Reduce the amount of prints. They are slow, and merging them into one is much faster.
You should use raw_input().lower(), so that the user can enter 'rUBy'. Where it converts it to lower case, 'ruby'.
Use elif not else. If I enter C, I don't want to be told I entered Python.

  In Python is there a equivalent to Ruby's puts?

In Python2 and 3 you can use '\n'.join(list).
In Python3 you can use print(*list, sep='\n').

  In the function print random.choice(["Perl", "Ruby"]) is there a way I can pull from the array instead of having to write out language names

You may mean filter the list, so it does not include 'Python'.

random.choice(filter(lambda lang: lang != "Python", choices))

import random

def welcome():
    choices = ["Perl", "Python", "Ruby"]
    user_choice = raw_input(
        (
            "Welcome, to the test script, this will test what language you "
            "would like to learn.. In order to find out these choices, write "
            "this same definition in all three different languages\n\n"
            "There are {} languages to choose from please pick one\n"
            "{}"
        ).format(len(choices), choices)
    ).lower()

    if user_choice == "ruby":
        print "You have chosen Ruby!\n"
    elif user_choice == "perl":
        print "You have chosen Perl!\n"
    else user_choice == "python":
        print "You're already writing in Python!!Let me choose for you! \n{}".format(
            random.choice(["Perl", "Ruby"]))
    else:
        print "Invalid choice."

welcome()


python search replace and join with delimiter

Welcome to code review, good job using a docstring and trying to make your code readable.

Space after a comma:

test2 = ("lorem","ipsum","dolor", "fright", "nec","pellentesque","eu",
"pretium","quis","sem","nulla","consequat","massa","quis",)

According to PEP0008 which I recommend checking for being the official Python style guide: a space should be left after a comma for readability.

Which should look like:

test2 = ('lorem', 'ipsum', ...)
Use descriptive names: names like left_join() newstr j are not describing the objects they represent ex: your function name can be def replace_word(words, word, new_word):
Type hints: You may use type hints to indicate what are the inputs and outputs in the following way:

def your_function_name(phrases: tuple) -> str:
Docstrings: Good job using a docstring for your function, however the description is not very clear here's a better description and btw docstrings should indicate what the input and the output is (what the function parameters are and what it returns):

def your_function_name(phrases: tuple, old_word: str, new_word: str) -> str:
    """
    Replace the old_word by the new_word if found in phrases.
    Args:
        phrases: Tuple of words.
        old_word: The word to replace.
        new_word: The replacement.
 Return:
     Joined string after replacements.
    """

str.replace() and str.join() You can use the replace method to achieve the same results in a shorter code and since you're familiar with join():

Instead of doing this for every letter in every word:

else:
    newstr += phrase + ','

You can do:

', '.join(words)

Code might look like:

And Note: You usually wouldn't be creating a function for such a simple task but use replace() and join() directly, I'm creating a function just for the sake of the example.

def replace_word(phrases: tuple, old_word: str, new_word: str) -> str:
    """
    Replace the old_word by the new_word if found in phrases.
    Args:
        phrases: Tuple of words.
        old_word: The word to replace.
        new_word: The replacement.
 Return:
     Joined string after replacements.
    """
    return ', '.join(word.replace(old_word, new_word) for word in phrases)

if __name__ == '__main__':
    test1 = ("bright aright", "ok", "brightness wright",)
    test2 = ("lorem","ipsum","dolor", "fright", "nec","pellentesque","eu",
 "pretium","quis","sem","nulla","consequat","massa","quis",)
    print(replace_word(test1, 'right', 'left'))
    print(replace_word(test2, 'right', 'left'))

Output:

  bleft aleft, ok, bleftness wleft

  lorem, ipsum, dolor, fleft, nec, pellentesque, eu, pretium, quis, sem, nulla,
  consequat, massa, quis


First is error handling. The problem is I cannot throw the errors further up in the app as the cookiestore interface doesn't not allow it.

You can define a custom unchecked exception and throw that.  (Or throw an existing unchecked exception if you can find one that is suitable.)

  Secondly I have made a persistantcookie so I have a concrete class to serialise. I then convert that to the cookie interface. It seems an ugly way to do it.

I don't think you have any sensible alternatives.  (And besides, I disagree that it is "ugly".)

And please correct the spelling of (at least) the public class and method names.  It is like chalk screeching on a blackboard ...


Two cross-platform implementations of getline in C

exit(1) is probably a bad idea, so is fprintf to stderr.  We don't know how big the string can be, therefore running out of memory could be valid, and if stderr is redirected to somewhere a client can see. realloc should already set errno to ENOMEM, so you could probably just return NULL, and modify comment that upon returning NULL, caller should check errno. Or maybe you should return empty string if there's no data, and use NULL to indicate error.

change calloc to malloc, as you anyway NULL terminate the string in your fgetc implementation.

Instead of having this code duplicated for error message (which I vote against), and actual calculation: chunk_size*(j+1)*sizeof*line+1, you could create a variable and use it in both places, therefore you know you print exactly what you did, and there wasn't a mistake if you had to change the calculation slightly.

Try this on windows (as it claims to be a cross platform implementation), but from memory fgetc will return '\r', which you'll put right into the line, whereas I'm pretty sure fgets won't return '\r', when the line terminator is "\r\n"; I believe fgets returns "\n", not "\r\n" on windows, even if "\r\n" is in the input stream.

You don't need to assign data to tmp like this: char* tmp=realloc(line,chunk_size*(i+2)*sizeof*line+1); as upon success you always do: line=tmp, and upon failure, line will no longer point to valid memory. So you could just assign to line.

Notice how you're calling malloc/calloc/realloc, I would add a freeline function to your code in order to free any memory allocated by this code.  The caller may not be using the same malloc/calloc/realloc you're using, and their free may not be compatible.

Finally I'm not really sure about this: chunk_size*(j+1)*sizeof*line+1
I think you want: chunk_size*(j+1)*sizeof*char+1, as I think line is of size 4 or maybe even 8?, print it out in the debugger, and see, I think you're allocating a lot more memory then you end up putting into the array.


A few things:

You are casting the result of your calls to malloc. That is something you shouldn't do actually.
If possible, try not to used fixed-size integer types (uint32_t, int32_t, etc...) for they are only conditionally supported by the compiler. For example, I doubt that you need a fixed-size type for your error codes. At least, use int_least32_t instead.
When you are not using any format string, you should consider using puts to printf (e.g. puts("---") instead of printf("---\n"). That's both shorther and safer.
Also, you initialize i to 0 twice in BSPrintContents. That seems pretty useless.


I don't see any immediate problems with it, but I would probably simplified it a bit. Not sure why you're doing it in two loops like that, but I might be missing something of course :)

<?php
$loops = 10000;

$start = microtime(true);

for ($i = 0; $i < $loops; $i++)
    theFunction();

$total = microtime(true) - $start;
$avg = $total / $loops;

echo "Average: " . $avg . "s\n";


Algorithm

Since its recursive and O(n), for large n you may get a stack overflow.
It will fail if the head is null (empty).
This part is redundant:

toReversePortionHead->setNextNode(NULL);

Since in each stack call you change the next pointer of the next to the current. For example:

In the base case :

(4) -> (5) -> (9) -> (10) -> nil

First pop:

(4) -> (5) -> (9) <- -> (10)

Second pop:

(4) -> (5) <- -> (9) <- (10)

You will end up with:

(4) <- -> (5) <- (9) <- (10)

So you set the member next of the resulting node to null

nil <- (4) <- (5) <- (9) <- (10)

Node

Your node is generic, you should make it a nested class. Also your get and set methods are too verbose and I would personally omit them.

NULL:

If you are using C++11 you should be using nullptr. If you are curious why is a better alternative you could check out this link https://stackoverflow.com/questions/13816385/what-are-the-advantages-of-using-nullptr

Code :

I would change it to this:

template <typename el>
void Linkedlist<el>::reverse() {

    if(!empty())
       recReverseList(head)-> next = nullptr;
}

template <typename el>
Node * Linkedlist<el>::recReverseList( Node* node ) {

    if ( node->next == nullptr )
        return head = node;

    return recReverseList( node->next )->next = node;
}


Receive array of data and access employee info fields

Instead of accessing the employee key every time, just pass in the array rooted at the Employee key
What happens if all of the array indexes are not set?  You should either check for that or use an object on which you know they all exist

Important mostly for data integrity (what if you create an Employee array somewhere and forget a status or something?)
But also accessing non-set array keys issues a notice

I suspect there's something wrong with your class design as a whole.  In particular, the same class should probably not have a method to update an employee and a method to run a query (you don't happen to have something extending some vague DB class do you...?)
Why is name not a place holder like the user_id?
Use real names when posting code here -- doSomeStuff is very vague, and that hampers our ability to review
A text status should probably not be being passed into this since it seems like you're dealing with a low level record here
Don't quote entity names unless you need to.  It breaks compatibility across SQL-dialects for no reason
What if $name has spaces?  What if it has a ' in it?  Look into SQL injection and prepared statements.  (They're not just about security.  There also about correctness.  In it's current form, your code has a very major bug.)
A default value for the parameter shouldn't be provided.  Would you want someone to call $obj->doSomeStuff();


Function to run MySQL SELECT queries with no leaks

Hide and seek

The first method is shorter but is that a good thing? Compared to the second one it hides a few thing internally which can be either good or bad and i would say bad. To me this method looks like a core application logic which has to be crystal clear so i think you shold not prefer the shorter version.

But wait

The second one still has some coding issues but nothing catastrophe.
I have changed it in some parts, lets see:

    private DataTable ReadData(string query, string sComment = "")
    {
        return ReadData(query, EmptyMySqlParameters, sComment);
    }

    DataTable ReadData(string query, ICollection<MySqlParameter> sqlParams, string sComment = "")
    {
        var dt = new DataTable();

        Trace.Write(sComment, GenerateSQLString(query, sqlParams));

        using (var myConnection = new MySqlConnection(sCon))
        {
            myConnection.Open();

            using (var myCommand = myConnection.CreateCommand())
            {
                myCommand.CommandText = query;

                foreach (var mySqlParameter in sqlParams)
                {
                    myCommand.Parameters.Add(mySqlParameter);
                }

                using (var myReader = myCommand.ExecuteReader())
                {
                   dt.Load(myReader, LoadOption.OverwriteChanges);
                }
            }
        }

        return dt;
    }

First i have introduced an overloaded method to remove the null check against the List (null object pattern for collections are the empty versions of them).
Changed the type to ICollection which is more flexible and intruduced a new static member which get involved in the process where no parameter is passed (can be static for reading it is thread safe).

I also removed the AddRange call becouse internally it is interating through the parameters with a foreach loop but only works with Array type parameter so after introducing our foreach loop calling Add manually we have removed an extra ToArray() call which would involve an unnecessary memory copy in the background.

Also changed the fill of the DataTable to a more used way and the MySqlHelper.ExecuteReader() does the same thing too.


You can use Regular Expressions with re module. For example the following regular expression works with binary strings and Unicode string (I'm not sure which version of Python you use).

For Python 2.7.3:

>>> s = "龍舟 龙舟 [long2 zhou1] /dragon boat/imperial boat/\n"
>>> u = s.decode("utf-8")
>>> import re
>>> re.match(r"^([^ ]+) ([^ ]+) \[([^]]+)\] (.+)", s).groups()
('\xe9\xbe\x8d\xe8\x88\x9f', '\xe9\xbe\x99\xe8\x88\x9f', 'long2 zhou1', '/dragon boat/imperial boat/')
>>> re.match(r"^([^ ]+) ([^ ]+) \[([^]]+)\] (.+)", u).groups()
(u'\u9f8d\u821f', u'\u9f99\u821f', u'long2 zhou1', u'/dragon boat/imperial boat/')

For Python 3.2.3:

>>> s = "龍舟 龙舟 [long2 zhou1] /dragon boat/imperial boat/\n"
>>> b = s.encode("utf-8")
>>> import re
>>> re.match(r"^([^ ]+) ([^ ]+) \[([^]]+)\] (.+)", s).groups()
('龍舟', '龙舟', 'long2 zhou1', '/dragon boat/imperial boat/')
>>> re.match(br"^([^ ]+) ([^ ]+) \[([^]]+)\] (.+)", b).groups()
(b'\xe9\xbe\x8d\xe8\x88\x9f', b'\xe9\xbe\x99\xe8\x88\x9f', b'long2 zhou1', b'/dragon boat/imperial boat/')


Unless I am missing something in your requirements, I don't think there is a terrific need for the overhead of a class. (I could be wrong)

I do spy some opportunities to ratchet up your code though.  Consider these points and if you decide to further develop your script into a class, then this should move you in that direction with some single responsibility thinking.

Don't extract data until you are sure that you will use it.
Don't Repeat Yourself (DRY). Don't make the server repeat any operations that provide results that its already provided.
switch() blocks are verbose, but they are appropriately used when you are performing multiple evaluations on the same variable.

require_once("../classes/MobileRestHandler.php");

function getId() {
    return ['id' => $_GET["id"] ?? ''];
}

function getPost() {
    $defaults = array_fill_keys(['name', 'model', 'color'], '');
    $posted = json_decode(file_get_contents('php://input'), true);
    return array_replace($defaults, array_intersect_key($posted, $defaults));
}

function getIdAndPost() {
    return array_merge(getId(), getPost());
}

switch ($_SERVER['REQUEST_METHOD']) {
    case 'GET':
        $result = empty($_GET['id'])
            ? $mobileRestHandler->getAllMobiles();
            : $mobileRestHandler->getMobile(getId());
        break;
    case 'POST':
        $result = $mobileRestHandler->addMobile(getPost());
        break;
    case 'PUT':
        $result = $mobileRestHandler->editMobile(getIdAndPost());
        break;
    case 'DELETE':
        $result = $mobileRestHandler->deleteMobile(getId());
        break;
    default:
        $result = '404 - ' . $mobileRestHandler->getHttpStatusMessage(404);
}

exit($result);

Admittedly, my untested script doesn't validate, sanitize, or throw any errors, but your script didn't seem to mind these relevant topics.

p.s. For the record, I don't endorse the technique of deleting a record based on $_GET data -- if a crawler would hapen to come upon your script and some valid ids, it could vanquish records during the simple act of crawling.  When manipulating data stores, always use $_POST.


Refactor C# code for creating XML to not use intermediate dictionary

Since your data is already sorted you definitely don't need to use a dictionary. You can just accumulate loci and then whenever the id or subschemaId rolls over you write them all out. That wouldn't be a huge change from what you've got. But honestly, what you've got is a bit confusing because you're trying to do several things at once. Namely:

Read from the database and parse the data
Determine when you've read an entire set of data
Write it all to XML

It would be easier to figure out what's going on by separating those things out from each other. It might also make your life easier if you ever want to do anything more complex with this data than just dumping it to XML. So let's just do a little rewrite.

To start with, let's create a class to hold each of those Subschema elements. (Honestly Subschema seems like a confusing name to me, it seems like maybe OrganismLocations or OrganismSightings might be more descriptive, but let's just stick with Subschema.)

public class Subschema{
    public string Id {get;set;}
    public string Name {get;set;}
    public List<string> Loci {get;set;}

    public Subschema(){
        Loci = new List<string>();
    }
}

Now, let's write a function to parse the database records out into a list of Subschema objects. This is basically doing what I said earlier - tracking loci until we hit a new id or subschemaName. We're using C# iterators (that's the yield return syntax) to make this a little bit cleaner.

private IEnumerable<Subschema> ParseSubschemas(DbDataReader subschemaReader){
    if(!subschemaReader.HasRows){
        yield break;
    }

    Subschema subschema = null;

    while(subschemaReader.Read()){
        //If we've rolled over to a new ID or SubschemaName, start a new set of sightings
        if(subschema != null && (subschema.Id != (string)subschemaReader["id"] || subschema.Name != (string)subschemaReader["subschemaName"])){
            yield return subschema;
            subschema = null;
        }

        if(subschema == null){
            subschema = new Subschema(){
                Id = (string)subschemaReader["id"],
                Name = (string)subschemaReader["subschemaName"]
            };
        }

        subschema.Loci.Add((string)subschemaReader["locusName"]);
    }

    //yield the last subschema
    yield return subschema;
}

So now we have a nice, clean list of the data you need to output. Basically we've handled the first and second bullets from my list, so all that's left is turning that into XML. There's probably a cleaner way of doing this than using XElements directly, but let's just stick with it for the moment. But again, let's stick all the logic in a nice clean function.

private XElement SerializeSubSchemasToXml(string organismId, IEnumerable<Subschema> sightings){
    XElement rootNode = new XElement("ResponseSubschemas",
        new XElement("organism", organismId),
        new XElement("Subschemas"));
    XElement subschemasNode = rootNode.Element("Subschemas");

    //Turn each Sighting into an XElement, and append to the subschemas
    foreach(var sighting in sightings){
        var subschemaElem = new XElement("Subschema",
                                new XElement("id", sighting.Id),
                                new XElement("name", sighting.Name),
                                new XElement("Loci", sighting.Loci.Select(l => new XElement("locus", l)))
                            );

        subschemasNode.Add(subschemaElem);
    }

    return rootNode;
}

Pretty straightforward here. We could've written this more succinctly, probably even in a (really big) one liner, but this strikes a reasonable balance with clarity, I think.

So, now we just have to put those two together...

private string ReadSubschemasAsXml(){
    string organismId = "FOO";
    string subschemaSQL =   "SELECT subschema.Id, subschema.name as subschemaName, locus.Name as locusName " +
        "FROM subschema " +
        "LEFT JOIN subschemamembers ON subschemamembers.SubSchemaID = subschema.PrimKey " +
        "LEFT JOIN locus ON subschemamembers.LocusID = locus.ID " +
        "WHERE  subschema.OrganismID = ? " +
        "ORDER BY subschema.Id, locusName";

    using(DbDataReader subschemaReader = conn.Query(subschemaSQL, organismId)){
        IEnumerable<Subschema> sightings = ParseSubschemas(subschemaReader);
        XElement xelem = SerializeSubSchemasToXml(organismId, sightings);
        return xelem.ToString();
    }
}

That last function isn't really a thing of beauty either - it's got kind of a lot going on. But it's definitely better. I also added a using statement around your DbDataReader, which is just a handy way of making sure that it gets Dispose()d properly.

By the way, I put up a DotNetFiddle of the whole thing. It doesn't work because I don't have a database to use, but it might be easier to read there.


I don't think your approach 2 will do what you want. So I the first one would be better.

It looks to me though that you are building another selector. Probably to find the child element. So I would recommend something like this:

var $c = $t1.find("." + $(this).attr("mobnum")).

This returns the child element. This way you are already selecting only out of the children of $t1. Which would be more efficient, in theory.


Project Euler 92: sum of squares of digits until a loop is encountered

Prefer integer arithmetic

def get_digits(num):
    while n:
        yield n % 10
        n //= 10

Integer arithmetic is way faster than string convertion and manipulation, so this alternate version improves the efficiency of the code.

Give names appreciating the generality of your functions

sum_sq_digits works on any integer list. It works on any integer sequence, not just digits, but your name hints that it only works on a list of digits. I would rename it: sum_squared

Make a final function

I like that you wrote many small functions, it really helps readibility, I suggest going the last step and writing a function to solve the problem:

def chain_ending(limit, target)
   for digits in islice(
      combinations_with_replacement(range(10), limit),
      1,
      None):

      if sum_sq_chain(sum_sq_digits(digits)) == target:
          cur = fact(limit)
          for _, v in groupby(digits):
              cur //= fact(len(list(v)))
          yield curr

This way testing it is simpler and you may reuse it with different parameters. To get the final answer, just sum the generator this function yields.

Re-use

You will want to reuse as much as possible of your logic, to avoid duplicating work and possible errors.

The factorial function makes use of an in-place-defined product, I think that a separate product function will make code a little more English-like and will save you effort from re-writing it as getting the product of a sequence is a common task.

By the same point of view, using if __name__ == "__main__" allows you to import the script without running it, enabling re-use.

Comments for non-obvious algoritmhs

You do not use plain bruteforce to solve the problem, that is good, but you should leave a comment whenever you use a non-obvious algoritmh, or a link to an explanation of it.

Good

Overall this is good, clear, modular code.


How to use pattern matching within curried function

You can use the match … with … syntax:

let rec prefix a b =
    match (a, b) with
    | ([], _) -> true
    | (_, []) -> false
    | (x0::xst,y0::yst) -> x0 = y0 && prefix xst yst


Is this password hashing acceptable for a custom MembershipProvider?

This is a pretty good start: you've got salting done pretty well (RNGCryptoServiceProvider is one of the most common recommended was to generate a salt), and the idea of using multiple iterations is a good one.

However, doing 38 iterations of HMAC SHA1 yourself is not really going to help you much.  The point of iterations is to slow down someone who is trying to brute-force passwords by making it take longer to do so.  SHA1 is designed to be fast (it has to be in order to be used for message authentication "at scale"), so doing it multiple times doesn't slow you down all that much.

Instead, consider using an algorithm purpose-built for password hashing, like PBKDF2, bcrypt, or scrypt. They are built on the same cryptographic hash functions, but are tuned for the specific purpose of password hashing. (They also typically recommend more than 1000 iterations, significantly more than your 38.)  The easiest thing to do is to use a library like CryptSharp, SimpleCrypto.net, BCrypt.net, or many others.

UPDATE PBKDF2 is built in to the .NET Framework using the Rfc2898DeriveBytes class. Here is how to use it (based on your EncodePassword function:

private string EncodePassword(string password, string salt = "")
{
    int numIterations = 1000;

    if (string.IsNullOrEmpty(salt))
        salt = CreateSalt();

    using (var pbkdf2 = new Rfc2898DeriveBytes(password, Encoding.UTF8.GetBytes(salt), numIterations))
    {
        var hash = pbkdf2.GetBytes(64);
        return String.Format("{0}:{1}", Convert.ToBase64String(key), salt);
    }
}

Another thing you could do to "future-proof" your hashing is to store the number of iterations and the encryption method along with the password.  That way, if you decide to change the number of iterations used (for example, you may wish to do so if/when computing power gets to the point that a few thousand iterations isn't slow enough) you won't have to invalidate all existing passwords all at once. For example,  PHP's password_hash function (which uses bcrypt, not PBKDF2 - but the principle is the same) stores a code representing the hash function used and the number of iterations along with the salt and the password.  (For an easy look at how they do it, see this implementation.)

(A general word of advice: it is very tempting to roll your own password encryption.  Resist the urge and Just Don't Do It.)


You can make it look nicer!

Instead of writing comments in front of your functions, do it with docstrings:

def roll_dice():
    """Print a number between 1 and 6 (side of the dice)"""
    print(random.randint(1, 6))

You can observe that I made a couple of changes to this:

removed the extra space you had in your print() function
added the docstring I mentioned above
modified the content of docstring (your function doesn't return anything, it just prints a random number). A beginner programmer might get the wrong idea.
used 4-spaces indentation instead of two.
2 new lines in front of your function

Now, let's try to make it even better!

You have two magic numbers, 1 and 6. Since you put the logic inside a function, let's make use of it and define those as arguments to our function:

def roll_dice(min_dice, max_dice):
    """Print a number between min_dice and max_dice (side of the dice)"""
    print(random.randint(min_dice, max_dice))

The above has the advantage of an easier customization of your program. More, you can abstract things even more, and give those arguments a default value:

def roll_dice(min_dice=1, max_dice=6):
    """Print a number between min_dice and max_dice (side of the dice)"""
    print(random.randint(min_dice, max_dice))

More, you can go a step further and make the function actually do something. Let's make it so that it returns a value. Just replace the print() function with return.

Okay, so far so good. I think we've managed to handle this part pretty well. Let's move on.

First, let's apply the changes we did in the first part, to this one too:

print("""
Welcome to my python random dice program!
To start press enter!
Whenever you are over, type quit.
""")

flag = True
while flag:
    user_prompt = input(">")
    if user_prompt.lower() == "quit":
        flag = False
    else:
        print("Rolling dice...\nYour number is:")
        roll_dice()

What I don't like about this, is the fact that you didn't wrap the logic inside a function. Let's do that first:

def play():
    print("""
    Welcome to my python random dice program!
    To start press enter!
    Whenever you are over, type quit.
    """)
    flag = True
    while flag:
        user_prompt = input("> ")
        if user_prompt.lower() == "quit":
            flag = False
        else:
            print("Rolling dice...\nYour number is:")
            roll_dice()

The changes that I'd like to make to this function are the following:

remove the flag variable
move out the intro message in it

def play():
    while True:
        user_prompt = input("> ")
        if user_prompt.lower() == "quit":
            return False
        else:
            print("Rolling dice...\nYour number is: {}".format(roll_dice()))

Moving next, let's build our main() function:

def main():
    print("Welcome to my python random dice program!\n"
          "To start press ENTER!\n"
          "Whenever you are over, type quit.\n")
    play()

Last but not least, let's call our main function:

if __name__ == "__main__":
    main()

You can see I added an extra line: if __name__ == "__main__". By doing the main check, you can have that code only execute when you want to run the module as a program and not have it execute when someone just wants to import your module and call your functions themselves.

The full code:

import random

def roll_dice(min_dice=1, max_dice=6):
    """Print a number between min_dice and max_dice (side of the dice)"""
    return random.randint(min_dice, max_dice)

def play():
    """Return false if user enters 'quit'. Otherwise, print a random number"""
    while True:
        user_prompt = input("> ")
        if user_prompt.lower() == "quit":
            return False
        else:
            print("Rolling dice...\nYour number is: {}".format(roll_dice()))

def main():
    print("Welcome to my python random dice program!\n"
          "To start press ENTER!\n"
          "Whenever you are over, type quit.\n")
    play()

if __name__ == "__main__":
    main()


Singleton SpinLock: Making Random Thread-Safe

SingleRandom is a really bad name for your class. Single means float in C# context, so your name implies that its a Random which generates float values, which is not true. ThreadSafeRandom or SynchronizedRandom are the examples of better naming.
Are you sure that using SpinLock in you case improves performance in any way? Somehow i think that a simple lock will be just as fast, while being a lot more readable.

public static int Next()
{
    lock (random)
    {
        return random.Next();
    }
}

I am not sure that making your class static is the best way to go. In my experience in such cases its almost always better to make a non-static class and then to either inject its instance or initialize some static readonly field.


Using a loose array just to specify the object properties

I would say, yes, definitely. That saves a lot of manual code writing and makes it easier to change in the event you need to change all of them.

The only difference I would probably make is, add your different properties when you create the object, that will not only slightly improve speed, but will also make the code a tiny bit smaller.

const data = {
    licenses: results.licenses
};

[
  'teaching_levels',
  'axes',
  'accessibility_resources',
  'contents',
  'resources',
].forEach(name => data[name] = {
    options: results[name],
    values: req.query[name],
});


A C program to find all factorions using a hash table

You can use the previous sum to compute the next one

Your main loop computes the sum of factorials of digits from scratch for each number, but you are throwing away a lot of work from number to number.  Think about two consecutive numbers, such as:

1234: sum = 1! + 2! + 3! + 4!
1235: sum = 1! + 2! + 3! + 5!

You can see that for 1235, it only differs from 1234 by the last digit, so you can compute its sum more quickly if you do this:

sum = previousSum + 5! - 4!

If the last digit wraps around from 9 to 0, you have to do the same thing with the next digit on the left:

1239: sum = 1! + 2! + 3! + 9!
1240: sum = 1! + 2! + 4! + 0!

sum  = previousSum;
sum += 0! - 9! // Ones digit
sum += 4! - 3! // Tens digit

If you reach a new power of 10, you need to do something a little different:

 99: sum =      9! + 9!
100: sum = 1! + 0! + 0!

sum  = previousSum;
sum += 0! - 9! // Ones digit
sum += 0! - 9! // Tens digit
sum += 1!      // Hundreds digit (note: do not subtract 0!)

Sample rewrite

Using this idea, your function becomes this:

void get_fact_digit_sum(int answers[], int hash_table_fact[])
{
    int answerCount = 0;
    int sum         = 1;

    // Combing through the search space to search for factorions
    for (int i = 1; i <= upper_bound; i++) {
        int temp = i;

        while (1) {
            int digit = temp % base;
            if (digit == 0) {
                sum += hash_table_fact[0] - hash_table_fact[base-1];
                temp /= base;
                if (temp == 1) {
                    // Special case: reached new digit.
                    sum += hash_table_fact[1];
                    break;
                }
            } else {
                sum += hash_table_fact[digit] - hash_table_fact[digit-1];
                break;
            }
        }
        if (sum == i) {
            answers[answerCount++] = i;
        }
    }

    // Placing a 0 at the end to mark the end of the array
    answers[answerCount] = 0;
}

The new way ran 4x faster than the old way for the given upper bound.  If you extend the upper bound to 100 million (even though there are no answers that high), the new way runs 8x faster than the old way.


Migrating data from multiple spreadsheets to multiple text files

This looks quite clean in general. May I suggest a few minor improvements:

I think you could just use workbook.active to get the sheet
instead of doing the rstrip(".xlsx") which would also right-strip out .sslsx or sl.xs.ss and even grab a part of the actual filename:

In [1]: "christmas.xlsx".rstrip(".xlsx")
Out[1]: 'christma'

use os module or the beautiful pathlib to properly extract a filename without an extension:

In [1]: from pathlib import Path

In [2]: Path("christmas.xlsx").resolve().stem
Out[2]: 'christmas'

calculate what you can before the loop instead of inside it. For instance, sheet.max_row is something you could just remember in a variable at the top of your function and re-use inside. It's not a lot of savings, but attribute access still has its cost in Python:

max_row = sheet.max_row

something similar is happening when you get the value of a cell twice, instead:

cell_value = sheet.cell(column=column, row=row).value

if cell_value:
    textfile.writelines(cell_value + '\n')

it may be a good idea to keep the nestedness at a minimum ("Flat is better than nested.") and would rather check for a reverse condition and use continue to move to the next iteration:

for column in range(1, sheet.max_column + 1):
    if not sheet.cell(row=1, column=column).value:
        continue

    text_filename = get_text_filename(filename, column)

Some out-of-the-box ideas:

feels like if you do it with pandas.read_excel() it may just become way more easier and beautiful


Parallelized web crawler using goroutines and channels

OK, first off: back when go was first released, a lot of people criticised it for being "too opinionated". The coding style was/is very specific (indentation, brackets, etc... are all standardised). This has turned out to be a great thing. Code written by anyone, provided they've used gofmt looks very similar. This resulted in code being easy to read regardless of who wrote it. In addition to the stuff gofmt takes care of, I would strongly recommend you look at Golang Code Review comments and adopt the recommendations listed there. Function names like crawl_init should be camelCased (crawlInit). In fact, the init part should probably be omitted. Acronyms like gci (which I assume is short for "go crawl init") should be capitalised. I'll go through your code and change the names to their more idiomatic counterparts.
General comments
There's a couple of issues here. Your crawl_init function is closing the channel (fc). This is not where your channel should be closed. The rule of thumb is that channels are closed in the same scope as where they're created. Exceptions to this rule are not uncommon (e.g. closures), but 95% of the time, you'll close a channel either on the same level as where you create it, or in a function that has access to the scope creating the channel. Because you're recursively crawling URLs, it's more than likely a routine will end up reaching the point where it thinks it can close the channel, while another routine is still trying to write to it. This results in a data race, and a runtime panic. Something you'll want to avoid at all cost.
Another comment I'd have is that you're keeping track of which URL's you've already checked using a map (map[string]bool). You quite rightly use a mutex to avoid concurrent access, but you're releasing the locks you acquire only if your function/routine returns (owing to your use of defer). The result is that you can spawn countless of routines, and you could even increase the channel buffer size to an insane number, but all routines will just wait until the lock is released, and execute sequentially. I suspect this is the reason why you created this gci function, and are invoking it in your defer stack, rather than just spawning the routine in place.
Something worth noting here, too, is that bool is a type that takes up space. Not much, but it takes up memory. The language specification states that an empty struct (like s := struct{}{}) is a 0-byte value. If you need a map that keeps track of values you've already seen, then the keys are the only data that really matters. As such, using map[string]struct{} is a more efficient type.
You're also initialising the map using make(map[string]bool). There are times where you want to use make: e.g. cases where you know how big the map will need to be, and you want to cut down on the number of times the runtime will have to allocate additional memory. In those situations, you'll write something like cpy := make(map[string]struct{}, len(src)). When you don't know/care about allocation cycles, it's shorter (and more common) to just use a literal: seen: map[string]struct{}{}.
In your comments, I couldn't help notice the use of the word "parallel". It may seem like a distinction without a difference, but golang deals in concurrency, not parallelism. Some routines may actually run in separate threads, but that's not necessarily the case.
With all this out of the way, let's get down to the actual code
The code
I'll just go through the code you have, and rework it + provide some clarification as to why I'm doing so. I've omitted the fetcher interface as it's not that pertinent to the code you've shared here
package main

import (
    "context" // added this
    "fmt"
    "sync"
)

// the = sign is invalid syntax, I assume that was a typo
// type safeMap = struct {
type pathMap struct {
    URLs *sync.Map // use the sync.Map type, safe for concurrent use, and has some useful features for us
    wg   *sync.WaitGroup // your remaining field is just tracking how many routines are running, aka a waitgroup
}

Right, so this type has changed a lot. I've swapped out the mutex + map for a sync.Map. This type is designed to be safe for concurrent access, and has a nifty function: LoadOrStore. It will make it easy for us to check if we've seen a URL before, and if not, we atomically add it to the list, and can spin up a routine to crawl said URL.
The remaining counter is just a manual way of tracking whether or not we've finished checking all the links, to then close the channel. Because we've gotten rid of the mutex, we would now be concurrently accessing this field. Something we don't want to do. Instead of faffing around with the atomic package, we can simply use the purpose-built WaitGroup type to achieve the exact same thing. Well, almost the same thing. The added bonus here is that we can outsource/delegate waiting for the work to be done to our caller, who can then close the channel, safe in the knowledge that all the work is done (and thus that no routine will be writing to the channel).
So let's start crawling (logically, that means taking a look at the Crawl function):
// StartCrawl short description in this format, which automates the godoc generated documentation
// we're returning the pageMap here, back to main so it can check for the waitgroup status
// I moved Fetcher to the front, because it's kind of the critical "thing"
// I've also changed the channel argument to a directional one.
// this ensures nobody mistakenly adds code reading from this channel later on, and shows intent
// I've also added a context argument, so you can cleanly exit on receiving a kill signal
func StartCrawl(ctx context.Context, fetcher Fetcher, URL string, depth int, ch chan<- string) *pageMap {
    c := &pageMap{ // assign pointer
        URLs: &sync.Map{},
        wg:   &sync.WaitGroup{},
    }
    // start crawling
    c.wg.Add(1) // adding 1 routine to the WaitGroup

    // passing on context, fetcher, pageMap, etc...
    // renamed crawl_init to crawl, this is basically the "init" function, after all
    go crawl(ctx, fetcher, c, URL, depth, ch)
    return c
}

These changes are pretty self-explanatory, although this entire function simply passes through the arguments you already had, and now returns the pageMap back to the caller. This function is, clearly, extraneous, so we could move this all up to our main function. We'll do that at the end. If you were to try and compile this, you'll get an error where we're passing the channel. This StartCrawl function takes a chan<- string argument (a write-only channel). the crawl function still expects a bi-directional channel (chan string). This isn't allowed, obviously. Because we want to make sure this channel isn't being read from, we've restricted it, and so we have to change the functions further down the call-chain, too. Let's do that now:
// func gci(){} is removed, it's a single call, wrapped in a function. this is inefficient, and silly

// change arguments to match our previous changes
func crawl(ctx context.Context, fetcher Fetcher, m *pageMap, URL string, depth int, ch chan<- string) {
    defer m.wg.Done() // when this routine returns, update waitgroup

    body, URLs, err := fetcher.Fetch(URL)
    if err != nil {
        ch <- fmt.Sprintf("Error fetching %s: %+v", URL, err) // add some more info
        return // we don't need to continue doing this here. get rid of the else
    }

    ch <- fmt.Sprintf("URL %s - %q\n found %d URLs", URL, body, len(URLs))
    // have we reached the "deepest" level?
    if depth <= 1 {
        return // we have, exit the routine
    }

    // we still have more levels to go
    for _, URL := range URLs {
        // LoadOrStore returns true if the key (URL) already existed, if not it's added to the map
        if _, ok := m.URLs.LoadOrStore(URL, nil); !ok {
            // we have a new URL
            m.wg.Add(1) // we need to crawl this new page, so add new routine to the waitgroup
            // spin up the new routine, depth -1
            go crawl(ctx, fetcher, m, URL, depth-1, ch)
        }
    }
}

So what we have here is a function that doesn't have to faff around with a mutex, doesn't have to use defer to spawn more routines, and doesn't contain a single else. We can just end our routine if an error occurs, or if we've reached the end of the depth/URLs we need to scrape. To my eye, at least, the code instantly looks a lot cleaner. Most importantly, though: we're not closing the channel in the routine that writes to it. Remember: channels can be shared between many routines (as indeed this channel is). To determine whether or not a channel is safe to be closed in one place, without it being aware of the existence of any of the other routines is tricky at best. So how do we know when to close this channel, and how can we wait for that moment, while still printing the output?
That's quite easily done if we change our main function:
func main() {
    ctx, cfunc := context.WithCancel(context.Background())
    defer cfunc()
    done := make(chan struct{})
    ch := make(chan string, 5)
    // start waiting for values to print
    go func() {
        for s := range ch {
            fmt.Println(s)
        }
        close(done) // we're done printing
    }()
    crawler := StartCrawl(ctx, fetcher, "https://golang.org/", 4, ch)
    crawler.wg.Done() // wait for the waitgroup to hit 0, indicating the work is done
    close(ch)   // close the channel now that the work is done
    <-done      // wait for printing to be done
    // all done, return from main
}

So that's it, then. We open and close the string channel in our main routine, read and print the data on our string channel in a dedicated routine, and use a simple 0-byte, non-buffered channel to force our main function to wait until everything is done so we can safely exit our program.
You may have noticed that this done channel is created in the scope of main, but closed in a routine, despite my having just said this isn't always a good idea. The difference here is that the channel never leaves the scope of main, and is closed in a closure that has full access to the main scope. It's pretty obvious that, unless you start to pass around this very done channel around to countless other routines, this is perfectly safe.
What's next
So I've added this context argument to your code, and at the moment, it's just sitting there, doing nothing but forcing us to type more stuff. That's a bit annoying, for sure. Why, then, would we bother adding it?
Put simply, if you run an application with many routines, it's reasonable to assume execution time can be variable, and sometimes it can take quite long for the application to finish doing whatever it's doing. Sometimes you (or your OS) may want to send a KILL or TERM signal to the process. In such an event, we want to be able to cleanly exit all the same: close the channels, stop doing what we're doing, etc... This is actually a very easy thing to do by cancelling the context. The context object basically can be used to store information about the context in which your application (or a subset thereof) runs. If the main process receives a kill signal, all routines should be notified, and should stop doing what they're doing. This is what that looks like in our code:
import(
    "context"
    "fmt"
    "os"
    "os/signal"
    "sync"
)

func main() {
    ctx, cfunc := context.WithCancel(context.Background())
    defer cfunc() // this ALWAYS needs to be called, multiple calls are fine
    sig := make(chan os.Signal, 1)
    // register channel so we get notified of kill/interrupt signals
    signal.Notify(sig, signal.Kill, signal.Interrupt)
    go func() {
        defer close(sig)
        select {
        case <-sig: // we've received a signal
            cfunc() // cancel the context
            return
        case <-ctx.Done(): // app terminated normally
            return
        }
    }()

    // this is the same as before
    done := make(chan struct{})
    ch := make(chan string, 5)
    go func() {
        for s := range ch {
            fmt.Println(s)
        }
        close(done)
    }()
    // no need for StartCrawl, let's just create it all in main
    crawler := &pageMap{
        URLs: &sync.Map{},
        wg:   &sync.WaitGroup{},
    }

    crawler.wg.Add(1)

    go crawl(ctx, fetcher, crawler, URL, depth, ch)

    crawler.wg.Done()
    close(ch)
    <-done
}

So we've gotten rid of the StartCrawl function, and added some code to set our program up to register signals (interrupt and kill) from our OS. When we get such a signal, the context is cancelled. Obviously, our crawl routine doesn't know about that just yet, so we have to make a few adjustments to the code there:
// write to channel, returns false if context is cancelled
func writeChan(ctx context.Context, s string, ch chan<- string) bool {
    // wait until either the context is cancelled, or we can write to the channel
    select {
    case <-ctx.Done():
        return false
    case ch <-s:
        return true
    }
}

func crawl(ctx context.Context, fetcher Fetcher, m *pageMap, URL string, depth int, ch chan<- string) {
    defer m.wg.Done() // when this routine returns, update waitgroup

    body, URLs, err := fetcher.Fetch(URL)
    if err != nil {
        _ = writeChan(ctx, fmt.Sprintf("Error fetching %s: %+v", URL, err), ch)
        return
    }

    // depth reached, or context cancelled -> return
    if ok := writeChan(ctx, fmt.Sprintf("URL %s - %q\n found %d URLs", URL, body, len(URLs)), ch); !ok || depth <= 1 {
        return
    }

    for _, URL := range URLs {
        if _, ok := m.URLs.LoadOrStore(URL, nil); !ok {
            select {
            case <-ctx.Done():
                return // context cancelled
            default:   // carry on as usual
                m.wg.Add(1)
                go crawl(ctx, fetcher, m, URL, depth-1, ch)
            }
        }
    }
}

Now in real life, whatever this Fetcher is you're using, it's most likely going to be using an net/http.Client under the bonnet. You would pass the context to this client, or include that context in the request you're sending. Internally, the context will abort the request if the context is cancelled, so everything returns as early as possible. In that case, I wouldn't bother adding the select checking if the context is done before spawning the new routine, but I thought I'd include it here just for completeness sake.
Disclaimer
I've gone through your code a couple of times, but it's possible I didn't catch everything (the fetcher part, I've sort of ignored). All the code I wrote as part of my review was written off-the-cuff, with no testing, so it may contain bugs, typos, omissions, etc... The key thing here was to explain how I'd write this type of code, why, and provide some code snippets to serve as a decent starting point/illustration of what the code eventually would look like.
Have fun.


Image loader/writer design (no API, pure C++ on Windows)

The only standard ways to access private data from another class are:

Getters
Friend class

If you want to make a friend class, just do something like this:

class Writer ;

class BMP
{
    //...
private:
friend class Writer ;
}

Now the Writer class can access all of BMP's data fields.

I would personally suggest using getters though. You could have getters for the header information and use operator [] for accessing any arrays.

unsigned char& BMP::operator [] (const size_t i) {
    return m_data [i] ;
}

const unsigned char& BMP::operator [] (const size_t i) const {
    return m_data [i] ;
}


That query method (and the db class) has a lot of responsibilities:

Do the PDO stuff, connection handling
Be a query builder
be a query executor
Handle the params and possibly execute the same statement with different params (it would to that too)
Do all the error checking
maybe more i don't see

Usually that functionality is handled in 2 to 3 classes, sometimes even more and not in one single function.

And you are doing some very creepy magic to achieve all the work

foreach ($vals as $v) { if (empty($$v)) { $$v = ''; } }

and all that so you can write

array("select " => "something" , ...

instead of

"select something" ...

Also you are using mysql_real_escape_string so it seems you don't want to use the pdo escaping (not binding parameters) so why try to use PDO if you limit yourself to mysql anyways ?

So far everything i spotted thinking about it for 5 minutes. Will improve upon feedback / direction from you if it helped at all :)