бггг)

Надеюсь, что новая ориентация группы никого не заставит из неё выходить, а наоборот добавит мужества изучить замечательный язык программирования 1С. Всем добра)

Ребят, кто уже проводил интеграцию 1C и эликсира? есть какая-нибудь либа?

Дочку разыграл, создал копию сайта школы и добавил новость

Есть либа

1СEX

неужели с 1С так все плохо?)

Это божественно, причем с ней работать заебешься)))

Или это значит, что одного раза достаточно?

Ну так вот, дочка повелась. Кашу и брокколи не переносит

Ждет, что мы будем с собой еду давать

кто иконку поменял!?

да я чуть из чата не удалился

да я чуть из чата не удалился

не переживай, сейчас в два раза больше одинэсников набежит

ХМЛХТТП

так что, лично мне кажется что тут оптимизация никакая не нужна

Категорически не согласен.

я обдумал, достаточно логичное решение что <> создаёт дополнительный binary

Зачем создавать строку, если уже на стадии компиляции ясно, что это один utf8- символ?

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

Зачем создавать строку, если уже на стадии компиляции ясно, что это один utf8- символ?

просто <> уже срабатывает после того как из символа мы делаем строку грубо говоря мы делаем str <> to_string([ch_num])

charlist-то это же список с числами

если мы будем его молча приводить к строкам полезут баги, не?

не совсем. мы делаем скорее <<str::binary, from_string(to_string([ch_num]))>>

я понимаю что тебе хочется, но мы же говорим про изменение оператора <>

по сути сейчас он конкатенирует 2 строки

а charlist строкой не является

по сути сейчас он конкатенирует 2 строки

я не предлагаю менять оператор <>

я предлагаю сделать оптимизатор чуточку умнее и все

понятное дело, что писать str <> char_num явная синтаксическая ошибка

ну а str <> [72] ?

список-то тут причем?

эликсировские строки - не списки

http://joxi.ru/MAjzpGZUvMPzOA?d=1

это чарлист, а не стринг

ты то не строки соединял, а к строке прибавлял charlist

ну а ch::utf8

это же по чарлисту и матчим

по чарлисту?

::utf8 это вроде просто модификатор внутри binary, разве нет?

для строк бы ты просто написал str1 <> str2 и никакой магии с <<>> не понадобилось бы

секунду

для строк бы ты просто написал str1 <> str2 и никакой магии с <<>> не понадобилось бы

ну я мог бы написать и <<str1::binary, str2::binary>>, собственно, в это и компилируется str1 <> str2

ну да

и он компилирует правильно

а ::utf8 преобразует число в binary

секунду, в доке посмотрю

https://elixir-lang.org/getting-started/binaries-strings-and-char-lists.html

http://joxi.ru/ZrJepNGH1LjJxA?d=1

это понятно, я сообщаю, что вот это целое на самом деле последовательность байт в кодировке utf8

хотя, не, там и binary хавает

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

и char::utf8 таки не binary

ну да, потому что он для того символа создаёт отдельную строку

то есть ты хочешь определять в аргументах <> << >> и из них собирать общий?

неприятно, что приходится задумываться о том, что эликсировский путь приаппендить символ оказывается пессимизиован.

то есть ты хочешь определять в аргументах <> << >> и из них собирать общий?

мне нужно просто выдернуть utf8 символ из одной строки и прицепить к другой

Что-то типа такого case str do ... <<c::utf8, rest::binary>> -> blabla <> <<c:utf8>> ... end

я сделал, все работало, но как-то неспешно. я заменил кусок кода на <<blabla::binary, c::utf8>> и оно ускорилось процентов на 10-20

ааа, я понял

да, тут какая-то жесть

но думаю это с эрлангом связано

минутку

http://joxi.ru/BA06RMNTBO6Jlm?d=1

если матчить через ::utf8 возвращается число и тебе его приходиться потом конвертировать

поэтому предлагаю матчить через binary-size графемами и потом также конкатенацией <> можно будет собрать (и она будет эффективна)

проблема в том, что про binary-size я в исходниках прочитал (((

и в доке это хз где отражено

в общем да, это место мутно и туманно и думаю тут из-за совместимости с синтаксисом эрланга так всё сложно

в общем да, это место мутно и туманно и думаю тут из-за совместимости с синтаксисом эрланга так всё сложно

я знаю про binary-size, но оно не подходит

у меня же utf8

например для русских букв надо делать binary-size(2)

а как вообще определить кодировку ?

хммм

ты прав

это я в этом вопросе не до конца разобрался

ну значит этот модификатор должен возвращать binary чтобы было логично

ибо хрень какая-то

ну значит этот модификатор должен возвращать binary чтобы было логично

этот модификатор возвращает Integer

Integer можно напрямую аппендить к бинарю, не обязательно как ut8-кодпойнт, и наооборот напрямую выдрать из бинаря.

это понятно, но если бы возвращалась строка, не было бы вопросов тогда ни у кого

эти лишние сущности с циферками, мне кажется что это от эрланга без поддержки unicode приехало

это понятно, но если бы возвращалась строка, не было бы вопросов тогда ни у кого

вопросов и так ни у кого, если не слишком лезть в дебри. Это вопрос исключительно оптимизатора, то ли эрланговского, то ли эликсировского, хз

эти лишние сущности с циферками, мне кажется что это от эрланга без поддержки unicode приехало

надо порыться может есть какой-нибуд char-size или uttf8-binary :)

вопросов и так ни у кого, если не слишком лезть в дебри. Это вопрос исключительно оптимизатора, то ли эрланговского, то ли эликсировского, хз

теперь уже я тоже косо в сторону эликсировского смотрю

=)

тоже воюю с кодировкой, хоть викторину устраивай

кто разгадает что за кодировка и какой там текст тому приз

мы тут с кодировкой не воюем :) кодировка у меня точно известная - utf8

распознавание кодировок - штука неточная и непростая

а вообще, все кодировки должны умереть кроме utf-8

а вообще, все кодировки должны умереть кроме utf-8

ага, в 2054 году

ага, в 2054 году

оптимист, однако

Кто хочет максимально правильной работы с кодировками - смотреть на IBM ICU.