Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Релиз libpng 1.6.0 с поддержкой упрощённого API, opennews (??), 18-Фев-13, (0) [смотреть все] Надо почитать что за упрощённое API Возможно получится кое-где упростить код в , Аноним (-), 21:41 , 18-Фев-13, (1) –2 // В raring 1 2 49, paulus (ok), 21:48 , 18-Фев-13, (2) // Класс, это ещё лучше , Аноним (-), 21:56 , 18-Фев-13, (3) +1 Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимат, Mihail Zenkov (ok), 22:49 , 18-Фев-13, (4) +10 // Попробуте попрограммировать, может тогда поймете I media-libs libpng Availa, kurokaze (ok), 00:02 , 19-Фев-13, (7) –1 // А вот и не сделают Для 1 2 есть потому что LSB, а для 1 4 слота нет , Аноним (-), 02:27 , 19-Фев-13, (9) // ну значит в пакет 1 6 будет помечен как тестируемый на долгое время, runoverheads (ok), 03:00 , 19-Фев-13, (10) а потом всё наебнётся после долгого времени В генте с png такое происходит регу, all_glory_to_the_hypnotoad (ok), 23:15 , 19-Фев-13, (42) вы хотите сказать - у вас в генте такое происходит регулярно ну так пересядьте н, mavriq_ (?), 16:10 , 21-Фев-13, (54) +1 Ты путаешь libpng с zlib libpng приходится делать хренову тонну вещей, посмотри, Аноним (-), 04:49 , 19-Фев-13, (11) –2 // Не люблю крайностей Должна быть золотая середина и разумный баланс Крайность с, www2 (??), 06:00 , 19-Фев-13, (15) +2 // Похерил API - меняй soname, блеать , ip1981 (ok), 20:42 , 19-Фев-13, (39) +3 Оно и есть soname меняется, срок на deprecated даётся более чем достаточный Но, Аноним (-), 00:43 , 21-Фев-13, (50) +1 Я в своей программе использую extern C png_struct png_create_write_struct imm, Mihail Zenkov (ok), 18:19 , 19-Фев-13, (28) –1 // Для таких как вы, видимо, и сделали упрощённый API И да, это нормалньый API, по, Аноним (-), 19:07 , 19-Фев-13, (32) +2 Приведите обычный пример, который применяется чаще хотя бы не реже , чем просто, Mihail Zenkov (ok), 20:15 , 19-Фев-13, (36) Разве вы не написали уже свою функцию my_write_png_file , ip1981 (ok), 23:46 , 19-Фев-13, (43) Посмотри как gimp-2 7 переходил на новую версию Я после обновления libpng сам х, Mihail Zenkov (ok), 18:30 , 19-Фев-13, (29) Каждый раз при выходе новой версии libpng 1 x нужно пересобирать всё ПО, от неё , iZEN (ok), 15:07 , 19-Фев-13, (24) // Недавно вышла 1 5 14 скоро выйдет 1 5 15, вовсе необязательно перепрыгивать на в, maxst (?), 15:34 , 19-Фев-13, (25) // Когда перепрыгивать, решают мантейнеры портов , iZEN (ok), 00:59 , 20-Фев-13, (46) –1 Нет У вас же есть portupgrade portmaster которые сохраняют старые версии библио, Аноним (-), 19:09 , 19-Фев-13, (33) // Совет использовать pormaster -w в usr ports UPDATING для libpng пакет png , iZEN (ok), 00:54 , 20-Фев-13, (45) –1 А тебе что, для каждого апдейта библиотеки должны в UPDATING писать Не делаешь , Аноним (-), 00:45 , 21-Фев-13, (51) зачем, когда есть фотошоп , Аноним (-), 23:28 , 18-Фев-13, (5) +3 // и не поспориш xD, exn (??), 23:32 , 18-Фев-13, (6) +2 настолько неожиданно, что даже не толсто, Аноним (-), 05:47 , 19-Фев-13, (14) +2 Фотошоп тоже на новую 1 6 обновится, не переживайте Только узнаем мы об этом че, б.б. (?), 06:19 , 19-Фев-13, (17) Ну вот, опять обновлять всю систему К libpng призывается всё Qt, gtk, cairo, p, Аноним (-), 02:26 , 19-Фев-13, (8) +1 // А что у вас за недосистема что она не умеет сохранять старые версии библиотек, ч, Аноним (-), 04:50 , 19-Фев-13, (12) +1 // Может у него LFS - Или FreeBSD, или Arch , www2 (??), 06:02 , 19-Фев-13, (16) +2 // Фря умеет сохранять старые либы , masakra (ok), 09:06 , 19-Фев-13, (18) Нет, фряшные порты не умеют , Аноним (-), 15:37 , 19-Фев-13, (26) +1 Порты и не должны этого уметь potrmaster -w, masakra (ok), 17:23 , 19-Фев-13, (27) –1 Как там ваш дядька в Киеве , Куяврик (?), 23:13 , 19-Фев-13, (41) А просто не обновлять libpng что, религия не позволяет package mask там или por, лох (?), 11:31 , 19-Фев-13, (22) –1 // А переписывать программы при каждой смене libpng разработчикам мэинтейнерам это , Mihail Zenkov (ok), 18:35 , 19-Фев-13, (30) // Абсолютно Ленивому ламерью западло, но оно может забандлить libpng любой протух, Аноним (-), 19:11 , 19-Фев-13, (34) Правильно, зачем хранить собственные костыли в одном месте Пусть лучше каждый р, Mihail Zenkov (ok), 20:29 , 19-Фев-13, (38) зато как значимость библиотеки возрастает , Аноним (-), 20:47 , 19-Фев-13, (40) Нет, костылей в коде быть вообще не должно Крайнее им место - в портах пакетах , Аноним (-), 00:47 , 21-Фев-13, (52) лох дело говорит, Resonance (ok), 13:45 , 02-Ноя-14, (55) apng , Аноним (-), 04:55 , 19-Фев-13, (13) // добавляется отдельным патчем , maxst (?), 09:27 , 19-Фев-13, (20) pngOS, Аноним (-), 09:24 , 19-Фев-13, (19) А какой глобальный смысл в удалении устаревшего кода Ну сохранили бы со статусо, клоун Стаканчик (?), 10:40 , 19-Фев-13, (21) –1 // Windows way , Аноним (-), 13:36 , 19-Фев-13, (23) +1 Чистить код нужно постоянно - чем меньше кода, тем выше его читаемость, меньше о, Mihail Zenkov (ok), 18:42 , 19-Фев-13, (31) +1   // Сами это написали, а выше ныли как страшно переписывать под новые версии libpng, Аноним (-), 19:13 , 19-Фев-13, (35)   // Как раз с libpng и возникают проблемы, ибо программа собраная с ее поддержкой же, Mihail Zenkov (ok), 20:21 , 19-Фев-13, (37) –1   Ну вот к примеру что можно найти в libpng-manual txt в разделе где перечисляются, maxst (?), 08:35 , 20-Фев-13, (47)   Вот только на практике при попытке собрать приложение написанное под API 1 2 x с, Mihail Zenkov (ok), 15:35 , 20-Фев-13, (48) –1   В ветке 1 2 x ширину изображения можно было получить двумя способами info_ptr- w, maxst (?), 16:28 , 20-Фев-13, (49) +1   И в glibc есть deprecated, и вообще вы сколько бибилотек пользуете Я постоянно , Аноним (-), 00:49 , 21-Фев-13, (53)   Прошлое многочасовое обновление с libpng 1 2 до 1 5 было со слезами на глазах и , анонимаус (?), 23:56 , 19-Фев-13, (44) +2 1,4,5,8,13,19,21,44

Сообщения

[Сортировка по времени | RSS]

	31. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	+1 +/–
	Сообщение от Mihail Zenkov (ok), 19-Фев-13, 18:42
	> А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со > статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем, > чьи проблемы ты должен решать? Чистить код нужно постоянно - чем меньше кода, тем выше его читаемость, меньше ошибок, легче портировать. Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. Да и как правило библиотеки с хорошим дизайном редко сильно меняют API, в основном просто расширяют, соответственно обратная совместимость не ломается.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	35. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	+/–
	Сообщение от Аноним (-), 19-Фев-13, 19:13
	> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. Сами это написали, а выше ныли как страшно переписывать под новые версии. libpng так и делают, только времени доют ещё больше.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 19-Фев-13, 20:21
	>> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. > Сами это написали, а выше ныли как страшно переписывать под новые версии. > libpng так и делают, только времени доют ещё больше. Как раз с libpng и возникают проблемы, ибо программа собраная с ее поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить. Где это они времени больше дают? Что-то не припомню при компиляции "Warning: xxxx this function depricated", за то вот error'ы как грибы после дождя, если версия не совпала.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	+/–
	Сообщение от maxst (?), 20-Фев-13, 08:35
	> Где это они времени больше дают? Ну вот к примеру что можно найти в 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.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	–1 +/–
	Сообщение от Mihail Zenkov (ok), 20-Фев-13, 15:35
	Вот только на практике при попытке собрать приложение написанное под API 1.2.x с новой 1.4.x заканчивается кучей ошибок, а не warning'ов. Я использую D как основной язык, так там API основной библиотеки долгое время был крайне нестабилен - ибо язык очень быстро развивался, но при этом я не ощущал от этого большого дискомфорта, так как реально старый API переставал работать только через продолжительный срок и при каждой компиляции я видел, что функция deprecated и дату/версию в которой ее удалят.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	+1 +/–
	Сообщение от maxst (?), 20-Фев-13, 16:28
	> Вот только на практике при попытке собрать приложение написанное под 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 тоже пройдет без особых проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз libpng 1.6.0 с поддержкой упрощённого API"	+/–
	Сообщение от Аноним (-), 21-Фев-13, 00:49
	> Как раз с libpng и возникают проблемы, ибо программа собраная с ее > поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни > с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить. И в glibc есть deprecated, и вообще вы сколько бибилотек пользуете? Я постоянно вижу развивающиеся (причём не ценой сотен костылей, а через устаревание старых интерфейсов) API, и это правильно. "Приводите" вы здесь один страдалец, и всё, что характерно, мимо.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема