static char* stralloc( const char* str ) {
    char* res = malloc( strlen( str + 1 ) );
    strcpy( res, str );
    return res;
}

Код выглядит как настоящий, замыленным взглядом ошибку увидеть сложно. А уж какие эффекты появляются! Эта функция вызывалась из двух мест:

static char* start() {
    return stralloc( "{'start':true}" );
}
 
static char* stop() {
    return stralloc( "{'stop':true}" );
}

Если вызывать только из первого места сколько угодно раз — всё работает. Если вызвать из второго места — падает при втором вызове. Если увеличить длину второй строки на один символ — опять же всё работает.

Рекомендую попробовать всем, кто использует языки с автоматическим управлением памятью. Незабываемые ощущения гарантированы!

Пришло время привести в порядок базовые знания.

В языке Java для строк используется тип java.lang.String. Символы в строке имеют тип Character — это 16-битные коды символов в кодировке Unicode.

Кодировка файлов может обеспечивать представление всех Unicode символов (UTF-8, UTF-16) или его подмножества (windows-1251). UTF-8 обеспечивает более компактное хранение наиболее распространенных символов (ASCII), но требует более сложного преобразования, поэтому существуют различные представления Unicode.

Что происходит, когда файл читается с помощью java.io.FileInputStream? Поток байтов преобразуется в последовательность Unicode символов. Стоп. Чтобы правильно преобразовать, надо знать кодировку файла. Но ни один из конструкторов FileInputStream не позволяет указать кодировку! Небольшое исследование выводит на инфрмацию о том, что используется умолчальная (дефолтная, стандартная) кодировка платформы. Что будет, если на самом деле в файле использована другая кодировка? Правильно, мусор. Как это победить? Есть такое свойство file.encoding, которое позволяет поменять стандартную кодировку, но оно не документировано (помните книжки типа «Недокументированные возможности MS Word 6.0?»).

Ладно, прочитали из файла строку в неправильной кодировке. В строке мусор. А мы этого не заметили и записали эту строку в другой файл. Конечно, через java.io.FileOutputStream. Тоже не имея возможности указать кодировку. В этом случае — к счастью. Потому что обратная функция почти все символы из мусора вернет в нормальное состояние. Кроме, если я не ошибаюсь, «И» и «ш». А мы будем долго удивляться, откуда такая выборочная беда, ну ведь почти всё же правильно работает!

Лучше бы все символы поломались. Потому что понимание проблемы в этом случае пришло бы быстрее. Вот пример того, что получается при двойной неправильной перекодировке (потоки тут не используются, но суть та же):

import java.io.UnsupportedEncodingException;
public class StreamEncoding
{
    public static void main( String[] args ) throws UnsupportedEncodingException
    {
        String s = "Иллюзия";
        System.out.println( new String(  new String( s.getBytes( "UTF-8" ), "windows-1251" )
                                        .getBytes( "windows-1251" )
                                      , "UTF-8"
                                      )
                          );
    }
}

Результат вывода:
�?ллюзия

Редкий случай — удалось понять суть проблемы. Обычно удаётся устранить проявления, но не докопаться до сути. Как же делать правильно?

1. В своих программах для файловых операций использовать java.io.InputStreamReader/Writer и их конструкторы с указанием кодировки. Не использовать более простые File(Reader/Writer), потому что они не позволяют указать кодировку. И уж тем более не использовать File(Input/Output)Stream.
2. Чужие программы иногда удается победить указанием свойства file.encoding в командной строке Java-машины. Очевидно, не всегда.

А почему под Linux всё работало? Потому что файл был в кодировке UTF-8, а это стандартная кодировка платформы в Linux. Только не надо нос задирать, в следующий раз попадется windows-1251 и всё будет наоборот.

Начнем с названия. Люди из этой компании вообще думают, как это искать? Игрался я с языком, который называется Nice. Как вы считаете, сколько результатов Гугл выдаст по запросу Nice Programming Language? 2.5 миллиона! И это для малоизвестного языка. А для только что объявленного Simple Programming Language уже почти 19 миллионов!

Естественно, проект расположился на Google Code. Интересно стало посмотреть в исходники, тема трансляторов мне близка (TreeDL хоть и дает всего 1.5 тыщи ссылок, зато релевантность существенно выше). Транслятор Simple написан на Java 6. Парсер рукописный, дерево гетерогенное, рукописное. Классы для узлов дерева содержат методы для генерации байт-кода JVM (У Microsoft на .NET был Basic, теперь и на JVM есть ). Решение достаточно эффективное, но плохо расширяемое.

Прежде чем на Windows удалось скомпилировать пустую программу, пришлось исправить три критические ошибки. Забавно, первые четыре баг-репорта — мои. Для версии 0.1.0 это, конечно, простительно, но осадочек остался. Нехорошо это — выкладывать сборку для платформы и ни разу ее не запустить... Впрочем, у проекта, похоже, один участник — Herbert Czymontek, он же simplecompiler.

Но самое главное — пока, судя по всему, есть только язык и транслятор с библиотекой. Средств визуального проектирования GUI нет. А пока их не будет, Simple своё название не оправдает. Впрочем, даже если они будут, не понимаю, чем BASIC проще нормальных языков. Ладно, поживем — увидим, деньги могут многое.

class A
end
 
class B < A
end
 
class B
   def m
   end
end

Так работает. Но если поменять местами два последних определения, то возникает сообщение об ошибке: superclass mismatch for class B (TypeError), поскольку указать базовый класс можно только при первоначальном определении класса.

Вообще, возможность добавления методов в существующий класс заставляет переосмыслить роль механизма наследования. На первый взгляд, в Ruby с открытыми определениями классов, динамической типизацией и duck typing наследование не требуется!

Программисты, «думающие» на C++/Java часто используют наследование не по назначению. Обсуждая с коллегой вопрос «зачем нужно наследование?» я наткнулся на быстрый ответ: для переиспользования кода. В этом и есть корень зла — при отсутствии нормальных механизмов повторного использования кода в этом качестве начинают использовать наследование. Но в Ruby-то такие механизмы есть. Так зачем наследование?

Похоже, что в Ruby и подобных языках наследование вернулось к своему первоначальному назначению — выразить намерение программиста, что один тип является подтипом другого. Кстати, если вспомнить принцип подстановки Лисков (Liskov substitution principle), то становится понятно, что подтип (subtype) тесно связан с подстановкой (substitution).

Вывод: используйте наследование в первую очередь как способ описания используемой модели, проектного решения. А уж потом реализуйте в классах требуемые методы.

1. При попытке установить gem на Ubuntu может возникать сообщение об ошибке:

extconf.rb:8:in `require’: no such file to load — mkmf (LoadError)
from extconf.rb:8
ERROR: While executing gem … (RuntimeError)
ERROR: Failed to build gem native extension.

Это означает, что не установлен пакет ruby###-dev, где ### — версия Ruby (текущая стабильная — 1.8). можно установить его, а можно сразу ruby-full, который гарантирует полную установку последней стабильной версии.

2. Просмотреть документацию локально установленных gems можно с помощью gem_server. После его запуска документация доступна по адресу http://localhost:8808.

3. gem renum дает возможность определять перечислимые типы:

enum :Status, %w( NOT_STARTED IN_PROGRESS COMPLETE )
 
enum :Size do
 
  Small("Really really tiny")
  Medium("Sort of in the middle")
  Large("Quite big")
 
  attr_reader :description
 
  def init description
    @description = description
  end
 
end
 
module MyNamespace
  enum :FooValue, [ :Bar, :Baz, :Bat ]
end

4. gem interface дает возможность определять интерфейсы в стиле Java (как набор методов) и проверять, что класс заданные интерфейсы реализует (конечно, типы параметров не специфицируются):

   require "interface"
 
   MyInterface = interface{
      required_methods :foo, :bar, :baz
   }
 
   # Raises an error until 'baz' is defined
   class MyClass
      def foo
         puts "foo"
      end
      def bar
         puts "bar"
      end
      implements MyInterface
   end

5. Две попытки снабдить Ruby средствами строгой типизации (но не статической!):
gem strongtyping:

      require 'strongtyping'
      include StrongTyping
 
      def foo(a, b)
         expect(a, String, b, Numeric)
         ...
      end

types:

typesig String, [Array, Hash]
def example2(string, array_or_hash)
  # ... here, we know that string is a String, and array_or_hash
  # is either an Array or a Hash (or a subclass thereof) ...
end

Eivind Eklund, автор types, утверждает, что его кунг-фу сильнее. И на первый взгляд это действительно так.

Все перечисленное меня больше интересует как способ описать контракт, а не проверить что-то во время работы программы.

6. Кстати, о контрактах. gem rubydbc позволяет добавлять в код пре- и постусловия:

class Foo
   include DesignByContract
 
   pre(:sqrt, "value must be >= 0") { |v| v >= 0 }
 
   pre("divisor must be != 0") { |dividend, divisor| divisor != 0 }
   post { |result, a, b| a - b * result < 1e-3 }
   def div(dividend, divisor)
      dividend / divisor
   end
 
   def sqrt(value)
      Math.sqrt value
   end
 
   post(:sqrt, "error is greater than expected") { |result, value|
         result * result - value < 1e-3
   }
end

7. gem rspec — must have для тестов. А без тестов в Ruby никуда...

Ruby — интерпретируемый язык (это не значит, что для него нельзя разработать компилятор. Но думать о Ruby проще как об интерпретируемом языке). Это накладывает отпечаток на схему организации и выполнения Ruby-программ. В этом смысле они ближе к shell-скриптам, чем к программам на «серьезных» языка типа C/C++/Java — Ruby интерпретатору подается программа (из файла или из стандартного входа), которая немедленно исполняется. Нет никаких деклараций, которые предварительно как-то обрабатываются (компилируются), а затем используются при выполнении программы — что вижу, о том и пою.

% ruby
puts "Hello, world!"
^D
Hello, world!

Это не значит, что деклараций нет вообще. Ruby — объектно-ориентированный язык, естественно, он позволяет определять классы. Но правильнее думать о классах как о немедленных указаниях интерпретатору выполнить определенные действия — зарегистрировать класс с заданным именем. Так же дела обстоят и с определением методов — это указание зарегистрировать в текущем классе метод с заданным именем.

Я хочу сказать, что у Ruby довольно простая вычислительная модель. Наверное, при использовании ограниченного подмножества возможностей языка можно и не задумываться о ней. И согласиться с многочисленными отзывами о Ruby как о простом для изучения и использования языке. Но в тонкостях языка без понимания внутреннего устройства разобраться не получается.

В свое время мне довелось оптимизировать ассемблерный код, сгенерированный компилятором языка С (кажется, DECUS С на СМ-4, то есть PDP-11). C тех пор код на С и частично на С++ я автоматически перевожу на ассемблер. Это сильно помогает понять, что же будет происходить во всяких нетривиальных ситуациях. Вот и с Ruby наблюдается похожая ситуация. Обязательно разберитесь с вычислительной моделью!

Ruby — объектно-ориентированный (ОО) язык. К сожалению, одной этой фразы мало — под крышей ОО собрались весьма непохожие друг на друга языки. Так что будем разбираться дальше. Одно можно сказать наверняка — в соответствии с классическим определением ОО в Ruby есть объекты. Этим объектам можно посылать сообщения. Ссылку на объект можно сохранить в переменной. Посылка сообщения соответствует вызову метода. Ну вот, уже что-то общее с широко используемыми языками.

class Klass
  def hello( addressee )
    return "Hello, " + addressee + "!"
  end
end
 
k = Klass.new()
puts( k.send( :hello, "world" ) ) # Послать сообщение :hello
puts( k.hello( "world" ) )        # то же самое, что вызвать метод hello

Хорошие новости — сообщения могут иметь параметры и возвращать значение.

Литеральными значениями могут быть заданы числа, строки, массивы, хэши, диапазоны, символы и регулярные выражения. Всё это — полноценные объекты. Никаких примитивных типов, как в Java, всё по-честному.

Числа имеют произвольную длину. Если не помещаются в машинное слово — автоматически используется реализация длинной арифметики. А чтобы проще было писать длинные литералы, разрешается использовать подчеркивания, интерпретатор их игнорирует. Для чисел с плавающей точкой используется машинный double.

PI_INTEGER = 3_141_592_653_589_793_238_462_643_383_279_502_884

В строках самая примечательная возможность — подстановка значения выражения, которое находится внутри #{...}. Как мне не хватало этого в Java!

Если не хотите думать об экранировании спецсиволов — используйте одинарные кавычки.

addressee = "world"
puts( "Hello, #{addressee}!" ) # напечатает Hello, world!
puts( 'Hello, #{addressee}!' ) # Напечатает Hello, #{addressee}!

Символы — это объекты, представляющие имена, используемые в программе. Отличаются от имен двоеточием в начале. В примере с посылкой сообщения, которое соответствует методу hello, был использован символ :hello. В Java пришлось бы использовать текстовую строку, что чревато описками.

1. Для использования символа имя не обязательно должно быть определено.
2. C/Java символы в одинарных кавычках — это совсем не то, не путать.

Про массивы, хэши, диапазоны и регулярные выражения скажу потом, когда понадобятся в примерах. Ничего концептуально нового там, вроде, нет.

Далее план такой (может и поменяться):

1. Классы и модули
2. Методы и блоки
3. Обработка неизвестных сообщений
4. Псевдо-DSL
5. Инструменты (будут подпункты)

На прошлой неделе выпустил новую версию TreeDL 2.3.2. Предыдущую версию за 16 месяцев скачали ну от силы 250 раз. За два дня после выхода этой по статистике SourceForge было скачано 120 файлов, причем новую версию скачали меньше 20 раз. Проект выскочил в Top500.
При этом сообщений о выходе новой версии нигде не было. Анонс в список рассылки я отправил уже после этого ажиотажа, да и подписчиков там 4 человека всего. На вебе никаких новых ссылок на проект, вроде, не появилось. Интересно, откуда взялась такая активность? Есть предположение, что это какой-то робот ходит, но я о таких не слышал.

TreeDL — это мой проект, который появился для облегчения работы над основными проектами по разработке трансляторов.

Трансляторы и компиляторы — это программы, которые с одной стороны имеют довольно большой размер (чем сложнее входной язык, тем больше размер его анализатора и кодогенератора), а с другой стороны обладают достаточно регулярной структурой (все конструкции языка обрабатываются схожим образом). Эта регулярность дает возможность атоматизировать разработку. Самый известный пример — генераторы лексических и синтаксических анализаторов, начиная с классических lex/yacc.
Помимо анализатора транслятор включает генератор кода (если это код на машинном языке, то транслятор называют компилятором). Если обработка языка сравнительно простая, то генерация кода происходит одновременно с разбором входной программы, такие трансляторы называют однопроходными. В более сложных случаях результатом анализа является внутреннее представление входной программы, чаще всего в виде дерева. Генератор кода обходит это дерево и создает результирующий код.
Оказалось, что структуру дерева внутреннего представления неудобно описывать на языке программирования общего назначения (например, Java). Пришлось придумать небольшой специализированный язык (DSL — domain-specific language) TreeDL, который дает возможность создавать компактное описание в виде набора структур с одиночным наследованием (классов с полями, но без методов). По этому описанию генерируется код на основном языке программирования. Дополнительно значительный выигрыш дает генерация всяких вспомогательных компонентов, связанных с деревом — обходчиков, фабрик, реализация интерфейсов для совместного использования с другими компонентами (например, TemplateModel для FreeMarker). Генерация кода дополнительных компонентов осуществляется подключением плагинов к транслятору TreeDL.
TreeDL v2 активно используется в проектах UniTESK и показал себя достаточно стабильным. При подготовке диссертации (защитился в конце 2006 года) появились новые идеи, которые не вписываются в рамки нынешней реализации. Взялся-таки за разработку TreeDL v3, но времени мало, когда что-то созреет — непонятно. А совсем бросать — тоже жалко.

#include <stdio.h>
 
int main() {
  int pid;
  printf("before");
  pid = fork();
  printf("\nafter");
  if(pid == 0) {
    _exit();
  }
  printf("\n");
}

На первый взгляд, печатается «before», далее из одного процесса получаются два, оба они печатают «after». Всё не так просто — «before» может остаться в буфере и напечататься в обоих процессах. И наоборот, один из «after» так и останется в буфере, когда процесс завершится вызовом _exit ().
Так что возможен и строго обратный результат — два «before» и один «after»

Я попался на первоначальную версию, ответив 1 и 4:

#include <stdio.h>
 
int main() {
printf("\nbefore");
fork();
fork();
printf("\nafter");
}

http://community.activestate.com/forum-topic/ppm4-mswin32-x64-404-erro

При попытке их поменять обнаружилось, что картинки хранятся непосредственно внутри файла BriansThreadedComments.php:

$images['spacer.png'] = "iVBORw0KGgo...";
if(isset($_GET['image']))
{
    header("content-type: image/png");
    print base64_decode($images[$_GET['image']]);
    exit;
}

То есть, для замены картинки её необходимо преобразовать в base64.

Если это разовое действие, то проще всего не устанавливать никаких программ, а воспользоваться web-сервисом, например, base64encode. На этом же сайте можно сделать и обратное преобразование — base64decode.

Замечу, что в данном случае размер картинки должен быть 13*13 точек, при меньшем размере будет виден «кусочек паркета».