Re: [dev] [announce] rat - ridiculously abysmal tar
On 7 November 2012 03:00, Christoph Lohmann 2...@r-36.net wrote: b...but I though Go was suckless? ;_; No. There was only one person pretending go to be suckless because of its pseudo Plan 9 heritage. Which languages qualify as suckless? Cheers, Alex
Re: [dev] interested in issue tracker dev
On 16 January 2012 01:27, Kurt H Maier khm-suckl...@intma.in wrote: On Sun, Jan 15, 2012 at 01:27:28PM +1100, Alex Hutton wrote: It seems to me it might overly complicate things to build the issue tracker into a mail system or into git. The core functionality of tracking issues can be implemented in a meta-language. are you even listening to yourself? What if the bug tracker can be updated via web, cli and/or irc? Does it make sense for each of those to fire off an email every time a bug is changed?
Re: [dev] interested in issue tracker dev
It seems to me it might overly complicate things to build the issue tracker into a mail system or into git. The core functionality of tracking issues can be implemented in a meta-language. For instance, you have one file per issue, and the issue files would look something like this. [timestamp] : Issue #XXX [Issue name] Opened by [user1 name] [timestamp] : Issue #XXX Status set to ABC by [user1 name] [timestamp] : Issue #XXX Description at (/path/to/description) by [user1 name] [timestamp] : Issue #XXX added tags (tag1,tag2,tag3) by [user1 name] [timestamp] : Issue #XXX assigned to [user2 name] by [user1 name] [timestamp] : Issue #XXX related email at (/path/to/email) sent by [user2 name] [timestamp] : Issue #XXX related email at (/path/to/email) received by [exter...@external.com] etc etc. You then have different daemons reading and writing to the file and carrying out various functions. For instance, you have some mailer that reads that an issue was assigned to a particular person, so it knows it should send an email to that person. A CI server could create issues when it detects a regression. Any daemon reading the file should ignore lines it doesn't understand, that way as new features are added to the meta-language the daemons won't break if they don't understand them. Issue files could be stored in a directory structure organised by time. There could be special directories containing symlinks to the issue files, for instance an 'Active issues' directory. Cheers, Alex
Re: [dev] Please recommend a suckless rss reader
This looks interesting: http://rss2imap.sourceforge.net/en/index.html I haven't tried it, though. On 30 October 2011 02:22, Yue Wu vano...@gmail.com wrote: Hello, list, I'm looking for a cli newsreader, suckless, less dependencies. Thanks! -- Regards, Yue Wu State Key laboratory of Natural Products and Functions Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China
Re: [dev] Suckless design in Games
A lot of the old-school games were written in assembly or C, so I believe it is quite possible to make excellent games with low level languages, and that the OO approach is unnecessary. That's my contribution to the conversation :). On 10 August 2010 20:23, Szabolcs Nagy n...@port70.net wrote: * Matthew Bauer mjbaue...@gmail.com [2010-08-09 21:02:53 -0500]: What game libraries are suckless? (SDL, OpenGL) What programming language is best for games? (C, Python, or Go) i consider this approach fairly nice and simple for 'flashgames': http://repo.hu/projects/animator/ reads drawing commands from stdin (optionally) writes events to stdout so game logic can be a separate process in whatever language (of course it has limitations eg only vector graphics, no bitmap operations like blitting and audio has to be handled separately)
Re: [dev] Suckless design in Games
An idea I had the other day, and this is for dealing with data compartmentation in games, was to write a game in C and use sqlite for all the data. I've never used sqlite so I don't know how the performance would go, but it seems like a good idea to store all the data in a relational database as it makes it less likely that the data structures would have to be refactored during development and it allows me to avoid having to use 'objects'.
Re: [dev] Suckless design in Games
You're right, that would be even simpler. I was thinking about whether or not the 'relational' abilities of the database would come in handy but I haven't come up with any definite uses for them yet. On 11 August 2010 10:18, Jacob Todd jaketodd...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:09:00AM +1000, Alex Hutton wrote: An idea I had the other day, and this is for dealing with data compartmentation in games, was to write a game in C and use sqlite for all the data. I've never used sqlite so I don't know how the performance would go, but it seems like a good idea to store all the data in a relational database as it makes it less likely that the data structures would have to be refactored during development and it allows me to avoid having to use 'objects'. But then you're using a database. Why not use a filesystem? Quake, Doom, and the games based off those engines (half-life, c) do.
