• GUI-приложение размером менее 1 Кб
    0

    1 или 100 кб — не важно. Только фрейморки обычно добавляют как минимум десятки мегабайт… И сравнение получается уже 1 или 100 мегабайт. А здесь уже разница чувствуется. Хотя по сравнению с современным софтом в десятки гигабайт и это мелочи :-)

  • GUI-приложение размером менее 1 Кб
    +1

    Хех. Периодически встречаю такие статьи в сети, в стиле "делаем супер-бурбулятор всего за 5 кб". И возникал вопрос, что раз результат такой супер, то почему он не используется в реальных приложениях? Нужно обязательно попробовать, это будет круто! libc? Не, не слышали. Только хардкор.


    dxPmdxConverter


    Проект номер раз: dxPmdxConverter. Пока было без наворотов, влазило в 16кб. Здесь было: манифест (368 байт), загрузка форм из ресурсов (и соответственно возможность визуального их редактирования!), интерфейс на двух языках, быстрое чтение файлов через MemoryMappedFile. Потом захотелось кроссплатформенного PNG — это уже 32кб, т.к. библиотеку пришлось тащить с собой… Почти успех.


    Winter Novel


    Проект номер два: Winter Novel — коммерческая игрушка, продающаяся в стиме (исходники не доступны). Все использованные данные конвертированы в Си-массивы и линкуются компилятором. Версия под Windows может собираться на чистом WinAPI. Максимально ужатая полная версия игры занимает порядка 350 кб. Туда вошли: TTF, libDUMB (воспроизведение трекерных IT-файлов). И это был полный провал. Пришлось реализовать большое количество функций из стандартной библиотеки. ЕХЕ с использованием стандартной библиотеки в итоге получается даже меньше. Кроме того, чистую WinAPI-версию люто ненавидят антивирусы. От сжатия пришлось отказаться вообще — кто-то из антивирусов неадекватно реагирует даже на UPX...

  • Переходим с Disqus на комментарии Github
    0

    Это умеет делать Staticman

  • Как с помощью трех открытых проектов написать диплом
    +1

    Nuklear — прикольная штука. Как я понял, автор изначально сделал эту библиотеку для упрощения создания пользовательского интерфейса внутри игры. Так сказать, для главного меню и экрана опций. А в итоге вон что из библиотеки получается. Спасибо за интересное применение!

  • Nuklear+ — миниатюрный кроссплатформенный GUI
    0

    Да, в мобильных браузерах в веб-версии почему-то происходит Select, а не Click. С удовольствием приму Pull Request, исправляющий это поведение. :-)
    Нативную Andorid-версию я собирать пока не пробовал. Но скорее всего скомпилируется без проблем (т.к. Open GL ES 2.0 уже есть), и работать тоже скорее всего будет нормально (т.к. люди вроде бы уже пробовали, всё у них нормально).

  • Nuklear+ — миниатюрный кроссплатформенный GUI
    +1

    Я с такой задачей не сталкивался. Nuklear — это порядка 18к строк кода. Не думаю, что там внутри есть что-то подобное. Да и набор контроллов ограничен. Т.е. если планируется сложный навороченный интерфейс, то лучше взять что-нибудь другое.


    Nuklear уже готов даже для коммерческих приложений

    Здесь я имел ввиду, что библиотека стабильна и свой функционал предоставляет хорошо. Т.е. если нужно сделать какую-нибудь микро-утилиту с 2 кнопками, то не обязательно для этого с собой тащить Qt. Но если делать сложный UI на Nuklear — это уже скорее ближе к извращению. Для каждой задачи свой инструмент.

  • Магазины/разработчики/покупатели/издатели
    0

    Я тоже хочу в GOG! Только мои игры туда почему-то не берут! x-D

  • Продвинутый Jekyll
    0

    Вроде бы нормально. Staticman внутри себя использует Akismet для проверки комментариев на спам.

  • Продвинутый Jekyll
    0

    Ну как минимум, это зависимость от внешних сервисов. Если на сайте есть реклама, то Disqus будет или платным, или показывать свою рекламу. И чисто психологический аспект: я не контролирую свои данные (комментарии), неизвестно что с ними может там стать.
    Ну и лично у меня ещё стояла задача переноса старых комментариев. Как это сделать в Disqus мне не очень понятно. Зато со Staticman нужно было просто создать соответствующие файлы, и комментарии 2007 года снова на сайте.

  • Продвинутый Jekyll
    0

    Прошу прощения, насчёт Netlify был не прав. По поводу отсутствия ограничений на плагины — это классно! Иногда вместо извращений с кодом можно сразу взять готовый плагин и просто его включить…
    По поводу вместо двух инструментов один — не согласен. Если домен свой, то им всё-равно нужно как-то управлять. Например, где создать поддомен? Можно воспользоваться чем-то типа FreeDNS, а можно сразу напрямую использовать CloudFlare.

  • Продвинутый Jekyll
    0

    Ну плюшек и здесь хватает. Jekyll делался как движок для программистов — его приятно использовать. Кроме того, open source. Как следствие получаем независимость от серверов GitHub, т.к. при желании можно перенести куда угодно. Https CloudFlare даёт по умолчанию. Для доменов *.github.io GitHub даже форсит https.
    Мне не совсем понятно, зачем для статических сайтов нужен URLRewrite, но в Jekyll он есть: permalink в заголовке страницы (пример).
    Ограничения, конечно, есть везде. Но если использовать Jekyll по предназначению, то в них редко упираешься. А если и упёрся — то один раз делается решение, выносится в отдельный файл и просто подключается.
    Да, Jekyll может далеко не всё. Мне так и не удалось узнать в Jekyll размер файла. Т.е. не получилось автоматом сделать ссылки в стиле "скачать (3 Мб)". Лично мне этот функционал в итоге так и не понадобился. Если же нужен часто, то по-моему лучше использовать более специализированные решения вроде netlify.
    Аналогично, если нужно очень гибкое облако тэгов. В предложенном решении нужно всегда помнить, какие тэги вообще есть в наличии. Если создаётся новый тэг, то его нужно прописать сразу в несколько мест, что не всегда удобно. Если тэгов с (пару-тройку) десятков и создать их заранее, то решение вполне удобное и имеет право жить. Если для каждой публикации куча тэгов, часто новые, и публикуетесь часто — то опять же лучше использовать что-то другое.

  • Продвинутый Jekyll
    0

    Нет, не требует. Данные POST'ом отправляются роботу, который соавтор в репозитории. Он и делает коммит. Для пользователей всё абсолютно прозрачно, формочку можно на том же Ajax сделать.

  • Играючи BASH'им
    0

    Библиотека виртуального терминала какая-то из уже готовых, или самописанная?

  • Магия SSH
    +1

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

  • Lazarus вездесущий
    +5

    Да? Ну буду рад увидеть на Хабре туториалы с картинками как в Lazarus сделать:


    ограбление центробанка Бангладеш и дерзкие атаки на систему SWIFT по всему миру, уничтожение данных южнокорейских медиа- и финансовых компаний
  • Lazarus вездесущий
    +10

    Хех. А я уж по названию подумал, что Delphi ожил :-)

  • Аналог std::vector из C++11 на чистом C89 и как я его писал
    0

    1) Примеры очень нужны. И желательно в самой статье. Не обязательно их подробно расписывать. Можно просто спрятать исходник под спойлер — кому нужно, тот почитает.
    2) Также хотелось бы пример с доступом к элементам вектора как к элементам обычного массива. Т.е. могу просто сделать family[i].Name = "Batman"?

  • Nuklear — идеальный GUI для микро-проектов?
    0

    Эм. Чтобы встроить библиотеку в свой код вам нужно использовать функции. Они где-то описаны. Да, иногда есть документация. Но многое приходится читать прямо в комментариях прямо в коде…
    И я не призываю вас изучать полностью исходники Nuklear. От этого действительно можно свихнуться. Но вот демки скорее всего обойти не получится. А вот они вовсе не так страшны, как вы их рисуете ;-)


    Но это естественно не отдельное решение и добавить в свой движок вы его не сможете.
    Вот-вот. Лучшего встраиваемого, чем Nuklear, я так и не нашёл...
  • Nuklear — идеальный GUI для микро-проектов?
    0

    1) Помните, что это OpenSource. Вы получаете решение абсолютно бесплатно, можете использовать его как хотите. Но при этом вам никто ничего не должен.
    2) Предложите лучшие альтернативы. С удовольствием использую в своей игре что-нибудь другое, если оно будет лучше.
    3) По моему опыту, с документацией обычно всё ещё хуже :-( Здесь есть хоть какая-то. И относительно много простых примеров, на многие случаи жизни.
    4) Если нашли какой-то фатальный баг, то есть много путей решения: а) пофиксить самому; б) заплатить кому-нибудь, чтоб исправил его; в) сидеть и ждать, пока кто-нибудь возможно захочет исправить ваш баг бесплатно.
    5) Не следует ожидать от микро-библиотеки супер-функционала и его мега-стабильности. Те же ноды — скорее пример, ЧТО можно закодить на этой мелочи. Собирать на этой библиотеке аналог Matlab вам никто не предлагает. Судя по скринам в документации библиотека делалась, чтоб на ней можно было быстро создать главное меню, настройки, и сфокусироваться на написании игры, а не интерфейса.
    6) Что вы подразумеваете под словами "полотно мутного текста"? Простая формочка из публикации занимает 20 строк кода, работает одинаково и стабильно. Если вы встраиваете GUI в свою игру, то остальные строки (создание окна, инициализация OpenGL и пр.) у вас уже есть.
    7) Если делаете с нуля — то просто берёте demo с удобной технологией и работаете с ней.
    От себя добавлю, что сейчас делаю коммерческую игру на чистом Nuklear: Wordlase. Да, есть далеко не всё. Не всё так красиво, как могло быть. Да, есть некоторое количество багов. Но всё преодолимо. Получить на этой библиотеке игру — реально.
    Исполняемые файлы и под Linux и под Windows у меня меньше 300кб, хотя содержат в себе декодеры PNG, TTF, OGG, JSON, TAR, GUI.

  • Читаем tar за 26 строк ANSI C кода
    0

    И мне больше понравился формат Cpio. В бинарной версии формата заголовок всего 26 байт + название файла. Реализация также на GitHub.

  • Читаем tar за 26 строк ANSI C кода
    +2

    Есть. Но какова вероятность, что компилятор для микроволновки будет поддерживать свежие стандарты? Или какие-нибудь KolibriOS/MenuetOS? В которых основным компилятором TCC, да ещё и лохматых годов выпуска, да ещё и сурово допиленный напильником. А С89 будет работать везде. Потому, что стандарт относительно простой, и при создании компиляторов Си в первую очередь стремятся к нему.

  • Читаем tar за 26 строк ANSI C кода
    0

    Добавил читалку Ar на GitHub

  • Читаем tar за 26 строк ANSI C кода
    +1

    А почему не преимущество? Да, в таком стандарте не очень комфортно писать. Но C89 почти гарантирует, что проект успешно скомпилируется в любом современном компиляторе, начиная от Clang и заканчивая восьмибитными микроконтроллерами. Писать свой проект можно на чём угодно, хоть на "Super-mega-boosted-python-java#". Но если есть желание использовать чужую библиотеку, и при этом она написана на C89, то есть приличная вероятность, что она без проблем подключится.
    Кроме того, Си есть Си. Т.е. отличная производительность за счёт низкоуровневости языка.

  • Читаем tar за 26 строк ANSI C кода
    0

    Если честно, не особо. Tar мне был просто интересен для исследования. А готовое решение надеялся что в комментах на хабре подскажут толковое.

  • Читаем tar за 26 строк ANSI C кода
    0

    Чтобы избежать хэшей и редактировать эти ресурсы напрямую? В JSON у меня ссылки вида "effects/snow.png", "sprites/girl.png". Загрузчик смотрит файлы в открытом виде, если нет, то пытается грузить из архива. В котором лежат по этому же пути.

  • Читаем tar за 26 строк ANSI C кода
    0

    Покрутил немножко. Я не вижу поддержки директорий, а без них совсем грустно.


    И длина имени файла всего 16 символов.

  • Читаем tar за 26 строк ANSI C кода
    0

    Ниже отписали, что отображение в память будет проблемно использовать с компрессором. Мне же нужно сначала распаковать gzip, а потом уже из результата читать tar.

  • Читаем tar за 26 строк ANSI C кода
    0

    Спасибо! Вроде бы формат не сильно отличается от tar. Позже попробую добавить и этот формат в свой "архиватор" на гитхаб.

  • Читаем tar за 26 строк ANSI C кода
    0

    Да, здесь согласен. Получается, что у меня в оперативке хранятся лишние картинки в виде сырых данных. Так получилось, что JSON-строки сразу конвертирую в дерево объектов, а память после tar и gzip освобождаю. Но это только из-за того, что JSON нужен весь и сразу. Попробую в своём проекте переделать логику менеджера спрайтов, чтобы сразу при инициализации грузил все картинки в формат текстуры, тогда tar-архив можно будет сразу освободить.

  • Читаем tar за 26 строк ANSI C кода
    0

    По стандарту GNU tar — 512 байт ровно. Очень длинный путь внутри tar не учитывается. Точнее, если будет больше 100 символов — то всё сломается. Если где-то такой вариант и учли в реализации, я об этом не в курсе.

  • Читаем tar за 26 строк ANSI C кода
    +1

    Именно! Это и пытался описать. Лично меня когда-то очень удивило, что архив — это не обязательно сжатие. Попытаюсь как-нибудь перефразировать, спасибо за замечание.

  • Читаем tar за 26 строк ANSI C кода
    0

    Я один раз читаю cжатый файл. Затем распаковываю архив. Это и есть пик, когда загружены и архив и его распакованная версия. Далее сжатый файл удаляется из памяти, во время работы приложения занято памяти ровно на распакованные tar-данные. Пример: data.tar 1000kb, data.tar.gz 250kb. Итого на диске хранится 250kb, пиковое потребление памяти 1250kb, потребление памяти в рабочем режиме — 1000kb. Другое дело, что если tar-файл будет большим, то грузить его весь в оперативку не рационально. Для таких случаев лучше присмотреть другое решение, а не dxTarRead.

  • Средства программирования PIC-контроллеров
    +3

    Кхм. А почему именно Mplab, а не более современная Mplab X от того же микрочипа?

  • Nuklear — идеальный GUI для микро-проектов?
    0

    Тогда всё отлично, спасибо! Прошу прощения, изначально не правильно понял смысл. Жду эти изменения в master'e Nuklear

  • Nuklear — идеальный GUI для микро-проектов?
    0

    Nuklear.h, 1156:


    1.) Using your own implementation without vertex buffer output
    So first up the easiest way to do font handling is by just providing a
    nk_user_font struct which only requires the height in pixel of the used
    font and a callback to calculate the width of a string. This way of handling
    fonts is best fitted for using the normal draw shape command API where you
    do all the text drawing yourself and the library does not require any kind
    of deeper knowledge about which font handling mechanism you use.
    IMPORTANT: the nk_user_font pointer provided to nuklear has to persist
    over the complete life time! I know this sucks but it is currently the only
    way to switch between fonts.
    2.) Using your own implementation with vertex buffer output

    While the first approach works fine if you don't want to use the optional
    vertex buffer output it is not enough if you do. To get font handling working
    for these cases you have to provide two additional parameters inside the
    nk_user_font. First a texture atlas handle used to draw text as subimages
    of a bigger font atlas texture and a callback to query a character's glyph
    information (offset, size, ...). So it is still possible to provide your own
    font and use the vertex buffer output.
  • Nuklear — идеальный GUI для микро-проектов?
    +1

    NK_INCLUDE_DRAW_TEXT_CUSTOM_FUNCTION
    Ну рисовалку картинок оно точно на драйвер перекладывает. Разве со шрифтами не так же? По-моему, это уже есть в Nuklear. GDI+ явно не использует стандартную рисовалку шрифтов от Nuklear.


    NK_INCLUDE_UNICODE_SUPPORT
    Не подскажете, почему не UTF8?

  • Nuklear — идеальный GUI для микро-проектов?
    0

    (написал выше)

  • Unicode — это очень увлекательно
    +6

    А с решением Björn Höhrmann не сравнивали? Его код выглядит гениально коротким и быстрым.

  • Nuklear — идеальный GUI для микро-проектов?
    +1

    Да сейчас и на сотни гигабайт софт можно найти. Только что в этом хорошего?...

  • Nuklear — идеальный GUI для микро-проектов?
    +1

    Спасибо за идею, помощь и подсказки. Для примера собрал свою веб-демку Nuklear:
    https://dexp.github.io/nuklear-webdemo/
    Уже добавлена в публикацию.