| Time |
Nick |
Message |
| 00:01 |
iqualfragile |
sapier: whover cares about mingw: fix it |
| 00:03 |
sapier |
I'm gonna stop supporting any windows thingy if I'm the only one who's required to support all different windows build variants |
| 00:11 |
ShadowNinja |
sapier: Um, don't remove whitespace from the whole repo, just from Jthread. |
| 00:12 |
sapier |
I had to touch all those files for jthread cleanup ... and every file I change is fixed automaticaly ... it's a all or nothing decision |
| 00:12 |
PilzAdam |
sapier, alternatively you rebase every single pull request |
| 00:12 |
sapier |
PilzAdam I guess I already do that the last days |
| 00:13 |
sapier |
that damn windows build works on exactly one machine |
| 00:14 |
sapier |
I interpret this as "not fixing trailing line ends" |
| 00:15 |
PilzAdam |
we can fix this once and for all when our pull request list is shorter |
| 00:16 |
sapier |
that wont ever happen PA |
| 00:16 |
sapier |
but I don't care about I'll find out how to revert keplers default behaviour to old juno style |
| 00:25 |
hmmmm |
I do agree that there needs to be a point when we remove all trailing whitespace |
| 00:26 |
hmmmm |
my IDE did that for a while and it kept making a mess of my commits |
| 00:26 |
hmmmm |
until I figured out how to disable it |
| 00:26 |
hmmmm |
and now it's annoying to do "git diff" and have trailing whitespace highlighted in red |
| 00:26 |
hmmmm |
so I have to go back and manually fix that |
| 00:26 |
iqualfragile |
hmmmm: isnt there some way to ignore whitespace changes? |
| 00:26 |
hmmmm |
shrug |
| 00:27 |
sapier |
I don't want to waste energy on whitespace discussions while I could use it for more usefull things |
| 00:43 |
ShadowNinja |
So, at what point will we trim the whitespace? 30 PRs? 10 PRs? |
| 00:43 |
sapier |
never |
| 00:51 |
hmmmm |
agh fuckfuckfifcufkcufck |
| 00:51 |
hmmmm |
I just realized i need to keep an intermediate schematic buffer to apply the trim to |
| 00:52 |
hmmmm |
so listen to how fast this is: |
| 00:52 |
sapier |
https://github.com/minetest/minetest/pull/1029 what about this variant only remove trailing whitespaces from non empty lines |
| 00:52 |
hmmmm |
1. apply rotation |
| 00:52 |
hmmmm |
2. blit to intermediate buffer with probabilities |
| 00:53 |
hmmmm |
3. trim schematic |
| 00:53 |
hmmmm |
4. blit to the vmanip |
| 00:53 |
hmmmm |
5. blit back to the map |
| 00:53 |
hmmmm |
that's technically 3 buffers |
| 00:53 |
sapier |
guess it's the only way to do |
| 00:54 |
hmmmm |
and then it does this for every single tree |
| 00:54 |
hmmmm |
i need to do some profiling and see how horrible this is |
| 00:55 |
sapier |
why don't you cache em? is memory usage that huge? |
| 00:55 |
hmmmm |
well this is generalized |
| 00:56 |
hmmmm |
if I were to cache something, it'd have to be one for every single possibility of the schematic |
| 00:58 |
hmmmm |
http://paste.ubuntu.com/6502012/ this is what I'm doing |
| 00:58 |
ShadowNinja |
local schemid = minetest.prepere_chematic("path", options) minetest.spawn_schematic(schemid) |
| 00:59 |
ShadowNinja |
goto == bad. |
| 01:00 |
hmmmm |
lol |
| 01:01 |
hmmmm |
hmmm |
| 01:01 |
hmmmm |
am I overgeneralizing this? |
| 01:02 |
hmmmm |
realistically the only direction I need is -y, +y would only be for ceiling placement and I don't even have ceiling placement for schematics added |
| 01:08 |
hmmmm |
this doesn't even fit the purpose of what I'm doing very well |
| 01:08 |
hmmmm |
take for example a jungle tree which has a base with a specific shape |
| 01:09 |
hmmmm |
if it generates shorter, the length would vary in the middle of the trunk, not along the edges |
| 01:09 |
hmmmm |
somebody just tell me if generically, programatically doing this is possible or not |
| 01:11 |
PilzAdam |
maybe propabilities per horizontal layer? |
| 01:11 |
|
Sokomine joined #minetest-dev |
| 01:12 |
hmmmm |
how would you possibly 1). encode that with the current schematic format but more importantly 2). specify which slice tangential to the y axis has a probability or not |
| 01:15 |
hmmmm |
i suppose #1 is impossible, and #2 can only be done through the player specifying the y offset through the console or something |
| 01:16 |
sapier |
the win32 sleep fix doesn't work it needs to be used for mingw too not only for msvc |
| 02:29 |
|
ecube joined #minetest-dev |
| 02:34 |
|
Miner_48er joined #minetest-dev |
| 02:38 |
|
salamanderrake joined #minetest-dev |
| 02:48 |
|
VanessaE joined #minetest-dev |
| 02:53 |
hmmmm |
god |
| 02:53 |
hmmmm |
dammit |
| 02:53 |
hmmmm |
why do i keep making retarded decisions on which order to put lua api parameters in |
| 02:56 |
VanessaE |
don't we all make bad decisions like that sometimes? |
| 02:56 |
VanessaE |
I went through that in plants_lib for a while before I just went with a table, remember? |
| 03:09 |
|
sapier left #minetest-dev |
| 03:18 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 03:18 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 03:44 |
|
KingsleyT joined #minetest-dev |
| 03:58 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 04:13 |
|
Miner_48er joined #minetest-dev |
| 05:04 |
|
OWNSyouAll joined #minetest-dev |
| 05:15 |
|
OWNSyouAll joined #minetest-dev |
| 05:20 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 05:25 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 05:27 |
|
OWNSyouAll joined #minetest-dev |
| 05:32 |
|
OWNSyouAll joined #minetest-dev |
| 05:45 |
|
OldCoder joined #minetest-dev |
| 06:03 |
|
nore joined #minetest-dev |
| 06:17 |
|
damiel joined #minetest-dev |
| 06:25 |
|
KingsleyT joined #minetest-dev |
| 07:03 |
|
e1z0 joined #minetest-dev |
| 07:17 |
|
djdduty joined #minetest-dev |
| 07:17 |
|
djdduty joined #minetest-dev |
| 07:33 |
|
VanessaE joined #minetest-dev |
| 08:02 |
|
darkrose joined #minetest-dev |
| 08:13 |
thexyz |
mapgen v7 is broken https://gist.github.com/xyzz/ed6a340431aafb384516/raw/1aff32580c9a5cf72065e929ac9ca293414f8ecd/gistfile1.txt |
| 08:19 |
|
e1z0 joined #minetest-dev |
| 08:20 |
|
e1z0 joined #minetest-dev |
| 08:23 |
|
e1z0 joined #minetest-dev |
| 08:25 |
VanessaE |
inb4 hmmmm says "aw fuck it, I'm ditching that whole mess and starting over" |
| 08:34 |
|
e1z0 joined #minetest-dev |
| 08:44 |
|
mrtux joined #minetest-dev |
| 09:12 |
|
sapier joined #minetest-dev |
| 09:29 |
|
Gethiox2 joined #minetest-dev |
| 09:38 |
|
werwerwer joined #minetest-dev |
| 09:40 |
|
Calinou joined #minetest-dev |
| 09:58 |
|
emptty joined #minetest-dev |
| 10:37 |
|
31NAAB2G3 joined #minetest-dev |
| 10:59 |
|
bas080 joined #minetest-dev |
| 11:06 |
|
ImQ009 joined #minetest-dev |
| 11:36 |
|
emptty joined #minetest-dev |
| 11:37 |
|
jin_xi joined #minetest-dev |
| 11:48 |
|
emptty joined #minetest-dev |
| 12:01 |
|
PilzAdam joined #minetest-dev |
| 12:25 |
|
kahrl joined #minetest-dev |
| 12:51 |
|
john_minetest joined #minetest-dev |
| 13:35 |
|
hmmmm joined #minetest-dev |
| 13:43 |
|
emptty1 joined #minetest-dev |
| 13:49 |
thexyz |
hmmmm: https://gist.github.com/xyzz/ed6a340431aafb384516/raw/1aff32580c9a5cf72065e929ac9ca293414f8ecd/gistfile1.txt |
| 13:56 |
hmmmm |
thanks |
| 13:57 |
sapier |
what tool is this? |
| 13:57 |
thexyz |
sapier: clang with -fsanitize=address |
| 13:57 |
thexyz |
sapier: CC=clang CXX=clang++ cmake .. -DCMAKE_CXX_FLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer -fno-optimize-sibling-calls" -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" -DENABLE_FREETYPE=1 -DRUN_IN_PLACE=1 |
| 13:58 |
sapier |
interesting :-) |
| 13:58 |
thexyz |
then run ./bin/minetest 2> log, then when it crashes you should run asan_symbolize.py < log | c++filt |
| 13:58 |
hmmmm |
in practice that shouldn'tve happened though |
| 13:58 |
hmmmm |
p ought to be restricted to node_min an node_max there |
| 13:58 |
sapier |
I hope that there aren't any bugs that really should happen :-) |
| 13:59 |
|
emptty joined #minetest-dev |
| 14:00 |
|
emptty2 joined #minetest-dev |
| 14:01 |
thexyz |
aand when I try to enter some /command in the chat I get this https://gist.github.com/xyzz/c8af3888a035258e8172/raw/3f4e5ab3b70e1587a072c27498baa882be578436/gistfile1.txt |
| 14:01 |
hmmmm |
that's in irrlicht, we can't do anything about that |
| 14:01 |
thexyz |
I don't understand this, how can it crash there? |
| 14:01 |
thexyz |
no, it's our file |
| 14:02 |
thexyz |
https://github.com/minetest/minetest/blob/master/src/intlGUIEditBox.cpp#L1434 |
| 14:02 |
hmmmm |
oh |
| 14:02 |
hmmmm |
*blinks* |
| 14:02 |
sapier |
guess this should be fixed immediatly :-) |
| 14:03 |
sapier |
some ppl are complaining about chat crashes this could be source |
| 14:04 |
hmmmm |
thexyz, it can crash there because that intlGUIEditBox was freed at the time setTextMarkers was called |
| 14:05 |
hmmmm |
in other words, irr::gui::CGUIEnvironment::postEventFromUser posted the event to an already-destroyed GUI object or w/e it takes |
| 14:05 |
hmmmm |
already-destroyed IGUIEditBox |
| 14:06 |
hmmmm |
I guess you need to somehow unbind the event before destroying that control |
| 14:06 |
sapier |
guess someone forgets to tell irrlicht about deletion? |
| 14:06 |
hmmmm |
that's like javascript except even worse |
| 14:07 |
sapier |
you always have to care if you give away pointers to other threads that's a design principle of c/c++ :-) |
| 14:07 |
hmmmm |
I mean irrlicht though, shouldn't it automatically unbind events on delete |
| 14:08 |
sapier |
how to notice? |
| 14:08 |
hmmmm |
destructor...? |
| 14:09 |
sapier |
it's our own destructor so if we don't do it in there who shall do it? |
| 14:09 |
hmmmm |
the parent class! |
| 14:10 |
sapier |
that'd require a event handling base class ... not sure if this is part of irrlicht |
| 14:11 |
sapier |
but yes a full featured toolkit should do it this way ... but irrlicht is quite limited as of toolkit features |
| 14:11 |
sapier |
https://github.com/minetest/minetest/pull/1029 anyone to review this one? (fixes windows build and removes some waste from jthread) |
| 14:20 |
|
iqualfragile joined #minetest-dev |
| 14:20 |
|
VanessaE joined #minetest-dev |
| 14:42 |
hmmmm |
how could a sem_wait or sem_post etc ever fail |
| 14:42 |
hmmmm |
ah EINVAL |
| 14:42 |
hmmmm |
the win32/jevent.cpp whitespace at the bottom, fix that! |
| 14:43 |
hmmmm |
otherwise it looks fine |
| 14:44 |
hmmmm |
I really dislike the way JThread works to be honest, it itself uses like 3 mutexes per thread for basically nonsense. i do feel like some logic could be condensed |
| 14:45 |
hmmmm |
so, thexyz, when did you get that last error exactly? |
| 14:49 |
sapier |
I haven't had a look at jthread thread itself |
| 14:50 |
thexyz |
hmmmm: what error? |
| 14:51 |
thexyz |
with chat? it happens every time |
| 14:51 |
hmmmm |
the intlGUITextBox or whatever |
| 14:51 |
hmmmm |
when though |
| 14:51 |
sapier |
hmmmm those mutexes jthread uses are necessary to provide it's interface |
| 14:51 |
hmmmm |
menu? in game? formspec? |
| 14:52 |
thexyz |
chat, > <thexyz> aand when I try to enter some /command in the chat |
| 14:52 |
sapier |
continuemutex and continuemutex2 are used for startup synchronization while runningmutex is used for shared data access |
| 14:52 |
thexyz |
in game |
| 14:52 |
hmmmm |
oh |
| 14:53 |
hmmmm |
sapier, exactly, which I think is stupid |
| 14:53 |
hmmmm |
the interface itself is unnecessary |
| 14:53 |
sapier |
no it isn't there are good reasons to do so |
| 14:53 |
hmmmm |
a while back i was considering scrapping jthread entirely and just adding some things to porting.cpp for threads |
| 14:54 |
sapier |
ok wait |
| 14:54 |
sapier |
the api doesn't even support creating a thread while not starting it |
| 14:54 |
hmmmm |
out of those three the only thing needed is runningmutex |
| 14:55 |
hmmmm |
yeah, some logic would have to be changed I get that |
| 14:55 |
sapier |
good god the more I look at it the more I think jthread was written by someone doing this the first time in his live |
| 14:55 |
hmmmm |
i'm most worried about the overall cleanness of design |
| 14:56 |
sapier |
but still one thing is implemented |
| 14:56 |
sapier |
jthread ensures threads are created and don't stall in non created state |
| 14:57 |
sapier |
once you return from start you can be sure your thread is up and running |
| 14:59 |
hmmmm |
i suppose that's a good thing, yes, but i'd say a good threading design would make such synchronization unneeded |
| 14:59 |
sapier |
no |
| 15:00 |
sapier |
imho it's good design to NOT rely on os scheduling assumptions |
| 15:00 |
hmmmm |
what? today isn't a holiday |
| 15:01 |
sapier |
think about last days 3 os 3 completely different error occurances for non threadsafe actions |
| 15:01 |
hmmmm |
that was because of safe data access not being used, not because the thread didn't start up in time |
| 15:02 |
sapier |
that doesn't make a difference ;-) making sure a thread is there after start is a good thing ... creating a thread isn't a lightweight operation either so those mutex locks don't change the overall performance |
| 15:03 |
hmmmm |
of course not, it's simply uglier than i think it could be made |
| 15:04 |
sapier |
it's not ugly just more complex ... and as complexity is hidden within jthread why bother? |
| 15:04 |
sapier |
calender door ... wait ... now I remember what I missed |
| 15:06 |
sapier |
I prefere more complex but safe solutions to simplistic solutions I always have to consider how to use it ... at least if their performance is almost equal |
| 15:07 |
sapier |
ok I removed the trailing newlines ... ready for merge? |
| 15:08 |
|
NakedFury joined #minetest-dev |
| 15:08 |
|
rubenwardy joined #minetest-dev |
| 15:10 |
|
zat joined #minetest-dev |
| 15:15 |
hmmmm |
dure |
| 15:15 |
hmmmm |
sure* |
| 15:18 |
|
Zeitgeist_ joined #minetest-dev |
| 15:23 |
sapier |
ok pushing jthread fixes now |
| 15:32 |
|
Akien joined #minetest-dev |
| 15:39 |
|
salamanderrake joined #minetest-dev |
| 15:55 |
Exio4 |
[21:59:50] <+ShadowNinja> goto == bad. |
| 15:55 |
Exio4 |
why? |
| 15:56 |
PilzAdam |
maybe he meant "goto bed"? |
| 15:57 |
|
Taoki joined #minetest-dev |
| 15:57 |
thexyz |
Exio4: are you genuinely wondering why goto is bad? |
| 15:59 |
Exio4 |
it is just other 'tool', if you overuse exceptions, ifs, or other 'features'... |
| 16:04 |
Exio4 |
the IRC isn't C code |
| 16:08 |
thexyz |
wtf is going on here |
| 16:08 |
hmmmm |
goto is fine, whoever told you it was bad is just parroting somebody's weaker assertion from the 60s about it being bad if overused just like anything |
| 16:10 |
thexyz |
it's bad because it's easily overused |
| 16:10 |
hmmmm |
my use case in the code sample that comment was made on is fine |
| 16:10 |
thexyz |
by people who aren't really familiar with the language |
| 16:11 |
thexyz |
yeah, i can agree that in this case it's okay |
| 16:20 |
Exio4 |
thexyz: and same with exceptions, they can be easily overused |
| 16:22 |
celeron55 |
anything can be overused; case closed |
| 16:24 |
celeron55 |
(just imagine what kind of code someone from assembly/basic background might have written in C tens of years back in time, and then stop that and do something useful instead) |
| 16:55 |
|
emptty joined #minetest-dev |
| 17:13 |
|
Calinou joined #minetest-dev |
| 17:25 |
|
Calinou joined #minetest-dev |
| 17:27 |
|
Calinou joined #minetest-dev |
| 17:29 |
|
mrtux joined #minetest-dev |
| 17:42 |
|
OldCoder joined #minetest-dev |
| 18:12 |
|
emptty joined #minetest-dev |
| 18:23 |
|
damiel joined #minetest-dev |
| 18:23 |
PilzAdam |
hmmmm, http://irc.minetest.ru/minetest-dev/2013-11-30#i_3464526 |
| 18:30 |
|
EvergreenTree joined #minetest-dev |
| 18:41 |
|
jin_xi joined #minetest-dev |
| 18:48 |
PilzAdam |
sapier, https://forum.minetest.net/viewtopic.php?pid=120404#p120404 |
| 18:49 |
PilzAdam |
I noticed that too, when you click on a server or a world in the server tab then your nick and password get reset |
| 18:51 |
sapier |
nick and password? |
| 18:52 |
sapier |
I didn't verify how password behaviour was before but as of security point of view reseting password on server switch is best to do |
| 18:52 |
sapier |
if not done you'd send the old servers password to whoever is at new server |
| 18:53 |
Exio4 |
*** Error in `/home/exio4/sources/minetest/build/../bin/minetest': double free or corruption (fasttop): 0x00007fffe8000950 *** |
| 18:53 |
Exio4 |
is this known |
| 18:53 |
Exio4 |
a double free error in master |
| 18:54 |
ShadowNinja |
sapier: I beleive the password is sent hashed. |
| 18:55 |
PilzAdam |
sapier, no, its just annyoing that clicking somewhere else changes the textfields |
| 18:57 |
sapier |
security is always annoying thats not a reason |
| 18:57 |
thexyz |
Exio4: is that reproducible? |
| 18:57 |
PilzAdam |
sapier, how is a hashed password a security risk? |
| 18:58 |
thexyz |
you can use it to login to any minetest server |
| 18:58 |
thexyz |
so that's a security risk |
| 18:58 |
sapier |
the hash is the only secret user has |
| 18:58 |
sapier |
knowing password and username is enough to enter |
| 18:59 |
thexyz |
but that's extremely inconvenient — I enter my nickname, password, then click some server and then I have to enter everything again |
| 18:59 |
thexyz |
well it's not like minetest's the most secure thing ever |
| 18:59 |
Exio4 |
thexyz: no idea, i'm getting random crashes and one of them was the double free, the other was one repated by john_minetest before |
| 18:59 |
thexyz |
Exio4: you could try running debug build in gdb or running debug build with clang address sanitizer |
| 19:00 |
sapier |
no I don't say its save at all ... but if we don't at least try to not tell everyone users credentials we can just skip them |
| 19:00 |
sapier |
it's even more comfort not having to remember any password |
| 19:00 |
Exio4 |
er |
| 19:00 |
Exio4 |
i think i got a reproduceable crash |
| 19:01 |
sapier |
great exio4 those are best ones to fix |
| 19:02 |
Exio4 |
well, half of the time it is the same crash, and it is a different one that what i posted here |
| 19:02 |
PilzAdam |
sapier, also I have the feeling that menu is slower since async, especially shutting down and starting a server/world |
| 19:03 |
thexyz |
Exio4: please do what I asked you for |
| 19:03 |
Exio4 |
thexyz: i'm uploading the log of thread apply all bt full |
| 19:03 |
sapier |
as you say ... maybe sleep(1) isn't best idea ;-) ... some ms should be enough there |
| 19:04 |
thexyz |
sapier: was the mingw build issue sfan5 was experiencing fixed in the end? |
| 19:05 |
Exio4 |
http://dpaste.com/1489385/ ? |
| 19:05 |
sapier |
mingw is broken and I wont fix it IMHO it's waste of time supporting 5 incompatible compilers at same os |
| 19:05 |
thexyz |
alright be prepared for butthurt then |
| 19:06 |
sapier |
and it's NOT broken because of things I added it's broken by design |
| 19:07 |
thexyz |
i'm not even asking you to fix it |
| 19:07 |
sapier |
ppl keep on telling windows in source what windows version it is ... I guess windows itself would know best but usually I'm wrong |
| 19:09 |
Exio4 |
i got the same bug when pressing play |
| 19:09 |
Exio4 |
:( |
| 19:09 |
sapier |
latest master exio? |
| 19:09 |
Exio4 |
should be |
| 19:10 |
|
Akien joined #minetest-dev |
| 19:10 |
sapier |
guess there's still something left ... is anything within minetest threadsafe? |
| 19:10 |
sapier |
:-) |
| 19:11 |
sapier |
can you compile -O0 and reproduce this one exio? |
| 19:11 |
Exio4 |
the only differences between my build and upstream, http://dpaste.com/1489393/ |
| 19:11 |
Exio4 |
it wasn't latest pull |
| 19:11 |
sapier |
ok then update |
| 19:12 |
sapier |
I fixed some errors quite similar to this one last night |
| 19:12 |
Exio4 |
ah |
| 19:12 |
Exio4 |
the jthread cleanup? |
| 19:12 |
sapier |
no the log thread registry thing |
| 19:13 |
sapier |
jthread cleanup is win32 build and as I was touching it I removed useless code too |
| 19:14 |
Exio4 |
btw, how do i build with "-O0"? i added it to CXXFLAGS with cmake-gui and it still said <optimized-out> :P |
| 19:14 |
Exio4 |
(such a noob question) |
| 19:14 |
sapier |
you need to modify CMakeLists.txt ... people in here keep thinking they can debug -O1 code ;-) |
| 19:15 |
sapier |
maybe they can ... I can't I need to know whats going on |
| 19:18 |
ShadowNinja |
cmake -DCMAKE_CXX_FLAGS='-O0' <-- I've seen something like this used. |
| 19:18 |
sapier |
might work too yes |
| 19:19 |
sapier |
there are many ways to do this |
| 19:19 |
ShadowNinja |
Does CMAKE_BUILD_TYPE='Debug' set -O0? |
| 19:19 |
|
IceCraft_ joined #minetest-dev |
| 19:19 |
Exio4 |
no, -O1 |
| 19:20 |
sapier |
but I'd suggest updating to latest master first |
| 19:21 |
|
IceCraft joined #minetest-dev |
| 19:22 |
Exio4 |
yes |
| 19:22 |
Exio4 |
seems like the double memory was the same as the other one |
| 19:22 |
Exio4 |
i'm not getting it |
| 19:23 |
|
IceCraft joined #minetest-dev |
| 19:25 |
|
IceCraft joined #minetest-dev |
| 19:27 |
|
ImQ009 joined #minetest-dev |
| 19:27 |
|
IceCraft joined #minetest-dev |
| 19:29 |
|
IceCraft joined #minetest-dev |
| 19:29 |
|
EvergreenTree joined #minetest-dev |
| 19:31 |
|
IceCraft joined #minetest-dev |
| 19:33 |
|
IceCraft joined #minetest-dev |
| 19:36 |
|
emptty joined #minetest-dev |
| 20:00 |
sfan5 |
thexyz: may I push http://pastebin.aquilenet.fr/?24b2ba01f2dbd61d#vgZkWWVCRew3+Q0+V+OpJy0zp4eNMcYV3JRTqgdUoJM= ? |
| 20:01 |
thexyz |
sfan5: if that works for you then why not |
| 20:01 |
thexyz |
if that breaks msvc build then I'll fix that eventually |
| 20:01 |
thexyz |
but it seems it should work |
| 20:01 |
sfan5 |
well... as long as MSVC does define _WIN32 it works |
| 20:01 |
thexyz |
but, I thought sapier has decided to decrease the sleep time |
| 20:02 |
thexyz |
sfan5: so you should rewrite it to use usleep and also decrease the interval |
| 20:02 |
thexyz |
100 ms should be fine |
| 20:02 |
sfan5 |
can you say these things before you say "then why not" |
| 20:02 |
sfan5 |
I already pushed |
| 20:02 |
thexyz |
sfan5: nah, that's fine, then leave it as is |
| 20:03 |
thexyz |
john_minetest: your comment doesn't add anything meaningful to the conversation |
| 20:03 |
thexyz |
john_minetest: can you please refuse from posting comments like that in the future? |
| 20:07 |
|
Calinou joined #minetest-dev |
| 20:11 |
|
damiel joined #minetest-dev |
| 20:11 |
|
damiel joined #minetest-dev |
| 20:15 |
|
Gethiox joined #minetest-dev |
| 20:35 |
sapier |
please test ... https://github.com/minetest/minetest/pull/1030 ... I was annoyed about empty search tab |
| 20:39 |
thexyz |
john_minetest: I would like to not see messages that add nothing to conversation here; I don't care about your views on javascript and shit. Moreover, that message wasn't even addressed on you. So please can we stop with the retardity? Compalining for the sake of complaining is not welcome here. |
| 20:40 |
thexyz |
I believe no one here cares if you have javascript enabled or not. |
| 20:42 |
sfan5 |
john_minetest: how would a script spy on you? |
| 20:43 |
Calinou |
pastebin.com has ads though :P |
| 20:44 |
thexyz |
and here it goes |
| 20:48 |
|
john_minetest left #minetest-dev |
| 21:02 |
thexyz |
the only one who's ever got annoyed by this just left this channel |
| 21:02 |
|
Gethiox joined #minetest-dev |
| 21:02 |
|
sapier1 joined #minetest-dev |
| 21:43 |
|
fairiestoy joined #minetest-dev |
| 21:56 |
|
ImQ009 joined #minetest-dev |
| 22:34 |
PilzAdam |
sapier, https://github.com/minetest/minetest/pull/1031 is good |
| 22:34 |
PilzAdam |
why did you make it 1 second in the first place? |
| 22:35 |
|
smoke_fumus joined #minetest-dev |
| 22:37 |
kahrl |
why not use sleep_ms? |
| 22:38 |
kahrl |
btw, the include guard for this file should start with L_ and not C_ |
| 22:44 |
sapier |
I didn't realize this would cause delays in startup ... and as of closing something I usually don't care if it's 1s or 2 :-) |
| 22:45 |
PilzAdam |
I havent noticed it at startup |
| 22:45 |
PilzAdam |
but the menu also "closes" when you start a world.... and I guess you see the problem there |
| 22:45 |
sapier |
that's what I meant with "startup" |
| 22:46 |
kahrl |
imho it would be better if we used a JThread method that called either pthread_join or WaitForSingleObject |
| 22:46 |
sapier |
kahrl thanks |
| 22:48 |
sapier |
pthread_join and waitforsingleobeject aren't exactly compareable are they? |
| 22:49 |
kahrl |
how so? |
| 22:49 |
sapier |
pthread_join is a thread function is single object thread bound too? |
| 22:49 |
sapier |
I don't know that much about win32 api |
| 22:50 |
kahrl |
it can wait on any handle that supports some kind of "signaled" state |
| 22:50 |
kahrl |
threads are signaled when they terminate |
| 22:50 |
sapier |
then this might be an option too yes |
| 23:04 |
sapier |
kahrl this way? |
| 23:20 |
kahrl |
seems good, maybe check for errors |
| 23:21 |
|
zat joined #minetest-dev |
| 23:21 |
kahrl |
sapier: ^ |
| 23:22 |
kahrl |
I don't know if they should be treated as fatal errors (using assert) or just written to stderr |
| 23:22 |
kahrl |
fatal is probably safer |
| 23:22 |
sapier |
if we can't rely on threading we should stop |
| 23:22 |
kahrl |
yeah |
| 23:27 |
kahrl |
maybe write a comment somewhere that Wait() may only be called after Start() and not after Kill() |
| 23:31 |
kahrl |
hold on a sec |
| 23:32 |
kahrl |
in the pthread implementation, jthread creates the threads a detached |
| 23:32 |
kahrl |
which means they can not be joined |
| 23:32 |
kahrl |
as* |
| 23:32 |
sapier |
? |
| 23:32 |
sapier |
it does work for me? |
| 23:32 |
kahrl |
maybe some implementation artifact? |
| 23:33 |
sapier |
as far as I know threads aren't detached by default |
| 23:33 |
kahrl |
pthread/jthread.cpp:87 |
| 23:34 |
sapier |
oops |
| 23:35 |
sapier |
ok wait I guess I forget to compile prior testing the asserted version |
| 23:36 |
sapier |
jthread is crap ... using pthread_cancel as default shutdown mechanism ... |
| 23:37 |
|
BlockMen joined #minetest-dev |
| 23:37 |
kahrl |
indeed... wtf |
| 23:38 |
sapier |
it's pure luck this doesn't crash evertim we close a thread |
| 23:38 |
sapier |
I switch to non detached mode and cleanup in destructor maybe this works |
| 23:39 |
BlockMen |
celeron55, here is the template for the subpages, currently without the fading out effect of the blue lines |
| 23:39 |
kahrl |
well we do make sure every thread terminates in an orderly fashion before we destruct the corresponding JThread |
| 23:39 |
sapier |
we can't without touching all threads |
| 23:39 |
kahrl |
so pthread_cancel is not actually called |
| 23:39 |
sapier |
do we? |
| 23:40 |
kahrl |
I thought we did |
| 23:40 |
sapier |
I haven't had a look at any single thread ;-) but I'd not be surprised if we didn't do |
| 23:40 |
sapier |
ok I just remove the detached I don't have any idea what this should be good for |
| 23:40 |
kahrl |
no |
| 23:41 |
kahrl |
that creates a memory leak for every thread that Wait() isn't called on |
| 23:41 |
sapier |
destructor ;-) |
| 23:41 |
kahrl |
the destructor does nothing if running == false |
| 23:42 |
sapier |
running is true as of thread has been started |
| 23:43 |
kahrl |
if the thread terminates itself (as it should) it sets it to false again |
| 23:44 |
sapier |
ok you're right |
| 23:44 |
sapier |
so another variable |
| 23:45 |
kahrl |
honestly we could just require that every thread is Wait()-ed on |
| 23:46 |
kahrl |
btw, is it possible to consolidate SimpleThread and JThread? |
| 23:47 |
sapier |
if we can hide this detail within jthread we should do |
| 23:48 |
sapier |
I don't know but I guess we could as we already modified jthread that much |
| 23:50 |
kahrl |
just wait in the destructor if the thread is running? |
| 23:50 |
kahrl |
after killing it |
| 23:51 |
sapier |
a little bit more to do but I guess I have a working solution now |
| 23:54 |
sapier |
ok I hope I didn't miss a case ... do we have to do same things on windows too? |
| 23:55 |
sapier |
I guess I should rename runningmutex to statusmutex |
| 23:58 |
sapier |
that's not good now "kill" wont do what name tells any longer |
| 23:58 |
kahrl |
just remove Kill() from the public interface |
| 23:58 |
kahrl |
it's only needed in the destructor |
