Путь приложения

Sat Nov 26, 2016 9:51 pm

Pathoswithin wrote:Тут Siemargl прав, бранчи нужны для тех дел, которые заведомо (и масштабно) ломают что-то конкретное.

no comments

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

А кто мешает настроить автосборку для конкретной ветки? И создать специальную тему на форуме, с описанием чего и как тестировать. Что, знаний и прав не хватает или религия не позволяет?

По поводу тестирования и сообщений об ошибках песня отдельная:
За всё время, что я "тусуюсь" на форуме, никто не пригрозил пальцем и не послал в багтрекер. Им кто-нибудь пользуется? Он вообще работает? И ладно я нуб. Но вы, "светила компьютерных наук", вы-то чего расслабились?
Хотя, на несерьёзном проекте он пожалуй не нужен...

Sat Nov 26, 2016 9:58 pm

Mega_Myr wrote:Хотя, на несерьёзном проекте он пожалуй не нужен...

Вот это ключевой момент, похоже.

Sat Nov 26, 2016 10:59 pm

На серьёзном проекте всё начинается с планирования. Планирования не было - проект несерьёзный. И текущие проблемы с этим связаны.

Pathoswithin wrote:Там, где раньше был путь в cp866, сейчас путь в utf-8. Существующие приложения редактируют конец строки и передают её в 70 функцию, которая определяет строку как utf-8 благодаря префиксу в начале. Как это будет работать без префикса?

0CodErr wrote:Я тебе уже говорил как и куда можно воткнуть этот байт.

Поцiент безнадёжен. Пожалуй, не буду тратить на него время.

Siemargl
Всё правильно.

К сожалению, 'sys' это ключ, и по другому сделать сложно. К счастью, он всегда равен рамдиску.

Sat Nov 26, 2016 11:07 pm

Нафига вообще новые создавать?! Тут все плачутся, что дескать разработчики не идут. Идут. Но всё больше прочь.

Sat Nov 26, 2016 11:19 pm

Pathoswithin
Текущие проблемы проблемы связаны с тем, что ты нарушил совместимость с POSIX.
От того, что проблему подпёрли костылём она не исчезла.
Продублирую свой пост

Siemargl wrote:fopen все так же не хочет создать файл с юникодным относительным путем

Пока не ясно, что с ними делать. Префиксы кодировки это нарушение POSIX. Нет там такой фигни. Или пути "/hd0/1/☺my_file" "/hd0/1/♥my_file" "/☺/hd0/1/♥my_file "/♥/hd0/1/☺my_file" должны указывать на один файл "/hd0/1/my_file"

Даже если "☺my_file" "♥my_file" "my_file" будут приниматься ядром как одинаковые это не избавит от проблем в существующем коде.

Пока префикс кодировки не будет убран, будут ошибки.
Карфаген должен быть разрушен.

Sat Nov 26, 2016 11:32 pm

Простой тест показал, что всё хуже, чем казалось:
♥☺222.png валидное имя файла в Windows. Так что не ясно является строка "♥☺222.png" utf-8 кодировкой имени "☺222.png" или нет.
С чем всех и поздравляю.

: 11.png (68.68 KiB)
Viewed 4826 times

Update.
Был неправ. символы ☺☻♥ двубайтные.

Sat Nov 26, 2016 11:36 pm

Я вообще не могу понять, как у вас такие пути получаются? Зачем строке маркер, если она будет обрабатываться? А если нужно обработать строку с маркером, почему нельзя использовать указатель+1?

Sat Nov 26, 2016 11:41 pm

Ну я предлагал такой вариант
кодировку сюда

Code: Select all

  * +20 = +0x14: byte: 0 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

и вот это

Code: Select all

(указатель | 0x80000000)

На ЯВУ это могут быть разные обёртки с суффиксами A и W.
Или же просто всюду использовать юникод(кому как нравится).

Sat Nov 26, 2016 11:43 pm

Pathoswithin
Смотри мой пост выше. Как сейчас файловая система будет обрабатывать имя "♥♥events_subsystem.txt ?"
Карфаген надо разрушать

Sat Nov 26, 2016 11:46 pm

Pathoswithin wrote:Я вообще не могу понять, как у вас такие пути получаются? Зачем строке маркер, если она будет обрабатываться? А если нужно обработать строку с маркером, почему нельзя использовать указатель+1?

Существующий код не предполагает, что имени файла присутствует префикс кодировки, который не является частью имени. Потому, что такое предположение не соответствует POSIX.

Sat Nov 26, 2016 11:52 pm

В виндовс есть супер префикс \\?\
Вроде никому не мешает, но написано, что не все функции его понимают.

Чем моя идея с префиксом по минусовому индексу(смещению) не понравилась?

Sat Nov 26, 2016 11:57 pm

Siemargl, префикс, он ведь необязательный. Но по минусовому смещению что-то всё равно будет. Если я тебя правильно понял, конечно.

Sat Nov 26, 2016 11:58 pm

Siemargl
1.Минусовый префикс коварная вещь. Он может попасть в несуществующую предыдущую страницу.
2.Это костыль к POSIX. По этой причине в gnu софте придётся писать спец. куски кода для Колибри.

Sun Nov 27, 2016 12:26 am

Serge « Вс ноя 27, 2016 2:10 am » Siemargl: в любом случае эти символы уже не годятся для префиксов. Они валидные.

Судя по wiki для NTFS в пространстве имён Posix допустимы любые символы из кодировки UTF-16, кроме U+0000 (NUL) и «/» (косая черта).
Выходит, никакие не годятся.

Sun Nov 27, 2016 12:56 am

Serge wrote:Siemargl
1.Минусовый префикс коварная вещь. Он может попасть в несуществующую предыдущую страницу.
2.Это костыль к POSIX. По этой причине в gnu софте придётся писать спец. куски кода для Колибри.

1. Для argv[0] этот подход годится. Для файловых функций - не очень.
2. писать все= придется. можно лишь попытаться минимизировать.
POSIXовый бардак в API, с другой стороны, пора бы уже начать хоронить, а не равняться на него.

Кстати, ты вот ссылаешься на POSIX, а там AFAIK, вопрос кодировок то и не определен.

Я предлагаю выработать свой подход.
Пока озвучены варианты
- CleverMouse - привести все к UTF-8 (возможно, предложение касалось только argv[0])
- Pathos - префиксы, сюда же варианты их модификаций - двухбайтовые и по отрицательному смещению
- Win-подход - сделать группы функций, для каждой кодировки (UTF8, UTF16LE, CP866)

Путь приложения

Who is online