Ага только не во всех браузерах SameSite=None; работает, так же как в новом Chrome. Так что нужен еще фильтр по UA. Потом, кто придумал, что там всегда должно быть Secure. Это вообще не понятно. Если я отдал куки по HTTP, то хочу по HTTP и получить. А вот разработчики Chrome придумали, что так нельзя. Привет, тепер у тебя куча лишнего геморроя с HTTPS для того чтобы запустить и протестить что то локально. Ясно что можно выключить в настройках браузера… Но это пока.
Я имел ввиду, что этот адаптер генерирует строку. Дело не в спорте. Если завтра выйдет новая версия TS, то вам 1. придется как-то проверять, что ваш генератор генерирует все еще корректный код 2. в случае проблем исправлять В случае использования родного TS AST вы получите часть проверок автоматически, ну и из AST вы всегда получите корректный код, потому что это гарантирует сам TS. Показать не могу это не опен сорс. И вообще это Java. OAS-спецификацию не могу прокрутить у меня на входе Java класс как объект Class<?>, на выходе AST TS модуля (точнее декларации). Чтобы посмотреть на что это похоже посмотрите это https://ts-ast-viewer.com/#
Просто буквально с месяц назад писал генератор TS интерфейсов из Java типов. Я знаю, что есть готовые. Но мне, как обычно, не подходили по тем или иным причинам. Поэтому пошел посмотреть на исходники.
И что же я вижу — генерация стрингов… Ну так не спортивно. Надо же AST генерировать. В TS все есть для этого.
Его же можно потом трансформировать еще, можно просто распечатать в строку. Но будет медленней конечно. Зато более поддерживаемо.
Все равно автор неправ для целых типов можно не делать полные перегрузки, как в статье.
public static IEnumerable<T> Consume<T>(this IEnumerable<T> source, T quantity) where T : IConvertible {
if(source == null) yield break;
long accumulator = 0;
long qLong = Convert.ToInt64(quantity);
foreach(T i in source) {
if(qLong <= accumulator) {
yield return i;
}
accumulator += Convert.ToInt64(i);
}
}
Наверно можно написать и более "дженерик вариант", если еще потребовать от T поддержку IComparable и использовать достаточно широкий аккумулятор, чтоб не попасть на переполнение или потерю точности, впрочем с плавающей точкой это не решается и в "правильном" варианте, надо знать что там внутри у метода
Ну если определить соответствующие операторы для string и int то такой код может быть корректным, а так конечно это не в ту сторону по шкале движение, в том смысле что статический контроль типов наоборот подавлен dynamic, там можно еще поиграть, например обявить T quantity, тогда ваш пример будет падать уже при компиляции, не знаю можно ли в с# как то форсировать проверку наличия оператора для дженерик типа..., так это переносится в рантайм.
ну с дженериками можно написать, если добавить еще дженерик интерфейс который умеет складывать и сравнивать, да к каждому типу придется еще делать имплементацию интерфейса. А вообще странно я на С# давно не писал, но почему нельзя написать сложение произвольных типов если есть перегрузка операторов.
А я про тормоза ничего не говорил. Я думаю, что Java на ПК и native code на малине будут иметь сравнимую производительность. Да ради бога я ему выделил 8 гиг памяти — пусть только работает. Тогда бы я начал с pocketsphinx заморачиваться.
Какая разница на чем написан, если все равно толком не работает? И его не вчера начали делать. Иногда проще начать с начала, чем допиливать. И на кошерной сишечке можно наваять лапши. В общем я больше надеялся, что кто-то напишет, что это у меня руки кривые, а у него все работает и замечательно распознает русский. Но таких видать нет. И 99% людей не будут ничего допиливать, они просто захотят его использовать и получат разочарование и потерянное время.
Ну русский там поддерживается довольно условно. Оно основано на Sphynx4. Не знаю может на малине pocketSphynx работает и лучше, но я как эту новость увидел на hackernews взял обычный для Java. Модель для русского языка датированную 16 годом а я думаю для pocketSphynx используется та же модель. И что? Ничего оно не распознает, только память жрет гигабайтами. Кстати модель английского и меньше и менее прожорливая, но все равно не распознает. Так что сфинкс в топку. Ну для английского есть альтернатива, ее я не проверял. А для русского заявлен только сфинкс. Так что можно было просто поверить комментариям на hackernews и не заморачиваться проверкой. Хорошо не стал тратить время на сетап этого всего на малине.
Это чего? Руками надо скрипт писать для документа? Так а чего сразу не взять Apache POI для Java? Будет тоже самое, только на чистой Java. Если бы их редактор умел хотя бы записывать макрос по действиям пользователя (ну там будет много мусора) или из документа сгенерировать скрипт, что не так и сложно. Было бы намного проще.
https://www.chromium.org/updates/same-site/incompatible-clients
Ага только не во всех браузерах SameSite=None; работает, так же как в новом Chrome. Так что нужен еще фильтр по UA. Потом, кто придумал, что там всегда должно быть Secure. Это вообще не понятно. Если я отдал куки по HTTP, то хочу по HTTP и получить. А вот разработчики Chrome придумали, что так нельзя. Привет, тепер у тебя куча лишнего геморроя с HTTPS для того чтобы запустить и протестить что то локально. Ясно что можно выключить в настройках браузера… Но это пока.
Я имел ввиду, что этот адаптер генерирует строку. Дело не в спорте. Если завтра выйдет новая версия TS, то вам 1. придется как-то проверять, что ваш генератор генерирует все еще корректный код 2. в случае проблем исправлять В случае использования родного TS AST вы получите часть проверок автоматически, ну и из AST вы всегда получите корректный код, потому что это гарантирует сам TS. Показать не могу это не опен сорс. И вообще это Java. OAS-спецификацию не могу прокрутить у меня на входе Java класс как объект Class<?>, на выходе AST TS модуля (точнее декларации). Чтобы посмотреть на что это похоже посмотрите это https://ts-ast-viewer.com/#
Просто буквально с месяц назад писал генератор TS интерфейсов из Java типов. Я знаю, что есть готовые. Но мне, как обычно, не подходили по тем или иным причинам. Поэтому пошел посмотреть на исходники.
И что же я вижу — генерация стрингов… Ну так не спортивно. Надо же AST генерировать. В TS все есть для этого.
Его же можно потом трансформировать еще, можно просто распечатать в строку. Но будет медленней конечно. Зато более поддерживаемо.
Ну простую можно копипастить. Что то более сложное лучше обобщать. А на std лежит еще тяжесть обратной совместимости.
Все равно автор неправ для целых типов можно не делать полные перегрузки, как в статье.
Наверно можно написать и более "дженерик вариант", если еще потребовать от T поддержку IComparable и использовать достаточно широкий аккумулятор, чтоб не попасть на переполнение или потерю точности, впрочем с плавающей точкой это не решается и в "правильном" варианте, надо знать что там внутри у метода
Ну если определить соответствующие операторы для string и int то такой код может быть корректным, а так конечно это не в ту сторону по шкале движение, в том смысле что статический контроль типов наоборот подавлен dynamic, там можно еще поиграть, например обявить T quantity, тогда ваш пример будет падать уже при компиляции, не знаю можно ли в с# как то форсировать проверку наличия оператора для дженерик типа..., так это переносится в рантайм.
а что ожидалось?
А так работает