#tde-devs < 2024/05/18 >
[07:29]denk: akh: step by step, line by line we're going to the file annihilation :)
[08:42]akh: :^)
[08:47]akh: Ended up pulling that code you flagged completely (it had additional issues)
[08:47]akh: You'd think that a library's sample code would be an example of recommended practice...
[08:55]denk: I don't like some code of error() function, but it's my opinion
[08:56]denk: what I would change: use a "stack" buffer to construct a message and switch to the dynamic code if the message is larger than the buffer
[09:05]denk: https://paste.dilos.org/?214c393b8c421612#oi31XQ0qUyFJTDV6IAKxmRcmvH6Dk24MSJ4CNQqBTsE=
[09:06]tde-bot: Page title: PrivateBin
[09:06]denk: something like that
[09:07]denk: I'm pretty sure that dynamic part will be used in <1% of most calls of the function
[09:07]denk: probably it will never happen
[09:08]denk: btw, preallocated buffer is more faster than a dynamic variant
[09:33]denk: once more: don't use my code as is, it's just an example!
[11:03]akh: faster but could end up truncating messages (though 65535 characters would be pathalogical)
[11:17]denk: compare the return value with the buffer size and switch to the dynamic branch
[11:23]denk: https://paste.dilos.org/?f1ed6f843b7de7a8#fOd71Apu3Ka1RGzjwj4IbeqEKLt840695G3kn7vsIOo=
[11:23]tde-bot: Page title: PrivateBin
[11:23]denk: the code works in a real project
[11:23]akh: vsnprintf will truncate if the string's too big for the buffer. One needs to check the return value (bytes that _would_ be written) against the actual buffer size: -1 error, <size ok, >=size truncated.
[11:24]akh: yea, like that :^)
[11:57]micheleC has joined
[12:08]akh: denk: What could be useful in low-memory environments would be an incremental snprintf, e.g. int isnprintf(char* buffer, size_t size, size_t offset, const char* format, ...)
[12:08]akh: don't think such a thing exists though
[12:17]denk: it should depend on the task (or a goal)
[12:17]akh: I'm thinking microcontrollers
[12:18]denk: early optimization is the evil
[12:18]akh: Plenty of ROM, very little RAM
[12:18]denk: huh
[12:19]akh: As an application for my suggested isnprint
[12:19]denk: solaris/illumos has a kernel cache, it's a preallocated area for some specific task
[12:20]denk: when the task need a memory (fixed size) for a packed of data, for example, it tries to allocate it from the cache
[12:20]denk: and then it can try to allocate via kmem_alloc
[12:22]denk: I think your task has similar functions, try to do something like that
[12:23]denk: if you call the heap too often you will have a very high memory fragmentation
[12:24]denk: every fragment has a record in a list where alloc/free does a search to find some address
[12:28]akh: I see what you're saying. Personally I tend to prefer code clarity over e.g. efficiency unless there's a compelling reason (cf. premature optimization). Fragmentation could be an issue though. I'll give it some thought...
[12:33]denk: printing by format is a very hard task because you don't know how many memory it needs until you parse the format and compute everything
[12:34]akh: yup
[12:34]denk: then you should do second pass to build a result
[12:39]denk: I remember the only situation where it's easy - boot loader
[12:39]denk: you can use memory from "here" and to the infinite
[12:40]denk: just don't forget to copy the result otherwise next call will overwrite it
[12:42]akh: Careful now. I run Linux systems with <32 MB of RAM. Infinity can sometimes be rather smaller than one expects!
[12:53]micheleC: @ahk: just for your info, when you believe a PR is ready for review, you should remove WIP from its title. WIP means that you are still planning to do some work on it, so we usually don't look into them unless specifically asked to.
[12:53]akh: OK, I'll keep that in mind
[12:54]akh: All three PRs are ready for review
[12:57]micheleC: ok, I will remove WIP and [probably review them tomorrow
[12:57]akh: I pulled the WIP labels
[12:57]micheleC: (y)
[12:57]micheleC: just noticed that
[12:58]denk: akh: I found that! https://bashny.net/t/en/52695
[12:59]denk: original in russian https://infojournal.ru/wp-content/uploads/2020/03/mir_info-6-2017.pdf
[13:00]denk: the story is from 2001 (23 years)
[13:01]micheleC: @ahk: am I correct that TDE/tdelibs#277 needs TDE/tdebase#487?
[13:01]akh: Been there, done that, placed variables into unused configuration registers because there was literally nowhere else to put them
[13:01]tde-bot: [TGW][tdebase] #487 - Adds thumbnail generation for WebP images
[13:01]tde-bot: https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/487
[13:01]tde-bot: [TGW][tdelibs] #277 - Adds WebP read support to kimgio
[13:01]tde-bot: https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/pulls/277
[13:01]akh: (That was in 2022)
[13:03]akh: micheleC: 487 doesn't strictly require 277 but if 277 isn't present (i.e. no kimgio_webp) then thumbnails for WebP images won't be generated.
[13:04]akh: I saw no ill effects when 487 was applied but kimgio_webp was missing
[13:04]micheleC: ok thanks for the clarification
[13:20]akh: micheleC: To further clarify: 487 does not require 277. 277 does not require 487. If either is missing then some/all new functionality will be unavaialable but nothing (old or new) will be broken.
[13:20]micheleC: (y)
[15:21]micheleC has quit (Quit: Kopete 0.12.7 : http://trinitydesktop.org)
[22:40]SlavekB has joined

#tde-devs < 2024/05/18 >