|
Notes |
|
|
|
|
Обсуждение также и тут - http://sasgis.org/mantis/view.php?id=1290 - наверное свяжите их связями? |
|
|
|
(0006713)
|
|
Tolik
|
|
05-05-2012 11:13
|
|
Надо обсуждать просто в правильной теме.
Если бы было легко переносить посты между хотелками - я бы перенёс. |
|
|
|
|
Перенёс сюда:
>в виде unit. Мне так проще
Тогда бери u_TileStorageBerkeleyDB, копируй его в своё название и вычищай оттуда всё связанное с беркли. Получишь пустую рыбу для простого хранилища. |
|
|
|
|
|
Да давайте сначала решим ЧТО делать, а уж КАК - потом разберёмся. :) |
|
|
|
|
Это вообще не связанные задачи ))
Тот же кэш GE - тоже полностью readonly. |
|
|
|
(0006746)
|
|
Garl
|
|
05-05-2012 12:01
|
|
|
насколько я понимаю у нас получается ограничение на 1 файл индекса? |
|
|
|
(0006752)
|
|
Dima2000
|
05-05-2012 12:09
(edited on: 05-05-2012 12:16) |
|
Э, да. 2ГБ. Примерно 120-130 млн тайлов. При размерах тайла в 10КБ это порядка терабайта. Да? А вот файлов данных может быть только 200ГБ (100*2ГБ).
Во всяком случае если сохранять совместимость с SAS4WinCE/SAS4Android.
|
|
|
|
|
>если сохранять совместимость с SAS4WinCE
Насколько я понимаю изначальную задачу - это подключение только для чтения результата экспорта. Наверное в такой постановке сохранять совместимость надо.
Или возможна прямая запись в хранилище, да ещё и с версиями тайлов, для полноценной работы? |
|
|
|
(0006756)
|
|
Garl
|
|
05-05-2012 12:17
|
|
|
ну совместимосто лучше сохранять, иначе - получится изобретение своего собственного кэша, который будет проигрывать BerkleyDB |
|
|
|
|
Нет, пока про запись в реальном времени (не экспортом) речи не идёт.
Как и про версию тайлов, по координатам z,x,y очень желательно иметь не более одного тайла (файла). Во избежание глюков. И для совместимости.
На лавры BerkleyDB я даже не замахиваюсь! Ни в коей мере.
За совместимость я +100500!
|
|
|
|
(0006762)
|
|
Garl
|
|
05-05-2012 12:40
|
|
|
у этого типа должен быть огромный плюс: скорость построения карты заполнения на больших зумах! |
|
|
|
|
А не будет. Скорость имхо ограничивается вовсе не работой диска, а скоростью перебора тайлов итератором. Вот тут (http://sasgis.org/mantis/view.php?id=1248) я уже предлагал закэшировать работу с диском, даже примерное решение предложил, мне поплевали на неуниверсальность для ЛЮБЫХ типов кэшей и забили ... Пока итераторами перебираются ВСЕ тайлы в регионе вне зависимости есть они или нет - оптимизировать работу с кэшем бессмысленно.
Сделайте экспорт в любой формат 100км*100км региона на 24-м зуме (которого нет!) и любуйтесь на перебор миллионов отсутствующих тайлов.
Ускорение будет только лишь если есть отдельный метод в хранилище для построения битовой маски наличия тайлов в заданном регионе. Он есть? ТАК ПОЧЕМУ ЖЕ ТОРМОЗИТ ПОСТРОЕНИЕ КАРТЫ ЗАПОЛНЕНИЯ СЕЙЧАС?!?! |
|
|
|
|
>оптимизировать работу с кэшем бессмысленно
Чтобы было что оптимизировать - надо чтобы было что оптимизировать.
Пока нет читалки для кэша SAS4WinCE/SAS4Android - это всё не более чем просто интересно.
>Пока итераторами перебираются ВСЕ тайлы в регионе
Сейчас есть возможность построить карту заполнения за один вызов хранилища. Если это хранилищем поддерживается и будет быстрее - флаг в руки. |
|
|
|
|
>надо чтобы было что оптимизировать
А оптимизировать работу родного кэша SAS значит не нужно, да?! Фигасе. Да он в тыщу раз нужнее! Для той же карты заполнения. Сколько народу пользуется SAS4WinCE и сколько родным кэшем? Несравнимо, имхо.
>Пока нет читалки для кэша SAS4WinCE/SAS4Android
Читалка проста, пишется за полдня если нет готового двоичного поиска (и пару часов если уже есть), оформление займёт больше времени. Алгоритм:
1. Найти в таблице Z[] нужный Z и взять указатель на таблицу X[Z].
2. Найти в таблице X[Z] нужный X и взять указатель на таблицу Y[Z,X].
3. Найти в таблице Y[Z,X] нужный Y и взять номер файла данных, смещение в нём, длину файла (всё в одной структуре).
4. Прочитать файл данных.
Первые 3 пункта относятся к файлу индекса. Все поиски в таблицах двоичные, таблицы сортированы по возрастанию, указатели прямые (int 32 бита).
>флаг в руки
Флаг беру. Буду изучать устройство хранилища по умолчанию и если там есть данный вызов - встрою туда ускорение, как понимаю.
А для начала напишу класс чтения пакованного кэша SAS4WinCE/SAS4Android. На днях. |
|
|
|
(0006774)
|
|
Garl
|
|
05-05-2012 15:32
|
|
вот кстати задачка встала : посмотреть покрытие файла .d00
навигатор далеко а на компьютере выходит никак и не посмотришь! |
|
|
|
(0006775)
|
|
vasketsov
|
05-05-2012 15:47
(edited on: 05-05-2012 15:55) |
|
>Буду изучать устройство хранилища по умолчанию и если там есть данный вызов
Данный вызов есть в кэше для GE. Он позволяет построить карту заполнения за один проход.
>оптимизировать работу родного кэша SAS значит не нужно, да?! Фигасе
Файловый кэш по умолчанию - не идексируемый (точне кэш в ядре конечно имеет свои плюшки, но нам, простым смертным, они недоступны). И в этом его беда (не единственная). Народ пользуется файловым кэшем не потому что он (кэш) так крут, а потому что на небольших масштабах он прост, надёжен и не требует ничего больше, никаких СУБД или DLL или ещё чего дополнительного.
Так что лучше посвятить силы созданию быстрого индексируемого версионного хранилища, а не заниматься ненужными "припарками" для "старого коня" (борозды не портящего, но и пашущего неглубоко).
|
|
|
|
|
Тссс, уже пишу класс чтения.
>посмотреть покрытие файла .d00
Правда это отдельная задача. И даже проще.
Прочитать начало файла, проверить сигнатуру (что дальше есть recovery info), если да, то пройти по файлу и читать info, в ней есть z,x,y и длина данных файла.
Не забыли что в файле данных все тайлы вперемешку с разных зумов? И не обязательно покрывают область (даже часть) целиком? Т.е. надо или для конкретного зума строить или несколько карт покрытия для каждого зума. И что строить? Битовую карту? Для z20 она 512К*512К битов! Или только в пределах указанного box?
>Данный вызов есть в кэше для GE
Спасибо, подгляжу. |
|
|
|
|
Про карту заполнения по битовой маске - доработка 1253.
>Или только в пределах указанного box?
Разумеется.
А если общее покрытие - наверное минимального зума и для него min-max будет достаточно. |
|
|
|
|
Минимальным может и z1 быть.
В пределах передаваемого box битовую карту можно. А зачем? Мне не совсем ясно.
А можно построить ограничивающий box для каждого зума, это полкилобайта всего. Его не хватит?
В 2ГБ файле данных может быть и пара миллионов тайлов (видел тайлы размером меньше килобайта), причём в общем случае разбросанных по всем зумам и по всей карте. |
|
|
|
|
|
dll в 1253-й посмотрю, спасибо, очень похожа. |
|
|
|
(0006782)
|
|
Dima2000
|
05-05-2012 17:24
(edited on: 05-05-2012 17:28) |
|
Garl, приложил прогу для вывода списка зумов и минимального ограничивающего box для каждого зума для файла *.d??. Прога консольная, тестовая, без оформления, вызывать с параметром имени файла.
|
|
|
|
(0006783)
|
|
Garl
|
|
05-05-2012 17:32
|
|
угу! спасибо. вот только в идеале увидеть бы это всё в карте заполнения :)
с другой стороны если бы мы в диалоге экспорта выбирали имя файла, то можно было бы сделать кнопку [i] для вывода инфо о выбранном файле, раз уж есть класс и он отдаёт данные :)
но это уже мечты ... |
|
|
|
|
Класса пока нет, прога тупо и без проверки ошибок идёт по файлу и набирает статистику. Без использования индекса, читается лишь .d?? файл. И только с recovery info разумеется.
И ограничивающий box - это совсем-совсем не карта заполнения...
>кнопку [i] для вывода инфо о выбранном файле
Я против, для получения такой инфы надо пройти по всему файлу. А если он на медленном устройстве? |
|
|
|
|
С классом пока небольшие проблемы, держать открытым файл индекса всё время существования класса не хочу (не знаю, может всё же придётся, но не нравится), а переоткрывать его заново для каждого тайла - явный идиотизм. Буду изучать вопрос, как делали умные люди до меня.
Ну и чтобы подогнать методы класса под стандарты Планеты надо тоже вникнуть... |
|
|
|
|
>держать открытым файл индекса всё время существования класса не хочу
Там есть метод Sync - тикает каждые 30 секунд или как настроишь. Запоминай GetTickCount (как DWORD) при операции обращения к хранилищу, а в Sync проверяй разницу GetTickCount и сохранённого значения, если большая - закрывай индекс.
1. Понятное дело открытие-закрытие индекса в критической секции.
2. GetTickCount не ходит в ядро - им можно пользоваться безболезненно. |
|
|
|
|
>увидеть бы это всё в карте заполнения
Т.е. построить карту заполнения по файлу .d00? Хм, идея интересна, но как это всунуть в GUI? Выбор файла? Если будете встраивать, то построение карты я пожалуй напишу ... В рамках этой же хотелки как часть поддержки такого формата кэша.
Проход по файлу и заполнение битового массива размером не более экрана (не гигабайты), с передачей в функцию ограничивающего box и зума. В будущем часть этого можно будет использовать и для класса (он будет строить карту не по файлу данных, а по индексу, это быстрее и логичнее для хранилища). |
|
|
|
|
>Там есть метод Sync
Спасибо за подсказку, так и сделаю, это правильно. |
|
|
|
(0006789)
|
|
Garl
|
|
05-05-2012 17:55
|
|
(если)когда будет полддержка этого типа кэша, там по идее будет опрос того есть файл или нету, и карта заполнения будет сториться автоматом...
если мне не изменяет логика |
|
|
|
(0006791)
|
|
Tolik
|
|
05-05-2012 17:59
|
|
|
Вот именно, опять отвлеклись на разные побочные фичи. Надо сначала сделать поддержку кэша, а там будет видно, как карты строятся и т.п. |
|
|
|
(0006792)
|
|
vasketsov
|
05-05-2012 18:01
(edited on: 05-05-2012 18:02) |
|
На самом деле можно и без GetTickCount обойтись, через Interlocked-функции и одним счётчиком, будет куда проще.
При обращении делать Increment.
А в Sync делать ему Exchange и сравнивать с нулём. Если 0 - соответственно не было операций.
>а там будет видно, как карты строятся
На самом деле карта заполнения строится и потайлово (без дополнительных телодвижений).
Так что гнев этот праведен :))))
|
|
|
|
|
>побочные фичи
Да, но их написать быстро. А класс долго. Да и часть кода пойдёт и в класс потом. |
|
|
|
|
|
Я заранее извиняюсь, но класс буду писать по шагам, от простого к сложному, не всё сразу. Похоже про пару часов написания я погорячился. :) |
|
|
|
(0006796)
|
|
Tolik
|
|
05-05-2012 18:13
|
|
|
Никто и не торопит, наслаждайтесь процессом. |
|
|
|
(0006808)
|
|
zed
|
|
05-05-2012 19:14
|
|
|
Dima2000, только вы наверное сделайте себе форк сасовского репо и все свои наработки оформляйте через пул-реквесты. Чтоб по-человечески всё было. |
|
|
|
(0006809)
|
|
Garl
|
|
05-05-2012 19:27
|
|
|
у тварища delphi5 форкать скорее будем от меого имени, или поможем и делфи и меркуриалом :) |
|
|
|
|
В качестве подсказки. Кроме реализации собственно Storage надо будет по коду поправить и дописать где надо.
То что делал vdemidov для новых типов кэша через фабрику и гуиды, ещё не доделано, а по старому:
1. Перечень в u_GlobalCahceConfig (соответственно добавляем константу перед implementation, очевидно 9).
2. Используем константу в коде, если не используем из-за нежелательности подключения модуля в uses - пишем её как комментарий (для целей дальнейшего поиска).
3. Все места в коде можно искать по строкам типа 'Cache_Id_GE', 'Cache_Id_BDB' или 'Cache_Id_GC' по всему проекту. |
|
|
|
(0006811)
|
|
zed
|
|
05-05-2012 20:04
|
|
>у тварища delphi5
Ну, если товарищ серьёзно задумал добавить более-менее сложный код в САС, то без отладки, как без рук. Т.е. ставить D2007 ему придётся по-любому. Иначе тут и говорить вообще не о чем. |
|
|
|
|
"Нет ребята, пулемёт я вам не дам!"(с)кино.
Ничего серьёзного я в Планету добавлять не собираюсь, как и обновлять дельфи и юзать меркуриал или репо.
По большому счёту, программа прекраснейшая! И меня раздражают лишь несколько моментов:
1. экспорт в SAS4WinCE (совместно реализовали),
2. тормозная карта заполнения (для родного кэша, другими не пользуюсь, кривовато но решил внешней утилиткой),
3. странный спиральный итератор (надеюсь прислушаетесь, поглядите и таки примете модификацию и поправите багу),
4. проход итераторов по отсутствующим тайлам (при экспорте, растеризации полигонов) - страшные тормоза,
5. отсутствие режима "инет без обновления кэша",
6. невозможность поставить на закачку лишь тайлы, присутствующие на другом зуме,
7. невозможность превратить карту заполнения в область выделения (реализует и предыдущий пункт),
8. строго подряд закачка тайлов, я бы предпочёл случайно накидать тайлов в регион, а если тайл есть, то запросить и рядом (такое или похожее уже описывалось) - многократно повысит скорость закачки в случае отсутствующих на сервере областей,
9. переключение по всем зумам, хочу отключать некоторые и колёсиком мыши шагать лишь по включенным (для каждой карты отдельно).
Пожалуй это всё. Кое-что сделано или почти сделано, что-то можно решить внешней утилитой, кое-что я точно не смогу, что-то уже запланировано вами. Ничего из этого не смертельно.
Если я могу помочь вам с этой прекрасной программой - флаг мне в руки. :) Но делать форк под себя - слишком неподъёмная задача. Тогда уж мне проще написать всё заново, сильно урезаное, зато понятное и шустрое. Но тем более не буду.
Вот как пример, чтение тайла из кэша SAS4WinCE я уже написал, оно наверное даже работает (во всяком случае уже компилится). А привести вызовы к вашему стандарту, который ещё отыскать надо, займёт ещё дня два. Вы ж ясно дело не будете встраивать метод .LoadTile(AXY,AZoom):string; ... |
|
|
|
|
|
А для отладки у меня есть консоль, команда Writeln(); и маленькие тестовые проги, вызывающие классы как угодно. :-D |
|
|
|
(0006817)
|
|
zed
|
05-05-2012 21:25
(edited on: 05-05-2012 21:30) |
|
>"Нет ребята, пулемёт я вам не дам!"(с)кино.
"Это несерьезно!"(c) "Операция Ы"
>Ничего серьёзного я в Планету добавлять не собираюсь, как и обновлять дельфи и юзать меркуриал или репо.
"Это же не наш метод!"(с) "Операция Ы"
>Но делать форк под себя - слишком неподъёмная задача.
Хинт: Чисто технически, форк делается нажатием ОДНОЙ кнопки на сайте.
Если уж это считать неподъёмной задачей, то я в растерянности. "Шеф, всё пропало!"(с) "Бриллиантовая рука"
>Вы ж ясно дело не будете встраивать метод
Меня терзают смутные сомнения, по поводу того, кто вообще будет встраивать этот тип кэша в САС, да и в смежной ветке про read-only кэш, ваше высказывание "И я готов написать всё необходимое, только встраивайте." вызывает у меня некоторое недоумение. Там же только внутренности саса и нужно ковырять. Ну да ладно, само как-нибудь устаканится.
|
|
|
|
(0006818)
|
|
zed
|
|
05-05-2012 21:29
|
|
>А для отладки у меня есть консоль
Одно дело отладить абсолютно изолированный класс, и совсем другое - написать и отладить новый тип кэша. То что будет класс чтения данных, это конечно плюс, но это только половина работы (а то и меньше), на пути реализации хотелки. |
|
|
|
|
zed: :))
>Одно дело отладить абсолютно изолированный класс
Да, разумеется.
Неподъёмной я обозвал не рег на сайте понятно, а разбирательство что и как устроено в Планете "внутрях". Поправить что-то мелкое (чем и занимаюсь) можно и так, а на крупное я не замахиваюсь.
"Написать всё необходимое" как раз и имелось в виду класс, готовый к подключению в Планету и сильно похожий на родителя (не меня ясно дело) или своего близкого аналога. С мелкими модификациями других файлов. Мелкими, формальными. Ну вот по типу как экспорт встроили.
Сделать ВСЮ работу по поддержке нового кэша я не обещался, это мне не по силам, извините.
|
|
|
|
|
|
Не святые горшки лепят. Присоединяйтесь. Там ничего сложного. И экспериментировать лучше с полной версией. И еще очень хорошо писать юнит-тесты. |
|
|
|
|
>Присоединяйтесь.
Спасибо, не обижайтесь, но нет.
Написать относительно независимый функционально законченный модуль (класс) могу, а что-то большее потребует гораздо более глубокого понимания взаимосвязей и взаимозависимостей в исходном коде. Сами же видите насколько глупые вопросы задаю даже при наличии исходников.
PS. Вы сглазили!! :-) Дельфя в gui перестала запускаться! Вылетает по ошибке записи памяти. Неделю назад работала. Только компилятором dcc32 и спасаюсь. |
|
|
|
(0006898)
|
|
Dima2000
|
08-05-2012 19:06
(edited on: 08-05-2012 19:08) |
|
Вопросик у меня возник, сколько ни смотрю исходники, ну никак не доходит. Help please.
В u_TileStorageFileSystem.pas метод LoadTile кроме самого тайла возвращает ещё и ITileInfoBasic - это обязательно? И как её формировать и что в неё входит? Судя по конструктору TTileInfoBasicExists.Create там и время, и размер, и версия, и ещё что-то непонятное про контент. Подскажите, может ну её? Приравнять nil и всё? Или где глянуть как её сформировать из z,x,y, размера тайла, флага его наличия? Других сведений о тайле в данном типе хранилища нету.
И второй, сразу уж. Метод LoadFillingMap делать или вы всё равно собрались их выковыривать из тайлохранилищ?
|
|
|
|
|
|
Ну раз версии нет, то вместо версии nil. Время какое хотите. Например по дате контейнера. ContentType берется из параметров хранилища так как он у вас для всех тайлов одинаковый должен быть. Посмотрите как сделано в хранилище тайлов в файловой системе. |
|
|
|
|
|
Метод LoadFillingMap можете не делать, если лень. От него будем избавляться. Новая реализация слоя заполнения его уже не юзает, но по-умолчанию она отключена. |
|
|
|
|
Приложил пока что получается, кое-что закомментировано. Посмотрите плиз, нет ли явных косяков?
Метод LoadFillingMap сделать не лень, просто нужно ли? Он вроде как быстрее должен работать чем с файловыми хранилищами (и намного).
>Посмотрите как сделано в хранилище тайлов в файловой системе.
Туда и смотрю, всё равно плохо понимаю. Вот так можно?
ATileInfo := TTileInfoBasicExists.Create(0, {Размер тайла}, nil, nil); |
|
|
|
|
|
А, ещё забыл спросить: если класс будет потомком TTileStorage, как по идее и должно быть, то что делать с остальными методами и пропертями? Они как бы не нужны получаются... |
|
|
|
|
|
Нельзя. контент тайп нужен обязательно. |
|
|
|
|
А что делать? Ведь в файлах не указан тип тайлов. Анализировать заголовок тайла?
Или примерно так? AContentTypeManager.GetInfoByExt(Config.TileFileExt); |
|
|
|
|
|
А что вам мешает сделать ровно точно так же как в TTileStorageFileSystem? |
|
|
|
(0006907)
|
|
Dima2000
|
08-05-2012 19:52
(edited on: 08-05-2012 19:54) |
|
Там вызывается ATileInfo := GetTileInfoByPath(VPath, AVersionInfo); - который лезет к файлу и возвращает TTileInfoBasicExists.Create(_GetFileDateTime, VInfo.nFileSizeLow, nil, FMainContentType) - где взять последний? Он в конструкторе чему-то приравнивается, можно сделать ровно так же?
Собственно я про это и спросил, там приравнивается именно AContentTypeManager.GetInfoByExt(Config.TileFileExt);.
|
|
|
|
|
>Он в конструкторе чему-то приравнивается, можно сделать ровно так же?
Именно. |
|
|
|
|
Я просто так и не понял что именно туда передаётся, потому и поостерёгся делать так же.
Сделал, спасибо.
Займусь LoadFillingMap. |
|
|
|
(0006911)
|
|
zed
|
|
09-05-2012 04:26
|
|
>Я просто так и не понял что именно туда передаётся
Вот причина, по которой таки нужно ставить делфи и смотреть код под отладчиком. Имхо, теряете много времени на догадки, когда можно просто взять и посмотреть. |
|
|
|
|
>теряете много времени на догадки
Немного спорно, одно конкретное значение ещё менее понятно чем именованный тип. Но в общем да, с отладчиком проще.
Странно что LoadFillingMap занимается и рисованием расчитанной карты, по идее вернули бы битовый массив наличия тайлов и всё, а уж как его отображать - дело вовсе не хранилища. Походу это пережитки прошлого, когда сделали карту заполнения "быстро и по простому"? Понимаю. Как понимаю и желание Демидова вынести это из хранилища. Сам пожалуй сразу так и сделаю, сначала битовый массив, а уж потом отрисовка. Ему потом работы меньше будет, может быть...
А ещё интереснее передать в метод указатель на функцию отрисовки флага наличия тайла. В частном случае функция может и просто бит в массиве ставить. Или рисовать сразу на экран. Выбор большой. Есть возражения к такой идее, с указателем на функцию? |
|
|
|
|
|
Нахрена битовые маски? там уже есть метод GetTileRectInfo. Все работает без всяких указателей и тд. И вполне быстро. |
|
|
|
|
>Нахрена битовые маски?
Не знаю ... Я привык всё экономить, да и про .tne забыл.
Спокойней пожалуйста, ну не разобрался.
>там уже есть метод GetTileRectInfo.
Посмотрел, по названию неясно его отношение к построению карты заполнения, вот и не обращал внимания, втюрился в LoadFillingMap.
Заполняет типизированный массив инфой о тайлах в box-е? О да, хороший метод. Зачем тогда вообще в хранилище LoadFillingMap, да ещё не на базе GetTileRectInfo?! Странно всё на мой взгляд, и непонятно.
Так всё же что надо реализовать в тайлохранилище для быстрого построения по нему карты заполнения? LoadFillingMap или GetTileRectInfo? Одна рисует в битмапку, вторая выдаёт массив с инфой ... Логичней вторую. Боюсь ответа "обе" ... Или достаточно вообще лишь TileExists?
>И вполне быстро.
Если всё так прекрасно - почему тормозит формирование карты заполнения на +4..+8 зуме?! Или для вас минута это "быстро"? :-( |
|
|
|
|
>Зачем тогда вообще в хранилище LoadFillingMap, да ещё не на базе GetTileRectInfo?! Странно всё на мой взгляд, и непонятно.
Затем что это устаревший метод, который еще используется.
Нужно реализовывать GetTileRectInfo и GetTileInfo. Все остальное подхватиться из родительского класса.
>>И вполне быстро.
> Если всё так прекрасно - почему тормозит формирование карты заполнения на +4..+8 зуме?!
А вы пробовали профайлером смотреть на что это время тратиться? Исключительно на запросы к файловой системе. |
|
|
|
|
>Нужно реализовывать GetTileRectInfo и GetTileInfo.
Спасибо! |
|
|
|
|
Приложил бета-версию класса.
Кажется сделал всё что было нужно, оно компилится, но возникла куча вопросов.
1. Не надо ли удалить предыдущее значение ATileInfo перед строкой 452? Оно вообще, переменная или экземпляр класса? И где тогда для него деструктор? Или как освобождать память?
2. В 451 строке можно ли так возвращать результат? Правильно ли @s[1] или как надо делать? Или как вообще вернуть через память КУСОК бинарного файла? И не будет ли память с результатом освобождена при выходе из функции?
3. Ну как же мне вызвать методы .CheckTilePosStrict и .CheckTileRect (строки 226 и 243)?! Создавать новый объект в конструкторе, и только потом у него будут эти методы?! Мрак.
4. Я вообще правильно возвращаю результаты в .LoadTile, .GetTileRectInfo, .GetTileInfo или это можно и проще сделать?
5. Почему у родителя TTileStorageAbstract нет метода .TileExists:boolean? Или его замещает .GetTileInfo?
6. Обязательно ли ВСЕ функции объявлять в private класса, даже если они не привязаны к классу (не пользуются его переменными) и могут быть лишь в разделе implementation? |
|
|
|
(0006976)
|
|
Garl
|
|
11-05-2012 17:47
|
|
|
у меня нежданно дома сломался на винде фрэймворк соответственно не пашет делфи. компилить смогу только на работе. пока не пересыплю домашнюю систему. |
|
|
|
|
Garl, спасибо. Я таки поставил 2007-ю дельфи и компилю юнит уже в окружении Планеты. Компилятся не все, модулей многих нехватает, но для этого достаточно, скомпилился. Вот проверить в Планете пока не могу.
Пересобирать всю Планету с этим классом ещё слишком рано.
Вот где бы help к дельфи нарыть, в архиве Lite его как оказалось нету. :-( |
|
|
|
(0006978)
|
|
Garl
|
|
11-05-2012 18:23
|
|
https://bitbucket.org/zedxxx/sas.requires/overview
не то ли что нужно для полного счастья? |
|
|
|
(0006979)
|
|
Dima2000
|
11-05-2012 18:37
(edited on: 11-05-2012 18:46) |
|
Скорее всего да, то. Видел, и на форуме, и в репо, ссылки на "полный комплект компонентов", только не работают они, искать нормальные и вообще разбираться с этим пока лень. Потом.
Вот за что и не люблю использовать посторонние компоненты, что потом их фиг найдёшь, да ещё и платными бывает становятся. И за что отдельно ненавижу встраиваемые в дельфи компоненты - стёр/переустановил дельфи, а они тю-тю. А где их брал и какой версии - часто фиг поймёшь. Имхо всё необходимое должно лежать в папке проекта. Кроме поставляемых с компилятором либ.
|
|
|
|
(0006980)
|
|
zed
|
|
11-05-2012 18:48
|
|
>только не работают они
Наглая ложь! Все компоненты из моего репо рабочие, по ним каждую ночь собирается ночная сборка саса между прочим. Если же у вас возникли какие-то проблемы с компиляцией или настройкой/установкой компонентов - прошу в топик http://sasgis.org/forum/viewtopic.php?f=47&t=1716&start=90 с детальным описанием проблемы (предварительно, читаем ридми и пробуем делать точь в точь, как там написано: https://bitbucket.org/zedxxx/sas.requires/src/cd1998f722c9/readme.txt ). |
|
|
|
(0006981)
|
|
Dima2000
|
11-05-2012 18:56
(edited on: 11-05-2012 19:04) |
|
Zed, извините. Я просто не нашёл куда нажимать чтобы скачать (совершенно непонятно!) и видел лишь текст описания. Почитал его и пошёл дальше. :)
Вот сейчас что-то скачалось, посмотрим что.
Нету каталога graphics32. Да, знаю, возьму у Демидова, однако нету же. :)
Про не работают ссылки я имел в виду например ссылку на компоненты в третьем сообщении указанной темы на первой странице. И её же видел где-то в репо, уже не помню чьём.
|
|
|
|
(0006982)
|
|
zed
|
11-05-2012 19:02
(edited on: 11-05-2012 19:04) |
|
>Я просто не нашёл куда нажимать чтобы скачать (совершенно непонятно!)
Нужно установить меркуриал и КЛОНИРОВАТЬ репозиторий. Просто скачать его не получится (там несколько вложенных под-репозиториев (subrepo) почти на каждый компонент в отдельности). Да, сразу не очень понятно, особенно тем, кто с меркуриалом до этого не работал, но разбираться нужно. Сас - достаточно сложный проект, с несколькими разработчиками, поэтому без системы контроля версий тут ну никак не обойтись. Так что, покурите маны пару дней, погуглите слегка - и всё станет ясно, как божий день.
|
|
|
|
(0006983)
|
|
zed
|
|
11-05-2012 19:15
|
|
>Нету каталога graphics32. Да, знаю, вощьму у Демидова, однако нету же. :)
Если вы клонируете репозиторий, то будет (потому что это вложенный репориторий от того самого vdemodov-а). Т.е. когда вы клонируете основной репо, он автоматом подтягивает в себя все включённые в него под-репозитории. А просто скопировав репозиторий вы как раз-таки и недополучите все эти subrepo.
P.S. Это всё тут жуткий оффтоп и нужно его потом подтереть. Лучше со всеми непонятками заходите в топик на форум. |
|
|
|
|
>достаточно сложный проект
Повидимому слишком для меня сложный.
Даже хелп к дельфи кажется есть, но не работает потому что требует .NET SDK 2.0! Сначала дельфи ставится криво, потом при запуске постоянно что-то вылетает, потом фик найдёшь всё требуемое (хотя кнопочка "скачать исходник" есть!), потом надо ещё какой-то репо ставить (который лично мне нафик не нужен), потом компоненты ещё интегрировать надо, потом ... Постоянно что-то ещё надо.
И вся эта морока лишь чтобы проверить пару методов класса чтения файла! В 10 раз быстрее было написать обёртку над классом и проверить. Если б ещё не искать смысл (и тип) каждой переменной по всему миллиону исходных файлов, очень редко комментированных.
Мрак.
Может когда разобрался и всё настроил оно и удобно, не знаю. И не узнаю.
>Это всё тут жуткий оффтоп и нужно его потом подтереть.
Согласен, обязательно. Потом забудем, трите сразу. :) Прямо от 6976, да и до него можно кое-что. Я бы и сам, но лучше вам как руководителю.) |
|
|
|
(0006985)
|
|
zed
|
|
11-05-2012 20:11
|
|
На самом деле, полная подготовка рабочего окружения для компиляции САСа, начиная от установки делфи, занимает минут 15. Если знаешь что, как и в какой последовательности делать. :)
>Даже хелп к дельфи кажется есть
Зачем? Гугл в помощь. Лично я хелпом в делфях так ещё ни разу и не воспользовался (хотя, у меня его наверное и нету, в Lite версии - не знаю, не проверял). |
|
|
|
(0006986)
|
|
vdemidov
|
11-05-2012 20:55
(edited on: 11-05-2012 20:58) |
|
Мельком просмотрел. Сразу пожелания:
1. Писать потокобезопасный код.
2. Вместо AssignFile пользоваться TFileStream
3. Сделать пул открытых файлов с данными, что бы не открывать их за каждым чихом.
PS: Тредсейфовость это самое главное требование. То что сейчас есть будет постоянно сыпать AV-шками.
|
|
|
|
(0006987)
|
|
vdemidov
|
11-05-2012 21:04
(edited on: 11-05-2012 21:44) |
|
>3. Ну как же мне вызвать методы .CheckTilePosStrict и .CheckTileRect (строки 226 и 243)?! Создавать новый объект в конструкторе, и только потом у него будут эти методы?!
Лучше получите конкретный объект в конструкторе.
>4. Я вообще правильно возвращаю результаты в .LoadTile, .GetTileRectInfo, .GetTileInfo или это можно и проще сделать?
Да вроде нормально, только TTileInfoBasicNotExists.Create(0, nil); лушче как в TTileStorageFileSystem создать один раз в конструкторе и не создавать каждый раз.
И еще посмотрите на правильное использование TTileRectInfoShort, а то получите авешку.
>5. Почему у родителя TTileStorageAbstract нет метода .TileExists:boolean?
А зачем ему там быть?
|
|
|
|
|
TFileStream легко.
Пул файлов данных уже не так легко, но можно. Хотя и сейчас не медленнее обычного файлового кэша.
Ну а хоть чуть подробнее про безопасность?
Почему такой код не потокобезопасен? Что не все функции в класс засунуты? Это легко.
Откуда AV будут? Я вижу лишь про места, где файлы открываются и читаются, но они все в блоках try... Причём файлы всегда лишь читаются, это можно и многопоточно. Флаг забыл поставить, да, не вопрос. |
|
|
|
|
>Ну а хоть чуть подробнее про безопасность?
> Почему такой код не потокобезопасен?
Почитайте для начала азы потокобезопасности сами все поймете. |
|
|
|
|
Если вы про реентабельность то её нет, увы - пропадает смысл кэшировать данные из индексного файла. Да плюс ещё оборачивать всё в блокировки ...
Используйте по объекту класса на каждый поток, это в данном случае безопасно. |
|
|
|
(0006991)
|
|
Tolik
|
|
12-05-2012 04:04
|
|
> потом надо ещё какой-то репо ставить (который лично мне нафик не нужен)
> Может когда разобрался и всё настроил оно и удобно, не знаю. И не узнаю.
Ну и напрасно. Меркуриал ставится за 5 минут, разбираешься в нём методом научного тыка за 10 минут, потом оказывается, что это очень нужная и удобная программа. За Дельфи не скажу (сам так и не поставил его), но тоже думаю, что вам будет легче поставить всё, что zed написал, и научиться этим пользоваться.
Не надо сопротивляться и пытаться что-то компилировать на коленке, учитесь пользоваться нормальными инструментами, это для вашей же пользы!
Потом потру офтопик, если не поленюсь. Очень длинная переписка получается, иногда на пустом месте. Про какого-то короеда уже 80 постов - а какая от него польза народному хозяйству? Из-за того, что вы не можете сами скомпилировать САС, на ваши идеи тратят время все участники проекта. |
|
|
|
(0006992)
|
|
Garl
|
|
12-05-2012 04:11
|
|
кстати огромный плюс в контроле версий - избавляемся от этого:
Обозначения:
[+] - добавление функционала
[-] - удаление функционала
[!] - исправление ошибок
[*] - исправление (не ошибок), улучшение
{!} - отладочные строки, можно безопасно удалить
всё хранится в коммите :) и легче найти на какой версии был введён баг, локализовать его и поправить не боясь потерять код.
я поначалу тоже его боялся. |
|
|
|
|
>Используйте по объекту класса на каждый поток, это в данном случае безопасно.
Увы, такого нет и не предвидится. К тайлохранилищу идут обращения от кучи разных потоков одновременно. |
|
|
|
|
>К тайлохранилищу идут обращения от кучи разных потоков одновременно.
Ок, кто ж знал. Будем думать дальше. |
|
|
|
|
>только TTileInfoBasicNotExists.Create(0, nil); лушче как в TTileStorageFileSystem создать один раз в конструкторе и не создавать каждый раз
А может вообще один на все хранилища создать? Там же всегда 0 и NIL?
>Причём файлы всегда лишь читаются, это можно и многопоточно
Указатель текущего положения в файле при чтении как двигается?
(вопрос с подвохом, если что)
>кто ж знал. Будем думать дальше
На то уже и написано пяток хранилищ, чтобы можно было по образу и подобию клепать. Хотя бы синхронизацию и вызовы. |
|
|
|
|
>олько TTileInfoBasicNotExists.Create(0, nil); лушче как в TTileStorageFileSystem создать один раз в конструкторе
Да, точно, не подумал.
>Указатель текущего положения в файле при чтении как двигается?
Внутри функций сам, между функциями везде стоят Seek. Т.к. нет BlockRead(@Seek, ...) (чтения файла по смещению), то связка Seek+BlockRead ничем не лучше BlockRead+BlockRead.
Проблема в другом, что вызов функций из нескольких потоков может испортить все приватные переменные класса (Tx[], Ty[]), в которых кэшируется индексный файл. Блокировками это лечить бессмысленно (.GetTileRectInfo может заблокировать остальные методы на секунды). А переносить кэширование (точнее буферизацию) в .GetTileInfo и в .LoadTile смысла мало, проще положиться на кэширование ОС.
Вот и думаю как лучше сделать. Исходники смотрю конечно. |
|
|
|
|
|
Думайте. Я бы посоветовал создать отдельный объект c интерфейсом отвечающий за работу с индексным файлом. Плюс добавил возможность, при размере индексного файла меньше какой-то величины, грузить его полностью в память. А доступ к каждому отдельному файлу упорядочил отдельной критической секцией. |
|
|
|
|
>Я бы посоветовал создать отдельный объект
Да, я тоже именно об этом и думаю. |
|
|
|
(0007621)
|
|
Tolik
|
|
24-06-2012 08:50
|
|
|
Скажите, кто-нибудь занимается этой хотелкой? Оч. хочется таких "консерв" :) |
|
|
|
|
Ну как сказать, я вроде бы занимался, даже почти "сделал", но уже больше месяца продвижений нет - сейчас нет ни времени, ни честно говоря желания доделывать: из простого юнита оно разрастается в огромную конструкцию, с несколькими классами, интерфейсами, объектами, внутренним кэшированием, ect ...
Вот недавно глянул свежим взглядом, кажется от AV-ек можно избавиться малой кровью, забрав приватные методы в критические секции. Это практически убьёт эффект кэширования индекса при многопоточных запросах, но зато не будет глюков. Возможно именно так и сделаю, без существенных изменений всего остального. А улучшать можно и потом, если скорость работы не устроит.
Самому очень хочется поддержку такого кэша в Планете, но объём работы отталкивает. Особенно если требуют сделать "всё сразу правильно и красиво".
В общем вернусь из отпуска и к концу июля займусь. |
|
|
|
|
|
Добавил связь с 653-й хотелкой ибо при реализации этой можно будет по произвольному TAR-у (без упаковки и до 2Гб размером) построить файл индекса и подключить его как кэш SAS4WinCE, что решит 653-ю. Или даже по сотне TAR-ов под одним именем и каждый до 2Гб. |
|
SAS4WinCE_ListZooms.zip (27,485) 05-05-2012 17:22
u_TileStorageSAS4WinCE.pas (16,546) 11-05-2012 16:59