godmar

"""
From: http://www.xs4all.nl/~rjoris/maximummatching.html
"""

"""Weighted maximum matching in general graphs.

The algorithm is taken from "Efficient Algorithms for Finding Maximum
Matching in Graphs" by Zvi Galil, ACM Computing Surveys, 1986.
It is based on the "blossom" method for finding augmenting paths and
the "primal-dual" method for finding a matching of maximum weight, both

godmar

# @author godmar

from math import sqrt, ceil

n = int(raw_input())
a = map(int, raw_input().split())
sn = int(ceil(sqrt(n)))
buckets = [set(a[sn*i:sn*(i+1)]) for i in range(n/sn)]

q = int(raw_input())

godmar

/*
 * Can we really implement anything, no matter how inefficient, and have it pass
 * just because it's frigging C++???
 */
#include <bits/stdc++.h>
using namespace std;

int
main()
{

godmar

n = int(raw_input())
nums = list(map(int, raw_input().split()))

q = int(raw_input())
for _ in xrange(q):
    line = list(map(int, raw_input().split()))
    idx = line[0]
    numzz = set(line[2:])

    lo, hi, count = idx-1, n, 0

godmar

/*
 * Can we really implement anything, no matter how inefficient, and have it pass
 * just because it's frigging C++???
 */
#include <bits/stdc++.h>
using namespace std;

class Node {
    int start, end;
    set<int> rset;

godmar

/*
 * Maximal sequence inspired by Eric's segment tree idea.
 * Using Hassan's original segment tree code implementation.
 * 
 * @author godmar
 */
import java.util.*;

public class MaximalSequence
{

godmar

/*
Kruskal can break early once the graph is connected in which case it doesn't have to process 
all edges. Thus, in cases like here, where the edges are dynamically ordered, not all edges
may need to be prepared. I tested this idea below. It cuts the runtime drastically for many 
of the test cases (and I verified that, many break after only a few percent of the edges). 
It doesn't cut worst case time because for some of the larger tests, the graph isn't 
connected until over 99% of the edges are considered. But, it also doesn't hurt. 
In fact, Kattis runtime was .1s faster than the eager, array-based version, so 
the use of the Iterator doesn't hurt.  Note that the solve() method could also be 
written to take an Iterator, which would avoid the somewhat random construction 

godmar

diff --git a/config/webpack.config.prod.js b/config/webpack.config.prod.js
index df6db14..6970253 100644
--- a/config/webpack.config.prod.js
+++ b/config/webpack.config.prod.js
@@ -43,6 +43,8 @@ if (env['process.env'].NODE_ENV !== '"production"') {
   throw new Error('Production builds must have NODE_ENV=production.');
 }
 
+console.log(`resolve path: ${paths.nodePaths}`)
+

godmar

$ tree node_modules/util node_modules/events
node_modules/util
├── LICENSE
├── node_modules
│   └── inherits
│       ├── inherits_browser.js
│       ├── inherits.js
│       ├── LICENSE
│       ├── package.json
│       ├── README.md

godmar

[email protected] /home/gback/fail-event-emitter2
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └─┬ [email protected]
│ │ │   ├─┬ [email protected]
│ │ │   │ └── [email protected]
│ │ │   └── [email protected]
│ │ └── [email protected]