Minetest logo

IRC log for #minetest-dev, 2015-05-07

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:33 diemartin joined #minetest-dev
01:25 diemartin joined #minetest-dev
01:37 Wayward_Tab joined #minetest-dev
03:08 kaeza joined #minetest-dev
03:12 Fritigern joined #minetest-dev
03:32 yh1986 hmmmm、est31: the basic cause of all-red graphics with shaders(android) is that "vVertexColor" in file "COGLES2Solid.vsh", r is actually
03:34 Hunterz joined #minetest-dev
03:35 Fritigern joined #minetest-dev
03:35 yh1986 'r' is actually day light, 'g' is actually night light, 'b' is actually light source.
03:38 yh1986 the shaders for android is uncompleted compared to the shaders in pc,
03:40 kaeza joined #minetest-dev
03:49 FR^4 joined #minetest-dev
03:56 FR^4 joined #minetest-dev
04:06 FR^4 joined #minetest-dev
04:14 Fritigern joined #minetest-dev
04:29 Fritigern joined #minetest-dev
04:32 Fritigern joined #minetest-dev
04:38 Fritigern joined #minetest-dev
04:58 OldCoder joined #minetest-dev
05:39 Wayward_Tab joined #minetest-dev
05:47 Hunterz joined #minetest-dev
05:50 Wayward_Tab joined #minetest-dev
06:21 Robert_Zenz joined #minetest-dev
06:35 jin_xi joined #minetest-dev
06:36 hmmmm https://github.com/kwolekr/minetest/commit​/656575b59d4f0d67452cca7409c9064f690f038c
06:40 kaeza joined #minetest-dev
06:41 TheWild joined #minetest-dev
06:44 selat joined #minetest-dev
06:46 TheWild left #minetest-dev
06:47 kilbith joined #minetest-dev
06:56 hmmmm https://github.com/kwolekr/minetest/commit​/b246812455737b2d0337dec905ba0256adefd105
07:06 nore joined #minetest-dev
07:08 Calinou joined #minetest-dev
07:08 Etzos Can someone take a look at https://github.com/minetest/minetest/pull/2679 ? The bug seems to prevent the game from running.
07:09 kaeza joined #minetest-dev
07:22 leat3 joined #minetest-dev
07:32 leat3 joined #minetest-dev
07:42 leat3 joined #minetest-dev
07:47 kilbith hmmm, updated MT today and it refuses to run now : http://pastie.org/10175243
07:50 Etzos Already reported in issue #2678. I found and fixed the error in PR 2679.
07:50 ShadowBot https://github.com/minetest/minetest/issues/2678 -- ugly server crash on, "hud_add" d720fd5 builtin/game/statbars.lua:49: in function initialize_builtin_statbars
07:50 kilbith nore, you can check it please ?
07:52 nore the code looks fine, but I haven't tested it yet
07:58 nore Ok, confirmed the bug, and checked that the fix works
07:58 nore I'll merge it, since it is very high priority
07:59 nore and the fix is simple enough
07:59 kilbith thanks nore
08:00 Yepoleb_ joined #minetest-dev
08:20 ShadowBot joined #minetest-dev
08:51 OldCoder joined #minetest-dev
09:24 chchjesus joined #minetest-dev
09:25 Megaf joined #minetest-dev
09:26 Calinou joined #minetest-dev
09:26 rubenwardy joined #minetest-dev
09:43 leat3 joined #minetest-dev
09:49 OldCoder joined #minetest-dev
09:56 leat3 joined #minetest-dev
10:06 leat3 joined #minetest-dev
10:17 leat3 joined #minetest-dev
10:31 yh1986 joined #minetest-dev
10:46 yh1986 joined #minetest-dev
11:02 yh1986 joined #minetest-dev
11:35 kilbith joined #minetest-dev
12:12 yh1986 joined #minetest-dev
12:17 Calinou joined #minetest-dev
12:37 ElectronLibre joined #minetest-dev
12:38 proller joined #minetest-dev
12:39 err404 joined #minetest-dev
13:38 err404 joined #minetest-dev
13:51 AnotherBrick joined #minetest-dev
13:54 proller joined #minetest-dev
14:02 Taoki joined #minetest-dev
14:44 hmmmm joined #minetest-dev
15:05 est31 joined #minetest-dev
15:10 FR^2 joined #minetest-dev
15:26 est31 about https://github.com/minetest/minetest/commi​t/b246812455737b2d0337dec905ba0256adefd105
15:27 est31 hmmmm, perhaps add an option to completely omit identation?
15:27 est31 right now having zero means to use single tabs
15:28 est31 perhaps make zero mean have no identation, and -1 means to use single tabs
15:28 hmmmm does it really matter
15:28 est31 no
15:29 * est31 should do those srp cleanups to do more higher prio work
15:30 est31 what are your plans for client side modding running hmmmm?
15:30 VanessaE ShadowNinja: that change needs to wait for 0.5 imho.  we can't be breaking shit so readily.
15:30 hmmmm i don't know but i have a lot of stuff to do
15:32 est31 VanessaE, the security patch or the patch to make mods non-global ?
15:32 VanessaE est31: the non-global opne
15:32 VanessaE one*
15:32 hmmmm are we really going to call it 0.5.0
15:32 VanessaE the security patch at least already has enough side-work ahead of it to stop it breaking mods more or less.
15:33 VanessaE hmmmm: well whatever we call it, though 0.5 makes about as much sense as anything else (as long as it isn't 0.4.x)
15:33 hmmmm it needs to be 1.0.0 if we want a chance at fixing our versioning scheme so minor version numbers actually mean minor version numbers
15:34 VanessaE if a proposed patch is gonna break anything, imho it belongs in that "let's break it all" version.
15:34 VanessaE 1.0.0 sounds better but then we get into that discussion we had before about confusing users (1.0.0 == 1.0 in a user's mind)
15:34 VanessaE (0.4.x = 4.x, etc)
15:35 est31 its their problem if they can't read a 0 at the start
15:35 VanessaE agreed, but if we can do something simple to prevent it in the future, why not?
15:36 est31 yea therefore 1.0.0 is better than 0.5.0
15:36 est31 and with client side modding, we are ready for 1.0.0
15:36 VanessaE what happens when we reach 3.0.0?
15:36 est31 then most users aren't 13 anymore and dont play minetest
15:37 est31 those who played it since 0.4.*
15:37 VanessaE and a whole NEW batch of 12-13 year olds comes in.
15:37 VanessaE and they still see the old 0.3.x versions from time to time either by someone talking about them or some idiot repo maintainer who doesn't update, etc.
15:37 VanessaE besides, it's not just kids
15:38 VanessaE it's adults who do that too
15:41 est31 perhaps make a poll, and let people decide
15:42 Robert_Zenz joined #minetest-dev
15:44 rom1504 and then name the 1.0.0 version "Hurr Durr I'm a sheep"
15:45 kahrl that other voxel game even has a single version number, in some cases, referring to to three *different* versions, and I don't see much confusion about it
15:45 kahrl and they certainly have their share of 13-year olds
15:46 VanessaE kahrl: probably because they didn't start with a 0 :P
15:46 est31 "Nyan, Nyan, I'm a Rainbow cat"
15:46 kahrl they actually did
15:46 VanessaE they did?
15:46 kahrl but then went through the 1.* cycle three times so far :)
15:47 VanessaE exactly
15:47 kahrl yes, Classic
15:47 VanessaE I guess the 0.x series wasn't widespread enough to matter, then
15:48 VanessaE in any case it should just not have a chance to confuse users is all I'm saying
15:48 rom1504 or you could go straight to 10.x to avoid any confusion and mischecking of program versions ;) ;)
15:48 VanessaE rom1504: what is this, Microsoft? :P
15:48 rom1504 windows yeah :D
15:48 est31 release a new major version every 6 weeks
15:49 est31 and start with 216
15:49 VanessaE ok now I gotta ask...why 216? :)
15:49 est31 its the systemd version on ubuntu :p
15:49 VanessaE oh heh
15:49 VanessaE how about 4607 then? :)
15:50 est31 oh sorry
15:50 est31 they use already 219
15:51 est31 413 sounds nice too
15:51 VanessaE heh
15:51 celeron55 i don't think this 0./1. confusion thing is nearly as significant as you're making it sound like
15:51 VanessaE celeron55: it's not INsignificant, though
15:52 VanessaE with the number of times I've had to correct someone about the leading zero, ...well... you get the point
15:52 celeron55 that doesn't mean they would be confused if the non-zero version actually did exist
15:53 VanessaE you'd be surprised :)
15:57 twoelk joined #minetest-dev
16:01 rubenwardy joined #minetest-dev
16:21 hmmmm :)
16:22 hmmmm I managed to delete 60 lines of code last night
16:22 hmmmm oftentimes, the most productive kind of changes are when you're able to remove code
16:28 proller joined #minetest-dev
16:35 ShadowNinja VanessaE: The namespace patch is completely non-breaking.
16:37 ShadowNinja What mods should do is return their namespace in addition to seting the global and recomment that anyone using their API switches.  After waiting a reasonable amount of time for people to update their API usage the global can be removed.
16:37 leat3 joined #minetest-dev
16:39 ShadowNinja (you could of course immediately switch completely and break compat, but that's the mod's fault)
16:40 est31 for me its change for the sake of change, nothing more
16:42 rubenwardy joined #minetest-dev
16:44 VanessaE ShadowNinja: ok.
16:51 leat3 joined #minetest-dev
17:00 leat3 joined #minetest-dev
17:05 hmmmm hey est31, are we waiting on anything for the SRP pull request??
17:07 Krock joined #minetest-dev
17:07 est31 yes me cleaning up csrp-gmp
17:07 est31 I'm on it right now hmmmm
17:07 MinetestForFun joined #minetest-dev
17:07 est31 but yes it got a bit stalled
17:08 est31 so my plan is to merge the code, but first not enable it because the packets are not finalized
17:08 hmmmm oh
17:08 hmmmm in any case I was wondering what m_authstate was
17:08 hmmmm you never explained the meaning behind that variable
17:08 est31 m_authstate is more an enum
17:08 hmmmm but it's an integer...
17:09 est31 yes because we have to be generic from auth mech to auth mech
17:09 est31 this is where a class based model would make some profits, I admit.
17:10 hmmmm well I think I should clarify on my rant about over-structuring code
17:10 hmmmm the overstructuring is very bad in things that are small and should be small
17:10 leat3 joined #minetest-dev
17:11 hmmmm but when you have a certain amount of internal mechanism state, and then several methods which have behaviors differing on the type of mechanism, it's kind of a good idea to have the whole base class/derived class thing there
17:11 hmmmm it's natural here
17:11 hmmmm whereas it wouldn't make sense to have drawtypes as a base class/derived class kind of setup
17:12 hmmmm it has to do with the amount of overhead justifying the additional structure
17:14 selat joined #minetest-dev
17:14 est31 what would the class based model cover?
17:15 hmmmm well first, the base class would be AuthMechanism or AuthMethod (the latter rolls off the tounge easier since it's only 3 syllables)
17:15 TheWild joined #minetest-dev
17:15 jin_xi joined #minetest-dev
17:15 hmmmm this would basically abstract away each time you have if (authmechanism == AUTH_MECHANISM_THING) { ...
17:16 hmmmm in any case you certainly don't need to do this, i'm just saying it would make sense here
17:20 jin_xi heyho if you like removing code, someone please review/help with the particles stuff.
17:20 jin_xi ie see if the approach taken is plausible at all or if a different approach is needed, like subclassing (particlesystem)scenenode
17:21 jin_xi comments about style and capitalizations not needed at this point, and it needs to be said at all
17:22 jin_xi ...shoulda been ...and its kinda sad it needs to be said
17:41 leat3 joined #minetest-dev
17:45 rubenwardy Code style is important for maintainability.
17:48 est31 man what I dont understand is how this stuff works
17:48 est31 I mean valgrind sais everything was freed
17:48 est31 but I cant find the call where it was freed
17:48 est31 I mean its just not there
17:49 est31 ahhh
17:49 est31 dammit I found where
17:50 est31 it was an array with a specified length inside a struct
18:26 est31 hmmmm, what do you think, should I remove that unsigned char stuff too?
18:26 est31 and make it char only?
18:27 hmmmm if it's a "buffer" containing some kind of "data", it should be a void *
18:27 est31 ok
18:27 hmmmm if it's actually being interpreted as individual bytes, then that's an implementation-specific detail and the cast should be inside of the function
18:27 hmmmm i.e.
18:28 hmmmm void *memcpy(void *dst, const void *src, size_t len) {
18:28 hmmmm const uint8_t *s = (const uint8_t *s)src;
18:28 hmmmm then do all your operations on s
18:29 hmmmm yes, that will be optimized away, so it's not like you're saving anything for using the parameter directly
18:29 hmmmm to add to that, whenever there's a length parameter of some kind, use size_t.  not int.  please for the love of god, use size_t
18:29 hmmmm this is what size_t was created for
18:30 hmmmm it is part of the official C89 standard
18:30 crazyR_ joined #minetest-dev
18:30 crazyR_ joined #minetest-dev
18:30 hmmmm I see scrappily coded interfaces that take char * and int for a buffer and frankly it's annoying for several reasons
18:31 est31 whats best for writing data?
18:31 hmmmm the biggest being that you have to add extra things like casts or unsigned-to-signed conversions that really aren't appropriate in the first place, just to stop compiler warnings/errors
18:31 est31 void ** ?
18:31 hmmmm what do you mean
18:32 est31 I mean the method should return something
18:32 est31 but in c you have only one thing to return
18:32 est31 so you have to pass an argument
18:32 est31 which type should that be?
18:32 hmmmm prefer to not allocate memory for the caller unless what you're returning is variable length
18:33 hmmmm i don't know man, this all comes down to nuance and it's quite subtle
18:33 hmmmm it mostly comes down to experience in seeing which kinds of interfaces work and which don't in terms of amount of friction generated when using it
18:33 est31 yea
18:34 hmmmm but if you have to add casts everywhere just to use the damn API, there's a sure sign the interface sucks
18:36 hmmmm that being said, generally when returning a new value, then no, void * is not a good choice
18:37 hmmmm the idea behind void * as input parameters (and even output parameters when the buffer is user-provided) is flexibility
18:38 hmmmm when you, the interface, allocates and returns some kind of thing, it's usually best to have this in a pre-defined format.  the user is going to have to know this anyway to delete it if they're using C++ new[] and delete[] operators.
18:38 est31 you cant delete[] something that has been malloced
18:38 hmmmm of course
18:39 hmmmm but the user shouldn't ever be calling delete[] or free() directly on your library's output
18:39 hmmmm you have that srp_free() function or whatever, correct?  only use that
18:39 est31 yes
18:40 Hijiri joined #minetest-dev
18:40 Hunterz joined #minetest-dev
18:53 est31 error: invalid conversion from ‘void*’ to ‘char*’
18:53 est31 Do I really have to cast after malloc?
18:54 hmmmm i have no context whatsoever
18:54 est31 I have a variable of type char*
18:54 hmmmm why not just pastebin the code?  http://fpaste.org/
18:54 est31 then I'm assigning that variable = malloc(uvlen);
18:54 hmmmm oh yes
18:54 hmmmm with C++, casting rules slightly changed
18:55 hmmmm you cannot implicitly convert void * to any pointer type any longer, so casting the result of malloc() is necessary
18:55 hmmmm however you can still implicitly convert any pointer type TO void... thankfully
18:56 * est31 wonders why there are separate char and void types altogether
18:56 hmmmm in traditional C, there was no void keyword
18:56 hmmmm malloc returned char *, memcpy took char *, everything was char
18:57 est31 that sounds very good
18:57 hmmmm but that didn't work because on some platforms, the sizes of pointers to different types were different, which made this conversion impossible
18:58 hmmmm and even if they were all the same size, you'd have to do all this nonsensical casting
18:58 hmmmm so in ANSI C, void * was defined to be a pointer that can fit any data pointer type
18:58 hmmmm this way you can have code like:
18:59 hmmmm unsigned long hash[5];  SHA1_Finalize(&context, hash); ... just as well as unsigned char hash[20];
18:59 hmmmm you wouldn't need to cast the input parameter
19:00 hmmmm likewise, it made constructs like: int *foobar = malloc(50 * sizeof(int)); /*allocate 50 ints*/  free(foobar);
19:00 hmmmm possible
19:01 est31 ok that sounds good
19:01 hmmmm you don't care what the type of pointer is to.  it's just a pointer to SOME kind of data
19:01 hmmmm until you actually start to use this data
19:02 hmmmm get it?
19:02 est31 yes
19:03 est31 so why did c++ make this stricter again?
19:04 hmmmm because there are some CS types who blindly believe that less implicit type conversions necessarily make the language 'safer'
19:05 hmmmm it only made it half-way stricter:  void * -> type * conversions cannot be implicit, but type * -> void * still can
19:06 hmmmm even if they made both conversion directions explicit-only, void * would still not only have value, but be necessary
19:06 hmmmm because there's that problem where pointer sizes might differ
19:06 hmmmm take for example the Cray 1
19:06 hmmmm ints were stored in a different part of memory than chars were
19:07 hmmmm they made the int storage much larger because the designers figured they would be using more integer types in computation than characters for text, and they had different address spaces altogether
19:07 hmmmm so sizeof(int *) > sizeof(char *), believe it or not!
19:08 est31 lol
19:08 hmmmm the traditional C compiler with no void * fails here, because malloc() returned a char *
19:08 hmmmm and addresses would get truncated
19:08 hmmmm so they had to write an int * version of malloc
19:13 rubenwardy joined #minetest-dev
19:15 est31 I'm keeping the lengths int, because the buffers wont exceed 1024 MB :p
19:15 est31 and its even more porting hassle
19:15 est31 because I've two versions of that file
19:15 est31 and the diff is small, but not non-existent
19:20 hmmmm what do you mean 1024mb
19:20 est31 you know, at the position where the length overflows
19:20 hmmmm the max value of an int you're guaranteed is 32787
19:21 est31 even that isnt exceeded
19:21 johnnyjoy joined #minetest-dev
19:21 hmmmm well okay, it's YOUR library... just saying that's horrible practice
19:21 est31 yea ...
19:22 est31 is there any advantage to store something in unsigned char* other than char* ?
19:22 est31 its horrible
19:22 est31 one is char*, the other data is unsigned char*
19:22 est31 and having to write unsigned bloats the code up
19:25 Wayward_Tab joined #minetest-dev
19:40 SudoAptGetPlay joined #minetest-dev
20:13 leat4 joined #minetest-dev
20:23 leat4 joined #minetest-dev
20:27 crazyR_ joined #minetest-dev
20:33 proller joined #minetest-dev
20:35 hmmmm if its bytes you want, you should look into u8 or uint8_t
20:35 hmmmm i recommend u8 because csrp can define them if they haven't been defined elsewhere
20:37 hmmmm yes, there's a difference here.  you want to treat the chars as plain bytes of data, but if you do any kind of operation on that character that may implictly upcast the datatype to a higher capacity one, you'll get bugs because it'll sign extend if the value is over 127
20:39 hmmmm a hilarious and subtle bug is when somebody passes a char * as a buffer for "bytes of things".  one of the fields in this blob of bytes happens to be a bitfield.  they do a right bitshift as part of an operation to extract a value from a byte, and unwittingly performs an arithmetic shift instead due to signedness
20:39 hmmmm i've seen this particular scenario happen more than a couple times
20:41 est31 oh
20:42 hmmmm another one is when somebody does a hex dump on said bytes:
20:42 hmmmm for (int i = 0; i != len; i++) printf("%02x ", data[i]); printf("\n");
20:42 hmmmm "why does it print out ffffff84?? for some characters"
20:42 est31 shouldnt that int be a size_t?
20:42 hmmmm yes
20:43 est31 otherwise it will be an endless loop
20:43 hmmmm i'm taking on the persona of a newb though who uses char * and int to specify a buffer
20:43 hmmmm no, how would that be an endless loop?
20:43 est31 because i!=len always
20:43 est31 when len > maximum int
20:44 hmmmm you'd get a warning for that
20:44 hmmmm but yeah
20:45 hmmmm est31, you should read this sometime https://www.securecoding.cert.org/confl​uence/display/c/CERT+C+Coding+Standard
20:46 hmmmm https://www.securecoding.cert.org/confl​uence/pages/viewpage.action?pageId=637
20:48 est31 btw why does it print that then?
20:49 hmmmm because it's signed
20:49 hmmmm that's a variadic parameter so it gets promoted to an int, and thus gets a sign extension
20:49 est31 ah
20:49 hmmmm to fix that you'd have to explicitly cast data[i] to (unsigned char), or, you know, make data an unsigned char pointer :)
20:53 est31 dammit now I'm using size_t and its segfaulting
20:55 est31 how weird
20:56 est31 I mean, how did it work before?
20:56 hmmmm it happens
20:57 est31 but know the reason now
20:57 est31 thats why I asked how it worked before
20:58 est31 because... it can't
21:04 crazyR_ is it possible to get the info that gets sent to the serverlist withosome sort of function or namespace
21:05 est31 for the client or server crazyR_?
21:05 crazyR_ or maybe get the online servers list from within lua(ingame)
21:05 crazyR_ server
21:05 est31 there is a method to give the server list within mainmenu lua
21:06 crazyR_ can you remember which method is used im currently trawling thought the code, but think i may have missed it
21:06 est31 its a httprequest
21:07 est31 https://github.com/minetest/minetest​/blob/9527984dbcfc0a6cc7aa0470430cb6​c3aa4103ba/src/serverlist.cpp#L195
21:08 est31 crazyR_, ^
21:09 crazyR_ thanks
21:12 crazyR_ think it may ust be eaiser to parse the data i need from here: http://servers.minetest.net/list
21:12 crazyR_ cache it for 5 mins at a time
21:12 est31 you can use luasocket like the irc mod does
21:12 est31 and then make an http request
21:13 crazyR_ i know. thats what i use vurrently for my api system.  thanks
21:13 est31 what you need it for?
21:13 crazyR_ just for a ingame infomation dashboard.
21:15 crazyR_ hmm actually. why am i over thinking it again
21:15 crazyR_ most of the inof is available via settings. others throught parsing players online etc etc. lag via the server status
21:24 est31 so I think this is it
21:25 est31 srp patch ready to merge, if it builds
21:25 * est31 doing last test whether it works, then deactivates protocol v25
21:26 est31 it doesnt :(
21:32 est31 ouch
21:32 est31 current network code really has some problem
21:32 est31 right now, I can send carefully crafted packets to the server to make it restart
21:33 est31 This isn't the cause of my error, but an interesting side note
21:36 est31 what we have to do is either catch exceptions or add some other mechanism
21:36 est31 that basically does the same as the exceptions do
21:36 Hijiri joined #minetest-dev
21:36 est31 with explicit checks and so on
21:36 ElectronLibre left #minetest-dev
21:37 est31 when I have time I do a PR with the exceptions
21:37 est31 later on we can do the explicit checks too
21:47 est31 ok works again
21:48 VanessaE has there been any movement yet on allowing backface culling to be specified as a node property?
21:50 hmmmm nope
21:50 VanessaE ok.
21:51 hmmmm right now there's nobody working on graphics anything
21:52 est31 whatever happened with RBA :(
21:53 hmmmm absolutely no idea
21:53 VanessaE he got too busy to mess with MT anymore.
21:53 VanessaE at his day job, that is.
21:53 hmmmm i want to work on the shaders
21:53 hmmmm i want to work on the mapgens, i want to work on lighting
21:53 hmmmm i want to work on everything but alas I can only do one thing at a time
21:53 hmmmm agh
23:00 Lunatrius` joined #minetest-dev
23:22 chchjesus joined #minetest-dev
23:31 Wayward_Tab joined #minetest-dev
23:34 Hijiri joined #minetest-dev
23:51 est31 hmmmm, I think #2620 can be merged now
23:51 ShadowBot https://github.com/minetest/minetest/issues/2620 -- SRP based login by est31
23:55 paramat joined #minetest-dev
23:55 est31 paramat, why that new PR?
23:56 paramat will push trivial update soon #2680
23:56 ShadowBot https://github.com/minetest/minetest/issues/2680 -- Conf.example: Update recommended maximum cloud radius to 26 by paramat
23:56 paramat further testing shows 26 is the maximum without clipping
23:57 est31 ok then merge it
23:57 est31 +1
23:57 paramat :)

| Channels | #minetest-dev index | Today | | Google Search | Plaintext