Frag: A Quake3 engine in Haskell(wiki.haskell.org)
wiki.haskell.org
Frag: A Quake3 engine in Haskell
https://wiki.haskell.org/Frag
4 comments
Frag is a decade old. Does it still run?
I've gotten it compiling! Though I'm not as excited after just now noticing salamynder's comment:
https://raw.githubusercontent.com/gentoo-haskell/gentoo-hask...
I basically have the same modifications, though I use a StoreableArray instead of an IOArray so theirs is probably faster.
I'm very satisifed I was able to fix all of these things so easily thanks to following the types and using ghci.
https://raw.githubusercontent.com/gentoo-haskell/gentoo-hask...
I basically have the same modifications, though I use a StoreableArray instead of an IOArray so theirs is probably faster.
I'm very satisifed I was able to fix all of these things so easily thanks to following the types and using ghci.
if there are problems compiling, it worked for me with this unrust-patch:
https://raw.githubusercontent.com/gentoo-haskell/gentoo-hask...
LOL, and I spent all that time getting it to compile. Do you know if this compiles with GHC 7.8?
I'm guessing it still runs on GHC 6.8, maybe GHC 7.6.3? It uses HOpenGL-2.0 and the current version is OpenGL-2.12.0.1 (with a name change apparently).
I'll try to compile it.
I'll try to compile it.
Whoa... I'm surprised this is building (using ghc 7.8.3). I just did:
update: Their cabal file doesn't have any bounds... easiest method would probably be to add bounds and use an older ghc. It depends on Data.HashTable from base 4.2. However I'm wondering if this is the only thing and if I can just use the hashtables package on hackage.
darcs get http://code.haskell.org/frag
cabal sandbox init
cabal install
update: Their cabal file doesn't have any bounds... easiest method would probably be to add bounds and use an older ghc. It depends on Data.HashTable from base 4.2. However I'm wondering if this is the only thing and if I can just use the hashtables package on hackage.
> Their cabal file doesn't have any bounds...
A surefire recipe for bitrot. If you want to maximize the ability of people to build your code in the future, upper bounds are essential for all your dependencies.
A surefire recipe for bitrot. If you want to maximize the ability of people to build your code in the future, upper bounds are essential for all your dependencies.
That's a sad state of affairs. So there is essentially no guarantee of backwards compatibility?
As I sadly recently discovered when I went back and revived a node.ja project from 2 years ago.
This is an advantage of PHP's Composer over node.js's npm, as it can write your require lines for you, so you resist the temptation to put "*".
This is an advantage of PHP's Composer over node.js's npm, as it can write your require lines for you, so you resist the temptation to put "*".
How slow is it, since it's using Haskell?
I love frag. Have you seen Nikki and The Robots?
https://github.com/nikki-and-the-robots/nikki
"Darcs is the standard revision control system of the Haskell community."
Hmm, was that the case in 2005?
Hmm, was that the case in 2005?
Yes, Darcs predates Git by a few years and was used by GHC, XMonad, Happstack, and several other well-known Haskell projects.
git was first released in April 2005. We (Haskell community) were using dvcs through darcs for about 2 years prior to that. dvcs made a lot of sense to the Haskell open source world back then, as we didn't have servers, so central repos (like CVS or SVN) were out of the question. It had to be p2p to get off the ground.
IIRC, yes. Back then git was one of many of a new crop of DVCSs, and didn't have nearly the developer mindshare it has now.