Обсуждение наглядно иллюстрирует перегруженность понятий в IT. Под словом «клиент» в оригинале понимался клиент базы данных, то есть то, что напрямую общается с бд, отправляет ей запросы. В комментариях же закономерно решили, что имеется в виду клиент из клиент-сервисной архитектуры, и в итоге каждый обсуждает что-то своё. Так и живём
Здесь речь идет о том, что для сборки dotNet6 нужен dotNet 5, а для сборки dotNet 5 нужен проприетарный dotNet 3.5
А расскажете, откуда информация о такой интересной зависимости? Не вижу ничего такого в официальных пререквизитах сборки и как-то удивлён тому, что dotnet 6 не может собраться на самом себе, интересно почитать обоснование такому требованию. Также очень интересно утверждение, что dotnet 5 собирается исключительно на древней версии 2002 года, хотя после неё и до dotnet 5 вышло 18 версий платформы.
А вы хоть раз пробовали собрать dotNet из предложенных ими исходников?
Разумеется, нет. Думаете, это заговор и они на самом деле не собираются?
Почему тот же JDK присутствует в официальных репозиториях, например, debian, а про dotnet там не слышали?
Этот вопрос можно адресовать мейнтейнерам официальных репозиториев.
Вот вам исходный код, а распространять мы будем дистрибутив в бинарниках, приложив таблицу совместимости.
Прямо в конце первого же абцаза по ссылке уточняется, что дистрибутивы распространяются через репозитории. Можно и бинарниками, при необходимости. Если таблица совместимости — это что-то ужасное, то прошу ужаснуться таблице совместимости jdk
Понимаю, что неприятно, когда вас поправляют, но увы, факт есть факт.
Хотя жаль, что не озвучена статистика по частоте боев наемников с пиратами на палубе/ранений наемников. С дивана кажется, что это должно происходить очень редко с учетом радаров
Как указано в статье, на борту может не быть вояк, а радары могут использоваться только для того, чтобы заранее предупредить экипаж и дать время скрыться в цитадели. В таком случае вполне вероятен сценарий обратного захвата вооружёнными силами. Например, так был отбит танкер «Московский университет» 6 мая 2010. А по запросу «mv taipan rescue» на ютубе можно посмотреть кадры такого сражения 5 апреля 2010.
Впрочем, с 10-х пираты уже не те, и подобное действительно происходит очень редко.
1. Просто вкинуть кучу кода, причём ещё два раза один и тот же — это не совсем статья, мне кажется. Если она нацелена на тех, кто не умеет делать контролы, то они ничего не поймут.
2. Есть контрол ToggleButton, используйте его
3. Зачем нужен IsCheckable? Есть IsEnabled.
4. Для изменения стиля контролов в wpf используются… стили и шаблоны. Если нужно динамически изменять их (для чего-то же вам нужна была DependencyProperty) — используйте DynamicResource. Следовательно, свойства для иконок и цветов не нужны.
5. Если таргетите .net framework — рекомендую использовать библиотеку Bindables, сократит код для DependencyProperty до двух строк + код обработки.
6. wpf-way — это использовать биндинги. Например, ButtonImage вы меняете в code-behind, это не нужно. В итоге сами свойства вы хоть и меняете, но вообще не используете.
7. В IsCkeckedPropertChanged вы меняете руками стили хардкодом. А что если я захочу в каком-то месте другой стиль при нажатии? Это делается триггерами, завязанными на IsChecked — когда он true, то одни сеттеры, когда false — другие. Хочет пользователь поменять только что-то одно, унаследуется от стиля и поменяет. Захочет что-то своё, сделает свой стиль.
8. UserControl_MouseEnter и UserControl_MouseLeave — то же самое. Делаем триггер стиля на IsMouseOver.
Так вы просветите меня, основ не знающего — в каких именно учебниках? Желательно с ссылками на главы.
Я вот прямо сейчас проверил: у меня на небольших объектах (64 байта) скорость выделения управляемой памяти оказалась в 3 раза выше, чем неуправляемой (выделение + удаление).
Так вы про выделение говорите или про выделение + удаление? Как замеряли удаление в управляемой памяти?
Ну, например, для работы с io_uring вместо epoll.
Так это же работа с файлами. Я спрашивал про сокеты.
И причём, тут, собственно, своя библиотека?
Так это же вы написали про свою библиотеку)
Потому что RTFM. Это просто обёртка над управляемым массивом.
Memory — это «не обёртка над управляемым массивом». Так что, действительно, RTFM.
Понятное дело, что здесь не рассматривались аспекты фрагментирования кучи
Вы сами же отвечаете на свой вопрос. Эти аспекты, которые здесь не рассматривались — и есть предназначение POH. Короче говоря, бенчмарк не говорит ничего о преимуществах/недостатках POH.
преимущество у нативного выделения в разы мне кажется немного странным
Оно потому и быстрее, что нативное, не? )
Также с POH есть второй неочевидный момент: передача указателя на буфер в вызов, инициирующий асинхронную операцию.
Так в асинхронных операциях нельзя использовать указатели. Либо я не понял, что имеется в виду, скиньте код.
Мы же о типе DateTime из C# сейчас говорим, не? Если вам дата пришла в виде строки, то очевидно, что она имеет тип «строка», а не DateTime.
А вам на API данные каким образом приходят? Не строками, интерпретируемыми платформой разве из json? Похоже, мы о чём-то разном говорим.
Ну а если ваше приложение, написанное на C#, сериализовало дату в подобном виде, то ССЗБ. Нормальный API должен принимать дату исключительно в формате ISO и слать нахрен тех, кто шлёт дату чёрти как.
Хорошо, переформулирую по ISO 8601: 2021-10-21T12:04:52. Какое это время в utc+0?
Local -> UTC при работе с API базы. API принимает дату в любом формате, но делает преобразование при необходимости. Или вы предлагаете в базу писать напрямую, минуя API?
1. Как он узнает, что есть необходимость? Пришла вам DateTime в виде строки с фронта. Тот же «10/21/2021 12:04:52 AM». Там нет никакого флажка, показывающего тип даты. Что делаем?
2. API будет один-единственный на все даты системы?
Вы о каких преобразованиях? Давайте на примере, в БД хранится значение, скажем, DateTime = 10/21/2021 12:04:52 AM, Kind — Local.
Расскажете, как грамотно написать API, чтобы получить UTC+0?
Я с вами разговариваю аргументами — а вы пытаетесь в ответ «задавить авторитетом». Я вам говорю — да, я знаю, часовые пояса — это сложно, но не повод же отказываться от них. Вы мне в ответ — вон есть свойство, это точно повод отказаться от часовых поясов!
Это как бы намекает что местное время (с часовым поясом) не всегда может однозначно определять момент во времени.
В каких ситуациях в вашей практике такое случалось? Как много записей из миллиона будут такими?
Серьезно, следуйте рекомендуемым практикам и не стреляйте себе в ногу.
Use this structure to work with dates and times whose offset (or difference) from UTC is known. The DateTimeOffset structure combines a date and time value with that time's offset from UTC. Because of its relationship to UTC, an individual date and time value unambiguously identifies a single point in time. This makes a DateTimeOffset value more portable from one computer to another than a DateTime value.
Часовым поясам вполне можно верить, просто нужно понимать, что смещение относительно UTC — это не вся необходимая информация, есть ещё локальное регулирование, тут уже нужно знать именование зоны, что не поддерживает DateTimeOffset, но поддерживает NodaTime.
Да, часовые пояса — это сложно, и если у вас будет подобная задача про соотношение исторических данных на обширных территориях, то вы действительно пройдёте все круги ада и стадии принятия, но у вас есть шанс успешно выполнить задачу.
Если у вас всё в UTC+0, то уже час ночи по Москве станет у вас предыдущей датой, и круги ада начнутся сильно раньше. То, что часовые пояса — это сложно всё-таки не повод от них отказываться совсем.
Если вы персонально живёте по локальным часам, то распределённая система — нет. От часового пояса будет зависеть, например, в какой день произошло событие в том конкретном месте, где оно произошло. Если у вас есть завязка на дни (типа, доставка в течении 3 дней) — то система, например, может считать доставку просроченной, хотя есть ещё день.
И то, что большую часть времени всё будет работать хорошо — сделает вам трудности в отладке. По данным у вас всё будет прекрасно. Или нет? Вы будете видеть, что товар пришёл ночью, хотя по факту он пришёл днём. Это кто-то где-то отправил Now? Может, кто-то залез в БД руками? Или всё правильно, но часовой пояс в том месте, где произошло событие такой, что в UTC+0 получилась другая дата? Во время отладки надо ещё не забыть про этот момент, который «не проблема подхода».
И тут — эврика, вы понимаете в чём проблема! Только решить вы её уже не сможете, у вас весь массив данных не содержит информации о часовых поясах.
Мысль с календарным днём натолкнула меня на свою неправоту раньше: нет, UtcNow не будет работать, даже в случаях, когда все следуют одному правилу. Если нужны часовые пояса — используйте DateTimeOffset.
Мне грустно повторяться, но выше я уже написал, что такая нормализация будет хорошо работать. Ровно до момента, пока кто-то, кто не в курсе (а, согласитесь, это рано или поздно наступит) не начнёт записывать просто DateTime.Now. И тогда у нас какой-нибудь список событий превратится в кашу, когда создание товара было после его отправки. Если вас не слопают пользователи на этом или вы готовы к такому повороту, учитывая, что отлаживать это не так-то просто, а взять информацию о том, какое значение корректное неоткуда — хорошо.
Давайте тогда поймём, зачем нам такая красота нужна. Вы пишете, что мы вдвое экономим место. Тут нужно уточнение, где именно. Например, в postgresql типы timestamp with timezone и timestamp without timezone занимают одинаково — 8 байт. Если речь про память, то DateTimeOffset занимает 12 байт для 32-битных систем и 16 байт для 64-битных, когда DateTime — 8 байт везде. Если такая экономия оправдана, то я полностью согласен — это оптимизация.
Стоит ли она озвученных мной рисков — инженерное решение, но я бы рекомендовал использовать DateTimeOffset по умолчанию. Всё же в реальных промышленных приложениях лучше пожертвовать несколькими байтами памяти, чем долго и мучительно страдать, пытаясь откопать истоки проблем с этими проклятыми датами.
Когда данные собраны в базу из разных источников, в подавляющем большинстве случаев неважно знать, какой часовой пояс использовал пользователь/система в момент отправки данных.
Можете привести какую-то статистику, или это просто мнение, взятое с потолка?
Так или иначе, это очевидно, что хранить ненужные данные — избыточно. Но в этой ветке речь идёт о том, когда часовой пояс важен.
Так что вы хотите сказать, в контексте? Что нужно использовать DateTime.UtcNow и терять то время, что было у пользователя, потому что это неважно знать? Или что нужно конвертировать каждый раз в локальное время? Или что в подавляющем случае время неважно и вообще надо на него забить?
Этот вопрос можно адресовать мейнтейнерам официальных репозиториев.Прямо в конце первого же абцаза по ссылке уточняется, что дистрибутивы распространяются через репозитории. Можно и бинарниками, при необходимости. Если таблица совместимости — это что-то ужасное, то прошу ужаснуться таблице совместимости jdk
Понимаю, что неприятно, когда вас поправляют, но увы, факт есть факт.
Впрочем, с 10-х пираты уже не те, и подобное действительно происходит очень редко.
1. Просто вкинуть кучу кода, причём ещё два раза один и тот же — это не совсем статья, мне кажется. Если она нацелена на тех, кто не умеет делать контролы, то они ничего не поймут.
2. Есть контрол ToggleButton, используйте его
3. Зачем нужен IsCheckable? Есть IsEnabled.
4. Для изменения стиля контролов в wpf используются… стили и шаблоны. Если нужно динамически изменять их (для чего-то же вам нужна была DependencyProperty) — используйте DynamicResource. Следовательно, свойства для иконок и цветов не нужны.
5. Если таргетите .net framework — рекомендую использовать библиотеку Bindables, сократит код для DependencyProperty до двух строк + код обработки.
6. wpf-way — это использовать биндинги. Например, ButtonImage вы меняете в code-behind, это не нужно. В итоге сами свойства вы хоть и меняете, но вообще не используете.
7. В IsCkeckedPropertChanged вы меняете руками стили хардкодом. А что если я захочу в каком-то месте другой стиль при нажатии? Это делается триггерами, завязанными на IsChecked — когда он true, то одни сеттеры, когда false — другие. Хочет пользователь поменять только что-то одно, унаследуется от стиля и поменяет. Захочет что-то своё, сделает свой стиль.
8. UserControl_MouseEnter и UserControl_MouseLeave — то же самое. Делаем триггер стиля на IsMouseOver.
Так это же работа с файлами. Я спрашивал про сокеты.
Так это же вы написали про свою библиотеку)
Memory — это «не обёртка над управляемым массивом». Так что, действительно, RTFM.
Силюсь понять, для чего может быть нужна своя библиотека для работы с сокетами — и не получается.
А зачем вообще тут использовать именно неуправляемый буфер, а не, скажем, Memory{T}?
Но мне интереснее то, как вы работаете с ситуациями, когда изменение на UTC+0 меняет хранимую дату?
Хорошо, переформулирую по ISO 8601:
2021-10-21T12:04:52. Какое это время в utc+0?1. Как он узнает, что есть необходимость? Пришла вам DateTime в виде строки с фронта. Тот же «10/21/2021 12:04:52 AM». Там нет никакого флажка, показывающего тип даты. Что делаем?
2. API будет один-единственный на все даты системы?
Расскажете, как грамотно написать API, чтобы получить UTC+0?
В каких ситуациях в вашей практике такое случалось? Как много записей из миллиона будут такими?
Договорились, буду следовать рекомендациям:
Да, часовые пояса — это сложно, и если у вас будет подобная задача про соотношение исторических данных на обширных территориях, то вы действительно пройдёте все круги ада и стадии принятия, но у вас есть шанс успешно выполнить задачу.
Если у вас всё в UTC+0, то уже час ночи по Москве станет у вас предыдущей датой, и круги ада начнутся сильно раньше. То, что часовые пояса — это сложно всё-таки не повод от них отказываться совсем.
И то, что большую часть времени всё будет работать хорошо — сделает вам трудности в отладке. По данным у вас всё будет прекрасно. Или нет? Вы будете видеть, что товар пришёл ночью, хотя по факту он пришёл днём. Это кто-то где-то отправил Now? Может, кто-то залез в БД руками? Или всё правильно, но часовой пояс в том месте, где произошло событие такой, что в UTC+0 получилась другая дата? Во время отладки надо ещё не забыть про этот момент, который «не проблема подхода».
И тут — эврика, вы понимаете в чём проблема! Только решить вы её уже не сможете, у вас весь массив данных не содержит информации о часовых поясах.
Мысль с календарным днём натолкнула меня на свою неправоту раньше: нет, UtcNow не будет работать, даже в случаях, когда все следуют одному правилу. Если нужны часовые пояса — используйте DateTimeOffset.
Давайте тогда поймём, зачем нам такая красота нужна. Вы пишете, что мы вдвое экономим место. Тут нужно уточнение, где именно. Например, в postgresql типы timestamp with timezone и timestamp without timezone занимают одинаково — 8 байт. Если речь про память, то DateTimeOffset занимает 12 байт для 32-битных систем и 16 байт для 64-битных, когда DateTime — 8 байт везде. Если такая экономия оправдана, то я полностью согласен — это оптимизация.
Стоит ли она озвученных мной рисков — инженерное решение, но я бы рекомендовал использовать DateTimeOffset по умолчанию. Всё же в реальных промышленных приложениях лучше пожертвовать несколькими байтами памяти, чем долго и мучительно страдать, пытаясь откопать истоки проблем с этими проклятыми датами.
Так или иначе, это очевидно, что хранить ненужные данные — избыточно. Но в этой ветке речь идёт о том, когда часовой пояс важен.
Так что вы хотите сказать, в контексте? Что нужно использовать DateTime.UtcNow и терять то время, что было у пользователя, потому что это неважно знать? Или что нужно конвертировать каждый раз в локальное время? Или что в подавляющем случае время неважно и вообще надо на него забить?