Time  Nick         Message
00:10 proller      http://minetest.setun.net/master/ - from data prepared for minetest
03:23 hmmmm        hnn
03:24 hmmmm        RealBadAngel, much better... but in terms of coding style, however, why not define arrays and set the spec.rotation as that
03:26 hmmmm        for example, case 21: { u8 rot_indexes[] = {3, 1, 2, 2, 2, 2}; spec.rotation = rot_indexes[tileindex]; break; }
03:27 hmmmm        also, do you notice any speed increase with that new code?  in theory you should (especially if you have a weaker gpu with less vram)
03:29 hmmmm        celeron not commenting on your code right now indicates (to me) that he doesn't feel like looking at it at the moment and getting into all that, especially since it was like 2am for him at the time you asked
03:29 hmmmm        so you shouldn't be offended
11:12 RealBadAngel i think i made final version of getNodeTile http://pastebin.com/kAbCpMUB
11:13 RealBadAngel no more switch, ifs etc, just one lookup table
11:13 RealBadAngel imho cannot be done faster :)
15:05 hmmmm        btw http://ompldr.org/vaGhmag/2013-02-16-084645_4640x1080_scrot.png !
15:05 hmmmm        that's right, multithreading
15:06 hmmmm        only problem is that the extra boundaries in the vmanip keep overwriting what other mapgens wrote causing some things like blocks of CONTENT_IGNORE along boundaries
15:07 hmmmm        we're really going to have to sit down and figure out what to do about the boundary stuff if we want minetest to progress
15:07 sapier       boundary on mapgen or in general?
15:07 hmmmm        on mapgen, in the vmanip
15:08 sapier       hmm this would be necessary to create a multithreaded mapgen ... yes but mapgen isn't the only thin benefiting of multicore
15:10 PilzAdam     hmmmm, have you seen this:
15:10 PilzAdam     http://forum.minetest.net/viewtopic.php?id=4796
15:11 sapier       multiple calls for same block?
15:11 hmmmm        the seed keeps changing because that's the blockseed, not the map seed
15:11 PilzAdam     yea, Im wondering about the multiple calls for the same block
15:11 * VanessaE   peeks in
15:12 sapier       can you verify this is a mapgen and not a lua problem?
15:13 hmmmm        this is an emergethread problem
15:13 sapier       why is same block emerged more than once?
15:13 VanessaE     oops, wrong channe;/
15:13 hmmmm        wait
15:13 VanessaE     hm?
15:13 hmmmm        notice how he's so close to the edge of the map
15:14 sapier       yes it's another strange thing
15:14 hmmmm        why is it that everybody wants to test boundary conditions where they know things are going to screw up
15:14 hmmmm        anyway here's what i say
15:14 sapier       I'm not quite sure if he's really at the edge
15:15 hmmmm        BlockMakeData.no_op was set to true in ServerMap::initBlockMake, and it went through the motions of generating a new block, but it didn't really
15:15 VanessaE     hmmmm: I don't know about "everybody", but I test such things precisely because I expect them to screw up, and in so doing, perhaps produce a useful error message or whatever
15:15 hmmmm        no_op gets set to true if its outside of boundaries
15:15 hmmmm        you see, initBlockMake never sets minp and maxp to anything if the range is outside of the boundaries.. that would explain why
15:15 sapier       if boundaries work everything else is most likely to work too so this is a legit testcase imho
15:16 hmmmm        well i didn't mean it that way
15:16 hmmmm        i meant why are they surprised that it screws up
15:16 sapier       ok so we should avoid calling lua functions in this case as this will generate lots of load
15:16 hmmmm        like "holy crap hrmm this is weird!  crazy stuff, man!"
15:17 sapier       ok its no surprise skrewing up at the edge ... but it shouldn't be ignored either
15:18 hmmmm        so it can be fixed by adding "if (!data.no_op)" before the scriptapi_environment_on_generated() call in EmergeThread::Thread
15:19 sapier       off topic I've added seek support to fileapi some days ago because it was requested ... I thought about this again and don't see a real usecase for it as file access is string based atm ... does anyone have an idea what seek could be good for?
15:19 hmmmm        the entire no_op business is basically due to a very crappy program flow, when in reality, initBlockMake should return true or false on success or failure, and have logic in EmergeThread::Thread to just... not carry out the generation if it does fail
15:19 sapier       maybe supporting seekline would be better
15:19 hmmmm        yeah, perhaps.
15:19 hmmmm        it would be.
15:20 sapier       is it difficult to make initBlockMake return true/false
15:20 hmmmm        no
15:21 hmmmm        don't just go do that, it requires changing up a lot of the logic in that function
15:21 sapier       sounds like one of those non cool changes not having very high chances to be merged
15:22 hmmmm        i'm going to do that along with some other cleanups later on... if you'd like to fix that bug right now you then just don't call scriptapi_environment_on_generated if it was a no_op
15:23 sapier       hmmmm do I remember correct you where working on scriptapi.cpp so splitting it wouldn't be a good idea atm?
15:23 hmmmm        yeah
15:23 hmmmm        i'm still trying to decide if it should get its own folder or not
15:23 sapier       Pilzadam doesn't seam to like the idea of splitting it
15:24 hmmmm        yeah.. he's full of bad ideas though
15:24 sapier       nevertheless I've created fileapi in separate file ... and am already considering to split this file again as sqlite support was lots of code
15:24 hmmmm        i mean you should come to expect that certain people will enjoy 6000+ LoC files
15:24 sapier       last time I was looking at it it was 7k lines
15:25 hmmmm        yeah that
15:25 sapier       fileapi would already add 800 lines so this file is already at edge
15:26 sapier       I was surprised how much code sqlite support added
15:28 sapier       hmm how do you do locking on multithreaded mapgen?
15:28 hmmmm        well i haven't changed anything else
15:29 hmmmm        just the locks that are already there
15:29 sapier       are they apropriate for multithreaded mapgen?
15:29 hmmmm        probably not but i don't know unless i do some profiling first
15:29 sapier       you won't find locking errors on profiling
15:30 sapier       you need to find out what exactly needs to be locked and design it correct
15:30 hmmmm        well not errors, i know there are no errors, i'm talking about problems where it would take too long to acquire
15:31 sapier       :-) it's easy to tell no errors if there is a big lock ;-) I still would consider a big lock an error
15:33 hmmmm        i was looking at that.... it's going to be tough
15:33 sapier       is there any documentation about how locking should be in minetest?
15:33 hmmmm        no
15:33 sapier       ;-/
15:34 hmmmm        sometime in the future what i want to do is RCU for individual MapBlocks, and have the data structure they're held in thread safe on its own
15:34 sapier       jeija added curl download threads recently ... those threads would need to access lua stack so if there are other usecases for asynchronous lua threads we need a locking mechanism there too
15:34 hmmmm        that would be ideal
15:35 sapier       no not ideal
15:35 sapier       I was thinking about encapsulating mods in separate lua threads too
15:36 sapier       but this would require completely new mechanisms for data exchange between mods
15:36 sapier       thus effectivly breaking all mods :-(
15:36 hmmmm        hmmm
15:36 hmmmm        i meant that would be ideal to what i said
15:37 hmmmm        this is all too complicated and would probably be too much trouble
15:37 sapier       ohh :-) yes separation is good but it's tricky to get it performant
15:37 sapier       yes but separating mods would enable things like mod profiling
15:37 sapier       per mod security settings ...
15:38 hmmmm        hold off on that thought for a while
15:38 sapier       atm I don't even succeed in adding file api to minetest ;-)
15:38 hmmmm        yeah
15:39 sapier       so I won't start a even more troubling change :)
15:39 hmmmm        i say that if we make a sweeping change in the lua api that breaks mods, it's probably only right that we go through each of the most important mods and fix them ourselves
15:40 sapier       maybe ther could be a transition phase where multiple mods could be in same mod container
15:40 hmmmm        this is going to need to be done eventually you know
15:40 hmmmm        remember when we were talking about having a separate lua mapgen thread
15:41 sapier       yes data access was a problem there too
15:41 hmmmm        so if this were to be put into place
15:41 sapier       so without this cross thread data access mechanisms this can't be added at all
15:41 hmmmm        the "mapgen" mod would request its own thread container
15:42 sapier       I'm not sure if this really would be a good idea as multiple mods may need to do things on mapgen
15:42 hmmmm        holy shit
15:42 hmmmm        stop
15:42 hmmmm        minetest is really becoming an OS
15:43 hmmmm        whoever said that yesterday was completely right
15:43 sapier       it is lua is a virtual machine
15:43 hmmmm        this is getting too complicated
15:43 hmmmm        AGHHHHHHHHHHhhhhhhh
15:44 sapier       it's not complicate you only have to use principles of os design ;-) but atm most features aren't add all done in a generic matter
15:44 sapier       e.g. those curl patches do use polling instead of semaphores
15:44 hmmmm        i mean look, now with what we're discussing, there's the IPC mechanisms, and we'd have to put in the scheduler, and then there's already the extensive API, and then it has its own virtual fs,
15:45 sapier       fileapi is almost a virtual fs yes
15:45 hmmmm        should've just made minetest an emacs plugin
15:45 sapier       a very simple one
15:46 sapier       but if we want to keep power of lua scripting while improving stability,performance and security this is the way to go ... imho
15:47 hmmmm        this is where minecraft has us beat.  minecraft doesn't need to bend over backwards for the mods it has, sure they're harder to make, but the developers can spend more time on developing instead of meta-developing
15:48 sapier       but this is our primary benefit against minecraft
15:48 hmmmm        it's a total double-edged sword... i guess how you see it depends on which side of the fence you're on
15:49 rubenwardy   I think he means that by making it easier to mod, developers are making worse mods because it is too easy.
15:49 hmmmm        that too
15:49 rubenwardy   or that there is no quality control
15:50 rubenwardy   MC mods can chsnge any part of the program, but MT mods can only use the API to change stuff. That is the true limitation
15:50 sapier       hmm I don't remember anyone saying to me my patches ease mod creation ;-) I'm the guy wanting to drop io:: os:: and load:: support for mods ;-)
15:50 sapier       currently mods can change anything they want to change ;-)
15:50 sapier       it's a little bit tricky ok true
15:51 rubenwardy   It is a matter of trust. Do you trust giving mods access to your file system?
15:51 hmmmm        clearly not, as he has demonstrated through his work
15:51 rubenwardy   Maybe there should be a privilege system for mods :P
15:51 sapier       I don't ;-) and for sure I don't want mods to start applications on their own
15:52 rubenwardy   at least Minetest does not support the loading of .DLL's or compiled lua. That would be a security risk.
15:52 sapier       we where talking about things that would be required to get this done the last about 30 minutes
15:53 sapier       minetest does support loading dlls
15:53 sapier       io::execute("ld <some parameters> <some dll>")
15:55 rubenwardy   I'll look at the history
15:57 rubenwardy   reading files should be allowed, writing with limitations, but not executing.
15:57 sapier       but this line in any of your mods and you'll se what I'm fightened of
15:57 sapier       os.execute("/usr/bin/xterm &")
15:58 sapier       on windows it'd require another line but not a problem either
15:58 sapier       rubenwardy this is why I created fileapi as it gives limited file acces
15:59 sapier       you know most ppl use browser password cache? do you really want a mod to have access to this and upload users passwords by jeijas curl addon?
16:00 sapier       if you really brave and don't care about security you may add following line to mod too:
16:00 sapier       os.execute("/bin/rm -rf ~/*") ;-)
16:01 sapier       but back to mapgen lua thread
16:02 sapier       problem with a own thread for this would be that if mod isolation was added at some time there would be two threads for any mod (mapgen/mod)
16:03 sapier       if mapgen would trigger all mod threads having a mapgen registred this wouldn't be a problem
16:03 sapier       still stack of a mod would have to be locked as mapgen theread as well as mod thread my use it concurrently
16:04 sapier       my == may
16:13 sfan5        rubenwardy: minetest supports loading of compiled lua, there is no direct way around that other than disabling require
16:14 sapier       exactly the same thing for disabling os to avoid execute
16:14 sfan5        rubenwardy: you can also load compiled lua modules(*.dll,*.so,*.dylib) from lua
16:27 rubenwardy   Is it possible to disable all parts of the io namespace, apart from the ones that are safe?
16:27 sapier       no
16:27 sapier       at least not with major manipulation in lua code
16:28 rubenwardy   damn
16:28 sapier       and as lua code was included modifying this would mean dropping lua update possibility
16:29 sapier       you can only drop a whole namespace without major changes
16:29 sapier       this is why I wrote fileapi including all necessary functions ... I'm still waiting for comments on what may be usefull too
16:31 rubenwardy   is the dofile function relative to the current folder?
16:31 sapier       there's only one feature you don't need to propose as it's already been denied "FULL FILESYSTEM ACCESS" ;-)
16:31 sapier       hmm ... you're right this may be an additional problem
16:31 sapier       I'll have a look
16:31 Taoki        PilzAdam: I need to go now. But if you have a minute, please read the suggestions I posted here and let me know what you think (if you're doing the mob system like I'm seeing): http://forum.minetest.net/viewtopic.php?pid=70745#p70745
16:31 Taoki        I'll read when I'm back, need to go now byw
16:31 Taoki        **bye
21:04 RealBadAngel celeron55, youre here?
21:46 hmmmm        rba, i was able to fix that problem i mentioned without removing the extra borders in the voxelmanipulator
21:47 hmmmm        i fixed it sorta but not really
21:47 hmmmm        need to still come up with something better.. right now if the node 0,0,0 in a block that's being copied from a voxelmanipulator is CONTENT_IGNORE, it aborts the copy
21:48 hmmmm        the reason why it doesn't 100% work is because a cave might modify that one node and it'll continue to copy over the CONTENT_IGNORE
22:33 proller      https://github.com/celeron55/minetest/pull/492
22:43 hmmmm        alright, anyway, i fixed it.  i skip cave generation if the boundary of the chunk to be generated is CONTENT_IGNORE, but there are obvious flaws with this... if anybody can come up with a better idea, please do share