Мне это знакомо. Я в свое время пытался решить своими силами одну задачу — чтение отсканированных книг в формате djvu на маленьких экранах смартфонов. Идея была связана как раз с сегментированием текста «на лету». Казалось бы, все просто — прямо в реальном времени берем страницу (как картинку), режем ее на строки (это достаточно просто), режем каждую строку на 2 или 3 части, выводим одну под другой. Да — выглядеть будет криво, но зато читать можно нормально, а не под лупой.
Для простого теста работало. Но потом стали появляться картинки, таблицы, картинки с текстом и прочая экзотика, на которой алгоритм естественно ломался:) Пытался работать и с этим, но вскоре погряз во множестве разных вариантов и забросил.
Действительно грань между простым текстом и всякими картинками-таблицами очень тонкая. Читая статью, пришла в голову мысль, что во множестве графических форматов не хватает такого, который был бы картинкой, но содержал бы в себе метаинформацию: текст — например для поиска по документу, а возможно также и информацию форматирования текста и векторную графику. Тогда можно было бы спокойно запаковывать все «спорные» объекты в такие картинки.
Понятно. Устройство выглядит довольно маленьким, как обычный смартфон; такое вполне комфортно держать как на фотке. Смартфоны с qwerty, такие как Nokia N900 и Blackberry, держат по тому же принципу.
Я имею в виду «планшетный» размер (экран около 8-9 дюймов). Это уже достаточно большое устройство, которое вот так на пальцах не удержишь, его нужно держать именно на ладонях.
Ключевая особенность — расположение клавиш. У Samsung Q1 оно на мой взгляд идеальное для работы «на ходу» — клавиатура разделена на две части под большие пальцы обеих рук, можно работать практически как с геймпадом.
У BlackBerry Passport — совершенно непонятно каким хватом его держать, чтобы было удобно работать с клавиатурой. Для того, чтобы дотянуться до каждой клавиши, придется держать его за нижнюю часть, в результате чего верхняя часть «перевешивает», создавая ненужную нагрузку на пальцы, а сам планшет очень легко может выскользнуть из рук, особенно если в толпе за него кто-то зацепится.
Я думал вы жаловаться будете, а вас похоже все устраивает:)
Принципиально новое в плане аппаратных возможностей еще может появиться, другое дело что они могут быть не такими востребованными и очевидными. Всякие 3D-сканеры, например.
А принципиально новое в форм-факторах — вряд ли (к сожалению). Плоские стеклянные кирпичи оккупировали мир. А вот возвращения к незаслуженно забытому старому хотелось бы. Samsung Q1 Ultra
У меня никогда не было такого устройства, но вот если что и покупать, то я бы купил такой девайс сейчас — разумеется, на современном железе, и более тонкий и легкий. Промежуточный вариант между смартфоном и ноутбуком, по сути — планшет с аппаратной клавиатурой, ориентированный не только (и не столько) на игры, сколько на работу «на ходу» (например в транспорте и прочих местах где нет удобной плоскости чтобы поставить ноутбук) — например написание и редактирование статей, активная переписка, даже программирование.
Мне действительно непонятно — неужели маркетологи крупных компаний не проводят исследования, опросы с целью выяснить предпочтения покупателей? Или это действительно никому не нужно кроме узкой прослойки гиков, и всех устраивают однотипные планшеты?
Можно еще надеяться что кто-то в Штатах запустит краудфандинговую компанию, но вот пока не запускают…
Возможно на планшете. И не то чтобы хочу, просто интересно пообсуждать… ведь такая маленькая система была бы очень неплохим решением для мобильных устройств.
И еще мне интересна тема преимуществ и недостатков ассемблера по сравнению с среднеуровневыми языками типа Си в системном программировании, на примере огромного опыта авторов Колибри. Сформулирую более конкретно: чего с точки зрения авторов Колибри не хватает в том же Си или С++, чтобы можно было портировать Колибри и не потерять при этом ничего ни в производительности, ни в минимализме?
Восхищаюсь вашим проектом. Но все-же объективным недостатком системы, написанной на ассемблере, является ее непортируемость под ARM, а значит под мобильные устройства, которые сегодня даже более актуальны чем обычные компьютеры. Да и писать на Ассемблере в современном мире высокоуровневых парадигм все-же тяжеловато, особенно если это большие объемы кода.
Поэтому тут возникает некая мысль, идея… насколько низкоуровневым должен быть язык программирования, чтобы можно было портировать код Колибри с ассемблера на этот язык и не потерять при этом ни капли производительности и компактности кода? Например Си — достаточно ли низкоуровневый, или вы там применяете какие-то приемы и хаки, которые недоступны в Си? Может быть, вам имеет смысл подумать над созданием какого-то альтернативного языка программирования (по-видимому расширения/модификации Си), с тем чтобы можно было портировать Колибри на этот язык, сохранив низкоуровневость Ассемблера и полный контроль над кодом, но при этом открыв возможность кодогенерации для других архитектур?
При этом нельзя точно сказать, в чем причина: действительно некачественый неоригинальный картридж, или какие-то скрытые особенности оригинальных картриджей, специально внесенные фирмой производителем (в данном случае HP).
LLVM вообще интересная тема (поэтому плюсую статью в любом случае), но вот перевод машинный.
Да и даже если бы был не машинный… вода:( Причем в американском стиле — «практическая вода». Возьмите такую-то команду — получите такой-то результат. При этом никакого фундаментального представления о том какие вообще бывают команды, что они конкретно делают и как именно — нет.
Есть такая книжка, Getting Started with LLVM Core Libraries. Там вся книжка такой воды. Даже официальная документация и то информативнее (хотя обычно книжки покупают чтобы разбавить «сухость» официальной документации и взглянуть на предмет с разных сторон)
Возможно конечно, это у меня завышенные требования… но это вообще проблема больших проектов: чтобы что-то понять, нужно много лет сидеть и писать реальный код, разбираясь в чужих исходниках.
Приятно, что наследники знаменитого Borland (на компиляторах которого многие еще под DOS учились программировать) продолжают развитие.
Так теперь там везде clang? И для Pascal тоже? И всякие специфичные для Embarcadero языковые расширения с++ он тоже поддерживает? Старый компилятор остался или его совсем выпилили?
А напишите обзорную статью по языку, с описанием всех интересных фич. Думаю, многие здесь с удовольствием прочитают, и возможно будет интересная дискуссия:)
Да я бы не сказал что там высочайший уровень абстракции. Обычная передача объектов, возвращаемых из одной функции, в другую, кое-где лямбды просматриваются, только скобок нет.
И не факт, что отсутствие скобок — преимущество. Да, это похоже на «человеческий язык», зато повышается вероятность случайно написать что-то синтаксически правильное и правильное с точки зрения «человеческого языка», но приводящее совершенно к другому, неожиданному результату.
Конечно идея хорошая. Конечно в обозримом будущем никакая власть на это не согласится, но почву надо готовить.
Хотя с «проектами», «идеями» и прочим будет сложновато для обывателя.
Я бы начал с простого распределения налогов по направлениям. То есть каждый гражданин может проголосовать, на какие направления (статьи расходов бюджета) он бы хотел тратить свои налоги.
Для простого теста работало. Но потом стали появляться картинки, таблицы, картинки с текстом и прочая экзотика, на которой алгоритм естественно ломался:) Пытался работать и с этим, но вскоре погряз во множестве разных вариантов и забросил.
Действительно грань между простым текстом и всякими картинками-таблицами очень тонкая. Читая статью, пришла в голову мысль, что во множестве графических форматов не хватает такого, который был бы картинкой, но содержал бы в себе метаинформацию: текст — например для поиска по документу, а возможно также и информацию форматирования текста и векторную графику. Тогда можно было бы спокойно запаковывать все «спорные» объекты в такие картинки.
Но сейчас люди не писатели, увы:) А смотреть фильмы, картинки вконтактике или играть в игрушки можно и с планшета.
Я имею в виду «планшетный» размер (экран около 8-9 дюймов). Это уже достаточно большое устройство, которое вот так на пальцах не удержишь, его нужно держать именно на ладонях.
У BlackBerry Passport — совершенно непонятно каким хватом его держать, чтобы было удобно работать с клавиатурой. Для того, чтобы дотянуться до каждой клавиши, придется держать его за нижнюю часть, в результате чего верхняя часть «перевешивает», создавая ненужную нагрузку на пальцы, а сам планшет очень легко может выскользнуть из рук, особенно если в толпе за него кто-то зацепится.
Принципиально новое в плане аппаратных возможностей еще может появиться, другое дело что они могут быть не такими востребованными и очевидными. Всякие 3D-сканеры, например.
А принципиально новое в форм-факторах — вряд ли (к сожалению). Плоские стеклянные кирпичи оккупировали мир. А вот возвращения к незаслуженно забытому старому хотелось бы.
Samsung Q1 Ultra
У меня никогда не было такого устройства, но вот если что и покупать, то я бы купил такой девайс сейчас — разумеется, на современном железе, и более тонкий и легкий. Промежуточный вариант между смартфоном и ноутбуком, по сути — планшет с аппаратной клавиатурой, ориентированный не только (и не столько) на игры, сколько на работу «на ходу» (например в транспорте и прочих местах где нет удобной плоскости чтобы поставить ноутбук) — например написание и редактирование статей, активная переписка, даже программирование.
Мне действительно непонятно — неужели маркетологи крупных компаний не проводят исследования, опросы с целью выяснить предпочтения покупателей? Или это действительно никому не нужно кроме узкой прослойки гиков, и всех устраивают однотипные планшеты?
Можно еще надеяться что кто-то в Штатах запустит краудфандинговую компанию, но вот пока не запускают…
И еще мне интересна тема преимуществ и недостатков ассемблера по сравнению с среднеуровневыми языками типа Си в системном программировании, на примере огромного опыта авторов Колибри. Сформулирую более конкретно: чего с точки зрения авторов Колибри не хватает в том же Си или С++, чтобы можно было портировать Колибри и не потерять при этом ничего ни в производительности, ни в минимализме?
Поэтому тут возникает некая мысль, идея… насколько низкоуровневым должен быть язык программирования, чтобы можно было портировать код Колибри с ассемблера на этот язык и не потерять при этом ни капли производительности и компактности кода? Например Си — достаточно ли низкоуровневый, или вы там применяете какие-то приемы и хаки, которые недоступны в Си? Может быть, вам имеет смысл подумать над созданием какого-то альтернативного языка программирования (по-видимому расширения/модификации Си), с тем чтобы можно было портировать Колибри на этот язык, сохранив низкоуровневость Ассемблера и полный контроль над кодом, но при этом открыв возможность кодогенерации для других архитектур?
Да и даже если бы был не машинный… вода:( Причем в американском стиле — «практическая вода». Возьмите такую-то команду — получите такой-то результат. При этом никакого фундаментального представления о том какие вообще бывают команды, что они конкретно делают и как именно — нет.
Есть такая книжка, Getting Started with LLVM Core Libraries. Там вся книжка такой воды. Даже официальная документация и то информативнее (хотя обычно книжки покупают чтобы разбавить «сухость» официальной документации и взглянуть на предмет с разных сторон)
Возможно конечно, это у меня завышенные требования… но это вообще проблема больших проектов: чтобы что-то понять, нужно много лет сидеть и писать реальный код, разбираясь в чужих исходниках.
Так теперь там везде clang? И для Pascal тоже? И всякие специфичные для Embarcadero языковые расширения с++ он тоже поддерживает? Старый компилятор остался или его совсем выпилили?
И не факт, что отсутствие скобок — преимущество. Да, это похоже на «человеческий язык», зато повышается вероятность случайно написать что-то синтаксически правильное и правильное с точки зрения «человеческого языка», но приводящее совершенно к другому, неожиданному результату.
Хотя с «проектами», «идеями» и прочим будет сложновато для обывателя.
Я бы начал с простого распределения налогов по направлениям. То есть каждый гражданин может проголосовать, на какие направления (статьи расходов бюджета) он бы хотел тратить свои налоги.