LINUX.ORG.RU

Пили патч в либкаку. С поддержкой цвета! Будем мувики так смотреть.

morse ★★★★★
()

Я карты в ASCII просто в vim'е рисую. Для перемасштабирования координат юзаю собственную утилиту mapbysusanin:

> cat mapbysusanin.c
/*
 * Author: Kurashov Artem
 * License: GNU GPLv3
 */
#include <stdio.h>
#include <stdlib.h>

int
main(int argc, char **argv)
{
    double          x[5],
                    y[5],
                    k[2],
                    rx,
                    ry;
    int             i;
    if (argc < 10) {
        printf
            ("Usage: mapbysusanin x_src y_src min_x_src min_y_src max_x_src max_y_src min_x_dest min_y_dest max_x_dest max_y_dest\nThis software remap coordinates from one rectangle to another.\n");
        return 1;
    }
    for (i = 1; i < 11; i += 2){
        x[(i - 1) / 2] = atof(argv[i]);
        y[(i - 1) / 2 + 1] = atof(argv[i + 1]);
    }
    k[0] = (x[2] - x[1]) / (x[4] - x[3]);
    k[1] = (y[2] - y[1]) / (y[4] - y[3]);
    rx = x[3] + (x[0] - x[1]) / k[0];
    ry = y[4] - (y[0] - y[1]) / k[1];
    printf("(%lf;%lf)\n", rx, ry);
    return 0;
}

saahriktu ★★★★★
()
Ответ на: комментарий от PPP328

Оно ж не генерирует байтмап

Я неправильно понял, а как это по-русски?
Может быть тогда: «Uses Braille for provided bytemap»?

Evenik ★★
()
Ответ на: комментарий от iVS

Это хорошо, но обычно к серверам коннектятся через ttyx а не xterm

someoneelsenotme
() автор топика
Ответ на: комментарий от CYB3R

Если жать текстовые файлы, то особой выгоды, конечно, не будет. Пожатые файлы в UTF-8 будут занимать где-то примерно в 1,1 раза больше дискового пространства чем пожатые файлы в KOI8-R. Однако, память дисковым пространством не ограничивается. При работе с юникодом каждый символ в wchar_t занимает в оперативке 4 байта. 4 байта. Даже ASCII символы. Т.е. wchar_t превращает всё в оперативке в UTF-32. Можно, конечно, читать в char *. Только тогда проявится непредсказуемость UTF-8. Неизвестно сколько байт какой символ и где модификаторы (а в однобайтных кодировках их просто нет). Да и мультибайтные функции расчитаны на работу с wchar_t.

Кстати, по стандартам юникода размер символа может вообще гулять в диапазоне 1-6 байт. Т.е. и UTF-32, по сути, мало. Нужен, как минимум, UTF-48.

Ну вот и зачем тратить в 4-6 раз больше оперативки на представление того, что можно описать 256-ю символами, да ещё и мучаться с разными ICU (для удаления модификаторов) и прочими лишними сущностями?

Юникод выбирают от безысходности. Когда перестаёт хватать 256 символов.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Какая-то экономия на спичках. Сколько у тебя оперативки? Ты что зря все эти гигабайты покупал? Ты их жрать будешь?
Или тебе на оперативку скинуться?

CYB3R ★★★★★
()
Ответ на: комментарий от CYB3R

Тут дело не только в экономии, но и в удобстве. Чем проще и предсказуемее - тем удобнее. Ну, а что касается экономии, то гигабайты текстов в однобайтовой кодировке при необходимости распарсить быстрее и проще чем в юникоде.

На этой машине у меня 8 гигов оперативки. Но, у меня ещё есть Raspberry Pi с 512 Мб опретивки (часть под видеопамять, часть под ядро, часть под софт с библиотеками,...). И удобно когда везде всё работает одинаково.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Да, но софт из данного топика у тебя не работает правильно именно из-за кодировки. А у всех остальных в этом топике всё в порядке.

CYB3R ★★★★★
()
Ответ на: комментарий от CYB3R

Да, но мне такой софт и не нужен. Когда я начинал здесь писать я ещё до конца не разобрался, и думал, что он работает с ASCII. А оно вон как...

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)

Добавил функционал чтения из ПНГ файла, теперь можно просто загружать пнг-хи а спец-функция загрузит оттуда битовую маску.

https://github.com/codemeow/ascii-earth/raw/master/screen2.png

Будем мувики так смотреть.

morse, можно, но только черно-белые, ибо нельзя контролировать цвет отдельных точек, только знако-места.

someoneelsenotme
() автор топика
Ответ на: комментарий от someoneelsenotme

нельзя контролировать цвет отдельных точек, только знако-места

Ну и нормально. Хоть как-нибудь.

morse ★★★★★
()
23 октября 2017 г.
Ответ на: комментарий от saahriktu

Это ж не чятик и не борда какая-нибудь, чтобы выкладывать временно. Тут треды даже за 1999-й год висят, и их даже кто-то читает. Обидно, когда ссылки умирают.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Если бы не умирали бы общественные FTP'шники, или хотя бы в стандарте WebDAV был прописан механизм получения публичных http(s) ссылок - висели бы скриншоты сколько угодно. А так хостинг не резиновый.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Чуть менее удобно, но вот эти товарищи как раз резиновые плюс отдают ссылки на разные размеры от малюсенькой превьюхи до оригинала: https://tech.yandex.ru/fotki/
Для неумирающих иллюстраций годится, автоматизация опять же.

massimus ★★★
()
19 марта 2018 г.
Ответ на: комментарий от bodqhrohro_promo

Ну так всё благодаря Python'овому скрипту TgImgUpl. Просто скармливаю ему путь к файлу картинки и получаю готовый URL.

saahriktu ★★★★★
()
Ответ на: комментарий от qula

Сравнение крайне некорректно. Колясочникам нужны ноги, у них просто нет возможности их юзать. А юзерам однобайтных локалей тысячи юникодных символов ненужны как ненужны ноги рыбам, у которых их отродясь не было.

saahriktu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.