Как я понимаю (могу ошибаться), с краудсорсинговыми картами это как-то обходят, но при этом есть ограничения как их можно использовать (грубо говоря нельзя выдавать за свои). Например, Яндекс.Карты не даёт скачать на телефонах Народные карты.
Лицензирование картографических данных никто не отменял. Т.е. вне зависимости от источника процесс их «легализации» будет несколько бюрократизирован… Слышал, что Яндекс этот процесс несколько ускорил тем, что организовал «свою собственную» картографическую фирму. Но всё равно у них обновления занимают иногда очень заметное время.
Тут другая проблема. Яндекс и Гугл (и все остальные) в России обязаны использовать лицензированные картографические материалы. Для этого необходима компания-поставщик с лицензией (которая довльно строгая и требует чтобы в штате было сколько-то картографов и тому подобное). Поэтому по сути они сами не могут вносить исправления *в карты* оперативно, даже когда знают о них.
С описанием же организаций на карте проблем нет никаких, всё зависит от расторопности компании.
Т.е. Вы со сути перехватываете и подменяете вызовы между этим контролом и системой?
Интересно, а Apple пропускает приложения с таким фривольным (с точки зрения самой Apple) отношением к системным контролам? Т.е. я полагаю. что у них такая политика просто, что вам это не нужно.
Хорошая новость, что ObjC никто пока не отменял и отменять не собирается.
На вскидку общие оптимизации / автовекторизация в LLVM посильнее будет, чем в каком-либо специализированном движке. Просто потому что количество ресурсов потраченное на это в LLVM заметно больше. Ну и результаты подтверждают это.
Думаю они там наиграли больше всего за счёт автовекторизации. Думаю они используют LLVM фремворк после анализа типов и специализации кода — т.е. когда надо уже максимально агресивно применить классические оптимизации.
Согласен, но в этот раз они прикрутили LLVM к JavaScript. А это многого стоит.
Вообще меня больше умиляют языки где такие ускорения возможны на протяжении долгого времени. Т.е. там копать-копать, не перекопать. Это вам не С/С++ :)
CUDA — это графика, которая ещё и для общих вычислений может использоваться. Phi — просто вычислитель. А массовому сегменту это не нужно, это High Performance Computing. Даже то что это Xeon как бы намекает.
Это вы — любитель грязных решений. Я переписал сборку проекта из миллиона строк и тоже знаю, о чём речь.
Совсем нет, но переписывание ради переписывания обычно смысла не имеет. Особенно когда трудозатраты на переписывание заметные. Причём в большом проекте всегда есть некоторое количество ошибок, которые не дают о себе знать, пока не начнёшь копать. Их исправление представляет обычно интересную инженерную задачу, но с точки зрения конечного результата иногда даже вредно (ибо на поверхность начинает лезть всякое разное). Вообще, я как правило отстаиваю точку зрения вычищения авгиевых конюшн, но это имеет смысл и возможно далеко не всегда.
Наличие генераторов генераторов генераторов просто не лучшим образом говорит об архитектуре системы сборки.
Нет, это говорит о том, что использование этих техник очень даже оправдано, когда они к месту. lex, bison, иногда что-то своё. За не использование этих инструментов, когда они к месту, надо расстреливать.
Иногда бываю другие, специфичные для разных областей забавные тулы.
В remake всё, что добавлено — отладчик. Это, конечно, позволит попроще жить в уже существующей дерьмовой инфраструктуре, но первопричина в том, что инфраструктура дерьмовая, а не в том, что отлаживаться тяжело. Писать надо так, чтобы отлаживаться не приходилось.
Чтобы отлаживаться не приходилось, говорите? Хм. Такого даже в идеальном мире не бывает ;-)
Прошу не принимать это как оскорбление, но вы идеалист-теоретик :)
Смысла в переменных, когда у них одно определение, нет никакого, ибо это не переменные, а константы. Например, при сборке на определённой ОС, определённой версии с определённой библиотекой, добавлять к ключам компиляции такой-то флажок, а с другой библиотекой, другой флажёк и так стопицот раз. Предлагаете каждый флажёк в отдельную переменную пихать, а потом всё слить воедино? А как же тогда стиль? Там не на один экран таких переменных набежит плотным текстом. Поэтому «CFLAGS +=», а вот откуда что пришло уже не так понятно.
Я, кстати, не про рекурсивный мейк говорил, а про включение в главный мейкфайл (include'ом). И это хорошая практика.
Про вербоз своими силами — в вашем случае и --dry-run отлично подойдёт. В реальности там будет ещё несколько генераторов генераторов, запуск этих генераторов, несколько кастомных правил, которые делают разные манипуляуции с выдачей генераторов. Генерация и обратобка зависимостей опять же. И разные файлы с разными ключами собираются, конечно же. Ну, то есть всё под одну гребёнку крайне сложно.
И, заметьте, это всё при нормальном код ревью и поставленных процессах. Ибо без них вообще адъ, мрак и средневековье. Я по долгу службы на всякое насмотрелся. Действительно большие проекты всегда живут своей жизнью.
Поэтому вместо изобретения велосипедов проще взять remake.
На счёт autoconf — это тоже ещё те грабли. То есть это решает многие проблемы, но далеко не панацея. Плюс, на винде он бесполезен практически (при условии, что проект собирается в некотором шеле — или cygwin, или самописном/самопортированном). Сейчас ответ более или менее понятен — cmake, но лет 15-20-25 назад было всё иначе, а проекты бывают по стольку живут и здравсвуют.
Кстати, в LLVM (типичный большой проект, работающий на всём зоопарке архитектур и ОС) есть и autoconf, и cmake. Собираются постепенно отказаться от autoconf. Но оба решения несколько недопилены (ибо там чёрт ногу сломит местами).
Если проект небольшой и свой, проблемы нет. Если проект большой или очень большой, да ещё и старый, там возникают нюансы. Во-первых, рекомендация про хороший стиль перестают работать. Во-вторых, там объективная необходимость в переменных, ибо кроссплатформенность и различные настройки и прочее. В-третьих, в большом проекте может быть много подпроектов, в которых свои мейкфайлы, которые включаются в главный. В-четвёртых, в большом проекте вся выдача подавлена — ибо по дефолту выдача нужна только если какие-то ворнинги/ошибки (и это правильно), поэтому отсутствие ключика --всё-равно-всё-печатать-и-не-волнует расстраивает при необходимости копнуть глубже.
А как cmake помагает с унаследованным ПО? Я не представляю как легко и просто перевести монструозный проект с огромным количеством включаемых друг в друга под разными условиями и разных последовательностях мейкфалов на cmake.
Кстати об STL. Есть libstdc++, есть libc++, они могут собираться с разными abi и иметь разные версии и разную степерь поддержки С++11. А ещё на макоси с 10.9 хидера STL теперь лежат не в системе, а в XCode, что добавляет приятных моментов. Так что даже с одним STL при необходимости написать хорошо портируемый кросс-платформенный мейк возникает куча внезапных нюансов, будь они не ладны.
На практике этого мало. Особенно когда хочется понять где переменная получила значение и распечатать то что реально исполнялось (-n не помогает, так как логика мейкфайла тогда меняется).
С описанием же организаций на карте проблем нет никаких, всё зависит от расторопности компании.
Интересно, а Apple пропускает приложения с таким фривольным (с точки зрения самой Apple) отношением к системным контролам? Т.е. я полагаю. что у них такая политика просто, что вам это не нужно.
Хорошая новость, что ObjC никто пока не отменял и отменять не собирается.
Думаю они там наиграли больше всего за счёт автовекторизации. Думаю они используют LLVM фремворк после анализа типов и специализации кода — т.е. когда надо уже максимально агресивно применить классические оптимизации.
Вообще меня больше умиляют языки где такие ускорения возможны на протяжении долгого времени. Т.е. там копать-копать, не перекопать. Это вам не С/С++ :)
Совсем нет, но переписывание ради переписывания обычно смысла не имеет. Особенно когда трудозатраты на переписывание заметные. Причём в большом проекте всегда есть некоторое количество ошибок, которые не дают о себе знать, пока не начнёшь копать. Их исправление представляет обычно интересную инженерную задачу, но с точки зрения конечного результата иногда даже вредно (ибо на поверхность начинает лезть всякое разное). Вообще, я как правило отстаиваю точку зрения вычищения авгиевых конюшн, но это имеет смысл и возможно далеко не всегда.
Нет, это говорит о том, что использование этих техник очень даже оправдано, когда они к месту. lex, bison, иногда что-то своё. За не использование этих инструментов, когда они к месту, надо расстреливать.
Иногда бываю другие, специфичные для разных областей забавные тулы.
Чтобы отлаживаться не приходилось, говорите? Хм. Такого даже в идеальном мире не бывает ;-)
Смысла в переменных, когда у них одно определение, нет никакого, ибо это не переменные, а константы. Например, при сборке на определённой ОС, определённой версии с определённой библиотекой, добавлять к ключам компиляции такой-то флажок, а с другой библиотекой, другой флажёк и так стопицот раз. Предлагаете каждый флажёк в отдельную переменную пихать, а потом всё слить воедино? А как же тогда стиль? Там не на один экран таких переменных набежит плотным текстом. Поэтому «CFLAGS +=», а вот откуда что пришло уже не так понятно.
Я, кстати, не про рекурсивный мейк говорил, а про включение в главный мейкфайл (include'ом). И это хорошая практика.
Про вербоз своими силами — в вашем случае и --dry-run отлично подойдёт. В реальности там будет ещё несколько генераторов генераторов, запуск этих генераторов, несколько кастомных правил, которые делают разные манипуляуции с выдачей генераторов. Генерация и обратобка зависимостей опять же. И разные файлы с разными ключами собираются, конечно же. Ну, то есть всё под одну гребёнку крайне сложно.
И, заметьте, это всё при нормальном код ревью и поставленных процессах. Ибо без них вообще адъ, мрак и средневековье. Я по долгу службы на всякое насмотрелся. Действительно большие проекты всегда живут своей жизнью.
Поэтому вместо изобретения велосипедов проще взять remake.
Кстати, в LLVM (типичный большой проект, работающий на всём зоопарке архитектур и ОС) есть и autoconf, и cmake. Собираются постепенно отказаться от autoconf. Но оба решения несколько недопилены (ибо там чёрт ногу сломит местами).
Подозреваю, что у вас remake вместо make подложен (и это, кстати, хорошо!). Вот что говорит о себе remake:
> remake --version
GNU Make 3.82+dbg0.9
Кстати об STL. Есть libstdc++, есть libc++, они могут собираться с разными abi и иметь разные версии и разную степерь поддержки С++11. А ещё на макоси с 10.9 хидера STL теперь лежат не в системе, а в XCode, что добавляет приятных моментов. Так что даже с одним STL при необходимости написать хорошо портируемый кросс-платформенный мейк возникает куча внезапных нюансов, будь они не ладны.