в случае vim, когда подключаешь rope надо сделать mkdir .ropeproject в папке проекта, иначе rope будет искать по всему ~. Насколько я помню из того что читал когда натыкался на это — это поведение самого rope.
Уметь придумывать хорошие эксперименты не легче чем их объяснять :)
Стоит отметить, что широкая публика сто лет назад мало знала о ультрафиолетовой катастрофе и излучении абсолютно черного тела, как мы сейчас мало знаем о физике элементарных частиц (если вы умеете проводить математические расчеты или моделирование процессов на её основе — то это не про вас :)
Поручитесь головой, что физика дошла до уровня когда ни один эксперимент не может опровергнуть модель? Получите по ней Поппером, т.к. польза от такой физики в понимании окружающих вещей весьма сомнительная. Мы никогда не сможем точно сказать что знаем достаточно о природе вещей, это знание максимум может нас удовлетворить. Не стоит забывать что знание это использует замечательную математику, которая по утверждению Эрдёша ещё не скоро будет готова решать такие проблемы: mathworld.wolfram.com/CollatzProblem.html
Забавно читать в начале 21го века положения о том, что современная физика узнала достаточно чтобы уверенно судить о окружающих нас вещах. Это общеизвестный факт, что ровно сто с небольшим лет назад то-же самое говорили о классической физике. Тем не менее всё перевернулось с ног на голову из-за красивого математического приёма одного достаточно консервативного физика (я о Максе Планке). Через сто лет история снова повторяется :)
Можно себе представить существ, которые на определенном этапе технического прогресса или в результате эволюции научились менять собственный генетический код. Для таких возможно многое — межзвездные путешествия в анабиозе на высоких скоростях, «биологический» подход к вещам (делаем не микроскоп, о очень мощный глаз), освоение различных планет и так далее. Вместо государства — рой :)
А что мешает второму потоку получить лок, удалить файл, освободить лок до того как первый поток получит шанс взять лок? :) Я согласен что это маловероятно — более того, если бы мы обсуждали код на С то в некоторых случаях (архитектура, количество ядер… ) это было бы даже невозможно — но мы говорим о php :) Какие гарантии дает php о последовательности выполнений инструкций в нескольких потоках? Тут можно сказать что это невероятно, но в таком случае тем труднее будет потом отловить возникшую багу, если она таки случиться, например, 2 раза… за два месяца :) и оба раза под носом у заказчика…
Кстати говоря, если в случае устаревания файла мы его всёравно удаляем, то разве @unlink($filename) не лучшее решение?) в том и другом случае возвращаем false. Нам впринципе не важно был ли файл удален нами или кто-то до нас уже заметил что он устарел и удалил его…
function getFlagFromFile($filename) {
if (file_exists($filename)) {
if (!$this->validate()) {
$sem = sem_get(1); //***
if (sem_acquire($sem) && file_exists($filename)) { //***
unlink($filename);
sem_remove($sem); //***
}
return false;
}
else {
return file_get_contents($filename);
}
}
return false;
}
1: file_exists($filename) — true
2: file_exists($filename) — true
1: !$this->validate() — true
2: !$this->validate() — true
1: $sem = sem_get(1);
1: sem_acquire($sem) && file_exists($filename) — true
1: unlink($filename);
1: sem_remove($sem);
2: $sem = sem_get(1);
2: sem_acquire($sem)
2: file_exists($filename) — false!
2: return false;
3: зависнет на веки т.к. семафор так и не был сброшен php.net/manual/ru/function.sem-get.php
resource sem_get ( int $key [, int $max_acquire = 1 [, int $perm = 0666 [, int $auto_release = 1 ]]] )
sem_get() returns an id that can be used to access the System V semaphore with the given key.
A second call to sem_get() for the same key will return a different semaphore identifier, but both identifiers access the same underlying semaphore.
function getFlagFromFile($filename) {
if (file_exists($filename)) {
if (!$this->validate()) {
if ($race = RaceCondition::prevent('FLAG_'.$filename)) { //***
unlink($filename);
$race->release(); //***
}
return false;
}
else {
return file_get_contents($filename);
}
}
return false;
}
OK :)
Не знаю насколько вероятно что подобные сценарии когда-нибудь возникнут на реально работающей системе — но, насколько я знаю в случае с многопоточным программированием если что-то может произойти — оно обязательно случиться на продакшне :)
Более того, ОО код можно писать на любом языке. Возьмем к примеру C.
Опишем простой интерфейс:
typedef int (*behavior_t)(char);
typedef struct {
int a;
int b;
behavior_t doSomething;
} foo;
void setA(foo*, int);
int getA(foo*);
void setB(foo*, int);
int getB(foo*);
void init(foo* f, int a, int b, behavior_t behavior);
//Наследование
void bar(foo* f, int a, int b) {
behavior_t behavior = 0;
init(f, a, b, behavior);
}
polymorphic_call(foo*);
Тоже самое, например, на python:
import abc
class Foo:
def __init__(self, a, b):
self.a = a
self.b = b
@abc.abstractmethod
def doSomething(self, c):
pass
или на Java:
interface Foo {
int a;
int b;
int doSomething(char c);
}
В С можно описывать интерфейс в понятиях данных и функций
В Python интерфейс можно описать в терминах класса и абстрактных методов
В Java можно описать интерфейс как интерфейс
В C++ можно описать интерфейс как абстрактный класс
ОО код можно писать при этом везде, это хорошо показано, например, в SICP.
ОО код отличается главным образом тем что он описывает задачу в терминах объектов, позволяет легко абстрагироваться от конкретных (типов) объектов через тот-же полиморфизм.
Инкапсуляция важна, но в том-же Python она «реализована» через name mangling — тем не менее это тоже ОО язык.
Python, Java, C++,… — все поддерживают ОО парадигму программирования, потому что в каждом языке есть встроенные средства позволяющие легко описывать задачу в терминах объектов. При этом базовые понятия в них разные, но легко писать ОО код можно и там, и тут, и там тоже, собственно, на мой взгляд только это по сути отличает язык который поддерживает ООП от языка который этого не умеет.
В конце концов по-сути это особенности синтаксиса, можно рассматривать программу как конфигурационный файл, который настраивает интерпретатор так, что он решает вашу задачу.
Можно смотреть на программу как на компилятор который принимает на вход данные и компилирует решение. ООП при этом техника конфигурации, которая прямо поддерживается или не поддерживается синтаксисом языка.
есть замечательная штука: github.com/klen/python-mode
она + NERDTree + github.com/lambdalisue/nose.vim + www.wana.at/vimshell/
а так-же bitbucket.org/agr/ropevim (в python-mode уже есть, там хэлпы по кей биндингам)
На освоение этого комбайна ушло пара дней (день и ночь точнее, сам уже давно использую vim)
Зато это даёт весь нужный функционал PyCharm и даже больше (рефакторинг, детектинг ошибок при сохранении файла, автокомплит, поиск, переименование, python shell, просто шелл, запуск\редактирование юнит тестов по одной клавише, соответствие pep8). Дополнительно vim не подвисает на больших python проектах и не тормозит как это делает pycharm.
Стоит отметить, что широкая публика сто лет назад мало знала о ультрафиолетовой катастрофе и излучении абсолютно черного тела, как мы сейчас мало знаем о физике элементарных частиц (если вы умеете проводить математические расчеты или моделирование процессов на её основе — то это не про вас :)
Поручитесь головой, что физика дошла до уровня когда ни один эксперимент не может опровергнуть модель? Получите по ней Поппером, т.к. польза от такой физики в понимании окружающих вещей весьма сомнительная. Мы никогда не сможем точно сказать что знаем достаточно о природе вещей, это знание максимум может нас удовлетворить. Не стоит забывать что знание это использует замечательную математику, которая по утверждению Эрдёша ещё не скоро будет готова решать такие проблемы: mathworld.wolfram.com/CollatzProblem.html
1: file_exists($filename) — true
2: file_exists($filename) — true
1: !$this->validate() -true
2: !$this->validate() -true
1: $this->canUseApc() -true
2: $this->canUseApc() -true
2: apc_add('some_key', 1)
2: unlink($filename);
2: apc_delete('some_key');
1: apc_add('some_key', 1)
1: unlink($filename); — NO SUCH FILE!
1: file_exists($filename) — true
2: file_exists($filename) — true
1: !$this->validate() — true
2: !$this->validate() — true
1: $sem = sem_get(1);
1: sem_acquire($sem) && file_exists($filename) — true
1: unlink($filename);
1: sem_remove($sem);
2: $sem = sem_get(1);
2: sem_acquire($sem)
2: file_exists($filename) — false!
2: return false;
3: зависнет на веки т.к. семафор так и не был сброшен
php.net/manual/ru/function.sem-get.php
resource sem_get ( int $key [, int $max_acquire = 1 [, int $perm = 0666 [, int $auto_release = 1 ]]] )
sem_get() returns an id that can be used to access the System V semaphore with the given key.
A second call to sem_get() for the same key will return a different semaphore identifier, but both identifiers access the same underlying semaphore.
OK :)
Не знаю насколько вероятно что подобные сценарии когда-нибудь возникнут на реально работающей системе — но, насколько я знаю в случае с многопоточным программированием если что-то может произойти — оно обязательно случиться на продакшне :)
Опишем простой интерфейс:
Тоже самое, например, на python:
или на Java:
В С можно описывать интерфейс в понятиях данных и функций
В Python интерфейс можно описать в терминах класса и абстрактных методов
В Java можно описать интерфейс как интерфейс
В C++ можно описать интерфейс как абстрактный класс
ОО код можно писать при этом везде, это хорошо показано, например, в SICP.
ОО код отличается главным образом тем что он описывает задачу в терминах объектов, позволяет легко абстрагироваться от конкретных (типов) объектов через тот-же полиморфизм.
Инкапсуляция важна, но в том-же Python она «реализована» через name mangling — тем не менее это тоже ОО язык.
Python, Java, C++,… — все поддерживают ОО парадигму программирования, потому что в каждом языке есть встроенные средства позволяющие легко описывать задачу в терминах объектов. При этом базовые понятия в них разные, но легко писать ОО код можно и там, и тут, и там тоже, собственно, на мой взгляд только это по сути отличает язык который поддерживает ООП от языка который этого не умеет.
В конце концов по-сути это особенности синтаксиса, можно рассматривать программу как конфигурационный файл, который настраивает интерпретатор так, что он решает вашу задачу.
Можно смотреть на программу как на компилятор который принимает на вход данные и компилирует решение. ООП при этом техника конфигурации, которая прямо поддерживается или не поддерживается синтаксисом языка.
github.com/klen/python-mode
она + NERDTree + github.com/lambdalisue/nose.vim + www.wana.at/vimshell/
а так-же bitbucket.org/agr/ropevim (в python-mode уже есть, там хэлпы по кей биндингам)
На освоение этого комбайна ушло пара дней (день и ночь точнее, сам уже давно использую vim)
Зато это даёт весь нужный функционал PyCharm и даже больше (рефакторинг, детектинг ошибок при сохранении файла, автокомплит, поиск, переименование, python shell, просто шелл, запуск\редактирование юнит тестов по одной клавише, соответствие pep8). Дополнительно vim не подвисает на больших python проектах и не тормозит как это делает pycharm.
www.ideone.com/LKz5m
Вот уж точно обезжиренно =)
groovy.codehaus.org/Creating+XML+using+Groovy%27s+MarkupBuilder