1.1, Аноним (-), 21:41, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Надо почитать что за упрощённое API. Возможно получится кое-где упростить код в своих проектах, а заодно устроить попоболь тем кто сидит на протухших дистрибутивах.
| |
1.4, Mihail Zenkov (ok), 22:49, 18/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимать/разжимать поток данных, можно ломать api чуть ли не с каждым выходом 1.x.0, да еще иногда, так что поправить с ходу это было нелегко.
Надеюсь с выходом упрощенного API ситуация изменится к лучшему.
| |
|
2.7, kurokaze (ok), 00:02, 19/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Меня всегда удивляло
Попробуте попрограммировать, может тогда поймете
>да еще иногда, так что поправить с ходу это было нелегко.
[I] media-libs/libpng
Available versions:
(1.2) 1.2.50
(0) 1.5.13-r1 ~1.5.14
в чем проблема? надо будет, отдельно для 1.6 сделают слот. вам то какая разница?
| |
|
3.9, Аноним (-), 02:27, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
А вот и не сделают! Для 1.2 есть потому что LSB, а для 1.4 слота нет.
| |
|
|
|
6.54, mavriq_ (?), 16:10, 21/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> В генте с png такое происходит регулярно
вы хотите сказать - у вас в генте такое происходит регулярно?
ну так пересядьте на другой дистр, коль для вас гента слишком сложна.
или вам хочется и морковку съесть, и на ^W^W^W^W считать себя круче других(я gentoo 0дминю \m/.. у себя дома), и не читать хаутушки по обновлению мира (мануалы для ламеров \m/)?
| |
|
|
|
|
2.11, Аноним (-), 04:49, 19/02/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимать/разжимать поток данных
Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.
> можно ломать api чуть ли не с каждым выходом 1.x.0, да еще иногда, так что поправить с ходу это было нелегко
Чтобы поправить сходу было нелегко - такого не было. А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.
| |
|
3.15, www2 (??), 06:00, 19/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
>А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.
Не люблю крайностей. Должна быть золотая середина и разумный баланс. Крайность суждений свидетельствует о незрелости.
| |
|
4.50, Аноним (-), 00:43, 21/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Должна быть золотая середина и разумный баланс.
Оно и есть. soname меняется, срок на deprecated даётся более чем достаточный. Но всё равно найдутся нытики-лентяи.
| |
|
3.28, Mihail Zenkov (ok), 18:19, 19/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.
Я в своей программе использую:
extern (C) png_struct* png_create_write_struct(immutable(char)*, void*, void*, void*);
extern (C) png_info_struct* png_create_info_struct(png_struct*);
extern (C) void png_init_io(png_struct*, FILE*);
extern (C) void png_set_IHDR(png_struct*, png_info_struct*, uint, uint, int, int color_type, int interlace_method, int compression_method, int filter_method);
extern (C) void png_set_pHYs(png_struct*, png_info_struct*, uint res_x, uint res_y, int unit_type);
extern (C) void png_write_info(png_struct*, png_info_struct*);
extern (C) void png_write_image(png_struct*, ubyte**);
extern (C) void png_write_end(png_struct*, png_info_struct*);
только для того чтобы просто сохранить изображение из памяти (raw rgba) в png. Это нормальный API? Такая простая операция должна выполнятся одной функцией, максимум двумя. Многие приложения вообще не работают с libpng напрямую, а используют прослойки типа freeimage. Похоже и до авторов библиотеки дошло - что навороты хорошо, но нужны они очень редко.
| |
|
4.32, Аноним (-), 19:07, 19/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Это нормальный API?
Для таких как вы, видимо, и сделали упрощённый API. И да, это нормалньый API, потому что просто сохранить rgba в png - это хорошо, но нужно это очень редко, и обычно нужна гораздо более широкая функциональность.
| |
|
5.36, Mihail Zenkov (ok), 20:15, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Приведите обычный пример, который применяется чаще (хотя бы не реже), чем просто сжать/распаковать в память/файл, где нужна большая функциональность, а то сразу что-то даже ничего в голову не приходит.
| |
|
|
3.29, Mihail Zenkov (ok), 18:30, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Чтобы поправить сходу было нелегко - такого не было.
Посмотри как gimp-2.7 переходил на новую версию. Я после обновления libpng сам хотел поправить, так как с другими библиотеками никогда проблем не было: максимум что-то переименовать или добавить параметр, а тут ... Хорошо нашел патч от другой версии гимпа и по аналогии поправил да и то кривовато, ибо по хорошему нужно было вникать гораздо глубже.
| |
|
2.24, iZEN (ok), 15:07, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО, от неё зависящее — факт.
У этой библиотеки принципы модульности и обратной совместимости не в моде.
| |
|
3.25, maxst (?), 15:34, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
> от неё зависящее — факт.
> У этой библиотеки принципы модульности и обратной совместимости не в моде.
Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.
| |
|
4.46, iZEN (ok), 00:59, 20/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.
Когда перепрыгивать, решают мантейнеры портов.
| |
|
3.33, Аноним (-), 19:09, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
> от неё зависящее — факт.
Нет. У вас же есть portupgrade/portmaster которые сохраняют старые версии библиотек, и такой хренью как в gentoo можно не страдать пока сильно не захочется.
| |
|
|
5.51, Аноним (-), 00:45, 21/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Совет использовать "pormaster -w" в /usr/ports/UPDATING для libpng (пакет png) что-то
> не припомню. http://www.freshports.org/graphics/png/ — каждый раз: "portmaster
> -r png-" или "portupgrade -fr graphics/png".
А тебе что, для каждого апдейта библиотеки должны в UPDATING писать? Не делаешь -w - сам дебил. portupgrade так по умолчанию сошки сохраняет.
| |
|
|
|
|
|
2.6, exn (??), 23:32, 18/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> зачем, когда есть фотошоп?
и не поспориш xD
| |
2.17, б.б. (?), 06:19, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
Фотошоп тоже на новую 1.6 обновится, не переживайте. Только узнаем мы об этом через 100 лет из музея компьютерной техники.
| |
|
1.8, Аноним (-), 02:26, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk, cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать. Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo возникла цикличная зависимость. Он не собирался, так как librsvg собран с libpng14, а librsvg не собирался потому что Cairo собран с libpng14. Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново. В общем, еле обновил, а теперь, видимо, снова придётся сделать это.
| |
|
2.12, Аноним (-), 04:50, 19/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk,
> cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать.
> Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo
> возникла цикличная зависимость. Он не собирался, так как librsvg собран с
> libpng14, а librsvg не собирался потому что Cairo собран с libpng14.
> Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось
> с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново.
> В общем, еле обновил, а теперь, видимо, снова придётся сделать это.
А что у вас за недосистема что она не умеет сохранять старые версии библиотек, чтобы и без пересборки всего это всё работало?
| |
|
3.16, www2 (??), 06:02, 19/02/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А что у вас за недосистема что она не умеет сохранять старые
> версии библиотек, чтобы и без пересборки всего это всё работало?
Может у него LFS ;-) Или FreeBSD, или Arch.
| |
|
2.22, лох (?), 11:31, 19/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
А просто не обновлять libpng что, религия не позволяет? package.mask там или portmaster -x...
И вообще, есть хороший принцип "работает -- не трогай". Одно дело -- разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.
| |
|
3.30, Mihail Zenkov (ok), 18:35, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> А просто не обновлять libpng что, религия не позволяет? package.mask там или
> portmaster -x...
> И вообще, есть хороший принцип "работает -- не трогай". Одно дело --
> разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.
А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит нормально? А потом в программе приходится липить кучу #ifdef на каждую версию библиотеки ибо не угадаешь, что будет у пользователя.
| |
|
4.34, Аноним (-), 19:11, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
> нормально?
Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии. Иначе либо библиотека ничего бы не умела либо была бы набором костылей для сохранения совместимости ради, опять же, ламерья.
| |
|
5.38, Mihail Zenkov (ok), 20:29, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
>> нормально?
> Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
> Иначе либо библиотека ничего бы не умела либо была бы набором
> костылей для сохранения совместимости ради, опять же, ламерья.
Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик использующий libpng самостоятельно напишет их в своей программе.
| |
|
6.40, Аноним (-), 20:47, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
>>> нормально?
>> Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
>> Иначе либо библиотека ничего бы не умела либо была бы набором
>> костылей для сохранения совместимости ради, опять же, ламерья.
> Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
> использующий libpng самостоятельно напишет их в своей программе.
зато как значимость библиотеки возрастает...
| |
6.52, Аноним (-), 00:47, 21/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
> использующий libpng самостоятельно напишет их в своей программе.
Нет, костылей в коде быть вообще не должно. Крайнее им место - в портах/пакетах.
| |
|
|
|
|
|
1.21, клоун Стаканчик (?), 10:40, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем, чьи проблемы ты должен решать?
| |
|
2.23, Аноним (-), 13:36, 19/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> сохранили бы со статусом "obsolete" - и фиг с ним.
> фиг с ним
Windows way?
| |
2.31, Mihail Zenkov (ok), 18:42, 19/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со
> статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем,
> чьи проблемы ты должен решать?
Чистить код нужно постоянно - чем меньше кода, тем выше его читаемость, меньше ошибок, легче портировать.
Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. Да и как правило библиотеки с хорошим дизайном редко сильно меняют API, в основном просто расширяют, соответственно обратная совместимость не ломается.
| |
|
3.35, Аноним (-), 19:13, 19/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.
Сами это написали, а выше ныли как страшно переписывать под новые версии. libpng так и делают, только времени доют ещё больше.
| |
|
4.37, Mihail Zenkov (ok), 20:21, 19/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.
> Сами это написали, а выше ныли как страшно переписывать под новые версии.
> libpng так и делают, только времени доют ещё больше.
Как раз с libpng и возникают проблемы, ибо программа собраная с ее поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.
Где это они времени больше дают? Что-то не припомню при компиляции "Warning: xxxx this function depricated", за то вот error'ы как грибы после дождя, если версия не совпала.
| |
|
5.47, maxst (?), 08:35, 20/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Где это они времени больше дают?
Ну вот к примеру что можно найти в libpng-manual.txt в разделе где перечисляются изменения между 1.2.x и 1.4.x:
The functions png_read_init(info_ptr), png_write_init(info_ptr),
png_info_init(info_ptr), png_read_destroy(), and png_write_destroy()
have been removed. They have been deprecated since libpng-0.95.
The png_permit_empty_plte() was removed. It has been deprecated
since libpng-1.0.9. Use png_permit_mng_features() instead.
| |
|
6.48, Mihail Zenkov (ok), 15:35, 20/02/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вот только на практике при попытке собрать приложение написанное под API 1.2.x с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.
Я использую D как основной язык, так там API основной библиотеки долгое время был крайне нестабилен - ибо язык очень быстро развивался, но при этом я не ощущал от этого большого дискомфорта, так как реально старый API переставал работать только через продолжительный срок и при каждой компиляции я видел, что функция deprecated и дату/версию в которой ее удалят.
| |
|
7.49, maxst (?), 16:28, 20/02/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Вот только на практике при попытке собрать приложение написанное под API 1.2.x
> с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.
В ветке 1.2.x ширину изображения можно было получить двумя способами:
info_ptr->width
png_get_image_width()
В ветке 1.4.x прямой доступ убрали как небезопасный и оставили только
png_get_image_width()
Именно это изменение вызвало наибольший дискомфорт: во многих старых приложениях был прямой доступ и видимо разработчики libpng не смогли придумать, как сделать чтобы чтение info_ptr->width некоторое время работало, но предупреждало, что этот подход deprecated...
По сравнению с этим, переход от 1.4.x к 1.5.x был относительно безболезненным, думаю 1.6.x тоже пройдет без особых проблем.
| |
|
|
5.53, Аноним (-), 00:49, 21/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Как раз с libpng и возникают проблемы, ибо программа собраная с ее
> поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни
> с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.
И в glibc есть deprecated, и вообще вы сколько бибилотек пользуете? Я постоянно вижу развивающиеся (причём не ценой сотен костылей, а через устаревание старых интерфейсов) API, и это правильно. "Приводите" вы здесь один страдалец, и всё, что характерно, мимо.
| |
|
|
|
|
1.44, анонимаус (?), 23:56, 19/02/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Прошлое многочасовое обновление с libpng 1.2 до 1.5 было со слезами на глазах и почти истерикой.
| |
|