Если все awaitable объекты завершены успешно, то результатом является совокупный список возвращенных значений этих объектов.
Если я правильно понял, это как ОжидатьЗавершенияВыполнения(), который используется для ожидания завершения последнего из списка фоновых заданий, только для обещаний. Вероятно, подобный синтаксис появится в скором времени и для Ждать. Но это в любом случае, не про сбор результата распараллеленного запроса из кучки результатов. Тут без костылей, даже не знаю, как обойтись.
Мне кажется Вы путаете асинхронность и многопоточность. Это связанные, но не тождественные понятия.
> без костылей
На самом деле, оптимизаторы внутри СУБД обычно хорошо справляются с такой задачей, и без участия прикладного разработчика. Оптимизатор, исходя из построенного плана, часто разбивает "тяжелый" запрос на кучу параллельно выполняющихся запросов. В MS SQL это настраивается с помощьюmax degree of paralrllism, в PostgreSQL, кажется, тоже была какая-то настройка. Но это уже тонкие материи, в области знаний DBA. Иногда, даже в СУБД возникают с такой параллельностью проблемы (гуглить CXPacket). А Вы хотите чтобы прикладной разработчик смог сам это захардкодить, без доступа к статистикам, сразу и правильно, не став причиной регресса, да еще и в несколько строчек кода? Может быть есть примеры сред разработки (языков), где такая задача решается легко и просто?
1С Фреш [...] Поскольку конфигуратор не предусматривается, то допилить решение для потребностей бизнеса нельзя.
Не то чтобы совсем нельзя. Есть же механизм расширений. Да, нужно пройти аудит, да есть требования и ограничения, но в целом - можно. Еще и зарабатывать потом, продавая это расширение другим пользователям.
Я так понимаю, речь о динамических списках, и невозможность потянуть за ползунок. Это ж известная проблема. Мне известны всего три альтернативы:
Получать выборку сразу и целиком тащить на клиент (мы же не рассматриваем этот вариант всерьез, да?)
сделать функциональный ползунок и получить лютые тормоза на highload, вычисляя размер ползунка и его положение при каждом получении порции данных (ведь для этого нужно оценить количество элементов списка до и после текущей порции, что по сути означает запрос с анализом всей таблицы).
разные ухищрения, когда настоящего ползунка нет, но есть какая-то заглушка. В 1с это безразмерный (всегда одинакового размера) ползунок, который находится посредине, если только мы не в начале или конце выборки.
Вообще, мне не попадалось системы, рассчитанной на "большие данные", где бы был реализован п.2. Всегда используются разные ухищрения, типа кнопки "загрузить еще", или что-то подобное.
Проблема не во вложенных попытках как таковых. Проблема в том что транзакция испорчена. Не каждая ошибка в транзакции приведет к такому эффекту. Например, обращение к несуществующей процедуре в попытке не приведет к "протуханию" транзакции. А вот ошибки, связанные с обращением к данным - приведут, даже если исключение перехвачено. В этом случае, любое следующее действие внутри транзакции приведет к "В данной транзакции уже происходили ошибки". Т.е. сама ошибка возникла ранее, но выстрелила в каком-то рандомном коде, который попытался выполнить действие в контексте протухшей транзакции. Это делает дебаггинг этой ошибки одним из самых неприятных.
Кстати, обратите внимание: мотоцикл подруливает передним колесом во время баланса. Предварительно, меняется угол наклона рулевой оси - таким образом еще сильнее смещается центр пятна контакта переднего колеса от оси поворота. Интересно, есть ли в этом агрегате вообще какой-то балансир/гироскоп, или все делается рулем?
Я бы обратил внимание на то, что точка контакта переднего колеса с поверхностью немного не совпадает с продолжением оси руля. т.е. при зажатом переднем тормозе, поворот руля немного сдвинет вбок всю систему байк-райдер. Возможно, при очень точном гироскопе (датчике) и очень точных движениях поворота руля, это может позволить удерживать баланс. Кроме того, в мото- и велотриале есть понятие статического баланса. Райдер удерживает баланс стоя на двух колесах. Обычно это делается с повернутым колесом. Вероятно, немалая часть этого баланса достигается за счет малозаметных движений тела райдера, но точно известно, что с повернутым колесом баланс держать сильно проще.
Кстати, подобную идею с геометрической вероятностью нажатия следующей буквы я реализовывал пару лет назад очень просто: Я не рисовал адаптивные хитбоксы. Я делал попарное сравнение геометрической "дальности" точки нажатия со всеми окружающими клавишами, и получал "вероятность" попадания. Для каждого введенного пользователем касания получается набор букв (я сохранял топ 3), ввод которых был наиболее вероятен. Для каждой буквы был свой поправочный коэффициент исходя из анализа частот совместного использования букв, исходя из Национального Корпуса Русского Языка (кстати, Яндексу респект за то что он есть). В результате, получаются красивые вогнуто-выпуклые границы хитбоксов (да-да, я физически их не использовал, но как их еще назвать?), где границы трех соседних кнопок сходятся в одной точке. Я посчитал это наиболее удачным вариантом. У вас же, края хитбокса формируются иногда довольно странно, судя по анимации:
К тому же, сохранение нескольких вероятных символов, в дальнейшем, позволяет очень просто и ненакладно проверить самые сомнительные буквы на корректность, перебрав варианты, сохраненные ранее. Помогает существенно повысить точность подсказок для коррекции.
Разрабатываю (пока неспешно) альтернативную "не-qwerty" клавиатуру. Поделюсь лайв-хаком: геометрический критерий можно включать "постфактум", когда пользователь закончил ввод очередного слова. В этом случае, мы имеем связь с буквами введенным не только "до", но и после проверяемого символа. Подменять уже распознанные символы, конечно не комильфо (по крайней мере если автокоррекция отключена), но вот подсказку в спелл-чекере вывести удается намного более полезную. В том числе, так лечиться вечный бич всех "торопыг" - ввод мягкого знака вместо пробела. Не встречал пока адекватных спелл-чекеров, которые распознают эту ситуацию.
к тому времени как он добирается до легких человек уже с симптомами и активная фаза заражения окружающих позади.
Ну так и мазок он будет брать примерно в тот момент. Пока нет никаких симптомов, нет и повода для беспокойства.
Или еще лучше: переболеет дома, а как температура спадет, по просьбе начальника пойдет тест делать, чтобы с чистой совестью выйти в офис на работу.
В статье о ложно-отрицательных. Это когда мазнули не там, не так, или не в то время (многие даже не знают, что есть/пить нельзя минимум за 2 часа до теста). Вирус просто не попадает в пробу (он ведь живет в легких, а не на поверхности горла).
Ложно-положительный результат обычно связан с загрязнением пробы при транспортировке или в лаборатории.
Главный – не лениться и при курьере проверять, что находится внутри упаковки.
…
Помогло бы это в описываемом случае? Да, при условии подключения диска к ПК и запуске любой информационной утилиты.
Так погодите, Вы же в начале статьи писали:
После подключения к USB, Windows сообщила, что видит новенький 6-терабайтный накопитель.
Я правильно понимаю, что до пересоздания раздела, Виктория тоже показывала емкость 6тб?
Куда смотреть, чтоб не наколоться?
Для участия в ППА у автора должен быть значок «Автор» (10 публикаций с рейтингом от +50 голосов за каждую) либо «Сторожил» (3 года аккаунту и +50 кармы). Так что большая часть этих статей также врядли оплачивалась.
На всякий случай уточню, что я не претендую на включение в статистику. Прекрасно понимаю, что при малом количестве просмотров часто могут возникать «выбросы» из статистики, навроде моей статьи. Вероятно статьи с менее 10к просмотров в расчет не принимались. Это всего лишь замечание, что и так бывает, а не требование к автору срочно признать мои заслуги.
Уточнение появилось потому, что кто-то после этого комментария зашел, и поставил минус статье с формулировкой «не соответствует тематике Хабра». Ну камон, статья с нестандартными примерами кода о новейшем фреймворке не соответствует тематике? Минусуйте коммент, если считаете его очередным «нытьем», в карму в конце концов можно минус воткнуть, если считаете нужным. Но статья-то тут причем?
Забавно, что моя статья об анимации в SwiftUI (которая по не понятным мне причинам, вообще не набрала ни одного плюса) на текущий момент имеет 19 закладок при 617 просмотрах. Если бы она попала в статистику (она вышла в июне, и формально попадает в первое полугодие), то по соотношению закладок к просмотрам была бы на первом месте (3 закладки на 100 просмотров, когда первое место сейчас — 2,3 закладки на 100 просмотров)
Теоретически у них должна быть очень большая коллекция размеченных русскоязычных текстов. Возможно их разметка вам не очень подойдет, но мне кажется, это может оказаться более перспективным, чем автоматический перевод.
Если все awaitable объекты завершены успешно, то результатом является совокупный список возвращенных значений этих объектов.Если я правильно понял, это как
ОжидатьЗавершенияВыполнения(),который используется для ожидания завершения последнего из списка фоновых заданий, только для обещаний. Вероятно, подобный синтаксис появится в скором времени и дляЖдать. Но это в любом случае, не про сбор результата распараллеленного запроса из кучки результатов. Тут без костылей, даже не знаю, как обойтись.Мне кажется Вы путаете асинхронность и многопоточность. Это связанные, но не тождественные понятия.
> без костылей
На самом деле, оптимизаторы внутри СУБД обычно хорошо справляются с такой задачей, и без участия прикладного разработчика. Оптимизатор, исходя из построенного плана, часто разбивает "тяжелый" запрос на кучу параллельно выполняющихся запросов. В MS SQL это настраивается с помощью
max degree of paralrllism, в PostgreSQL, кажется, тоже была какая-то настройка. Но это уже тонкие материи, в области знаний DBA. Иногда, даже в СУБД возникают с такой параллельностью проблемы (гуглить CXPacket). А Вы хотите чтобы прикладной разработчик смог сам это захардкодить, без доступа к статистикам, сразу и правильно, не став причиной регресса, да еще и в несколько строчек кода?Может быть есть примеры сред разработки (языков), где такая задача решается легко и просто?
Не то чтобы совсем нельзя. Есть же механизм расширений. Да, нужно пройти аудит, да есть требования и ограничения, но в целом - можно. Еще и зарабатывать потом, продавая это расширение другим пользователям.
Я так понимаю, речь о динамических списках, и невозможность потянуть за ползунок.
Это ж известная проблема. Мне известны всего три альтернативы:
Получать выборку сразу и целиком тащить на клиент (мы же не рассматриваем этот вариант всерьез, да?)
сделать функциональный ползунок и получить лютые тормоза на highload, вычисляя размер ползунка и его положение при каждом получении порции данных (ведь для этого нужно оценить количество элементов списка до и после текущей порции, что по сути означает запрос с анализом всей таблицы).
разные ухищрения, когда настоящего ползунка нет, но есть какая-то заглушка. В 1с это безразмерный (всегда одинакового размера) ползунок, который находится посредине, если только мы не в начале или конце выборки.
Вообще, мне не попадалось системы, рассчитанной на "большие данные", где бы был реализован п.2. Всегда используются разные ухищрения, типа кнопки "загрузить еще", или что-то подобное.
Проблема не во вложенных попытках как таковых. Проблема в том что транзакция испорчена. Не каждая ошибка в транзакции приведет к такому эффекту. Например, обращение к несуществующей процедуре в попытке не приведет к "протуханию" транзакции. А вот ошибки, связанные с обращением к данным - приведут, даже если исключение перехвачено.
В этом случае, любое следующее действие внутри транзакции приведет к "В данной транзакции уже происходили ошибки". Т.е. сама ошибка возникла ранее, но выстрелила в каком-то рандомном коде, который попытался выполнить действие в контексте протухшей транзакции.
Это делает дебаггинг этой ошибки одним из самых неприятных.
Полезно будет упомянуть, что на ИТС есть стандарт описывающий работу с транзакциями , рекомендую к ознакомлению.
Кстати, обратите внимание: мотоцикл подруливает передним колесом во время баланса. Предварительно, меняется угол наклона рулевой оси - таким образом еще сильнее смещается центр пятна контакта переднего колеса от оси поворота.
Интересно, есть ли в этом агрегате вообще какой-то балансир/гироскоп, или все делается рулем?
Я бы обратил внимание на то, что точка контакта переднего колеса с поверхностью немного не совпадает с продолжением оси руля. т.е. при зажатом переднем тормозе, поворот руля немного сдвинет вбок всю систему байк-райдер. Возможно, при очень точном гироскопе (датчике) и очень точных движениях поворота руля, это может позволить удерживать баланс.
Кроме того, в мото- и велотриале есть понятие статического баланса. Райдер удерживает баланс стоя на двух колесах. Обычно это делается с повернутым колесом. Вероятно, немалая часть этого баланса достигается за счет малозаметных движений тела райдера, но точно известно, что с повернутым колесом баланс держать сильно проще.
Поговаривают, что в аду есть отдельный котел для тех, кто меняет цвета колонок на диаграммах в докладе.
Кстати, подобную идею с геометрической вероятностью нажатия следующей буквы я реализовывал пару лет назад очень просто: Я не рисовал адаптивные хитбоксы. Я делал попарное сравнение геометрической "дальности" точки нажатия со всеми окружающими клавишами, и получал "вероятность" попадания. Для каждого введенного пользователем касания получается набор букв (я сохранял топ 3), ввод которых был наиболее вероятен. Для каждой буквы был свой поправочный коэффициент исходя из анализа частот совместного использования букв, исходя из Национального Корпуса Русского Языка (кстати, Яндексу респект за то что он есть). В результате, получаются красивые вогнуто-выпуклые границы хитбоксов (да-да, я физически их не использовал, но как их еще назвать?), где границы трех соседних кнопок сходятся в одной точке. Я посчитал это наиболее удачным вариантом. У вас же, края хитбокса формируются иногда довольно странно, судя по анимации:
К тому же, сохранение нескольких вероятных символов, в дальнейшем, позволяет очень просто и ненакладно проверить самые сомнительные буквы на корректность, перебрав варианты, сохраненные ранее. Помогает существенно повысить точность подсказок для коррекции.
Разрабатываю (пока неспешно) альтернативную "не-qwerty" клавиатуру. Поделюсь лайв-хаком: геометрический критерий можно включать "постфактум", когда пользователь закончил ввод очередного слова. В этом случае, мы имеем связь с буквами введенным не только "до", но и после проверяемого символа. Подменять уже распознанные символы, конечно не комильфо (по крайней мере если автокоррекция отключена), но вот подсказку в спелл-чекере вывести удается намного более полезную. В том числе, так лечиться вечный бич всех "торопыг" - ввод мягкого знака вместо пробела. Не встречал пока адекватных спелл-чекеров, которые распознают эту ситуацию.
Ну так и мазок он будет брать примерно в тот момент. Пока нет никаких симптомов, нет и повода для беспокойства.
Или еще лучше: переболеет дома, а как температура спадет, по просьбе начальника пойдет тест делать, чтобы с чистой совестью выйти в офис на работу.
Ложно-положительный результат обычно связан с загрязнением пробы при транспортировке или в лаборатории.
Так погодите, Вы же в начале статьи писали:
Я правильно понимаю, что до пересоздания раздела, Виктория тоже показывала емкость 6тб?
Куда смотреть, чтоб не наколоться?
Ну да. Из пункта А есть три [типичных] пути — в пункты Б, В и Г. Нахождение в пункте А — это как бы и не путь вовсе.
Для участия в ППА у автора должен быть значок «Автор» (10 публикаций с рейтингом от +50 голосов за каждую) либо «Сторожил» (3 года аккаунту и +50 кармы). Так что большая часть этих статей также врядли оплачивалась.
Уточнение появилось потому, что кто-то после этого комментария зашел, и поставил минус статье с формулировкой «не соответствует тематике Хабра». Ну камон, статья с нестандартными примерами кода о новейшем фреймворке не соответствует тематике? Минусуйте коммент, если считаете его очередным «нытьем», в карму в конце концов можно минус воткнуть, если считаете нужным. Но статья-то тут причем?
Судя по новостям, проект живой.