В целом интересно, но есть пара вопросов:
VMProtect можно использовать бесплатно только при работе с вашим сервисом (что влечет за собой необходимость иметь 2 версии программы) или я могу проктектор использовать и для защиты программы при продаже на запад бесплатно? Если второе то можно ли будет иметь одну и ту же версию программы для обоих видов продаж, чтобы не путать пользователя?
Аффиляты сами выбирают какие программы продавать или происходит автоматическое добавление программ в каталоги?
Не уверен, насколько сопоставим эффект, но на компьютере использую программу F.lux.
Она похожим образом желтит экран в темное время суток.
Глаза реально меньше устают и если выключить программу, то чувствую заметный дискомфорт.
Единственное что напрягает в PyCharm, это неверные ошибки в HTML шаблонах и CSS.
Не знаю как писать корректно тэги на хабре, поэтому убрал символы <, чтобы парсер не удалил
Говорит что не существует путь, оно в общем то и понятно, не PHP чтобы обязательно существовать:
a href="/contacts/"> /a>
img src="{{ image_path }}/image.png" />
div style=«background:url({{ image_path }}/image.png)»> /div>
form action="{{ site_url }}/sent/" method=«POST»>
Аналогично в CSS:
.bt{background:url({{ image_path }}/main.png) no-repeat 72% 0}
Показывает ошибку что тэг не закрыт:
<input name=«email» type=text {% if mail %} value="{{ mail }}"{% endif %}>
<td {% if grey %} class=«table-grey»{% endif %}>
Всё что внутри показывает как ошибки:
script type=«text/javascript»>
{% if image_path %}
{% endif %}
/script>
Супер!
Я правильно понял, что в новой версии будут полные и стабильные реализации c поддержкой IDE и прочего и 64 битов и Linux/Mac?
И ещё маленький вопрос: FireMonkey будет заменой VCL или они будут парарельно в дельфи или ещё как? Не получится ли, что понадобится переписывать программы.
Delphi.NET давно мёртв, ему на смену пришёл Delphi Prism.
Embarcadero сейчас акцентируются на создании 64-битного компилятора (выйдет в сентябре) и Linux/Mac (может тогда же будет доступен, но сомневаюсь).
ARM? Думаю ждать пока не стоит, хотя и не уверен что очень надо.
Опять же, если разбрасываться во все стороны, то ничего не успеешь, не майкрософт, не хватит ресурсов. Хотя последняя дельфи у меня работает на порядок стабильнее студии 2010.
Скоро и на дельфи можно будет компилить программы для Mac и Linux.
Только, боюсь, как и любое кроссплатформенное, будет выглядеть ненативно, т.е. на мой взгляд, средненький плюс в наличии кроссплатформенности.
Пытался тут купить домен на domains.webmoney.ru. Дак даже авторизоваться не смог, при разных способах авторизаций ошибки лезут. От техподдержки толку, конечно, мало. Дают советы даже не вчитываясь что я им пишу.
Одна из ошибок была как раз про автоматически созданные кошельки и возможно инструкция koreec помогла бы, но уже поздно, купил в другом месте, а вебмани буду и дальше обходить стороной.
Пробовал, но это тоже не совсем то, что надо. Это автокомплит, а хотелось бы именно проверку на использование словосочетаний. К сожалению, потерял ссылку, где была реализация близкая к тому, что мне надо, но там правильность подбора вариантов была не очень высокая
Первый пункт это то, что я давно ждал.
Ещё бы доразвить его и предлагать автоматически варианты перевода, если существует более используемый. Тогда бы стало бы почти идеальная возможность контролировать что правильно ли ты пишешь (Я часто пишу сразу на английском, а уже потом перепроверяю переводчиками).
function GetFileAttributes(lpFileName: PChar): Integer; stdcall; external 'kernel32.dll' name 'GetFileAttributesW';
Если MS надо что то изменить, то она создаёт новую функцию с префиксом Ex или предусматривает заранее параметры в существующей, т.е. на текущую реализацию это не влияет. Обратную совместимость никто не отменял, на этом уверенность в части проблем с API и строится.
Неужели в .NET MS от версии к версии стала изменять определения функций?
При том что Delphi использует Win32 API, а не тот же .NET.
А сам API вообще то не изменяется, разве что развивается (обратная совместимость, однако). Единственно что бывает, это добавляю более строгие проверки, но это уже проблема криворуких программистов.
А если и случится, то изменить описание API функции можно хоть в Delphi 1 и всё будет опять нормально работать. Все исходники же есть, да и переопределить функцию только для своей программы это 1 строчка.
Т.ч. это абсолютно не аргумент.
А на современных компах скорость работы Delphi и C++ уже не принципиально отличается на большинстве типовых задач. Конечно, если нужна экстремальная производительность, то C, конечно, предпочтительнее.
А вот скорость разработки в C++ не увеличилась.
Майкрософт не сумашедшие чтобы отказываться от поддержки Win32. На хабре даже топики были про их команды, которые занимаются тестированием совместимости программ с новыми версиями винды.
Тот же TotalCommander написан вроде на Delphi 2 и до сих пор работает.
И если этот «тупик» настанет, то случится это не раньше чем сама винда будет переписана на .NET, т.е. случится это явно в отдалённом будущем. Одновременно должно случится так, что Embarcadero похоронит к тому времени Delphi окончательно.
Поэтому не вижу реальных причин перехода на .NET. Я предпочитаю развиваться вширь и изучать например Python/Django. Пользы от этого намного больше, особенно учитывая тенденцию смешения в web сервисы.
Я согласен конечно, но на данный момент всё выглядит так (я делаю вывод на основе всех встречанных мной программ на .NET), что необходимо прикладывать больше усилий для оптимизации кода на .NET, что вероятно нивелирует приемущества увеличения скорости разработки.
VMProtect можно использовать бесплатно только при работе с вашим сервисом (что влечет за собой необходимость иметь 2 версии программы) или я могу проктектор использовать и для защиты программы при продаже на запад бесплатно? Если второе то можно ли будет иметь одну и ту же версию программы для обоих видов продаж, чтобы не путать пользователя?
Аффиляты сами выбирают какие программы продавать или происходит автоматическое добавление программ в каталоги?
Она похожим образом желтит экран в темное время суток.
Глаза реально меньше устают и если выключить программу, то чувствую заметный дискомфорт.
Не знаю как писать корректно тэги на хабре, поэтому убрал символы <, чтобы парсер не удалил
Говорит что не существует путь, оно в общем то и понятно, не PHP чтобы обязательно существовать:
a href="/contacts/"> /a>
img src="{{ image_path }}/image.png" />
div style=«background:url({{ image_path }}/image.png)»> /div>
form action="{{ site_url }}/sent/" method=«POST»>
Аналогично в CSS:
.bt{background:url({{ image_path }}/main.png) no-repeat 72% 0}
Показывает ошибку что тэг не закрыт:
<input name=«email» type=text {% if mail %} value="{{ mail }}"{% endif %}>
<td {% if grey %} class=«table-grey»{% endif %}>
Всё что внутри показывает как ошибки:
script type=«text/javascript»>
{% if image_path %}
{% endif %}
/script>
Я правильно понял, что в новой версии будут полные и стабильные реализации c поддержкой IDE и прочего и 64 битов и Linux/Mac?
И ещё маленький вопрос: FireMonkey будет заменой VCL или они будут парарельно в дельфи или ещё как? Не получится ли, что понадобится переписывать программы.
Embarcadero сейчас акцентируются на создании 64-битного компилятора (выйдет в сентябре) и Linux/Mac (может тогда же будет доступен, но сомневаюсь).
ARM? Думаю ждать пока не стоит, хотя и не уверен что очень надо.
Опять же, если разбрасываться во все стороны, то ничего не успеешь, не майкрософт, не хватит ресурсов. Хотя последняя дельфи у меня работает на порядок стабильнее студии 2010.
Только, боюсь, как и любое кроссплатформенное, будет выглядеть ненативно, т.е. на мой взгляд, средненький плюс в наличии кроссплатформенности.
Одна из ошибок была как раз про автоматически созданные кошельки и возможно инструкция koreec помогла бы, но уже поздно, купил в другом месте, а вебмани буду и дальше обходить стороной.
thefall.gorillaz.com/
Ещё бы доразвить его и предлагать автоматически варианты перевода, если существует более используемый. Тогда бы стало бы почти идеальная возможность контролировать что правильно ли ты пишешь (Я часто пишу сразу на английском, а уже потом перепроверяю переводчиками).
function GetFileAttributes(lpFileName: PChar): Integer; stdcall; external 'kernel32.dll' name 'GetFileAttributesW';
Если MS надо что то изменить, то она создаёт новую функцию с префиксом Ex или предусматривает заранее параметры в существующей, т.е. на текущую реализацию это не влияет. Обратную совместимость никто не отменял, на этом уверенность в части проблем с API и строится.
Неужели в .NET MS от версии к версии стала изменять определения функций?
А сам API вообще то не изменяется, разве что развивается (обратная совместимость, однако). Единственно что бывает, это добавляю более строгие проверки, но это уже проблема криворуких программистов.
А если и случится, то изменить описание API функции можно хоть в Delphi 1 и всё будет опять нормально работать. Все исходники же есть, да и переопределить функцию только для своей программы это 1 строчка.
Т.ч. это абсолютно не аргумент.
А вот скорость разработки в C++ не увеличилась.
Тот же TotalCommander написан вроде на Delphi 2 и до сих пор работает.
И если этот «тупик» настанет, то случится это не раньше чем сама винда будет переписана на .NET, т.е. случится это явно в отдалённом будущем. Одновременно должно случится так, что Embarcadero похоронит к тому времени Delphi окончательно.
Поэтому не вижу реальных причин перехода на .NET. Я предпочитаю развиваться вширь и изучать например Python/Django. Пользы от этого намного больше, особенно учитывая тенденцию смешения в web сервисы.