Time |
Nick |
Message |
02:09 |
|
Baytuch joined #minetest-dev |
02:19 |
|
Baytuch joined #minetest-dev |
03:19 |
|
Baytuch joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:42 |
|
Yad joined #minetest-dev |
06:10 |
|
calcul0n_ joined #minetest-dev |
08:21 |
|
Fixer joined #minetest-dev |
08:57 |
sfan5 |
does anyone feel like looking at #12536 |
08:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12536 -- Misplaced leaves with visual_scale > 1 |
08:58 |
sfan5 |
also do we want #12515 for 5.6? |
08:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/12515 -- Add zstd minetest.compress support by 20kdc |
09:16 |
|
olliy joined #minetest-dev |
09:50 |
|
YuGiOhJCJ joined #minetest-dev |
10:09 |
|
HuguesRoss6 joined #minetest-dev |
11:11 |
|
Baytuch joined #minetest-dev |
11:35 |
|
Baytuch joined #minetest-dev |
12:03 |
|
Taoki joined #minetest-dev |
12:41 |
erle |
sfan5 any idea what minetest.compress is being used for currently except cobbling together PNGs and compressing item meta? |
12:44 |
sfan5 |
how would I know |
12:45 |
sfan5 |
I don't know of any uses in mods I come into contact with at least |
12:45 |
erle |
i thought you looked at that PR for some reason |
12:45 |
erle |
rubenwardy could i have another CDB dump so i can investigate? or some way to programmatically search CDB for minetest.compress? |
12:51 |
rubenwardy |
https://content.minetest.net/zipgrep/3c39b4a6-acc6-4bcb-82af-5bb3bc64bef9/ |
12:51 |
erle |
thanks |
12:52 |
MTDiscord |
<Jonathon> Minetest.compress is also used for stuff like map storage to files by some mods |
12:53 |
rubenwardy |
I don't think it's worth prioritising that PR for 5.6. But if someone else wants to review it before the deadline they can |
12:53 |
rubenwardy |
I'd rather have #7865 |
12:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/7865 -- Add crosshair support for Android by srifqi |
12:53 |
erle |
rubenwardy, are you using grep to find the lines? if so, “git grep -W” can show the function context of the search result (not saying i want it, but maybe that knowledge is helpful if you ever want to improve the results page. |
12:53 |
erle |
) |
12:53 |
rubenwardy |
I'm using `zipgrep` |
12:54 |
rubenwardy |
https://linux.die.net/man/1/zipgrep |
12:54 |
rubenwardy |
it's passed to egrep which uses grep -E so should support similar args |
12:55 |
erle |
ah i used that as well |
12:55 |
erle |
i have seen the function context thing so far only in git grep |
12:55 |
erle |
other greps don't have it afaik |
13:07 |
rubenwardy |
How do I open a new modalmenu from guiFormspecMenu? |
13:07 |
rubenwardy |
I suppose I'd need to pass in a callback/event handler, which then changes the menu |
13:16 |
Zughy[m] |
I'd rather have the dual weilding, considering how much the timing is fortuitous for Minetest thanks to Microsoft. You won't ever have an occasion like this again, so please put as many features as you can that can close the gap with MC to pass a message of caring. People won't wait years, only devs will. And you need players, not more C++ geeks |
13:21 |
erle |
i am not entirely sure what part of the zstd marketing blurb is a lie, but i just tried to figure out the optimal compression level for zstd in terms of minetest content and i was not able to outperform zlib with the default settings for both in terms of compression for a) text below 300 bytes b) ~30kb binary data c) a ~94kb html page. the zstd result is consistently about 5% larger. for text, zstd handily beats zlib when you |
13:21 |
erle |
specify maximum compression, but then it takes 25 times as long (the difference was 0.01s vs >0.25s to compress the html page). nevertheless, i think the default compression level of zstd should be adjusted to somewhere where it actually beats zlib for content that people are compressing. |
13:22 |
erle |
if anyone of you has tried to figure out the optimal compression level already, please share |
13:23 |
sfan5 |
I'm glad erlehmann is here to start discussion about irrelevant things again |
13:24 |
erle |
uh, i just want to make sure that users do not actually get something worse |
13:24 |
erle |
i think there *is* a compression level where it beats zlib, it is just not the default one |
13:24 |
sfan5 |
how users use the API and which tradeoffs they want to make is up to them |
13:24 |
sfan5 |
we shouldn't mess with library defaults |
13:31 |
erle |
i think it is relevant if it turns out we need more knobs than “compression level” |
13:38 |
erle |
okay, according to this https://github.com/facebook/zstd/issues/1134 the problem is known and it depends heavily on what you want to compress. in the example, nothing below 4kb compressed better with zstd than with zlib. |
13:40 |
erle |
and it makes sense, as they do not care about small files. what “small” is is what i am trying to determine, since the meta i want to compress will not be much more than a few tens of kilobites maximum. |
13:40 |
MTDiscord |
<GreenXenith> It would be nice to sneak in any prs that don't have conflicts and are approved (dual wielding? Texture mods?) before the freeze if possible, like zughy said this and next release are opportune times to take advantage of the user influx |
13:41 |
MTDiscord |
<GreenXenith> My 2 cents, carry on |
13:41 |
erle |
sfan5 regarding library defaults: zstd aims to be as fast as zlib with default compression settings. so by default, you seem to gain not much, except the 5% penalty (i am not compressing stuff >100kb in any mod, so i did not test that). |
13:41 |
rubenwardy |
in other news, #12367 |
13:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/12367 -- Add minetest.get_player_window_information() by rubenwardy |
13:42 |
MTDiscord |
<GreenXenith> That would certainly be nice to get in |
13:42 |
MTDiscord |
<GreenXenith> But I wouldn't be sad if it had to wait for next release |
13:43 |
erle |
you have a checkmark at “resist fingerprinting”, how did you solve it? |
13:44 |
rubenwardy |
if development is particularly active, we could always do releases sooner. Like after 3-4 months rather than 6 |
13:44 |
rubenwardy |
we're not |
13:44 |
rubenwardy |
you can already use IP addresses |
13:44 |
rubenwardy |
fingerprinting also requires a lot of different metrics to be reliable, which we don't have |
13:44 |
sfan5 |
but you're just now adding another one |
13:44 |
erle |
yes |
13:45 |
MTDiscord |
<GreenXenith> Thems the breaks |
13:45 |
erle |
every bit is useful |
13:45 |
erle |
anyways, someone™ will have fun making servers handle weird numbers |
13:46 |
erle |
rubenwardy i understand “i do not want to solve it” but then the checkmark should not be before “resist fingerprinting” |
13:46 |
erle |
especially since we live in a world in which evil actors can and will gobble up any info and use it against anyone |
13:47 |
erle |
(NSA using google tracking cookies etc.) |
13:48 |
MTDiscord |
<GreenXenith> Disregarding a faulty checkmark, the pr is ready |
13:52 |
erle |
btw, i figured out how people use zstd for small data (smaller than ~32kb) – they provide dictionaries, because that data is often uniform. if you do that, it indeed outperforms zlib by A LOT. if you do not do that, it tries to “learn” the structure of the data and the tradeoffs can be suboptimal for quite a long time. |
13:53 |
erle |
(i.e. if i would use minetest.compress in a mod using zstd, i would want to provide a dictionary, because i am only compressing stuff <100kb anyways) |
14:03 |
|
olliy joined #minetest-dev |
16:22 |
|
Baytuch joined #minetest-dev |
17:01 |
|
Fixer joined #minetest-dev |
17:15 |
|
Baytuch_2 joined #minetest-dev |
17:29 |
|
kilbith_ joined #minetest-dev |
17:31 |
|
Desour joined #minetest-dev |
17:44 |
|
kilbith joined #minetest-dev |
18:14 |
|
erle joined #minetest-dev |
18:16 |
|
Baytuch joined #minetest-dev |
18:23 |
|
erle__ joined #minetest-dev |
18:24 |
|
Baytuch joined #minetest-dev |
18:31 |
|
Baytuch joined #minetest-dev |
22:25 |
|
Baytuch joined #minetest-dev |
22:30 |
|
Baytuch joined #minetest-dev |
22:36 |
|
panwolfram joined #minetest-dev |
22:55 |
|
Baytuch joined #minetest-dev |
23:14 |
|
Baytuch joined #minetest-dev |