На самом деле в картах важны не только непосредственно картографическая составляющая, но и отметки разного рода заведений на них. На гугле уже отмечано куча кафешек/банкоматов/магазинов/бензозаправок и т.д. А новые эппловские карты будут изначально «чистым листом», и когда все эти отметки для России появятся на их картах большой вопрос.
Хмм, Fn+Left|Right действительно работают. А вот Alt+Left|Right (которым я достаточно часто пользуюсь) нет, тоесть оно печатает [D[C вместо того чтобы по словам бегать. Может знаете как настроить чтобы заработало?
Я пробовал iTerm, но не перешел потому что он не понимает сочетания Cmd+Left|Right (передвигать по курсор по словам), Fn+Left|Right (вместо Home, End, которых нет на клаве макбуков). Есть ли возможность научить iTerm понимать эти сочетания клвиш?
До уровня proof-of-concept. «Оно, может, и умно, но больно непонятно. Над вами потешаться будут». Тоесть в качестве ресерча — было прикльно, а рассказать простым людям что понятие число и конкретное число вещи мало реально.
>Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности.
Да я и написал потому «в духе». Все равно пользователь формирует свой язык: «Юр лицо», «Контрагент», «Прайс лист» и различает их от конкретного контрагента. Причем классовая модель добавить лишних полей конкретному контрагенту никак не запрещает.
Вообще я работал не в области баз данных а MDD и на основе описания языка я автомаически генерил редакторы к этим языкам, валидацию и т.д. С «динамическим» прототипированием так не выйдет. При этом язык можно редактировать параллельно с моделями, так что никакой сложности с изменениями базовой структуры нет.
Да, я понимаю. Я когда исследованием на этой почве занимался, довел идею прототипов до абсолютного предела: в одной из моих метаязыков я убрал не только понятие «класс», но и понятие «тип», определил порядок на значениях так, что значение стало сужением типа. То есть 3 и int были объектами одного рода. Меня просто всегда привлекала построение систем с минимальным числом базовых сущностей.
>В итоге классы на порядок усложняются
Да ничего подобного, вы просто узко смотрите на понятие класс — на самом деле разницы между традиционной классовой моделью и прототипной не так много. Просто посмотрите на реализцую ООП в языках отличных от С++/Java — в той же скале можно добавлять атрибуты/методы прямо в экземпляр класса прямо при описании конкретного инстанса без проблем, при этом оставаясь в пределах статической типизации.
Я просто очень не люблю динамическую типизацию, а ваше описание прототипов именно в духе динамической типизации. А как показывает практика гибкость прототипов прекрасно реализуюется в классовой модели, при этом сохраняя все преимущества классовой.
Я приблизительно по схожей теме защитил магистерскую и баколаврскую. Только у меня были не прототипы, а «специализации», позволяющие наследование между «составными» объектами (не обязательно одинаковых «классов») и изменение значение атрибутов/связей на произвольном уровне вложенности (например, при наследовании схем баз данных поменять тип поля произвольной таблицы). Так вот, прототипирование для этого совсем не нужно, все прекрасно реализуется в рамках классической ОО парадигмы. Нужно только правильно классифицировать связи и ввести более общее понятие наследования.
Вообще мне казалось что на хабре проскакивал коммент чувака с подобными проблемами, и что он написал им письмо с просьбой всеже иметь возможность купить обновление и они пошли на уступку. Так что можете попробовать :)
BuiltWith — расширение выводит информацию о используемых на сайте технологиях: язык, движок (если может догадаться), использование аналитики разных вендоров и т.д.
Код в разных стилях в рамкох одного проекта просто мозолит глаза, и лично я всегда использую стиль проекта в котором учавствую. Но есть и более существуенные проблемы. Я, на самом деле, вообще не слежу за тем сколько пробелов я поставил и где — ИДЕЯ за меня все и так автоматически реформатит. Так вот, когда я начну пользоваться этим в чужом файле — она отреформатит весь файл, в результате маленькие изменения првевратятися в большие, что совершенно не удобно.
>По-моему лучше, периодически выделять время на чистку кода, чем задалбывать всех каждый раз, при комите.
К сожалению, такой подход обычно порождает «синдром разбитых окон», о чем хорошо написано в книге «Программист-прагматик» Соблюдать конвенцию — не слишком сложно, и стоит просто приучится делать это на автомате.
>что могу задать свой цвет с абсолютно любым именем
Верно.
>И всё же хотелось бы базировать свою раскраску на стандартной, где её можно увидеть?
hi Comment guifg=#99968b gui=italic
hi Todo guifg=#8f8f8f gui=italic
hi Constant guifg=#8a11a8 gui=none
hi String guifg=#95e454 gui=italic
hi Identifier guifg=#cae682 gui=none
hi Function guifg=#cae682 gui=none
hi Type guifg=#cae682 gui=none
hi Statement guifg=#8ac6f2 gui=none
hi Keyword guifg=#8ac6f2 gui=none
hi PreProc guifg=#e5786d gui=none
hi Number guifg=#e5786d gui=none
hi Special guifg=#e7f6da gui=none
hi Delimiter guifg=#e5786d gui=none
Вот отсюда черпай названия и «линкуй» свои навзания к этим.
Минусуют потому, что сообщения об опечатках замусоривают коментарии, так как устаревают сразу же после правки, и поэтму их принято слать автору в личку. А для того чтобы слать в личку было удобно, стоит поставить расширение для хрома, которое будет слать сообщение автоматом по Ctrl+Enter
Смогу ответить, если вы скажете, как определить «вот это строка». Ведь вы файл редактируете, а значит опираться на оффсет по символам нельзя. Да и как сохранить эту информацию в файл? Идея умеет получать эту информацию на основе полного семантического анализа. Однако, если это легко регекспами получить — то можно сделать так (например подсвечивать во всех строках):
:syn region start=/"/ end=/"/ contains=sqlKeyword,sqlOperator,sqlStatement,sqlFunction,sqlNumber,sqlType
:hi — отвечает, по сути, за представление подсветки ситнаксиса. В цветовых схемах используется следующий формат команды:
hi StatusLine guifg=#f6f3e8 guibg=#444444 gui=italic
hi Comment guifg=#99968b gui=italic
Определяет стиль региона StatusLine как заданный цвето текста (guifg), цвет фона (guibg) и стиль начертания (gui). Стилем может быть любой идентификатор, но есть соглашение про несколько стандартных: что стиль Keyword обычно отвечает за ключевые слова, а Comment — за коментарий. Но вообще можете задать любо имя, хот PesNaLdine.
Далее, в описании подсветки вы задаете сначала стили с именами привязанными к структуре языка — например pascalFuncionCall, pascalCompilerOptions, и т.д. А далее задается «представление», путем отображения языковых стилей, на общие стили, которые определены в ваших цветовых схемах:
hi link pascalFunctionCall Function
hi link pascalCompilerOptions PreProc
Подсвечивает регион pascalFunctionCall как регион Function, а pascalCompilerOptions как регион PreProc. Просто стиль слева берется целиком из стиля справа. Так как обычно в языках много конструкций, а в цветовых схемах определены только общие для всех языков конструкции, на один стиль часто ссылается несколько названий регинов разметки (как у меня в примерах — стили ключевых слови экранирующих символов «привязоны» к одному и томуже стили из цветовых схем Keyword).
Согласно википедии, у Win7~35%, у Vista ~10%, У XP ~38% (от всех OS), т.е. не XP таки больше чем у половины пользователей. Хотя, безусловно, и не так чтобы сильно больше.
Не подумайте что лезу не в свое дело, просто действительно интересно откуда могут взяться такие большие Exel файлы и почему именно в этом формате, раз они явно не для чтения/редактирования человеком?
До уровня proof-of-concept. «Оно, может, и умно, но больно непонятно. Над вами потешаться будут». Тоесть в качестве ресерча — было прикльно, а рассказать простым людям что понятие число и конкретное число вещи мало реально.
>Прототипная модель и классовая могут быть, а могут не быть динамически типизированными, это не их особенности.
Да я и написал потому «в духе». Все равно пользователь формирует свой язык: «Юр лицо», «Контрагент», «Прайс лист» и различает их от конкретного контрагента. Причем классовая модель добавить лишних полей конкретному контрагенту никак не запрещает.
Вообще я работал не в области баз данных а MDD и на основе описания языка я автомаически генерил редакторы к этим языкам, валидацию и т.д. С «динамическим» прототипированием так не выйдет. При этом язык можно редактировать параллельно с моделями, так что никакой сложности с изменениями базовой структуры нет.
Да, я понимаю. Я когда исследованием на этой почве занимался, довел идею прототипов до абсолютного предела: в одной из моих метаязыков я убрал не только понятие «класс», но и понятие «тип», определил порядок на значениях так, что значение стало сужением типа. То есть 3 и int были объектами одного рода. Меня просто всегда привлекала построение систем с минимальным числом базовых сущностей.
>В итоге классы на порядок усложняются
Да ничего подобного, вы просто узко смотрите на понятие класс — на самом деле разницы между традиционной классовой моделью и прототипной не так много. Просто посмотрите на реализцую ООП в языках отличных от С++/Java — в той же скале можно добавлять атрибуты/методы прямо в экземпляр класса прямо при описании конкретного инстанса без проблем, при этом оставаясь в пределах статической типизации.
Я просто очень не люблю динамическую типизацию, а ваше описание прототипов именно в духе динамической типизации. А как показывает практика гибкость прототипов прекрасно реализуюется в классовой модели, при этом сохраняя все преимущества классовой.
К сожалению, такой подход обычно порождает «синдром разбитых окон», о чем хорошо написано в книге «Программист-прагматик» Соблюдать конвенцию — не слишком сложно, и стоит просто приучится делать это на автомате.
Верно.
>И всё же хотелось бы базировать свою раскраску на стандартной, где её можно увидеть?
Вот отсюда черпай названия и «линкуй» свои навзания к этим.
Да ничего нечестного. Просто (лично мне) вим нравится легкостью, которая убивается таким вот инструментарем.
>ну как-как. внутри кавычек, натурально.
Так я этот вариант и привел. Только внутри кавычек может быть и не SQL — а XPath или просто строка.
Определяет стиль региона StatusLine как заданный цвето текста (guifg), цвет фона (guibg) и стиль начертания (gui). Стилем может быть любой идентификатор, но есть соглашение про несколько стандартных: что стиль Keyword обычно отвечает за ключевые слова, а Comment — за коментарий. Но вообще можете задать любо имя, хот PesNaLdine.
Далее, в описании подсветки вы задаете сначала стили с именами привязанными к структуре языка — например pascalFuncionCall, pascalCompilerOptions, и т.д. А далее задается «представление», путем отображения языковых стилей, на общие стили, которые определены в ваших цветовых схемах:
Подсвечивает регион pascalFunctionCall как регион Function, а pascalCompilerOptions как регион PreProc. Просто стиль слева берется целиком из стиля справа. Так как обычно в языках много конструкций, а в цветовых схемах определены только общие для всех языков конструкции, на один стиль часто ссылается несколько названий регинов разметки (как у меня в примерах — стили ключевых слови экранирующих символов «привязоны» к одному и томуже стили из цветовых схем Keyword).