- Avoid cargo, it it may seem tempting, but you'll just keep running into untested code paths and design flaws; it's not meant to do it.
- Using a target specification to describe your platform is recommended, and you'll likely need one for one reason or another anyways (example: https://github.com/hackndev/zinc/blob/master/thumbv6-none-eabi.json ). Pass it to rustc via --target=target.json
- You wan work without the standard library, by following those instructions: https://doc.rust-lang.org/book/no-stdlib.html
- Inline assembly (asm!) blocks are fed directly into LLVM and have horrible error checking, tread lightly and verify the output.
- LLVM can end up generating dodgy versions of certain instructions on certain versions, it may for example turn "lgdt" into the utterly useless 16-bit version (which truncates the upper 8 bits of the address). Specify operand sizes.
- An "intel" option is supported, but it seems to be somewhat dodgy (for example, it seemed to d
require 'guard/guard' | |
# | |
# Based on the guard-handlebars gem, which uses the following license: | |
# | |
# Copyright (C) 2012 by Chris Homer | |
# | |
# Permission is hereby granted, free of charge, to any person obtaining a copy | |
# of this software and associated documentation files (the "Software"), to deal | |
# in the Software without restriction, including without limitation the rights |
Compiling mozjs_sys v0.0.0 (https://github.com/servo/mozjs#2af5849a)
error: failed to run custom build command for `mozjs_sys v0.0.0 (https://github.com/servo/mozjs#2af5849a)`
Process didn't exit successfully: `V:/3rd-party/servo-clean/target\debug\build\mozjs_sys-661d4efe7c7ca939\build-script-build` (exit code: 101)
--- stdout
touch /v/3rd-party/servo-clean/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/master/mozjs/js/src/configure
cd /v/3rd-party/servo-clean/target/debug/build/mozjs_sys-661d4efe7c7ca939/out && \
PYTHON=""c:/python27/python.exe"" \
MOZ_TOOLS="/" CC="gcc" CPP="gcc -E" CXX="g++" AR="ar" \
/v/3rd-party/servo-clean/.cargo/git/checkouts/mozjs-fa11ffc7d4f1cc2d/master/mozjs/js/src/configure --disable-jemalloc --disable-js-shell --disable-tests --disable-shared-js --without-intl-api --disable-export-js --without-pthreads || (cat config.log && exit 1)
# Background: JRuby installs on Travis is painfully slow. The version which is preinstalled is very old. Here are some GitHub | |
# issues about it: | |
# | |
# https://github.com/travis-ci/docs-travis-ci-com/pull/743 | |
# https://github.com/travis-ci/travis-rubies/issues/22 | |
# https://github.com/travis-ci/travis-ci/issues/6892 | |
# https://github.com/travis-ci/packer-templates/issues/391 | |
# | |
# Since the upstream issue is still unresolved, and a JRuby install takes anywhere from 100 to 200 seconds (!), we decided to | |
# implement this workaround. With this in place, the JRuby install takes about 10 seconds. |
# Attempt to work around an incorrect line number in a JRuby stack trace. Thus far, unsuccessful. | |
module PipelineSteps | |
class Auth | |
class << self | |
def some_method | |
app = nil | |
app[:auth_object] ||= begin | |
file_contents = 'puts "gurka"' |
To import this data, use the following command:
$ mongoimport --db time --collection holidays --upsert < holidays.json
Then run the leaktest.rb
like this (adding a Gemfile with the mongo
gem etc):
$ bundle exec ./leaktest.rb
// Almost works, but it still complains about a few missing properties with this approach | |
export default class ProtectedRoute extends Ember.Route.extend(AuthenticatedRouteMixin) { | |
public actions: null; | |
public activate: null; | |
public afterModel: null; | |
public beforeModel: null; | |
public controller: null; | |
public controllerFor: null; | |
public controllerName: null; | |
public deactivate: null; |
namespace Foo | |
{ | |
// This program illustrates an arguable case where the usage of goto could be said to be warranted. | |
class Program | |
{ | |
private static int ParseArgumentsAndRun(string[] args) | |
{ | |
int returnValue; | |
if (args.Length != 1) |
The screenshot below illustrates a problem I see sometimes, where people try to make code that is far too dense to be readable. On my screen I see a fulll page of code, with very little surrounding whitespace. This makes the code very unreadable to me.
The code in question is taken from WebSSH2, more specifically this file. Note: I am not in any way saying that this code is much worse than all other code that exists (including code that I've authored myself), but the spontaneous feeling I had when looking at this code was that it felt like a "big wall of text". If we write code like this, other people are likely to get the same feeling, which unfortunately will likely scare some people away from our (open source) code bases.
So: the problem is not with a particular project, but rather with a particular style of writing code.