Time |
Nick |
Message |
00:12 |
|
Taoki_1 joined #minetest-dev |
06:48 |
|
thatguythatcode joined #minetest-dev |
07:19 |
|
Calinou joined #minetest-dev |
09:48 |
|
rubenwardy joined #minetest-dev |
09:54 |
|
rsiska joined #minetest-dev |
10:04 |
|
rubenwardy joined #minetest-dev |
10:29 |
|
celeron56 joined #minetest-dev |
10:36 |
|
iqualfragile joined #minetest-dev |
10:44 |
|
rubenwardy left #minetest-dev |
10:58 |
|
rubenwardy joined #minetest-dev |
13:19 |
|
rubenwardy joined #minetest-dev |
13:34 |
rubenwardy |
How do I apt-get curl dev package? |
13:34 |
rubenwardy |
(linux) |
13:42 |
sfan5 |
i'm just going to leave this here: https://gist.github.com/4642453 |
13:52 |
|
darkrose joined #minetest-dev |
13:52 |
|
darkrose joined #minetest-dev |
13:56 |
|
brinsjt joined #minetest-dev |
13:57 |
|
rsiska joined #minetest-dev |
14:41 |
|
brinsjt joined #minetest-dev |
15:27 |
|
sapier joined #minetest-dev |
15:28 |
sapier |
can someone explain to me why deleting textures on reload may crashes server on connect of client? I've read http://irc.minetest.ru/minetest-dev/2012-11-25 and can't reproduce celerons bug with that commit included |
15:35 |
|
Taoki joined #minetest-dev |
16:16 |
|
Taoki joined #minetest-dev |
16:22 |
|
Calinou joined #minetest-dev |
16:28 |
|
rubenwardy left #minetest-dev |
16:30 |
|
Taoki_1 joined #minetest-dev |
16:31 |
|
rubenwardy joined #minetest-dev |
16:42 |
|
hmmmm joined #minetest-dev |
17:15 |
|
Exio joined #minetest-dev |
17:44 |
|
Progers joined #minetest-dev |
17:45 |
|
Progers_ joined #minetest-dev |
17:46 |
Progers_ |
hi |
17:46 |
Progers_ |
Hm |
17:46 |
Progers_ |
Quassel IRC is working good :D |
17:47 |
sapier |
are namespaces allowed within minetest code? |
17:52 |
Calinou |
afaik, yes |
17:52 |
Calinou |
what does irrlicht do? :P |
17:53 |
sapier |
Yes but to use irrlicht you'll have to accept it ... adding namespaces to improve code readability within minetest code is another thing |
17:54 |
sapier |
I wondered about using namespaces in preparation of splitting monster files within minetest |
18:00 |
|
nyuszika7h joined #minetest-dev |
18:16 |
sapier |
celeron55 what do you think about moving RemoteClient to its own file? |
18:21 |
rubenwardy |
what is this? |
18:21 |
rubenwardy |
https://github.com/celeron55/minetest/tree/kwolekr_mg_r1 |
18:23 |
VanessaE |
that's hmmmm's mapgen v7 fork :-) |
18:24 |
VanessaE |
s/fork/branch/ |
18:24 |
darkrose |
if you look at the commits, it's really obvious |
18:36 |
hmmmm |
everything there has already been merged into master |
18:36 |
hmmmm |
still waiting on the two other patches i have pull requests for |
18:36 |
hmmmm |
it's pretty tempting to just press the giant green button myself and get it over with. |
18:38 |
VanessaE |
heh |
18:40 |
hmmmm |
sapier, i believe scriptapi.cpp should be the first thing to get split up. |
18:40 |
hmmmm |
the next course of action for me, personally, is to move all EmergeThread related things to emerge.cpp, along with the EmergeManager. |
18:40 |
sapier |
yes |
18:40 |
sapier |
you're right scriptapi.cpp is another monster file |
18:41 |
hmmmm |
i'm pretty sure it's the single largest source file |
18:41 |
sapier |
is there any chance to add subfolders? |
18:41 |
hmmmm |
i'd say so |
18:41 |
hmmmm |
you want to make a /script/ directory? |
18:41 |
hmmmm |
that's a pretty big change though, i'd talk to more people first. |
18:42 |
sapier |
in longterm I was more in direction server/client/common subdirectories with subfolders in each again |
18:42 |
VanessaE |
I have a huge update to colors.txt for minetestmapper.py - which includes defaults for many popular mods. Interested? |
18:42 |
hmmmm |
that's too Java project-y |
18:43 |
hmmmm |
i don't believe we have as many source files that it'd take to warrant such division. |
18:43 |
sapier |
what's java if you do code organization? :-) ... still as most ide's support virtual folders this is not my primary concern |
18:43 |
sapier |
I've done it for myself everyone else has to do it like she/he likes |
18:43 |
hmmmm |
well Java was really made with IDEs in mind |
18:44 |
hmmmm |
a lot of people don't like that |
18:44 |
hmmmm |
but it's because of the sheer amount of source files necessary for a java project that it really necessitates having a deep directory structure |
18:44 |
sapier |
I've recognized this too ... but we have far to many files in a single folder too |
18:44 |
hmmmm |
there are other projects with way more.. |
18:45 |
hmmmm |
right at this moment in time i'd say it's a comfortable amount, maybe others would disagree, but |
18:45 |
sapier |
I know ... I won't argue about that either as it's most likely a matter of personal preference |
18:45 |
hmmmm |
if scriptapi.cpp in particular is broken up, i'd estimate it'd be divided into about 6-8 source files |
18:46 |
hmmmm |
which would make it an excellent candidate for a subdirectory |
18:46 |
sapier |
my definition of comfortable is if I (normaly) don't have to scroll around in file list to access files I'm working at |
18:46 |
sapier |
:-) |
18:46 |
sapier |
yes I know I'm lazy |
18:46 |
hmmmm |
depends on what your font size is and everything, lol |
18:47 |
sapier |
there are already some naturak split marks within scriptapi to start at |
18:47 |
sapier |
moving each class into a own file might be a good start |
18:47 |
hmmmm |
yeah |
18:48 |
hmmmm |
there are a LOT of classes though, so |
18:48 |
sapier |
:-) ok I'll have a look and split where it seams to be reasonable |
18:48 |
hmmmm |
don't do that just yet, i need to add stuff to scriptapi.cpp |
18:48 |
hmmmm |
in the latest patch |
18:48 |
sapier |
ok so I'll wait |
18:49 |
hmmmm |
but yeah |
18:49 |
hmmmm |
i'm thinking of something like |
18:49 |
hmmmm |
scriptapiobj.cpp scriptapienv.cpp scriptapinoise.cpp and so on |
18:49 |
hmmmm |
scriptapi code common to everything and/or misc. things stay in scriptapi.cpp |
18:50 |
sapier |
yes I thought nearly same |
18:50 |
hmmmm |
ha ha, great minds think alike |
18:51 |
sapier |
could you check and merge pull requests 447 and maybe 437 |
18:52 |
sapier |
https://github.com/celeron55/minetest/pull/447 |
18:52 |
sapier |
https://github.com/celeron55/minetest/pull/437 |
18:52 |
RealBadAngel |
+1 for idea of splitting scriptapi, its way too big |
18:52 |
sapier |
its 7k lines ... so about 6k above my personal limit |
18:52 |
hmmmm |
same |
18:52 |
sapier |
if you need more than 1k lines something is wrong with your design |
18:53 |
hmmmm |
what did celeron have to say about the assert_backtrace thing |
18:53 |
sapier |
except if its a resouce file |
18:54 |
sapier |
it was called "backtrace" first he said backtrace shouldn't assert so I added assert functionality to this function and renamed it to assert_backtrace ... I don't know if he did check it since then |
18:54 |
sapier |
first version didn't do a parameter check too |
18:55 |
sapier |
I'd use normal assert but it doesn't show a stacktrace |
18:55 |
hmmmm |
do you have both a backtrace and a backtrace_asert? |
18:55 |
sapier |
no only assert_backtrace .. as far as I understood evaluating stack is a destructive operation |
18:55 |
hmmmm |
nonsense... of course it's not |
18:55 |
sapier |
it's not? |
18:56 |
hmmmm |
how would that be destructive, you're only reading things |
18:56 |
sapier |
lua_pop is only reading? |
18:57 |
Progers |
i have installed Kubuntu 12.10 :D |
18:57 |
hmmmm |
oh, nevermind, are you sure you need lua_pop for a backtrace though? |
18:58 |
|
sapier1 joined #minetest-dev |
18:59 |
sapier1 |
no I'm not sure but there already was a script_get_backtrace function |
18:59 |
hmmmm |
hmmm |
18:59 |
hmmmm |
yeah i was just going to ask where the actual function is |
18:59 |
hmmmm |
that's in script.cpp i assume? |
18:59 |
sapier1 |
yes |
19:00 |
hmmmm |
p0p |
19:00 |
hmmmm |
let's see here.. |
19:01 |
hmmmm |
no, the get* functions push onto the stack, the pops are there for the purpose of reversing the things it did |
19:01 |
hmmmm |
but that's really convenient that it has a backtrace function _for_ you already |
19:01 |
hmmmm |
but in theory it shouldn't be destructive at all. |
19:02 |
hmmmm |
now what does the backtrace do exactly, show you the contents of the stack or does it just show the heirarchy of function calls? |
19:02 |
hmmmm |
or both? |
19:02 |
sapier1 |
function call hierarchy |
19:03 |
sapier1 |
no variables |
19:03 |
hmmmm |
alright, i should add in my dumpstack() that i was using for testing my code |
19:03 |
hmmmm |
that might be useful |
19:04 |
hmmmm |
sapier, when is assert_backtrace intended to be called? |
19:04 |
sapier |
yes :-) that would help a lot |
19:04 |
sapier |
It's to be called in mods where you need to check function parameters |
19:05 |
hmmmm |
alright, because i was going to say, luaErrorHandler already does a backtrace. |
19:05 |
sapier |
e.g. mobf uses some sort of this pointer for most of it's functions if it's broken something went terribly wrong |
19:05 |
hmmmm |
didn't realize it had more utility |
19:06 |
sapier |
and most time you recognize this in a function called about 10 times ... which is a real pain to debug |
19:08 |
hmmmm |
so wait a minute let me look at this... if do_assert is true then the function basically does nothing |
19:08 |
hmmmm |
except returns nil |
19:08 |
sapier |
yes like assert does |
19:09 |
hmmmm |
but where does it actually perform the assert? |
19:09 |
sapier |
if parameter is false: e.g. |
19:09 |
sapier |
assert_backtrace(some_variable ~= nil) |
19:09 |
sapier |
assert(some_variable ~= nil) |
19:09 |
sapier |
it's same syntax |
19:10 |
hmmmm |
oh |
19:10 |
hmmmm |
haha |
19:10 |
hmmmm |
that's true |
19:11 |
hmmmm |
so wait, what does luaL_error do exactly |
19:11 |
hmmmm |
wouldn't that call luaErrorHandler? |
19:12 |
|
jin_xi joined #minetest-dev |
19:13 |
sapier |
lauxlib.c L 86 |
19:13 |
sapier |
its just printing the error message and line where error occured |
19:14 |
sapier |
but you're right maybe script_error would be better at this place |
19:15 |
hmmmm |
well you've tested this right? and it does the intended behavior |
19:15 |
sapier |
yes it does show backtrace and doesn't crash application after it ... but that doesn't implie there may not be a better way to continue after backtrace |
19:16 |
sapier |
my primary concern was to have that backtrace |
19:16 |
hmmmm |
i mean i'm concerned with it because it looks (to me) like it would print out a duplicate backtrace |
19:16 |
hmmmm |
but that's not the case |
19:16 |
hmmmm |
i'd still rather wait for celeron's final say and see what he wants |
19:16 |
hmmmm |
sorry |
19:16 |
sapier |
no problem |
19:16 |
sapier |
at least someone did look at it now :) |
19:16 |
hmmmm |
nobody looks at my pull requests |
19:17 |
sapier |
if you tell me what request you are talking about I'll have a look ... but I can't decide anything ;-) |
19:18 |
hmmmm |
these https://github.com/celeron55/minetest/pull/441 things https://github.com/celeron55/minetest/pull/442 |
19:21 |
sapier |
NULL isn't best thing to use for portability issues ... but minetest uses it everywhere so I assume it's fine here too |
19:24 |
sapier |
why are mapgen and mapgen params created separatly? |
19:25 |
sapier |
L 168 seems to be a merge artifact |
19:27 |
hmmmm |
[02:21 PM] <sapier> NULL isn't best thing to use for portability issues ... but minetest uses it everywhere so I assume it's fine here too |
19:27 |
hmmmm |
what..? |
19:28 |
hmmmm |
mapgen and mapgen params are created separately because the mapgen needs a mapgenparams in order to be created |
19:28 |
sapier |
NULL has lots of different meanings for different platforms and processors ;-) ... but I assume this doesn't matter for those minetest does support |
19:29 |
hmmmm |
it always means the integer representation of 0 as per the C and C++ standard |
19:29 |
hmmmm |
if NULL is something else other than the integer representation of 0, then it's not C++. |
19:29 |
sapier |
:-) yes if everyone would use standard ;-) |
19:29 |
hmmmm |
it's some other language. |
19:29 |
hmmmm |
can you show an example where that would fail, then....? |
19:30 |
hmmmm |
this is just a part of the language |
19:30 |
sapier |
if it's defined as (void*) 0 for example |
19:30 |
hmmmm |
it's like saying that strlen() will return a float in some implementation because not everybody uses the standard |
19:30 |
hmmmm |
(void *)0 still has the integer value of 0 |
19:31 |
sapier |
It's what I've learned when doing embedded programming on different processors with different toolchains ;-) |
19:31 |
hmmmm |
(int)((void *)0) is still 0 |
19:31 |
sapier |
int dummy = NULL is problematic |
19:31 |
hmmmm |
give me a specific example |
19:32 |
hmmmm |
and what did you do to solve the problem |
19:32 |
sapier |
some compilers will fail for this because (void*) 0 is a pointer while int dummy ain't |
19:32 |
sapier |
int dummy = 0 is solution |
19:33 |
hmmmm |
on those platforms, NULL is indeed defined as (void *)0 |
19:33 |
hmmmm |
although you should be able to, i don't see why you'd set an integer to NULL... |
19:33 |
sapier |
dosn't really make sense but is done in some code I've seen |
19:34 |
hmmmm |
none of the minetest code at least |
19:34 |
sapier |
true |
19:34 |
hmmmm |
but, seriously. let's be rational here |
19:34 |
sapier |
it's an academic discussion :-) so don't change anything |
19:35 |
hmmmm |
if the C++ standard says that strlen() returns a size_t, let's assume that it'll always be a size_t unless we find a specific example of a platform that doesn't follow the standard that we wish to support |
19:35 |
hmmmm |
for example. |
19:35 |
sapier |
this is true for now but will it be true in 5, 10 15 years? |
19:35 |
hmmmm |
of course |
19:35 |
hmmmm |
i don't see why anything would change |
19:36 |
hmmmm |
even if it does for some reason change, we can still set the compilers to use the C++11 standard where we know it to be true |
19:36 |
sapier |
standards are subject to change I'm working with lots of really old code and see what asumptions where made at time of its creations ... most assumptions where true by the time of writing |
19:36 |
sapier |
some where false even then but thats another problem :) |
19:37 |
hmmmm |
well were they assumptions, or were they following the standard? |
19:37 |
hmmmm |
one is unacceptable, the other is the goal of any coder |
19:37 |
hmmmm |
let me guess, they assumed the size of a pointer is the size of a long? |
19:37 |
sapier |
that code was written when there was not one single "standard" |
19:37 |
hmmmm |
there is now |
19:38 |
sapier |
no one was an architecture using token + offset to access memory |
19:39 |
hmmmm |
oh by the way, L168 isn't a merge artifact, i put that there to separate the MapgenParams from the end of the EmergeManager things |
19:39 |
sapier |
there are multiple standards today too ;-) but it's better than past |
19:39 |
sapier |
ok |
19:39 |
hmmmm |
it probably shouldn't be there but it does make things neater |
19:40 |
hmmmm |
when I put the things above it into emerge.cpp, it'll be removed |
19:40 |
sapier |
441 doesn't seem to have any obvious problems |
19:42 |
|
Taoki joined #minetest-dev |
19:49 |
sapier |
I don't understand for what reason are you using a while loop in there? |
19:49 |
hmmmm |
? |
19:49 |
sapier |
the mystrtok_r function |
19:50 |
hmmmm |
because that's just how you do it |
19:50 |
hmmmm |
do you mean the first while loop to skip the tokens? |
19:51 |
hmmmm |
that's a necessary detail of strtok_r, a token starts with the first non-delimiter character |
19:51 |
hmmmm |
so if you had ",;" as your delimeter, and you had ,,,,,;,abc, then the only things it should spit out are "abc" and then NULL |
19:51 |
hmmmm |
it must have this behavior in order to follow the standard |
19:51 |
sapier |
but you won't skip multiple with new version? |
19:52 |
hmmmm |
well i skipped multiple with both versions |
19:52 |
hmmmm |
the behavior in both are exactly the same, only difference is that i simplified the second one |
19:52 |
sapier |
as far as i understand if you have two delimiters at start in new version you'll get an empty token |
19:53 |
hmmmm |
no you won't, it skips over both of them, hence the loop |
19:54 |
hmmmm |
that's the point of the loop |
19:54 |
hmmmm |
test it and see for yourself |
20:31 |
sapier |
ok .... I should have looked at full version first ... I didn't even recognize outer while loop until now :-( |
20:34 |
sapier |
I know you told me ... didn't help :-) |
21:52 |
sfan5 |
http://forum.minetest.net/viewtopic.php?id=4596 |
21:53 |
sfan5 |
anyone take a look at that |
22:12 |
|
ecube joined #minetest-dev |