axiak

We couldn’t find that file to show.

axiak

from typedispatch import *

@dispatch(regexmulti(r'(\d{3})\D{0,2}(\d{3})\D?(\d{4})'))
def phone_numbers(phone_numbers):
    for match in phone_numbers:
        print '-'.join(match.groups())


@dispatch()
def phone_numbers(text):

axiak

#!/usr/bin/perl
use strict;
use warnings;

my $x = [qr/([aieou]+)/io, qr/(\d+)/o]; #<- Here is a list of 2 regexes...
my $line = <STDIN>;

foreach my $regex (@{$x}) {
    if ($line =~ $regex) {
        print "a vowel or digit!\n";

axiak

#!/usr/bin/env python
"""
contactinfo.py is a simple script to get contact information from
Facebook.

To use, first install mechanize [1]. Then use the friendstocsv application [2]
on Facebook to export a csv file with all of your friends. Be sure
to include at least the profile URL.

Afterwards, edit this file to put your email, password, and user agent

axiak

// Newbie programmer
int factorial_newbie(int n) {
    if (n == 0) {
        return 1
    } else {
        return n * factorial_newbie(n - 1)
    }
}
println factorial_newbie(6)

axiak

import tempfile
import os
from subprocess import Popen, PIPE

# Prereqs:
# apt-get install html2ps ghostscript

def convert_to_pdf(html):
    " Convert some html to a pdf. "
    ps_process = Popen("html2ps", stdin=PIPE, stdout=PIPE, shell=True)

axiak

The way I envision any scheduling system to work is by (1) a brute force program generating a feasible but poor schedule subject to hard constraints and (2) some probabilistic algorithm(s) optimizing said poor schedule given a number of things to weigh in.

I've already written a quick brute force program [1]. The result is the attached file. Please look at the attached file, and consider why the schedule is so poor. In order for the schedule to get better, we need to figure out what makes a schedule good and what data we will need in order to measure that. Some of this is tricky since it's so intuitive.

I've written below a list of what I think are some pieces missing. Any text in square brackets ([....]) are data that I've identified we will likely need/use in order to implement the constraint.

FEASIBILITY PROGLEMS (aka hard constraints)

- For Splash, some timeslots only work with certain grade ranges. Timeslots don't know this. I'm not sure how we should encode this type of constraint, but we would need

axiak

The way I envision any scheduling system to work is by (1) a brute force program generating a feasible but poor schedule subject to hard constraints and (2) some probabilistic algorithm(s) optimizing said poor schedule given a number of things to weigh in.

I’ve already written a quick brute force program ¹. The result is the attached file. Please look at the attached file, and consider why the schedule is so poor. In order for the schedule to get better, we need to figure out what makes a schedule good and what data we will need in order to measure that. Some of this is tricky since it’s so intuitive.

I’ve written below a list of what I think are some pieces missing. Any text in square brackets ([….]) are data that I’ve identified we will likely need/use in order to implement the constraint.

FEASIBILITY PROBLEMS (aka hard constraints)

- For Splash, some timeslots only work with certain grade ranges. Timeslots don’t know this. I’m not sure how we should encode this type of constraint, but we would need

axiak

sealed abstract class Token[T <: Ordered[T]](location: T) extends Ordered[Token[T]] {
  override def compare(other: Token[T]): Int = {
    location compare other.location()
  }
  def location(): T = location
}
case class Start[T <: Ordered[T]](loc: T) extends Token[T](loc)
case class End[T <: Ordered[T]](loc: T) extends Token[T](loc)

axiak

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
		  http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
           version="2.5">
</web-app>