|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Линда (Linda Yaw) выложила компиляцию некоторой части обсуждений. Выглядит примерно так: http://mumps.org/mdc/work/tg19/analysis-and-plan-20200608 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2020, 11:52 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Из новостей. Поддержка NEW $TEST добавлена в MiniM и MUMPS V1. В Cache и GT.M была добавлена ранее. В MiniM добавлена также форма с инициализацией NEW $TEST=expr. Предложение по добавлению NEW $TEST было датировано аж июнь 1994 года. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2020, 23:52 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Евгений, Относительно текущих версий Cache/IRIS это не так: см., например, $TEST и NEW , да и ошибка <SYNTAX> поправит сомневающегося. Более того, InterSystems едва ли нуждается в этой команде: ведь в Cache она выполняется неявно при вызове методов классов (даже по DO), а прочие DO ISC рассматривает как устаревший код и особо не заинтересована в их развитии. Раз уж зашёл разговор о Стандарте: свершилось чудо, и InterSystems начала участвовать в деятельности по подготовке нового Стандарта? Точной ссылки не нашёл, но по достоверным сведениям где-то в середине 90-х на одном из заседаний MDC их представитель заявил, что они более не считают себя связанными обязательствами по соблюдению Стандарта. Возможно, кто-то из членов MDC тех лет или сотрудников InterSystems мог бы уточнить этот момент, хотя исходя из текущего состояния языка ObjectScript он едва ли нуждается в уточнении. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2020, 21:31 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov свершилось чудо, и InterSystems начала участвовать в деятельности по подготовке нового Стандарта? Их представителей пока не наблюдал. Про NEW $TEST в Cache писал со слов, возможно не так перевел. Из новостей: добавляются операторы <= >= ]= ]]= Удалось отговорить от отрицаний '<= '>= ']= ']]= ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2020, 21:51 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Добавили бы ещё: $increment (вот он-то по факту есть "у всех": в Cache, YottaDB, GT.M, MiniM), $replace (Cache, YottaDB, MiniM(?)), $list* (Cache, YottaDB, MiniM). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2020, 11:04 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov Добавили бы ещё: $increment (вот он-то по факту есть "у всех": в Cache, YottaDB, GT.M, MiniM), $replace (Cache, YottaDB, MiniM(?)), $list* (Cache, YottaDB, MiniM). Про $increment и $bit пришлось рассказывать мини-лекцию, что это не столько для арифметики и конструирования строк как альтернатива $ZBIT, сколько для корректной работы транзакций. Если $i() и отыщется в планах, то это надолго. $replace в MiniM есть, даже есть $zpcrereplace с регэкспами. На добавление не-Z функций в MDC смотрят неодобрительно, но все же как на реальность. С $list надо вообще-то детально специфицировать что там с кодированием, что возвращает Код: plaintext 1.
Пока все относятся к листам как к чему-то с чем можно оперировать только через $list функции, то оно может быть как-бы и ок, но для стандарта описывать надо. Чтобы поведение программ было одинаковым для разных реализаций. Кстати, листы в YottaDB добавлял Константин? Помнится он рассказывал http://thedarkaugust.blogspot.com/2016/03/blog-post_20.html что у него листы конструируются лишь с частичной совместимостью с Cache. Интересно было бы узнать поподробнее о поддержке листов в YottaDB, как они сейчас сделаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2020, 12:14 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
ну я ...листы конструируются лишь с частичной совместимостью с Cache... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2020, 12:31 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
ну я добавляются операторы <= >= Мне всегда нравились <= => ну я Удалось отговорить от отрицаний '<= '>= ']= ']]= Правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2020, 13:42 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
ну я Пока все относятся к листам как к чему-то с чем можно оперировать только через $list функции, то оно может быть как-бы и ок, но для стандарта описывать надо. Чтобы поведение программ было одинаковым для разных реализаций. ну яДвоичная совместимость частичная...Похоже, так всё и осталось: Код: javascript 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2020, 14:37 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
ну я С $list надо вообще-то детально специфицировать что там с кодированием... А кстати, кто из остальных, кроме MiniM, участвует? Fidelity? YottaDB? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2020, 12:24 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov ну я С $list надо вообще-то детально специфицировать что там с кодированием... А кстати, кто из остальных, кроме MiniM, участвует? Fidelity? YottaDB? Участвует ISC в стандартизации или нет, в любом случае мне не попадалась формальная спецификация листов от ISC. За MiniM могу сказать то же самое, спецификация формата не открывалась. А по YottaDB - так вроде листы у вас, в СП.АРМ добавлялись, источник информации у вас. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2020, 12:54 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
ну я ...в любом случае мне не попадалась формальная спецификация листов ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2020, 13:09 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov А кстати, кто из остальных, кроме MiniM, участвует? Fidelity? YottaDB? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2020, 21:30 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Опять я дискуссию пропустил... Когда я писал про совместимость листов, имелось ввиду, что лист, созданный в одной системе, корректно прочитается в другой (допустим вы записали что-то в базу в формате $list и передали эти данные). Особенности связаны с форматами чисел, которые в разных системах имеют разную точность и разные диапазоны. Таким образом внутреннее представление будет отличаться (простейший пример 1000 и 1E3 - целое число и число с плавающей точкой с дробной частью, равной 0). Но при извлечении элемента и использовании его в операциях это будет одно и то же везде. Т.е. совместимость гарантирует правильное извлечение данных, а не двоичное совпадение полученных листов. Кстати, приведенный пример Alexey MaslovПохоже, так всё и осталось: USER>s a=$lb("0","0"),b=$lb(0,0) w a=b 0 YDB>s a=$lb("0","0"),b=$lb(0,0) w a=b 1 не совсем корректный, не зря для сравнения листов была введена функция $LISTSAME. Она в обеих системах даст одинаковый результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 17:53 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
И уж чтобы расставить точки на i, некорректное поведение в приведенном примере ИМХО со стороны Cache. Это связано с неявной типизацией данных, которая там появилась, однако используется совершенно беспорядочно и недокументированно. Я уже писал про $zhex, в листах проявляется то же самое. Результат зависит от предыдущей операции с этими данными ! Отсюда и необходимость в функции $LISTSAME. В нашем варианте в YottaDB функция $listsame была добавлена только для совместимости при переносе программ и данных между системами. USER>s a=$lb(1000),b=$lb(1E3) USER>w a=b 0 YDB>s a=$lb(1000),b=$lb(1E3) YDB>w a=b 1 Если уж говорить о стандартизации внутреннего формата, я бы хранил в листах только один тип данных - строки. Таким образом отпадает необходимость хранить признак типа, и остается предельно простая конструкция - длина и сама строка. Полная совместимость для любых М-систем будет обеспечена, поскольку не будет зависеть от специфики реализации внутреннего представления чисел. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 12:45 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
LittleCat ...пример не совсем корректный... Беглый просмотр заметки по MUMPS-2020 показал, что важная часть начатой работы: обновить минимальные требования к диапазонам и точности чисел, которая должна обеспечиваться стандартной М-системой. До стандартизации $list-ов ещё ох как далеко, хотя наверное она упростилась бы, если ограничиться таким определением: Если два листа a и b, созданные из набора элементов (a1,...,an) в двух разных М-системах, после двоичного копирования в любую из этих М-систем выдадут одинаковый результат $listsame(a,b) независимо от используемой М-системы, то формат листов в рассматриваемых М-системах логически совместим по чтению-записи и физически - по чтению. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 13:02 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov Просто он не о логической ($listsame), а о двоичной совместимости. При наличии функции $listsame полная двоичная совместимость ИМХО бессмысленна. Сейчас при обмене данными Cache <-> YottaDB функция $listsame в любой из этих систем выдаст правильные значения при сравнении листов, полученных на разных платформах. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 13:29 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Костя, это ведь не я завёл речь о кодировании $list, а Евгений, непосредственно участвующий в М-стандартизации: ну я С $list надо вообще-то детально специфицировать что там с кодированием, что возвращает $ascii($listbuild(expr[,...]),expr) Пока все относятся к листам как к чему-то с чем можно оперировать только через $list функции, то оно может быть как-бы и ок, но для стандарта описывать надо. Чтобы поведение программ было одинаковым для разных реализаций. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 13:56 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Ага, свое предложение по стандартизации я озвучил выше :-) Ну и еще попытался показать на примерах, как развитие без плана и стандарта может завести в дебри.... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 13:59 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Сами по себе скрытые типы данных - вещь неплохая: их наличие, очевидно, ускоряет арифметические операции и делает более компактным хранение чисел (если хранить в листах), ну и в Стандарте нет ни слова, что так делать нельзя. Других неприятностей с ними, кроме $zhex, вроде бы не наблюдается, а ей, кстати, ISC сама не рада: её унаследовали у одной из благоприобретённых М-систем и теперь вынуждены поддерживать (про это даже статья была на community). Да, могли бы объявить эту функцию "legacy" и предложить новую, "правильную", но видимо их основные клиенты уже привыкли к особенностям $zhex и непонятно, ради кого стараться. Новые идеи, и в частности функции, всегда воспринимаются и внедряются с трудом, поэтому понятна осторожность, с которой вендоры их добавляют. За последние 10 лет не припомню существенных добавок в базовый набор функций ObjectScript, кроме $locate и $match. Регулярные выражения - прекрасная идея, но вот кинутся ли, к примеру, разработчики YottaDB ("идя навстречу пожеланиям трудящихся") добавлять их в свой движок? - сомневаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 15:23 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov Сами по себе скрытые типы данных - вещь неплохая: С этим никто не спорит, я про подход. Получается, что результат операции зависит от предыдущих действий, и ты сам это наглядно показал на примере нуля в листах, который получен разными способами. Про $zhex я писал. А сколько еще таких мест, на которые мы пока не наткнулись ? Вот в чем проблема, а не в каких-то конкретных задачах. Я как-то привык, что если у меня есть число 1.34, и я хочу взять целую часть, то я могу это сделать разными способами. Но получается, что результат не совсем одинаков. Мне этого не видно и заранее проверить это я никак не могу, и дальнейшие операции с этими данными дают разный результат. И это в пределах одной системы ! (Чего уж там кросплатформенная ^DATACHECK) USER>s a=$lb(1.34\1) USER>s b=$lb($p(1.34,".")) USER>w a=b 0 $LB и $ZHEX, это то, что мы знаем. Но после этого кто может гарантировать, что нет еще каких-то плюшек на эту тему ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 15:42 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
$list и все что около не использую. Пока не будет сделано как предлагает Константин - тип данных только строки. А то понаделали тут панимаешь ... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 16:23 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
LittleCat Я как-то привык, что если у меня есть число 1.34, и я хочу взять целую часть, то я могу это сделать разными способами. Но получается, что результат не совсем одинаков. ... $LB и $ZHEX, это то, что мы знаем. Но после этого кто может гарантировать, что нет еще каких-то плюшек на эту тему ? 1) Целая часть числа - это первый элемент списка, а не весь список. И результат таки одинаков: Код: sql 1. 2. 3. 4.
2) Плюшки есть, куда ж без них? О них ранее упомянутое эссе разработчика ISC КМК, Стандарт ограничивает вендоров, и в погоне за (... впишите нужное...) они вольно или невольно его нарушают. В GT.M/YottaDB, скажешь, плюшек нет? Как хорошо сказал K.S.Bhaskar, "Стандарт - это то, к чему мы привыкли". Однако, если стандартизаторы будут последовательны на выбранном пути:
... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 16:25 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov И результат таки одинаков: Как добыть правильные данные, мы все знаем, я про другой результат, из твоего первого примера про нули. Alexey Maslov В GT.M/YottaDB, скажешь, плюшек нет? Я такого не говорил. Там тоже есть плюшка с сортировкой длинных чисел в индексах, вопрос о которой я пытался поднять, но не был понят. Вот пример проблемы (под другой системой подразумевается Cache) S arr("202004080830202004080930")="" S arr("202004090830202004090930")="" s arr("202004090800000000000000")="" s x="" f s x=$o(arr(x)) q:x="" w !,x," ",+x Result in another system is normal numeric sorting 202004080830202004080930 202004080830202004100000 202004090800000000000000 202004090800000000000000 202004090830202004090930 202004090830202004100000 In YottaDB we see string sorting 202004090800000000000000 202004090800000000000000 202004080830202004080930 202004080830202004000000 202004090830202004090930 202004090830202004000000 Тут также из-за того, что целые числа имеют ограниченную точность, то, что влезает в сетку, сортируется как числа, а что нет - как строки. ИМХО это неправильно, но переубедить пока не удалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 16:39 |
|
MUMPS 2020
|
|||
---|---|---|---|
#18+
Alexey Maslov Костя, это ведь не я завёл речь о кодировании $list, а Евгений, непосредственно участвующий в М-стандартизации: ну я С $list надо вообще-то детально специфицировать что там с кодированием, что возвращает $ascii($listbuild(expr[,...]),expr) Пока все относятся к листам как к чему-то с чем можно оперировать только через $list функции, то оно может быть как-бы и ок, но для стандарта описывать надо. Чтобы поведение программ было одинаковым для разных реализаций. $ascii() это и есть не двоичный формат представления, это функция языка, которую могут использовать программисты чтобы посмотреть какую последовательность образует строка. В принципе, то что получено в качестве $LB(), может быть получено и конкатенацией, и как-то иначе. И Евгений не может пояснить почему это стало важно в 2020, потому что это всегда было важно. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2020, 17:01 |
|
|
Start [/forum/topic.php?fid=39&msg=39980391&tid=1556118]: |
0ms |
get settings: |
24ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
84ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
470ms |
get tp. blocked users: |
2ms |
others: | 335ms |
total: | 954ms |
0 / 0 |