Hey folks, I'm back from the underworld! I'm glad to see that some people posted here while I was away.
FireRogue wrote:given that its easier to start a discussion with lots of people, even if they're not all paying attention, i suggest you join me in adding it to your auto-join list. it might also attract others if we've got a large number of people in the channel, and even if not, at least plenty of people will have logs of any ideas you put down and might be able to help you capitalize on it.
I second this suggestion. For your interest, from now on I'll be on the channel more often again.
I suggest a logo that can be displayed on a terminal, something like this:
Code: Select all
| ,--/ +--,
| (oOo) |
Red Spider Project
(Yes, of course we can have more than one logo.)
Xenomortis wrote:I'd like to try to help out with something; I'm a .NET neophyte for my day-job (VB) and feel the need to expand my programming knowledge and experience.
Xenomortis wrote:Although I don't know how this git thing works, I'm currently trying to get something setup.
Judging from the GitHub network graph you've figured it out. Well done!
Xenomortis wrote:A couple of organisation things:
1. What's actually been achieved; what exists and how does it integrate together?
Oh boy. I think the biggest achievements so far are that 1) we started this project enthousiastically and got several people to work on it; 2) we more or less managed to make it work like an cross-platform installable package with some fun commands that are more or less ready to use (xkcd-fetch et al); 3) we got a website and an (at this point not very well populated) IRC channel. What exists, well it's not much but we have a rudimentary infrastructure, some working commands, several fun subprojects and some artwork. How it integrates: the install script puts things in the right place and informs your shell about the path to the commands (not sure whether this describes the state on master or on rsroot-env, but this is the way it's going to be anyway). The rsshell script then uses that to create a cozy self-contained environment in which the commands can run and cooperate in any way they like. You are encouraged (but not required!) to write your commands such that they can easily be combined with other commands.
Xenomortis wrote:2. What's being worked on?
Pretty much everything in the project (some things are more or less done but those are the exceptions). Most of it didn't get much attention for a while, but I'd say it's dormant rather than dead. In addition I strongly suspect there are some contributions that didn't make it to GitHub yet. BRNMan pushed some C# code to his master branch, perhaps you could have a look at that?
Xenomortis wrote:I feel as those the above should be referenced somewhere.
Yes, definitely. That goes on the pile of things we should write a wiki page for.
Xenomortis wrote:With that in mind; any ideas for what I could try? I'm willing (and actually want) to move away from my familiar .NET platform (which is perhaps necessary for platform independence). Python seems popular so I could try something with that I guess.
You evidently already found something to work on, but here are my two cents on your platform choice. First off, you're not strictly required to drop .NET entirely if you want to do cross-platform work, but you do need to adopt a different style of programming (i.e. avoid the Windows APIs as much as possible) and avoid some of the surface languages (e.g. PowerShell). You definitely can
write something cross-platform in C#. Secondly, Python is very good choice indeed. We've more or less adopted it as our "cross-platform shell language". That said, it doesn't necessarily hurt if somebody contributes a platform-specific program once in a while. Also, most languages allow you to write cross-platform stuff.
So in my spare time over the past few days, I've been working on an implementation of Conway's Game of Life. It's run through the command console and is written in C++ (because that was such a sensible
choice given my C# and VB.NET experience).
A few twists and features:
- There are actually two species; blue Os and red Xs. The blue species follows the standard rules (B3/S23), the red species follows the rules for High Life (B36/S23) - a cell is also born if it has six live neighbours. In the case of both species contributing to the birth of a cell, the colour is determined by the most common species (in the case for 6 neighbours, a red cell is only born if red neighbours outnumber blue, otherwise it remains dead).
- The universe array can be set to be either toroidal or klein-bottle like. Pass through -t or -k for a torus or klein-bottle universe respectively, default is the intuitive torus.
- A file called start.txt can be included into the same directory as the compiled executable; this can be used to determine the initial states; ',' seperate cells on a given row, an empty cell is dead, if it contains x,r or 2 it's red and if it contains o,b or 1 it's blue. If a row has too few specified entries, the remaining cells are dead.
That's a fun idea!
Xenomortis wrote:Major caveat: it's currently Windows only due to the manipulation I do with the command console. It's likely you'll have to widen the command console too, unless you narrow the array in the source code before compiling.
I don't have anything POSIX compatible right now to test potential ports. If anyone can suggest work-arounds or alternative to the Windows specific parts that'd be fantastic.
The only work-around I can think of is to create a virtual machine with Linux and test your stuff over there. Well, that or have a POSIX user join in. The alternative to the Windows-specific parts you're looking for is probably ncurses
. That one is POSIX-specific but works on Windows with an emulation layer (like MSYS which is bundled with Git for Windows). You could also use both implementations and have a build script (CMake) decide which one to use, depending on the platform.
Xenomortis wrote:Need to add in a few more passable arguments (for array dimensions, delay between iterations, seed probabilities, etc). The format of start.txt I'll probably change to make more intuitive.
I'd like to add another option to the universe space-type; namely spherical. It's slightly pathological; either I glue the top and right sides together and the bottom and left sides (resulting in the top-right and bottom-left cells being their own neighbours) or I glue the whole outer-edge together (any cell on the edge will neighbour every other cell on the edge, plus its regular neighbours) - how should I extend the rules in these cases?
I'd go for the first option, this is usually also the way it's defined in topology. It makes intuitive sense if you think of the backwards-slanting diagonals as circles of latitude.
Xenomortis wrote:(I don't suppose a universe based on the projective plane would be out of the question either)
You should definitely implement that!
Xenomortis wrote:Oh, and I have no idea how to integrate this into the setup.py script.
No wonder, there's no way to do that yet as the current script only accomodates for interpreted languages. Your best bet for now is to just write your own CMake script that puts the compiled end product in /bin and any intermediate build products in /build. setup.py will than invoke the CMake script. Alternatively you can just leave it for now, because I'm planning on writing a general CMake script that deals with everything build-related anyway.