What are you working on? v67 - March 2017

[Scratch]

I spent a few hours today rewriting data validation for [url]http://mangle.me[/url]
And by rewriting, I mean removing 99% of it and opting for a solution that isn't going to take me fifty weeks to make feature full.

I have to admit, I didn't know the existence of stderr, only really and out, therefore it's a lot easier now to find invalid input

I wouldn't call it perfect at all, but it should be stable enough for small traffic.

A friend of mine wants me to implement the lazy 'I'm feeling lucky' button, which should be interesting,
but I've got to work on improving the front-end, because using it's not a very upfront
it's a good page for noscript though

[vid]https://tenryuu.blob.core.windows.net/astrid/17-06-08_18-40-27.webm[/vid]

[cartman300]

[img]http://carp.tk/$/LibTech_2017-06-08_10-41-44.png[/img]

Accidental fragment shader fuck up, the dragon looks metallic! :eng101:

[suXin]

It's been about 1 year, seems like now I finally understand Promises and async/await

[reevezy67]

I hate this, long lines of instantiating stuff. I don't think there's really a better way though.

Could probably move the action button listener, but that doesn't really solve much.

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        vocab = Vocab(this);

        val toolbar = find<Toolbar>(R.id.toolbar)
        setSupportActionBar(toolbar)

        val fab = find<FloatingActionButton>(R.id.fab)
        fab.setOnClickListener { _ ->

            val fm = supportFragmentManager
            val newFragment = NewItemDialogFragment(vocab);
            newFragment.show(fm, "dialog")
        }

        val drawer = find<DrawerLayout>(R.id.drawer_layout)
        val toggle = ActionBarDrawerToggle(
                this, drawer, toolbar, R.string.navigation_drawer_open, R.string.navigation_drawer_close)
        drawer.addDrawerListener(toggle)
        toggle.syncState()

        //Nav view.
        val navBarListener = NavBarListener(drawer, this);
        val navigationView = find<NavigationView>(R.id.nav_view)
        navigationView.setNavigationItemSelectedListener(navBarListener)

        //List View
        val listView = find<ListView>(R.id.main_lv)
        val lvAdapter: MainActivityLvAdapter = MainActivityLvAdapter(this, R.layout.main_lvitem, vocab.getArray());
        listView.adapter = lvAdapter
        listView.onItemClickListener =  MainListViewListener(this, vocab)
        registerForContextMenu(listView)
        
        //TTS
        tts = TTS(this, Locale.ENGLISH)
    }

[WTF Nuke]

[QUOTE=DrDevil;52324943]Cool, I have been booked for a live-shader gig. I don't get any money, but atleast free food and beer during the event![/QUOTE]

Being paid in food and beer is basically just skipping the middleman.

[ben1066]

Working on trying to unit test a CPU (Verilog so actually a CPU). Can anyone think of a better way of writing tests, currently I'm doing something like

TEST_CASE("ADD_A_r")
{
    auto cpu = std::make_unique<CpuWrapper>();

    uint8_t code[] = {0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0xF0};
    cpu->WriteMemory(code, 0, sizeof(code));
    cpu->Reset();

    cpu->SetA(0);
    cpu->SetB(0);
    cpu->SetC(1);
    cpu->SetD(2);
    cpu->SetE(0xF);
    cpu->SetH(0);
    cpu->SetL(8);

    // Set flag to check it's cleared
    cpu->SetNeg(1);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 1);
    REQUIRE(cpu->GetA()     == 0);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 1);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 2);
    REQUIRE(cpu->GetA()     == 1);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 3);
    REQUIRE(cpu->GetA()     == 3);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 4);
    REQUIRE(cpu->GetA()     == 18);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 1);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 5);
    REQUIRE(cpu->GetA()     == 18);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 6);
    REQUIRE(cpu->GetA()     == 26);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(8);

    REQUIRE(cpu->GetPC()    == 7);
    REQUIRE(cpu->GetA()     == 10);
    REQUIRE(cpu->GetCarry() == 1);
    REQUIRE(cpu->GetHalf()  == 0);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);

    cpu->RunCycles(4);

    REQUIRE(cpu->GetPC()    == 8);
    REQUIRE(cpu->GetA()     == 20);
    REQUIRE(cpu->GetCarry() == 0);
    REQUIRE(cpu->GetHalf()  == 1);
    REQUIRE(cpu->GetNeg()   == 0);
    REQUIRE(cpu->GetZero()  == 0);
}

I'm using Verilator to get a C++ simulator of the design, however it's still laborious to write out tests for each opcode. Could try and do formal tests, but Yosys doesn't support time based assertions, making any attempt at a formal proof a fair bit more challenging as I can't do something like "x; in 8 cycles assert(carry == 1)", which I could do if it did have time based assertions. I can formally prove the ALU is accurate, so it's mostly testing that the CPU uses the correct operation, acts on the correct registers, memory addresses etc in the correct number of cycles.

[Trumple]

[QUOTE=LennyPenny;52321624]I skimmed the blog post but couldn't actually find the part where you worked around the alexa restriction.
Care to share?[/QUOTE]

Oops sorry, yep Tamschi was right (to be honest did you expect anything else from Tamschi?)

It's basically a misuse of the way the apps are invoked. Unfortunately "open" and "close" are keywords in the Alexa API so I had to make two apps, one called "close the blinds" and one called "open the blinds". The downside of this is that I can't say something like "shut the blinds" without making another app called "shut the blinds" (ok I could in theory do this but you see the limitations of this workaround)

It would never be accepted to the official Alexa Skills store because it breaks the conventions, but it allows developers to ignore these conventions for testing

[Karmah]

Spent most of today safetying my undo/redo history system.

I started off implementing add/remove actions, but realized that I could in theory eventually fuck up and access a null pointer, so I switched most systems over that access level objects to shared pointers.

After debugging for a while, I got exactly the results I wanted: a "deleted" (removed) object existing solely in the undo stack as a member of the delete action, then actually being deleted from memory when that action is pushed off the stack.
In theory this would have been a simple change, if it weren't for all the subsystems that may use a level object, like lights getting registered into lighting managers, shadow managers, visibility managers, etc.

Screen shot of the interface thus far:
[t]http://i.imgur.com/ycDHXYx.png[/t]
Nothing fancy, still using the default ImGui scheme.

Once I finish up all the ui functionality I want, I'm going to replace the rest of my interface (console and shader editor) with ImGui I think. It's just so handy to work with.

[Geel]

I'm currently in the process of converting Marketplace.tf from MongoDB to MySQL.

I've spent the past 2 days writing scripts to migrate the data itself over. Generally just involves fetching all the documents from Mongo, converting them into SQL format, and inserting them. Afterwards it checks to ensure every single record was migrated successfully. Very repetitive task honestly.

I had a weird fever dream last night that was very abstract but basically parts of my life were Mongo ObjectID hashes and some were missing or something.

So that's concerning.

[SeriousLion]

Any particular reason you are converting it to MySQL?

[Geel]

[QUOTE=frietje2008;52333060]Any particular reason you are converting it to MySQL?[/QUOTE]

MongoDB was a mistake.

[jwki]

[QUOTE=Karmah;52331374]Spent most of today safetying my undo/redo history system.

I started off implementing add/remove actions, but realized that I could in theory eventually fuck up and access a null pointer, so I switched most systems over that access level objects to shared pointers.

After debugging for a while, I got exactly the results I wanted: a "deleted" (removed) object existing solely in the undo stack as a member of the delete action, then actually being deleted from memory when that action is pushed off the stack.
In theory this would have been a simple change, if it weren't for all the subsystems that may use a level object, like lights getting registered into lighting managers, shadow managers, visibility managers, etc.

Screen shot of the interface thus far:
[t]http://i.imgur.com/ycDHXYx.png[/t]
Nothing fancy, still using the default ImGui scheme.

Once I finish up all the ui functionality I want, I'm going to replace the rest of my interface (console and shader editor) with ImGui I think. It's just so handy to work with.[/QUOTE]

Not trying to be discouraging but shared ownership for something like objects in a level could become an issue down the road. Sure it solved your immediate issue with the command stack pointing to dead memory, but completely changing the ownership semantics of your object for that doesn't sound right to me. Are your objects very heavy such that copying an object into a temporary buffer when deleting it so you can restore its state in the undo would be unfeasible?

[paindoc]

I've been working with Janga on his vector field software - and so far, its been quite an educational experience. I've not worked on deployed software thats being used by people before, but its really neat to know that the work I do will be used by artists and gamedevs to make neat things for their games.

The big things I've been working on is adding more vector field operators/modules. Predictably for me, I added a noise field type most recently:

(totally stealing these from Janga himself, I forgot to capture evidence of my work :v)

[t]http://i.imgur.com/aTBXqOy.png[/t]
[vid]https://gyazo.com/eeffc257edf7bd41fb3363b6c321e522.mp4[/vid]

I've otherwise been working on various "boring" things not directly related to features, despite being important otherwise. This has included getting us setup to build with x64, fixing various graphics bugs, adding logging so I can collect data to make fixing graphics bugs way easier, cleaning up the build system to be less nightmarish, and making various type-safety tweaks and fixes elsewhere that were causing issues with x64 builds. I'm hoping to have more time this weekend to add the last of the feature modules I need to add, buuuuuut I also have to find out why SLI configurations cause the application to CTD, why AMD users get a hall of windows, and why our depth buffer stuff was so borked (and hopefully get it working, so the UI elements + field arrows stand out more). So, that'll be a mixture of fun (fixing difficult issues) and not-fun (fixing seemingly obscure driver bugs in Vulkan ;~;)

[editline]edited[/editline]

question, though: Is there any benefit to building in x64 (beyond more RAM), like improved optimizations or anything? I had read that you might get more auto-vectorization and notice slightly improved performance in x64, but it'd be good to know for sure. It wasn't [I]that[/I] hard to get it building, but I'm hesitant (and Im sure Janga is) to release a new platform executable without knowing its worth the probable new bugs and issues

[Cold]

Ehh, the whole auto vectorization, more register(s)(space), bigger fetches are sometimes argued, but generally results in the sameish microcode and the same performance on x86.

Windows has like 2-5% overhead on syscalls under wow64, context switches are slower, you can have less threads, whole lot of bs like that, that probably isn't bottlenecking your program.

If you're releasing for more then just windows, you'll need 64bit anyway.

[Karmah]

[QUOTE=JWki;52333687]Not trying to be discouraging but shared ownership for something like objects in a level could become an issue down the road. Sure it solved your immediate issue with the command stack pointing to dead memory, but completely changing the ownership semantics of your object for that doesn't sound right to me. Are your objects very heavy such that copying an object into a temporary buffer when deleting it so you can restore its state in the undo would be unfeasible?[/QUOTE]

Haha nothing is ever certain, i'm winging pretty much everything.
I should be fine - the system worked with just raw pointers before. It wasn't much of a change, objects registered and unregistered themselves (as opposed to external systems directing it), and passed their own references around. Now they just pass around a supplied shared reference.

I'm just covering all edge cases. If it turns out to be too cautious I can change it around.

[Ac!dL3ak]

[QUOTE=geel9;52333352]MongoDB was a mistake.[/QUOTE]

Are you checking to make sure that inserts into MongoDB are moved over to MySQL while the script is running? Or are you already performing inserts into both MongoDB and MySQL in the codebase?

[Geel]

[QUOTE=Ac!dL3ak;52334182]Are you checking to make sure that inserts into MongoDB are moved over to MySQL while the script is running? Or are you already performing inserts into both MongoDB and MySQL in the codebase?[/QUOTE]

We'll just take the site down before the transition process. An hour of downtime isn't a big deal.

[Topgamer7]

[QUOTE=geel9;52333352]MongoDB was a mistake.[/QUOTE]

I don't think he was referring to why the swap. I think he was asking why MySQL, instead of perhaps postgres or another db?

If he wasn't referring to that, then why not postgres or something other than MySQL?

[Ac!dL3ak]

[QUOTE=geel9;52334408]We'll just take the site down before the transition process. An hour of downtime isn't a big deal.[/QUOTE]

I guess, but why take it down if you can just do a seamless transition? Also, why MySQL, and not something like Postgres, CockroachDB, or another ACID guaranteed database system?

[Geel]

Specifically, we're going with MariaDB, not MySQL. We chose that because it's what we're familiar with on scrap.tf and Postgres had enough differences that I felt it wasn't worth learning an entirely new database -- especially when going with what we thought was a "cool choice" for a database back in 2013 turned out to be a terrible move. Frankly, the important part is getting back onto SQL -- the exact engine isn't incredibly relevant.

We aren't doing a seamless transition because that's a lot more work for relatively little payoff. The time to migrate the database is like 30 minutes. That's a very easy sacrifice to make when compared to the hours of time it would take to manage multiple databases simultaneously.

[Ac!dL3ak]

What happens if something breaks while you're performing the migration?

[Karmah]

Man the hours go by so quick
I really didn't get a lot done today, don't know why

I did a little filebrowser thing on the left but I no longer really need it.

I decided to build a directory combo box for props and collision hulls, and added a 3D preview tool tip that orbits the model. Eventually I'll do some math to get the camera positioned an appropriate distance away so large models aren't too zoomed in / small models not distinguishable.

[t]http://i.imgur.com/hcQSn5V.png[/t]

[paindoc]

[QUOTE=Karmah;52335807]Man the hours go by so quick
I really didn't get a lot done today, don't know why

I did a little filebrowser thing on the left but I no longer really need it.

I decided to build a directory combo box for props and collision hulls, and added a 3D preview tool tip that orbits the model. Eventually I'll do some math to get the camera positioned an appropriate distance away so large models aren't too zoomed in / small models not distinguishable.

[t]http://i.imgur.com/hcQSn5V.png[/t][/QUOTE]

The progress you've made with ImGui in such a short amount of time has been really neat to see. Makes me want to get more ImGui stuff in my project.

[reevezy67]

Nothing I've done lately is all that interesting compared to the graphics and shit all you guys do, nevertheless:
[t]http://i.imgur.com/fNgid48.png[/t]

I'm about 30 hours in to this project now and I just realised I don't know the syntax for a for loop in Kotlin.

[jwki]

[QUOTE=paindoc;52336083]The progress you've made with ImGui in such a short amount of time has been really neat to see. Makes me want to get more ImGui stuff in my project.[/QUOTE]

Really speaks for how easy and intuitive to use it is I'd say.

[DrTaxi]

[QUOTE=paindoc;52333688]question, though: Is there any benefit to building in x64 (beyond more RAM), like improved optimizations or anything? I had read that you might get more auto-vectorization and notice slightly improved performance in x64, but it'd be good to know for sure. It wasn't [I]that[/I] hard to get it building, but I'm hesitant (and Im sure Janga is) to release a new platform executable without knowing its worth the probable new bugs and issues[/QUOTE]

If you've already gotten it to work, why not just measure?

(Personally I've seen MSVC x64 builds show some 10%-20% improvement, but I've never paid too much attention.)

Auto-vectorization, by the way, is a nice feature for compilers to have because it can give you performance improvements for free, but you can't rely on it: Lots of seemingly innocuous changes can prevent it from activating, and you may find yourself wondering where your performance went after you tried to optimise that one loop by breaking out of it early. If you [I]need[/I] that performance, you either need to watch your /Qvec-report with eagle eyes or write explicit SIMD code.

[paindoc]

[QUOTE=DrTaxi;52337389]If you've already gotten it to work, why not just measure?

(Personally I've seen MSVC x64 builds show some 10%-20% improvement, but I've never paid too much attention.)

Auto-vectorization, by the way, is a nice feature for compilers to have because it can give you performance improvements for free, but you can't rely on it: Lots of seemingly innocuous changes can prevent it from activating, and you may find yourself wondering where your performance went after you tried to optimise that one loop by breaking out of it early. If you [I]need[/I] that performance, you either need to watch your /Qvec-report with eagle eyes or write explicit SIMD code.[/QUOTE]

Yeah, I've used /Qvec and /Qpar report levels to check for things and it mostly just told me that the compiler must hate me. We don't need the performance boost right now: most of the work is put on Vulkan and the GPU, and I don't think we're CPU bottlenecked at all. Plus, RAM usage isn't an issue either.

When I measured, the measured improvement was maybe 10% at most but I wasn't sure if there were additional benefits I was missing. That and my hardware is on the upper end of what I'd expect any users of our software to have, so it'd be easy for me to undervalue enhancements.

[editline]10th June 2017[/editline]

I've made some changes to our build system and cmakelists that allow for x64 builds, so those are at least taken care of for future usage. That was the big thing, our build process was all messed up.

Also, the last coder used

[cpp]
__asm int 3;
[/cpp]

for a debug break code in all of his Vulkan callbacks, so the biggest change I had to make for x64 compatibility was using

[cpp]
__debugbreak();
[/cpp]

which is the MSVC intrinsic that accomplishes the same thing, but actually works in x86 and x64 builds.

[Ott]

[QUOTE=geel9;52333352]MongoDB was a mistake.[/QUOTE]

Should've used ROHONGODB

[Phygon]

Man, fuck every single person that leaves a one-star review on a product before reaching out to customer support just to put more pressure on the dev to fix it that second (even more so when the issue is not RTFM). It's seriously not cool, especially when you [I]never fucking respond to the support that you received or take down the review[/I].

In other news, making unity assets is profitable and stressful.

[paindoc]

Getting this LOD shit working has been the biggest challenge I've faced in a personal project, yet. There's no one-size-fits-all solution, no "best" solution, because each one has its own downsides that are rather considerable. And despite damn near copying what Proland does, I've not had any luck. All my chunks have the same data, somehow. And when they don't, the stitching between chunks is non-existent.