SVN синхронизируются по сравнению с обновлением для заголовка (subclipse)

Необходимо вызвать (), чтобы можно было дождаться возврата функции и получить ее возвращаемое значение. Также потребуется другой тип делегата. Это должно сработать:

public static string readControlText(Control varControl) {
  if (varControl.InvokeRequired) {
    return (string)varControl.Invoke(
      new Func<String>(() => readControlText(varControl))
    );
  }
  else {
    string varText = varControl.Text;
    return varText;
  }
}

-121--1223598-

Мой Клоюр немного ржавый, но это кажется буквальным переводом знаменитого Haskell one-liner:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

[Я собираюсь использовать псевдо-Haskell, потому что это немного более лаконично.]

Первое, что вам нужно сделать, это просто позволить лени утонуть. Когда вы смотрите на определение так:

zeroes = 0 : zeroes

Ваша немедленная реакция кишечника как строгий программист будет "ZOMG бесконечный цикл! Должен исправить ошибку! " Но это не бесконечный цикл. Это ленивый бесконечный цикл. Если вы делаете что-то глупое, как

print zeroes

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

Лень похожа на денежную систему: она основана на предположении, что подавляющее большинство людей никогда не используют подавляющее большинство своих денег. Так что, когда вы кладете 1000 долларов в банк, они не хранят их в своем сейфе. Они одолжили его кому-то другому. На самом деле, они используют деньги, что означает, что они одалживают 5000 долларов кому-то еще. Им нужно только достаточно денег, чтобы они могли быстро перестановить их так, чтобы они были там , когда вы смотрите на них, давая вам вид , что они на самом деле хранят ваши деньги.

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

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

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

Следующий шаг - zipWith . ( map Клоюре - это просто обобщение того, что в других языках программирования обычно представляют собой три различные функции: map , застежек -молний и zipWith . В этом примере он используется как zipWith .)

Причина, по которой семейство функций застежек -молний названо таким путем, заключается в том, что оно на самом деле работает как молния, а также в том, как лучше всего визуализировать его. Скажем, у нас есть какое-то спортивное мероприятие, где каждый участник получает две попытки, и счет от обеих попыток складывается, чтобы дать конечный результат. Если у нас есть две последовательности, run1 и run2 с оценками из каждого прогона можно вычислить конечный результат так:

res = zipWith (+) run1 run2

Предполагая, что нашими двумя списками являются (3 1 6 8 6) и (4 6 7 1 3) , мы выстраиваем оба этих списка рядом друг с другом, как две половины молнии, а затем зацикливаем их вместе, используя нашу заданную функцию ( + в данном случае), чтобы получить новую последовательность:

3   1   6   8   6
+   +   +   +   +
4   6   7   1   3
=   =   =   =   =
7   7  13   9   9

Участник # 3 выигрывает.

Итак, как выглядит наш fib ?

Ну, он начинается с 0 , затем мы добавляем 1 , затем мы добавляем сумму бесконечного списка с бесконечным списком, сдвинутым на один элемент. Проще всего просто нарисовать, что

• первый элемент равен нулю:

   0
  

• второй элемент - один:

   0 1
  

• третий элемент является первым элементом плюс первый элемент остального элемента (т.е. второй элемент). Мы снова представляем это как молнию, ставя два списка друг на друга.

  0 1
  +
  1
  =
  1
  

• Теперь только что вычисленный элемент является не только выходом функции zipWith , но и входом , так как он добавляется к обоим спискам (которые фактически являются одним и тем же списком, только что сдвинутым на один):

   0 1 1
  + +
  1 1
  = =
  1 2
  

• и т.д.:

   0 1 1 2
  + + +
  1 1 2
  = = =
  1 2 3
  
  
  0 1 1 2 3 ^
  + + + + |
  1 1 2 3 ^ |
  = = = = | |
  1 2 3 5---+---+
  

Или если нарисовать его немного по-другому и объединить список результатов и второй список ввода (которые действительно одинаковы, в любом случае) в один:

0   1   1   2   3   ^
+   +   +   +   +   |
1 = 1 = 2 = 3 = 5---+

Вот как я визуализирую его, в любом случае.

-121--2128148-

Есть разница. При использовании представления Синхронизировать (Synchronize) обновляются только элементы в представлении. С помощью Subversion папки также имеют редакцию, которая создается каждый раз при изменении нижестоящего элемента. Однако, поскольку они не отображаются в представлении, они никогда не обновляются. При выполнении команды Команда (Team) > Обновить (Update) в проекте все папки и файлы обновляются до единой версии. У меня есть пара блогов, которые объясняют это:

Это объясняет основную концепцию SVN смешанной рабочей копии редакции и имеет важное значение для понимания этого:

http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html

Второй показывает функцию в Subclipse для решения этой задачи:

http://markphip.blogspot.com/2006/12/subclipse-synchronize-feature-show-out.html

Поскольку был написан второй блог, большинство пользователей Subclipse обнаружили, что им не нравится эта функция, даже если она помогает с этой проблемой. Так что он теперь выключен по умолчанию в текущих версиях. Думаю, никто им больше не пользуется.

Главное - время от времени использовать Team > Update on your project, чтобы довести все до единой редакции.

Марк

Я думаю, ваше предположение, что синхронизация - это то же самое, что и обновление до HEAD, неверно. Если на языке Subclipse «синхронизация» означает «фиксация», то это определенно неверно, потому что фиксация не обновляет вашу рабочую копию. Вы должны явно обновить после того, как подтвердите, что находитесь в HEAD.

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

Эта статья может помочь прояснить эту концепцию смешанных редакций: http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html

Я также рекомендую вам ознакомиться ознакомьтесь с документацией SVN , так как работа с плагинами и расширениями для Subversion всегда становится проще, когда вы понимаете, как работает базовая система SVN.