Здравствуйте, Sinclair, Вы писали:

S>У каждого пользователя — своя база. Например. Или нет — зависит от архитектуры.

Без разницы — все-равно нужно проверить изменилась база или нет. Или изменился ли пользователь. Отож.

S>>Пользователь нажал на кнопку — делаем запрос к серверу, обновляем таблицу, отображаем на форме. Если пользователь изменился (но форма все так же доступна через IoC глобально) — то что?
S>То увольняем того, кто так спроектировал. Раз уж он не поддаётся обучению. Либо форма была открыта в контексте пользователя, и при логауте она обязана закрыться. Либо форма открыта в "глобальном" контексте, и тогда её всё равно, кто там пользователь.

Вы представляете себе WinForms. А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.

Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.

Боле того — запрос к серверу может быть не один а много — так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?

Здравствуйте, Shmj, Вы писали:

S>Без разницы — все-равно нужно проверить изменилась база или нет. Или изменился ли пользователь. Отож.
Не надо ничего проверять. Постарайтесь воздержаться от веществ. Хотя бы временно.

S>Вы представляете себе WinForms.
Нет, я представляю собой здравый смысл.

S>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.

S>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
Что такое "оповещать"? Зачем это вообще делать?

S>Боле того — запрос к серверу может быть не один а много
Вот именно.
S>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
а) в вашей парадигме возникают проблемы
б) ни у кого другого таких проблем не возникает

Посмотрите на то, как сделано примерно 100% софта.
1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.

Здравствуйте, Sinclair, Вы писали:

S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.

В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.

S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
S>Что такое "оповещать"? Зачем это вообще делать?

Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.

Забывайте дедовские технологии, когда событие было привязано к одной форме.

S>>Боле того — запрос к серверу может быть не один а много
S>Вот именно.
S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
S>а) в вашей парадигме возникают проблемы
S>б) ни у кого другого таких проблем не возникает

Возникают — у многих. Но многим пофиг — нет стройной идеологии.

Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.

S>Посмотрите на то, как сделано примерно 100% софта.
S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов

Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.

S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.

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

Здравствуйте, Shmj, Вы писали:

S>В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
Это никак не связано с клиньями у вас в голове.

S>Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Прекрасно. Как событие, так и формы существуют только в контексте "пользовательской сессии". Если пользователь отключился — всё, нет ни форм, ни оповещений от "предыдущего" пользователя.
Пока вы этого не поймёте, будете страдать.
S>Забывайте дедовские технологии, когда событие было привязано к одной форме.
"Дедовские технологии". Юноша, я ещё в конце 90х участвовал в разработке системы, где все открытые формы автоматически отображали произошедшие изменения.
И не только в ответ на запросы "текущего пользователя", а и от других пользователей системы. Вряд ли вы сможете чем-то меня удивить.

S>Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Есть идеология. Проблем нет.

S>Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм.
Нет.

S>Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
Что за бред вы пишете? Нет никакой локальной базы у сайта. Откройте свой телефон — там у 90% приложений нет никакой "локальной базы". Это можно легко проверить, отключив сеть, и убедившись в том, что кроме пустого экрана приложение ничего не покажет.

S>>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.

S>Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
Да кто вам такой бред сказал? Конечно же тестируют. Просто никто не делает приложения так, как вы — где "база" независима от "пользователя", и от обоих независимы "оповещения".
Попробуйте, скажем, сменить пользователя в приложении Альфа-банка. И посмотрите, действительно ли придёт оповещение об исполнении перевода от "предыдущего" пользователя, и смешаются ли балансы счетов Васи и Пети.

Здравствуйте, Sinclair, Вы писали:

S>>Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
S>Прекрасно. Как событие, так и формы существуют только в контексте "пользовательской сессии". Если пользователь отключился — всё, нет ни форм, ни оповещений от "предыдущего" пользователя.
S>Пока вы этого не поймёте, будете страдать.

Очень хорошо, здорово. А теперь потрудитесь объяснить что такое "пользовательская сессия" в контексте десктопного приложения. Что за зверь такой? Быть может это что-то типа отдельного процесса на уровне операционной системы?

Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения?

Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?

S>>Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
S>Да кто вам такой бред сказал? Конечно же тестируют. Просто никто не делает приложения так, как вы — где "база" независима от "пользователя", и от обоих независимы "оповещения".
S>Попробуйте, скажем, сменить пользователя в приложении Альфа-банка. И посмотрите, действительно ли придёт оповещение об исполнении перевода от "предыдущего" пользователя, и смешаются ли балансы счетов Васи и Пети.

Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это?

Здравствуйте, Shmj, Вы писали:

S>Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.

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

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

Здравствуйте, Shmj, Вы писали:

S>Очень хорошо, здорово. А теперь потрудитесь объяснить что такое "пользовательская сессия" в контексте десктопного приложения. Что за зверь такой? Быть может это что-то типа отдельного процесса на уровне операционной системы?
Нет, зачем? Это просто сессионный токен, который выдан вам сервисом аутентификации.
S>Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения?
Самый простой вариант — да, убить процесс
S>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?
Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.

S>Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это?
Конечно менял. Там, если что, есть режим с "демо аккаунтом".

Здравствуйте, Sinclair, Вы писали:

S>Нет, зачем? Это просто сессионный токен, который выдан вам сервисом аутентификации.

И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли?

S>>Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения?
S>Самый простой вариант — да, убить процесс

Вот в этом у вас и проблема... В 2025 году так никто не делает. Программа продолжает работать, просто переходит на страницу входа — вот в чем фишка.

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

S>>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?
S>Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.

Вот именно что:

1. Закрыть все формы.
2. Обнулить все состояния.
3. Оборвать все запросы и длительные операции.

Не просто формы — сейчас в формах никто данные не хранит, еще раз вам говорю — данные изменяются отдельно — и при изменении даных несколько форм может обновиться.

Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?

S>>Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это?
S>Конечно менял. Там, если что, есть режим с "демо аккаунтом".

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

Здравствуйте, Shmj, Вы писали:


S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?

Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.

Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.
И про это тоже Sinclair в начале ветки писал.
В целом ваша дискуссия похожа на разговор опытного архитектора с начинающим программистом. Лучше сосредоточиться на том, чтобы подумать, как реализовать то, о чем говорит опытный архитектор, вместо того, чтобы загружать его вопросами кодирования, как написать асинхронный обработчик.

Здравствуйте, Shmj, Вы писали:

S>И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли?
Логично всем запросам, у которых есть cancellation token, выдать cancel.
Тех, у которых нету — надо просто игнорировать их результат. Всё, пользователь ушёл, результат запроса уже нерелевантен.
И всё это делается в процессе логаута. Пользователь пытается выйти из системы — приложение дожидается окончания (либо завершения, либо отмены) всех асинхронных запросов.
Как раз для того, чтобы не было вопроса, "а чо делать, когда Вася проснулся, а голова — в тумбочке".

S>Вот в этом у вас и проблема... В 2025 году так никто не делает. Программа продолжает работать, просто переходит на страницу входа — вот в чем фишка.
У меня как раз проблем нет.
S>Понимаете ли что реальность — она другая. По логике вещей — пользователь вышел — и все должно схлопнуться, исчезнуть, задиспозится. Но нет — так нельзя. Программа по прежнему работает.
Так это же ваша программа. Как сделаете — так и будет. Вот, например, microsoft office позволяет как залогиниться в онлайн-аккаунт, так и сделать sign out. При этом никаких "асинхронных процессов" не остаётся.

S>>>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?
S>>Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.

S>Вот именно что:

S>1. Закрыть все формы.
S>2. Обнулить все состояния.
S>3. Оборвать все запросы и длительные операции.
Всё верно.
S>Не просто формы — сейчас в формах никто данные не хранит, еще раз вам говорю — данные изменяются отдельно — и при изменении даных несколько форм может обновиться.
Ну так и в чём проблема?

S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Ну так это вам виднее. См. п.1.

S>Так дело вот в чем. Чтобы эта ошибка проявилась — нужно не простои изменить пользователя. Нужно чтобы первый пользователь запустил некую длительную операцию, которая выполняется дольше чем вход/выход из аккаунта. Это трудноуловимые ошибки и тестеры их не обнаружат да и пользователи очень редко когда столкнуться.
Нет там никаких операций, которые выполняются дольше, чем вход/выход из аккаунта.
Такую операцию придётся специально придумать. И в ней не будет никаких чудес. Если я сделал заявку на кредит и вышел из аккаунта, а мне её завтра одобрили — в приложение ничего не придёт.
Это была бы огромная дыра в security. За такое могут и лицензию отобрать.

Здравствуйте, Sinclair, Вы писали:

S>>И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли?
S>Логично всем запросам, у которых есть cancellation token, выдать cancel.

Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.

Так с чем вы еще не согласны то?

S>Тех, у которых нету — надо просто игнорировать их результат. Всё, пользователь ушёл, результат запроса уже нерелевантен.
S>И всё это делается в процессе логаута. Пользователь пытается выйти из системы — приложение дожидается окончания (либо завершения, либо отмены) всех асинхронных запросов.
S>Как раз для того, чтобы не было вопроса, "а чо делать, когда Вася проснулся, а голова — в тумбочке".

А с чем вы спорите? Именно это я сказал в самом начале. И ушло много сообщений, чтобы вы, наконец, поняли идею.

S>Так это же ваша программа. Как сделаете — так и будет. Вот, например, microsoft office позволяет как залогиниться в онлайн-аккаунт, так и сделать sign out. При этом никаких "асинхронных процессов" не остаётся.

А где гарантия что там не остается таких процессов? Кто проверял? Какой процесс вы проверяли?

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


S>>Так дело вот в чем. Чтобы эта ошибка проявилась — нужно не простои изменить пользователя. Нужно чтобы первый пользователь запустил некую длительную операцию, которая выполняется дольше чем вход/выход из аккаунта. Это трудноуловимые ошибки и тестеры их не обнаружат да и пользователи очень редко когда столкнуться.
S>Нет там никаких операций, которые выполняются дольше, чем вход/выход из аккаунта.

А кто дает такую гарантию? Это должно быть выражено в цифрах — сколько секунд выходит из системы пользователь и сколько секунд самая длительная из возможных операций.

S>Такую операцию придётся специально придумать. И в ней не будет никаких чудес. Если я сделал заявку на кредит и вышел из аккаунта, а мне её завтра одобрили — в приложение ничего не придёт.
S>Это была бы огромная дыра в security. За такое могут и лицензию отобрать.

Иногда бывает что сервер долго не отвечает.

Здравствуйте, Быдлокодер, Вы писали:

Б>Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Б>Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.

OperationCanceledException в среде .net. Это то, о чем я писал в самом начале.

Б>Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.

Речь про дектопные/моб. приложения. В сетевых проще — там один запрос 1 ответ.

А в десктопных нередко состояние регают в IoC-фреймворке и для многих глобальных форм оно существует на протяжении всей жизни приложения.

Б>И про это тоже Sinclair в начале ветки писал.
Б>В целом ваша дискуссия похожа на разговор опытного архитектора с начинающим программистом. Лучше сосредоточиться на том, чтобы подумать, как реализовать то, о чем говорит опытный архитектор, вместо того, чтобы загружать его вопросами кодирования, как написать асинхронный обработчик.

В конце до него наконец дошла идея, которую он не мог понять — что за исключение такое, которое не нужно обрабатывать. Ему привычнее .Net — у меня то стек технологий огромный и я как бы вижу самую суть. Но для него нужно назвать ключевое слово OperationCanceledException.

Здравствуйте, Shmj, Вы писали:

S>В конце до него наконец дошла идея, которую он не мог понять — что за исключение такое, которое не нужно обрабатывать. Ему привычнее .Net — у меня то стек технологий огромный и я как бы вижу самую суть. Но для него нужно назвать ключевое слово OperationCanceledException.

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

Здравствуйте, Shmj, Вы писали:

S>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.

Э-што? Это Sinclair пришел к пониманию?


S>Так с чем вы еще не согласны то?

Мы согласны, у нас консенсус: ты — идиот

Здравствуйте, Marty, Вы писали:

S>>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.
M>Э-што? Это Sinclair пришел к пониманию?

Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит.

Здравствуйте, Shmj, Вы писали:

S>>>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.
M>>Э-што? Это Sinclair пришел к пониманию?

S>Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит.

Он молчит, потому что понял, что твою тупость не пробить ничем

Здравствуйте, Marty, Вы писали:

S>>Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит.
M>Он молчит, потому что понял, что твою тупость не пробить ничем

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

Если хочешь действовать не как хомо а как сапиенс — то:

1. Объясни суть спора, с чем был не согласен Sinclair.
2. Опиши к какому выводу пришли и какое к этому отношение имеет OperationCanceledException.

Выбор за тобой — либо быть хомо либо сапиенсом.

Здравствуйте, Shmj, Вы писали:

S>Ты сейчас действуешь по примативному инстинкту — поддержка соц. иерархии. Типа если ты шестеришь перед авторитетом — то якобы можешь стать бета — чистый примативизм.

Ой, я перед Sinclair что ли шестерю? Ты идиот, или просто прикидываешься?


Sinclair тебе всё по полочкам разложил, разжевал, положил в рот. Я ему вообще удивляюсь в данном случае, так терпеливо разжевывать для тебя базовые понятия. Но он вроде преподаёт, у таких есть уже практика общения с неучами


S>Если хочешь действовать не как хомо а как сапиенс — то:

S>1. Объясни суть спора, с чем был не согласен Sinclair.

Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится


S>2. Опиши к какому выводу пришли и какое к этому отношение имеет OperationCanceledException.

S>Выбор за тобой — либо быть хомо либо сапиенсом.

А, ты типа вжика, в белой польте стоишь красивый...

Вопросов больше не имею

Здравствуйте, Marty, Вы писали:

S>>1. Объясни суть спора, с чем был не согласен Sinclair.

M>Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится

Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически?

Это вообще не досягаемо для тебя — а то что ты в соц. иерархию примативную умеешь — это мы видели, но это не несет смысла.

Здравствуйте, Shmj, Вы писали:

M>>Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится

S>Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически?

Конек или нет — Синклер тебе донёс предельно ясно, всё разжевал, в рот положил


S>Это вообще не досягаемо для тебя — а то что ты в соц. иерархию примативную умеешь — это мы видели, но это не несет смысла.

Мне пох на твою иерархию, а то, что ты непробиваемый дилетант — это ты доказал многократно