Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Moghjubar]

That sounds overintimidating... o.O

[Skyrunner]

If you can dodge a tank shot you can dodge a bullet!

Wait, that actually makes sense



Anyhow, the stream idea itself is really cool.

edit: I use Cherrypy for the backend. I'm trying to think of a way to store information the clients send to the server, and I'm starting to think that I'll have to use SQL in the end :| It's a lot of effort to write and test my own database structure while also keeping it efficient and stuff. But making a database and learning SQL or a library like SQLAlchemy sounds like a lot of work T_T Only if there were a really simple database that supports a JSON-like data structure...

[Thief^]

Wow!

That's... ambitious.

I've made a game in pure Windows API (no middleware) before, and it's hard. The biggest sticking point will be any kind of physics/collision detection, though certain kinds of game (e.g. puzzle, strategy) can avoid this.

Software 3D is also horrible to do, CPUs are surprisingly slow.

[Orange Wizard]

Yeah, I raised my eyebrows at that bit. Software rendered? Are you sure about this?

[Skyrunner]

To be fair, he did say that he would make a software-rendered version first, then swap it out for hardware-accelerated versions if/when he needs the extra performance.

Also, does nobody have a suggestion for a database that can be accessed like JSON? That is, via the dictionary interface (dict["key"] = value)

[Thief^]

Yeah, I raised my eyebrows at that bit. Software rendered? Are you sure about this?

Yeah, my thought too. I have a toy multi-threaded software 3d renderer I wrote for fun, and it struggles to get 130 fps rendering the inside of a cube. On a 6-core hyperthreaded cpu. 512x512 window. Bilinear-filtered texture, diffuse-only point lighting.

You might say 130 fps sounds good, but if I expanded it to a full 1080p screen I'd get a huge 14 fps. Rendering a single cube.

[BlindKitty]

To be fair, he did say that he would make a software-rendered version first, then swap it out for hardware-accelerated versions if/when he needs the extra performance.

Also, does nobody have a suggestion for a database that can be accessed like JSON? That is, via the dictionary interface (dict["key"] = value)

Take a look at MongoDB; it has really well support and keeps the documents as binary JSON (BSON) internally. Or you can take a look at CouchDB, which does the same thing, but is much less known, I think (at least that's my impression after looking for various DBs on the Internet). I suppose both have some support in Python.

[Mephisto]

Also, does nobody have a suggestion for a database that can be accessed like JSON? That is, via the dictionary interface (dict["key"] = value)

I know you expressed feeling like SQLAlchemy would be a lot of work, but something like that might be the best way to get what you want if you want a SQL database.

It's not SQLAlchemy and I don't agree with everything it does, but the Django ORM has the capability to do this. Want dictionaries?

Code: [Select]

Model.objects.filter(**{stuff}).values()Now you have a list of dictionaries for every row that the filter matches.

[Gentlefish]

Just got finished with a Perl script that backs up files and directories (recursively!) or a .backup in the user's ~/ directory. I did not use any system() calls.

It took me four hours out of my night.

The other three scripts took no more than half an hour each.

Fuck yeah.

[Skyrunner]

All these database systems are incredibly complex. I'm surprised nobody has made a very simple wrapper for SQL that lets the user just pretend the db is a dict. I don't need any fancy joins or searches (or even simple ones), just key-value data with nested data structure.

[Thief^]

The "nested" is the key problem. SQL tables are flat. Any nesting comes from joins.

[Skyrunner]

Yeah... nested is so nice and logical though.


Database: card sets
Set1 {
  Author: A,
  Privacy: Public,
  Content: [282,293, 294, 103]
}
...


I suppose this could be done with SQL, but nestedness is always nice to have.

[BlindKitty]

Well, 'simple' and 'database' aren't exactly going all that well together. But why can't you just keep that in memory? Or dump the dictionary to the file and read/write a single JSON? To be honest, the SQL system and nested dictionaries are probably as far away from each other as data structures go, so it is not so surprising to me. It's just the fact that when you need nested data structures, the SQL is not a really good idea to achieve that. You can do that, but joins are expensive, as far as I know, and using MongoDB/CouchDB/PogreSQL/other DB would make more sense IMHO.

[Thief^]

A traditional database like SQL is best for massive amounts of data that follows a very rigid structure, e.g. billions of money transaction records at a bank.

For a small amount of data, especially if it's extremely variable in structure, it may just be quicker to use a file.

[Antsan]

You could change my C++ contains() to have a linked-list arg instead, it will still clone the rest of the list each iteration.

I don't see how that's relevant. The code which originally was shown (in Prolog) doesn't do any copying or cloning and the same goes for any other implementation of member I have ever seen for linked lists didn't either.
The thing is, saying "that looks expensive" and claiming that it probably would be without being some kind of super wizard programmer is not true. Writing a O(n) member check for any type of sequence recursively is trivial in any language I know, including C++.