Re: 48 hour game jam
On 2012-10-30 23:17, Manu wrote: I've fixed all the outstanding Linux stuff, I'd love to finish off that OSX stuff some time soon. Unfortunately I haven't much time to work at D right now at all, but I can usually squeeze in an hour per day, more during the weekends. I'm online at the IRC D channel when I'm at the computer. I have the code ready for the creating a window but I need help to integrate it with the game engine. Last time I compiled the game engine there was some problem related to OpenGL headers or similar. -- /Jacob Carlborg
Re: 48 hour game jam
On 31 October 2012 09:35, Jacob Carlborg d...@me.com wrote: On 2012-10-30 23:17, Manu wrote: I've fixed all the outstanding Linux stuff, I'd love to finish off that OSX stuff some time soon. Unfortunately I haven't much time to work at D right now at all, but I can usually squeeze in an hour per day, more during the weekends. I'm online at the IRC D channel when I'm at the computer. I have the code ready for the creating a window but I need help to integrate it with the game engine. Last time I compiled the game engine there was some problem related to OpenGL headers or similar. Cool, I'll come and idle too when I'm at home. Probably just a few more little #ifdef's here and there. And the include/lib paths are weird for OpenGL in OSX if i recall...
Re: 48 hour game jam
On 2012-10-31 11:42, Manu wrote: Cool, I'll come and idle too when I'm at home. Probably just a few more little #ifdef's here and there. And the include/lib paths are weird for OpenGL in OSX if i recall... The standard way when building Cocoa applications is to use the OpenGL framework, located at /System/Library/Frameworks/OpenGL.framework. It will contain both the headers and the actual library. I'm usually online somewhere between 19:30 and 22:00 GMT +1. -- /Jacob Carlborg
Re: 48 hour game jam
On 19 October 2012 01:12, F i L witte2...@gmail.com wrote: Trying to build in Linux, but having problems. I follow the steps from github wiki How to build under Windows, except I run 'Fuji/create_project.sh' instead of '.bat'... now I'm a bit confused as to what steps to take. Running 'Fuji/make' has errors, and running 'Stache/make_project.sh' - 'make' gives me: make[1]: *** No targets. Stop. make: *** [Stache] Error 2 which I assume is because Fuji isn't built (?). Help please! Nice screenshot, btw :) Did you ever follow my linux build instructions? I'd be curious to know if anyone else can successfully build it.
Re: 48 hour game jam
On 18 October 2012 23:58, Jacob Carlborg d...@me.com wrote: On Thursday, 18 October 2012 at 20:11:56 UTC, Manu wrote: Ah yes, what do the OSX OpenGL libs look like? GLX is only a very thin front end on a fairly conventional OpenGL. It's only a couple of functions that would be replaced by some mac variant I expect. Mac OS X has the OpenGL framework: https://developer.apple.com/**library/mac/#documentation/** GraphicsImaging/Reference/CGL_**OpenGL/Reference/reference.** html#//apple_ref/doc/uid/**TP40001186https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/CGL_OpenGL/Reference/reference.html%23//apple_ref/doc/uid/TP40001186 And a couple of high level Objective-C classes. This is the programming guides for OpenGL on Mac OS X: https://developer.apple.com/**library/mac/#documentation/** GraphicsImaging/Conceptual/**OpenGL-MacProgGuide/opengl_** intro/opengl_intro.htmlhttps://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html I'll come on IRC in 5 minutes or so. I won't be online tonight, it's getting late here. Tomorrow or perhaps saturday. I've fixed all the outstanding Linux stuff, I'd love to finish off that OSX stuff some time soon.
Re: 48 hour game jam
I have fixed all associated bugs now and the Linux build runs properly. There was a recently fixed DMD bug that causes a problem with the camera, if you're using an older DMD, the camera will have problems. GDC should theoretically work fine, but my binary is out of date (from the debian package manager) and it doesn't work for me, so I haven't proven it works. On 19 October 2012 11:02, Manu turkey...@gmail.com wrote: On 19 October 2012 01:12, F i L witte2...@gmail.com wrote: Trying to build in Linux, but having problems. I follow the steps from github wiki How to build under Windows, except I run 'Fuji/create_project.sh' instead of '.bat'... now I'm a bit confused as to what steps to take. Running 'Fuji/make' has errors, and running 'Stache/make_project.sh' - 'make' gives me: make[1]: *** No targets. Stop. make: *** [Stache] Error 2 which I assume is because Fuji isn't built (?). Help please! Nice screenshot, btw :) I added Linux build instructions to the wiki, includes the Fuji build instructions. There are a few differences from Windows. The main problem is a bug in premake4 for D, it seems to throw an error generating makefiles for my project (D support is new and experimental). I plan to look into the premake bug this weekend. You can generate a monodevelop project through, which works fine with the Mono-D plugin installed. That's how I'm building/running/debugging on Linux at the moment.
Re: 48 hour game jam
On 19 October 2012 01:12, F i L witte2...@gmail.com wrote: Trying to build in Linux, but having problems. I follow the steps from github wiki How to build under Windows, except I run 'Fuji/create_project.sh' instead of '.bat'... now I'm a bit confused as to what steps to take. Running 'Fuji/make' has errors, and running 'Stache/make_project.sh' - 'make' gives me: make[1]: *** No targets. Stop. make: *** [Stache] Error 2 which I assume is because Fuji isn't built (?). Help please! Nice screenshot, btw :) I added Linux build instructions to the wiki, includes the Fuji build instructions. There are a few differences from Windows. The main problem is a bug in premake4 for D, it seems to throw an error generating makefiles for my project (D support is new and experimental). I plan to look into the premake bug this weekend. You can generate a monodevelop project through, which works fine with the Mono-D plugin installed. That's how I'm building/running/debugging on Linux at the moment.
Re: 48 hour game jam
On 2012-10-17 16:14, Manu wrote: Okay, awesome. Cheers. I got it running on Linux-x64 last night, so I think that's the only thing holding OSX back. Ok, I have a fully working window, which behaves properly and receives events. In addition to that I have an application menu with the standard items and a dock icon. This is all running completely separate. No I would need some help to integrate this back in the game engine. This is the latest error I have when compiling: In file included from ../Source/MFFont.cpp:5: In file included from ../Source/MFTexture_Internal.h:7: In file included from ../Source/../Source/Drivers/OpenGL/MFOpenGL.h:46: ../Source/../Source/Drivers/OpenGL/glew/glxew.h:97:10: fatal error: 'X11/Xlib.h' file not found #include X11/Xlib.h ^ 12 warnings and 1 error generated. make[1]: *** [../Build/Release/Fuji/MFFont.o] Error 1 make: *** [Fuji] Error 2 Either glxew.h shouldn't be used or it's need to have a Mac OS X version. -- /Jacob Carlborg
Re: 48 hour game jam
On 18 October 2012 22:26, Jacob Carlborg d...@me.com wrote: On 2012-10-17 16:14, Manu wrote: Okay, awesome. Cheers. I got it running on Linux-x64 last night, so I think that's the only thing holding OSX back. Ok, I have a fully working window, which behaves properly and receives events. In addition to that I have an application menu with the standard items and a dock icon. This is all running completely separate. No I would need some help to integrate this back in the game engine. This is the latest error I have when compiling: In file included from ../Source/MFFont.cpp:5: In file included from ../Source/MFTexture_Internal.**h:7: In file included from ../Source/../Source/Drivers/**OpenGL/MFOpenGL.h:46: ../Source/../Source/Drivers/**OpenGL/glew/glxew.h:97:10: fatal error: 'X11/Xlib.h' file not found #include X11/Xlib.h ^ 12 warnings and 1 error generated. make[1]: *** [../Build/Release/Fuji/MFFont.**o] Error 1 make: *** [Fuji] Error 2 Either glxew.h shouldn't be used or it's need to have a Mac OS X version. Ah yes, what do the OSX OpenGL libs look like? GLX is only a very thin front end on a fairly conventional OpenGL. It's only a couple of functions that would be replaced by some mac variant I expect. I'll come on IRC in 5 minutes or so.
Re: 48 hour game jam
On Thursday, 18 October 2012 at 20:11:56 UTC, Manu wrote: Ah yes, what do the OSX OpenGL libs look like? GLX is only a very thin front end on a fairly conventional OpenGL. It's only a couple of functions that would be replaced by some mac variant I expect. Mac OS X has the OpenGL framework: https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Reference/CGL_OpenGL/Reference/reference.html#//apple_ref/doc/uid/TP40001186 And a couple of high level Objective-C classes. This is the programming guides for OpenGL on Mac OS X: https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html I'll come on IRC in 5 minutes or so. I won't be online tonight, it's getting late here. Tomorrow or perhaps saturday. -- /Jacob Carlborg
Re: 48 hour game jam
Trying to build in Linux, but having problems. I follow the steps from github wiki How to build under Windows, except I run 'Fuji/create_project.sh' instead of '.bat'... now I'm a bit confused as to what steps to take. Running 'Fuji/make' has errors, and running 'Stache/make_project.sh' - 'make' gives me: make[1]: *** No targets. Stop. make: *** [Stache] Error 2 which I assume is because Fuji isn't built (?). Help please! Nice screenshot, btw :)
Re: 48 hour game jam
On 2012-10-16 19:57, Ethan wrote: I'm just going to throw it out there that you don't actually need to touch Objective-C at all. Cocoa/Foundation/all those Objective-C interfaces sit on top of something known as Core Foundation, which are C APIs. The pointers used by Core Foundation can generally be used as Objective-C objects of the same type as well. That's not entirely correct. Most of the types in Core Foundation are a toll free bridge to the corresponding Objective-C types in the Foundation framework. But all the GUI related classes, i.e. AppKit, are not available in the same way. It would be handy to have a D binding to all the Core- libraries on OSX. I might do that myself when I get my Mac if such a binding doesn't already exist. The book should be equally applicable for iOS as well, but last time I was in iOS land I was still a newbie to the whole OSX programming thing. If you're going to write GUI applications on Mac OS X you need to interact with the Objective-C frameworks. The reason for this is that, as stated above, AppKit is only available from Objective-C and you really need to be able to create your own Objective-C classes and subclasses. There are two ways to interact with Objective-C * Create an Objective-C/D bridge * Make D binary compilable with Objective-C The Objective-C/D bridge would use the Objective-C runtime functions defined in C to interact with Objective-C. Every time an object is passed over the bridge it needs to be encapsulated or de-encapsulated. Another problem is the code/template bloat. A Hello World application will be around 60MB in size. This has already been done: http://www.dsource.org/projects/dstep The other approach would be to make D binary compaitable with Objective-C, that is, provide extern (Objective-C) declarations. This would generate basically the same code as the Objective-C compiler would, but with the nice syntax of D instead of the horrible syntax that Objective-C is. This would also allow you do create bindings to Objective-C classes, methods and functions just as with C. The problem with this approach, it's a lot of work to modify the compiler. But that has already been done as well: http://michelf.ca/projects/d-objc/ This fork of DMD isn't ready yet (there's an alpha available) and there hasn't been any changes made in over a year. If I recall correctly, Michel Fortin said he hasn't got the time now to work on this. It also the problem with always playing catchup with the upstream version of DMD. -- /Jacob Carlborg
Re: 48 hour game jam
On 17 October 2012 09:35, Jacob Carlborg d...@me.com wrote: On 2012-10-16 19:57, Ethan wrote: I'm just going to throw it out there that you don't actually need to touch Objective-C at all. Cocoa/Foundation/all those Objective-C interfaces sit on top of something known as Core Foundation, which are C APIs. The pointers used by Core Foundation can generally be used as Objective-C objects of the same type as well. That's not entirely correct. Most of the types in Core Foundation are a toll free bridge to the corresponding Objective-C types in the Foundation framework. But all the GUI related classes, i.e. AppKit, are not available in the same way. It would be handy to have a D binding to all the Core- libraries on OSX. I might do that myself when I get my Mac if such a binding doesn't already exist. The book should be equally applicable for iOS as well, but last time I was in iOS land I was still a newbie to the whole OSX programming thing. If you're going to write GUI applications on Mac OS X you need to interact with the Objective-C frameworks. The reason for this is that, as stated above, AppKit is only available from Objective-C and you really need to be able to create your own Objective-C classes and subclasses. There are two ways to interact with Objective-C * Create an Objective-C/D bridge * Make D binary compilable with Objective-C The Objective-C/D bridge would use the Objective-C runtime functions defined in C to interact with Objective-C. Every time an object is passed over the bridge it needs to be encapsulated or de-encapsulated. Another problem is the code/template bloat. A Hello World application will be around 60MB in size. This has already been done: http://www.dsource.org/**projects/dstephttp://www.dsource.org/projects/dstep The other approach would be to make D binary compaitable with Objective-C, that is, provide extern (Objective-C) declarations. This would generate basically the same code as the Objective-C compiler would, but with the nice syntax of D instead of the horrible syntax that Objective-C is. This would also allow you do create bindings to Objective-C classes, methods and functions just as with C. The problem with this approach, it's a lot of work to modify the compiler. But that has already been done as well: http://michelf.ca/projects/d-**objc/ http://michelf.ca/projects/d-objc/ This fork of DMD isn't ready yet (there's an alpha available) and there hasn't been any changes made in over a year. If I recall correctly, Michel Fortin said he hasn't got the time now to work on this. It also the problem with always playing catchup with the upstream version of DMD. It occurred to me last night, I think almost all the work to get OSX running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical.
Re: 48 hour game jam
On 2012-10-17 13:57, Manu wrote: It occurred to me last night, I think almost all the work to get OSX running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical. They are fairly similar. I'll have a look at the iPhone driver when I get home tonight. If you want the game to look as a proper Mac OS X application there are some additional code that is required. That is for creating the main menu and the dock icon. Anyway, I know how to handle this now. -- /Jacob Carlborg
Re: 48 hour game jam
On 17 October 2012 17:08, Jacob Carlborg d...@me.com wrote: On 2012-10-17 13:57, Manu wrote: It occurred to me last night, I think almost all the work to get OSX running is actually already done in the iPhone drivers. You might be better off to copy the iPhone files, and adapt that to OSX. Ethan seems to think iPhone and OSX are almost identical. They are fairly similar. I'll have a look at the iPhone driver when I get home tonight. If you want the game to look as a proper Mac OS X application there are some additional code that is required. That is for creating the main menu and the dock icon. Anyway, I know how to handle this now. Okay, awesome. Cheers. I got it running on Linux-x64 last night, so I think that's the only thing holding OSX back.
Re: 48 hour game jam
On Monday, 15 October 2012 at 14:47:06 UTC, Manu wrote: Ah, nicely spotted, I should stick that DLL in the zip now that you mention it. I've just tried running this version: https://github.com/downloads/RemedyGameJam/stache/Stache-Windows-0.1d.zip It cannot run asking for d3dx9_43.dll and then says failed to load Fuji_Debug.dll.
Re: 48 hour game jam
On Wednesday, 17 October 2012 at 15:47:14 UTC, Manu wrote: Wait up, I misread (my error message is deceiving!) I have no idea why it would complain about the missing d3dx dll, unless you're running the exe from the wrong location. The dll is sitting right there next to the exe right, in the bin folder? They sit in the same bin folder however note: it asks for d3dx9, not d3dx11 ! This is happening in Vista 32-bit, if that matters.
Re: 48 hour game jam
On Tuesday, 16 October 2012 at 02:45:42 UTC, so wrote: On Monday, 15 October 2012 at 20:41:55 UTC, Paulo Pinto wrote: Now imagine those that have experimented how powerful Lisp and Smalltalk based OS were. It is so sad to see IDE makers still trying to replicate the experience from those environments. -- Paulo Thanks for mentioning that, checked lisp os and next thing was www.loper-os.org/?p=69. It might be offensive to some people but reading his posts/rants now, i kind of like what he says. This is what i was talking about when i say that i feel lucky because Lisp was not my first language. Looks like he experienced the language devolutions and very (rightly so) frustrated. An example: You will not find a “Thumbs Down for Python” essay in this blog, because Python users make no attempt to peddle their crock of shit as “the future of Lisp.” I have no quarrel with users of Python, Ruby, Dylan, and other shoddy “infix Lisps.” Because they are honest. It is the lying of Clojure users which upsets me, and their deliberate attempts to rewrite history, to make people forget that truly-interactive, advanced Lisp systems once existed I know that site, you should have a look at http://www.loper-os.org/?p=932 presentation. Now imagine that computer system was developed in the late 70's and how things would look like today if it wasn't for the AI Winter. Same thing with Smalltalk environments, which are the only ones I know with the same capabilities. Everything that is trendy nowadays, unit testing, code refactoring, live editing, JIT and AOT compilation, full GC based environments, was already available in Lisp and Smalltalk machines. Or for that matter look at Native Oberon, a fully working desktop operating system implemented in a GC enabled systems programming language. Sad that mainstream always takes generations to accept something. -- Paulo
Re: 48 hour game jam
On Monday, 15 October 2012 at 22:45:16 UTC, H. S. Teoh wrote: On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote: On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote: [...] It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) [...] You should talk with the Go guys which seem to be happy re-inventing the type of tools we used in C++, back in the days templates were still not available, somewhere around 1993 in my case. On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-) Does anyone remember the pre-processor hacks from Borland C++? [...] I remember Borland C++, yes... but I don't recall what preprocessor hacks were there. T I don't recall any longer how they were exactly. In can recall that they were implemented with macros. Then you needed to #define a set of values and include the relevant file multiple times for each set of parameter macros. -- Paulo
Re: 48 hour game jam
On 15 October 2012 16:18, Martin Drasar dra...@ics.muni.cz wrote: On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Uploaded a new build with keyboard controls (prev only gamepad supported), and also bundled the DLL's, which some people didn't seem to have on their system...
Re: 48 hour game jam
Nice work -- I can use this as a reference to get started with D and Fuji right? On Tue, Oct 16, 2012 at 6:03 PM, Manu turkey...@gmail.com wrote: On 15 October 2012 16:18, Martin Drasar dra...@ics.muni.cz wrote: On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Uploaded a new build with keyboard controls (prev only gamepad supported), and also bundled the DLL's, which some people didn't seem to have on their system...
Re: 48 hour game jam
On 2012-10-15 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki When using git submodules the recommended way of cloning is to use git clone --recursive. -- /Jacob Carlborg
Re: 48 hour game jam
On 16 October 2012 12:18, Danni Coy danni@gmail.com wrote: Nice work -- I can use this as a reference to get started with D and Fuji right? On Tue, Oct 16, 2012 at 6:03 PM, Manu turkey...@gmail.com wrote: On 15 October 2012 16:18, Martin Drasar dra...@ics.muni.cz wrote: On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Uploaded a new build with keyboard controls (prev only gamepad supported), and also bundled the DLL's, which some people didn't seem to have on their system... Sure. I also backported the fixes into Fuji, and polished up the D bindings last night to work on Linux. Was gonna put a Linux build script in there, since most people here are linux users.
Re: 48 hour game jam
On 16 October 2012 12:50, Jacob Carlborg d...@me.com wrote: On 2012-10-15 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/**RemedyGameJam/stache/wikihttps://github.com/RemedyGameJam/stache/wiki When using git submodules the recommended way of cloning is to use git clone --recursive. Ah, well. Allegedly I'm still rather a git noob. I'll update that, although the following steps still stand. I didn't have any luck making the subrepos default to a particular branch. (It worked once, but I couldn't see why, and then it stopped working)
Re: 48 hour game jam
On 2012-10-16 13:40, Manu wrote: Sure. I also backported the fixes into Fuji, and polished up the D bindings last night to work on Linux. Was gonna put a Linux build script in there, since most people here are linux users. We want a script for Mac OS X as well :) I replaced dist/bin/premake4 with a Mac OS X binary and I tried running stache/Fuji/create_project.sh. this is the output I got: ... Building Fuji (release) Creating ../Build/Release/Fuji glew.c DebugMenu.cpp In file included from ../../dist/include/Fuji/Fuji.h:356, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/MFTypes.h:69: error: ‘ssize_t’ does not name a type In file included from ../../dist/include/Fuji/Fuji.h:390, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/Util.h: In function ‘void MFFixUp(T*, void*, int)’: ../../dist/include/Fuji/Util.h:54: error: ‘intp’ was not declared in this scope ../../dist/include/Fuji/Util.h:54: error: expected `;' before ‘offset’ ../../dist/include/Fuji/Util.h:57: error: ‘offset’ was not declared in this scope ../../dist/include/Fuji/Util.h:59: error: ‘offset’ was not declared in this scope make[1]: *** [../Build/Release/Fuji/DebugMenu.o] Error 1 make: *** [Fuji] Error 2 -- /Jacob Carlborg
Re: 48 hour game jam
On 16 October 2012 16:08, Jacob Carlborg d...@me.com wrote: On 2012-10-16 13:40, Manu wrote: Sure. I also backported the fixes into Fuji, and polished up the D bindings last night to work on Linux. Was gonna put a Linux build script in there, since most people here are linux users. We want a script for Mac OS X as well :) I replaced dist/bin/premake4 with a Mac OS X binary and I tried running stache/Fuji/create_project.**sh. this is the output I got: ... Building Fuji (release) Creating ../Build/Release/Fuji glew.c DebugMenu.cpp In file included from ../../dist/include/Fuji/Fuji.**h:356, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/**MFTypes.h:69: error: ‘ssize_t’ does not name a type In file included from ../../dist/include/Fuji/Fuji.**h:390, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/Util.**h: In function ‘void MFFixUp(T*, void*, int)’: ../../dist/include/Fuji/Util.**h:54: error: ‘intp’ was not declared in this scope ../../dist/include/Fuji/Util.**h:54: error: expected `;' before ‘offset’ ../../dist/include/Fuji/Util.**h:57: error: ‘offset’ was not declared in this scope ../../dist/include/Fuji/Util.**h:59: error: ‘offset’ was not declared in this scope make[1]: *** [../Build/Release/Fuji/**DebugMenu.o] Error 1 make: *** [Fuji] Error 2 Well I've not tested mac, but I'll make the Linux build work tonight, and from that, you should be able to adapt it easily. Does OSX have X11 libs? If there is no X11 libs for OSX, then you will need to knock up an MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a window, then call into MFRenderer_OpenGL.cpp init, as the windows/X11 ones do). Infact, I'd really like to have a proper cocoa version anyway... ;) You might also have problems with sound and input in osx, if they aren't using the same libraries as linux. Writing the backend drivers for new platforms is very easy, I've just never wanted to run on a mac. I don't suppose you might like to help me out making proper support for OSX? I'll be home on a couple of hours if we could take it offline then. There's probably 2-3 drivers that need to be written, and some tweaks to the typical C++ platform disambiguation nonsense at the top of Fuji.h.
Re: 48 hour game jam
On 2012-10-16 15:29, Manu wrote: Well I've not tested mac, but I'll make the Linux build work tonight, and from that, you should be able to adapt it easily. Does OSX have X11 libs? Yes, Mac OS X has X11. If there is no X11 libs for OSX, then you will need to knock up an MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a window, then call into MFRenderer_OpenGL.cpp init, as the windows/X11 ones do). Infact, I'd really like to have a proper cocoa version anyway... ;) Yeah, a proper Cocoa version is always nice. You might also have problems with sound and input in osx, if they aren't using the same libraries as linux. Writing the backend drivers for new platforms is very easy, I've just never wanted to run on a mac. I don't suppose you might like to help me out making proper support for OSX? I'll be home on a couple of hours if we could take it offline then. There's probably 2-3 drivers that need to be written, and some tweaks to the typical C++ platform disambiguation nonsense at the top of Fuji.h. It depends on how much work it is, but I can have a look. -- /Jacob Carlborg
Re: 48 hour game jam
On 16 October 2012 18:02, Jacob Carlborg d...@me.com wrote: On 2012-10-16 15:29, Manu wrote: Well I've not tested mac, but I'll make the Linux build work tonight, and from that, you should be able to adapt it easily. Does OSX have X11 libs? Yes, Mac OS X has X11. What about alsa/pulse/oss, linux input? I presume OSX has it's own variants of each of these things. If there is no X11 libs for OSX, then you will need to knock up an MFDisplay_OSX.cpp for cocoa, which should be trivial (just create a window, then call into MFRenderer_OpenGL.cpp init, as the windows/X11 ones do). Infact, I'd really like to have a proper cocoa version anyway... ;) Yeah, a proper Cocoa version is always nice. Indeed, but does that involve .m files? :) You might also have problems with sound and input in osx, if they aren't using the same libraries as linux. Writing the backend drivers for new platforms is very easy, I've just never wanted to run on a mac. I don't suppose you might like to help me out making proper support for OSX? I'll be home on a couple of hours if we could take it offline then. There's probably 2-3 drivers that need to be written, and some tweaks to the typical C++ platform disambiguation nonsense at the top of Fuji.h. It depends on how much work it is, but I can have a look. I'll do it with you/do most of it myself, I just need someone to test it, and give me OSX advice.
Re: 48 hour game jam
On 16 October 2012 16:08, Jacob Carlborg d...@me.com wrote: On 2012-10-16 13:40, Manu wrote: Sure. I also backported the fixes into Fuji, and polished up the D bindings last night to work on Linux. Was gonna put a Linux build script in there, since most people here are linux users. We want a script for Mac OS X as well :) I replaced dist/bin/premake4 with a Mac OS X binary and I tried running stache/Fuji/create_project.**sh. this is the output I got: ... Building Fuji (release) Creating ../Build/Release/Fuji glew.c DebugMenu.cpp In file included from ../../dist/include/Fuji/Fuji.**h:356, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/**MFTypes.h:69: error: ‘ssize_t’ does not name a type In file included from ../../dist/include/Fuji/Fuji.**h:390, from ../Source/DebugMenu.cpp:1: ../../dist/include/Fuji/Util.**h: In function ‘void MFFixUp(T*, void*, int)’: ../../dist/include/Fuji/Util.**h:54: error: ‘intp’ was not declared in this scope ../../dist/include/Fuji/Util.**h:54: error: expected `;' before ‘offset’ ../../dist/include/Fuji/Util.**h:57: error: ‘offset’ was not declared in this scope ../../dist/include/Fuji/Util.**h:59: error: ‘offset’ was not declared in this scope make[1]: *** [../Build/Release/Fuji/**DebugMenu.o] Error 1 make: *** [Fuji] Error 2 Wanna jump on IRC, or some IM? googletalk?
Re: 48 hour game jam
On 2012-10-16 18:39, Manu wrote: Wanna jump on IRC, or some IM? googletalk? Sure, I'll be in the D IRC channel with the alias doob. -- /Jacob Carlborg
Re: 48 hour game jam
On 2012-10-16 17:19, Manu wrote: What about alsa/pulse/oss, linux input? I presume OSX has it's own variants of each of these things. Yes, it has it's own variants. Although I have no experience with these frameworks. Indeed, but does that involve .m files? :) Yes, it's possible do it in D as well. I see that Fuji is written in C++, so your choices are: Objective-C, D or Objective-C++. Objective-C++ is basically Objective-C and C++ in the same source file. But it's not possible to mix the object models, i.e. a C++ class cannot inherit from an Objective-C class, or the other way around. Here's an Objective-C - D bridge I've made, it has some documentation of how to interact with Objective-C from another language: http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals I'll do it with you/do most of it myself, I just need someone to test it, and give me OSX advice. Ok, I'll see. Then it shouldn't be any problems. -- /Jacob Carlborg
Re: 48 hour game jam
On 16 October 2012 20:13, Jacob Carlborg d...@me.com wrote: On 2012-10-16 18:39, Manu wrote: Wanna jump on IRC, or some IM? googletalk? Sure, I'll be in the D IRC channel with the alias doob. Cool, I'm idling in there.
Re: 48 hour game jam
I'm just going to throw it out there that you don't actually need to touch Objective-C at all. Cocoa/Foundation/all those Objective-C interfaces sit on top of something known as Core Foundation, which are C APIs. The pointers used by Core Foundation can generally be used as Objective-C objects of the same type as well. I don't actually have my Mac over from Australia yet to whip up some code examples, or even port Fuji myself. But needless to say this is the (free download) book I've been using as reference: http://www.pangeasoft.net/book/buy.html It would be handy to have a D binding to all the Core- libraries on OSX. I might do that myself when I get my Mac if such a binding doesn't already exist. The book should be equally applicable for iOS as well, but last time I was in iOS land I was still a newbie to the whole OSX programming thing.
Re: 48 hour game jam
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote: We did a 48hr game jam at work this past weekend. Now that's a hilarious game :) good job.
Re: 48 hour game jam
Ethan: but I have already come across a few things that make me think it's about 99% ready for production code instead of the full 100%. D has some rough edges still, and I think most of such rough edges are now known to D designers and the D community. Some of those edges will be fixed (some of them even have an already written patch in GitHub!), while some of them probably will not be fixed or will not be fixed soon, sometimes because there is no good way to fix them among the ecology of the other D features, or because D designers don't want to fix them (like some segfaults caused by nulls). I'll go in to more detail in another thread, Good. Reports from practical usage are usually interesting. but I did find it odd that D is a language that aims to make life easier for the programmer yet makes you jump through hoops at times. D design comes from people that have a long experience of C and C++ (and some experience of Java and a bit of experience of Python, and Perl). This means in D you find many details wisely designed. But another consequence is that several parts are also designed in a old style. Some parts of D design are surely far away from some new trends in language design. A lot of experience about older ways is both a blessing and a curse :-) Bye, bearophile
48 hour game jam
We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki
Re: 48 hour game jam
On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Martin
Re: 48 hour game jam
On 15 October 2012 16:18, Martin Drasar dra...@ics.muni.cz wrote: On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Ah, nicely spotted, I should stick that DLL in the zip now that you mention it. Controls are by gamepads (work in a console dev studio, no shortage of 360 pads! ;)
Re: 48 hour game jam
On 15 October 2012 17:02, bearophile bearophileh...@lycos.com wrote: Manu: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. And how did D do? Well actually. It was my team-mates first D code. He was interested, read some stuff, never actually wrote any code. We actually took quite tangible benefits from using D for this one. We actually used the class factory (!), I didn't think I'd ever use that ;) Also used a convenient C# style event system, trivial to implement in D. But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. That said, the code probably isn't particularly idiomatic D code. That's to be expected from new comers I suppose, bringing the conventions of their languages to the table, but it's also a great thing in terms of adoption potential, people can ween themselves in slowly. It's not an all or nothing switch.
Re: 48 hour game jam
On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote: But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is can't call this function with these arguments, and you have to go through and manually expand the templates in your head to see what went wrong. Not fun.
Re: 48 hour game jam
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)?
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 06:37:06PM +0200, Peter Alexander wrote:
On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote:
But mainly it's all the little things, conveniences that add up and
make the experience more enjoyable.
I find this as well.
D has a lot of neat and interesting features, but really the big
advantages over C++ (for me) are:
- No header files
- Closures
- Polymorphic lambdas
Yeah closures are a major necessity in any modern language. Recently
I've had to work with some code that was greatly simplified because I
could simply return closures. Writing the same code in C++ or C would
have required horrendously more code and complexity.
I also found std.algorithm and std.range to be incredibly powerful in
expressing common sequential operations in a concise way, often as
one-liners where in C++ you'd have to manually write a for/while loop
with manually-managed indices, increments, loop termination conditions,
etc..
Writing custom structs/classes to conform to the range API also makes it
possible to pass things around to library code that expect ranges,
greatly eliminating lots of boilerplate code that would be needed in C++
to transcribe from one object list to another and back, ad nauseum.
- Aliases
- Simple(r) templates
The biggest advantage of D templates is that the syntax is actually
sane!! When I was coding in C++, my eyes started to glaze over as soon
as templates get nested more than 2 levels deep. Especially when a
compiler error message contained a single template name that spanned 16
lines of output. Not fun.
The biggest problem with D at the moment for me is the quality of
error messages, especially when using templates with constraints. The
best error you'll get is can't call this function with these
arguments, and you have to go through and manually expand the
templates in your head to see what went wrong. Not fun.
[...]
I've asked before for a catch-all template, which is a template that
will be selected only if no other template is matched. This can then be
used in library code to print a nicer error message than the current
situation where the compiler basically talks to you in Klingon.
One alternative I've thought of (and tried before on one occasion) is
that instead of writing:
RetVal MyTemplateFunc(T)(T args...) if (Condition1) {...}
RetVal MyTemplateFunc(T)(T args...) if (Condition2) {...}
RetVal MyTemplateFunc(T)(T args...) if (Condition3) {...}
One could write:
RetVal MyTemplateFunc(T)(T args...)
{
static if (Condition1) { ... }
else static if (Condition2) { ... }
else static if (Condition3) { ... }
else static assert(0, NiceErrorMsgOnWhyConditionsDidNotMatch);
}
To be even more helpful, one could expand the static assert into a
block:
... else
{
pragma(msg, Template conditions failed:);
pragma(msg, Condition1 Clause1 = , Condition1_clause1);
pragma(msg, Condition1 Clause2 = , Condition1_clause2);
pragma(msg, Condition2 = , Condition2);
...
static assert(0);
}
Something like this is probably the compiler's job, but one could
present the info in a more human-understandable way, for example:
RetVal MyTemplateFunc(S,T)(S s, T t)
{
static if (isInputRange!S)
{
static if (isForwardRange!T)
...
else static assert(0, t must be forward range when s
is output range);
}
else static if (isForwardRange!S)
{
static if (isOutputRange!T)
...
else static assert(0, t must be output range when s is
forward range);
}
else ...
}
Of course, effort needs to be invested to write code in this way in the
first place. As a baseline, it's probably still better to have the
compiler print out exactly which conditions failed to match (by
recursively expanding templates for you). The output will be very
verbose, though.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: 48 hour game jam
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote: ... - Simple(r) templates I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. It was there in recent reddit discussions too. I am reading those comments (some posters obviously have some kind of agenda) and seeing no one refuting them. They neither know C++ well enough to do metaprogramming nor D. Because if they did know, they would never bring templates into any discussions which involves C++/D comparison. Comparing to C++. * D templates easier to use. * There are constructs you can't just do templates without. (templates without static if is c without if) * Some things possible (string/float/alias/... arguments) because there is no C++ way of doing these. * Some things possible in practice (there are things you can achieve with C++ templates but they are practically impossible) * You can have all these and able get higher performance. There are probably more of those i just can't remember now.
Re: 48 hour game jam
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote: On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote: But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is can't call this function with these arguments, and you have to go through and manually expand the templates in your head to see what went wrong. Not fun. For me: - aliases (Can't believe how Java and C# don't have them) - templates - meta-programming - open source language Sadly at work it is hard to sneak in D, because we mainly do JVM/.NET stuff, with C++ projects considered legacy(!). -- Paulo
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 07:19:42PM +0200, so wrote:
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote:
...
- Simple(r) templates
I keep seeing things like this and probably i am failing to understand
it. This is a vast understatement for D templates. Yes, easier to
use, i agree. But C++ templates are stone age comparing to D and i
don't see this mentioned enough where it matters most. [...]
[...]
One of the major advances of D templates over C++ is its potent
combination with other D features like aliases/enums, static if,
compile-time introspection, and signature constraints. For example,
consider this:
// This template checks if T satisfies certain properties, like
// having a .NodeType type, parseAtom and parsePrimary methods,
// etc.
template isExprType(T) {
static if (is(T.NodeType)
is(isNodeType!(T.NodeType)
is(T.parseAtom(Lexer.init))
is(T.parsePrimary(Lexer.init)) ...)
{
enum isExprType = true;
}
else
enum isExprType = false;
}
// This template checks that T is a valid node type. That is,
// the previous template uses this one to enforce T.NodeType
// being a type that satisfies certain properties.
template isNodeType(T) {
static if (is(T.precedence : int))
enum isNodeType = true;
else
enum isNodeType = false;
}
// By using the above template as a signature constraint, we're
// free to make use of properties we assumed about T, such as
// parametrizing the return type on .NodeType as defined in T
T.NodeType parseExpr(T)(Lexer lex)
if (isExprType!T)
{
...
// Or calling functions we verified to exist in T
auto node1 = T.parseAtom(lex);
auto node2 = T.parseAtom(lex);
...
// Or using properties of T.NodeType that we verified
// exists, even though the template itself is
// independent of how T.NodeType is even defined by T!
if (node1.precedence node2.precedence)
...
}
This is a ducktyping system where any type that satisfies isExprType
will work with parseExpr. This isn't just C++'s conform to conventions
described in the missing accompanying documentation or get 10 pages of
template errors. This is *compile-time* verification that any type T
you instantiate parseExpr with, conforms to the requirements defined by
isExprType. And furthermore, even T.NodeType itself has been checked to
have certain properties -- such as a .precedence property that is
convertible to int (which means it can be an actual int field, or a
@property function that returns an int, or something that returns an
object convertible to int, etc.).
This allows you to implement an expression parser that is completely
independent of the concrete types of the expression being parsed. AND
this is done without requiring 100 template parameters that specify
every configurable parameter: you just specify them in the type used to
instantiate parseExpr.
Better yet, if you designed the isExprType template correctly, you can
even have a derived class of an expression node that stores a value, and
specifies parsing functions that computes the value on the expression
on-the-fly. So instantiating parseExpr with the base class gives you an
expression tree, and instantiating it with the derived class computes
the value of the expression at parse-time. In the latter case, even the
return type is the correct derived class so you don't even need to
down-cast a base class reference to get at the value. (I actually have
code that does this. You cannot imagine the sense of power when code
like this can be written _cleanly_, without bending over backwards and
running a 100-meter dash with your left leg tied to your neck.)
Now try doing this in C++. It is in all likelihood plain impossible, or
so extremely painful that it's not worth the suffering to implement.
T
--
Lottery: tax on the stupid. -- Slashdotter
Re: 48 hour game jam
On Monday, 15 October 2012 at 16:46:38 UTC, F i L wrote: ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)? Well, the main reason for that is because I wrote a large chunk of the code. I didn't come across any area where final was needed because I kept the code heirarchy very shallow and relied on inheriting from multiple interfaces. So. I'm a D newbie. I've looked at this site before, but the only time I looked in to the language in any depth was last Thursday night when I read the introductory chapter of Andrei's D book. Turns out that the first chapter, combined with C++ and C# knowledge and sitting in earshot of Manu for when I had questions about how D works, was all I needed to write game logic from scratch. Straight up, I'm fairly impressed with the language. I've been moaning for years that there aren't any system level/performance oriented languages coming out with all of the nice things found in programming languages created in the 30-odd years since C++ was unleashed upon the world. The code I wrote was definitely more inspired by C# than C++, but I didn't really want to go in to the jam trying to write C# code in another language. I tried to do things in a more D like way. I think I succeeded in some areas - such as the one line creation table where we used to use an entire 1000+ line file back in the PS2 days - but towards the end I definitely started falling back in to more C++ style coding just to get stuff in the game and working. I'll definitely be looking more in-depth in to D, but I have already come across a few things that make me think it's about 99% ready for production code instead of the full 100%. I'll go in to more detail in another thread, but I did find it odd that D is a language that aims to make life easier for the programmer yet makes you jump through hoops at times. I'll be pretty happy to leave C++ behind when D2 is rock solid.
Re: 48 hour game jam
On Monday, 15 October 2012 at 17:19:43 UTC, so wrote: On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote: ... - Simple(r) templates I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. snip I'm going to start a bit of a rant now. D templates are certainly powerful, and are inarguably an improvement over C++ templates, but they are still based on C++ templates, and inherit a lot of their fundamental problems. The main problem is the whole duck typing thing. Duck typing is the cause of all the horrible error messages in C++ templates, and D carried it over. Consider this: auto s = chain(a,b,c,, d,e,f).splitter(,); Seems like a reasonable thing to do, but you get an error: std/algorithm.d(2020): Error: undefined identifier 'length' ... similar errors from inside std.algorithm ... What am I supposed to make of that? D attempts to mitigate this by adding template constraints, but this just makes the error messages shorter, not more useful. Here's another example, this time trying to instantiate a constrained template: bool b = filter!(not!isPunctuation)(Hello, world!).endsWith(world); Again, seems reasonable. I want to remove all the punctuation from a string and then test if it ends with the word world. Again, I get an error: Error: template std.algorithm.endsWith does not match any function template declaration std/algorithm.d(4375): Error: template std.algorithm.endsWith cannot deduce template function from argument types !()(FilterResult!(not,string),string) This error message is no more useful than saying you can't do that. Why doesn't any function match? Why can't it deduce the template parameters? I don't believe there's any easy way to solve these problems with the current template design. You really need something like concepts or typeclasses to get quality errors. These aren't things that are easily tacked on. So yeah, D's templates are better than C++'s, but they're still templates.
Re: 48 hour game jam
On 15 October 2012 19:46, F i L witte2...@gmail.com wrote: On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/**RemedyGameJam/stache/wikihttps://github.com/RemedyGameJam/stache/wiki Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)? This game doesn't exactly raise the bar in terms of computational requirements ;) Also, it's quite a lot of game to write in 48 hours, we didn't have time to worry about things like that. And also, to some extent, we wanted to do it in a pure D way (ie, a way I wouldn't usually write code), mainly as an exercise, to test the productivity potential of D without worrying about all the stuff I normally waste time with.
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote: [...] I'm going to start a bit of a rant now. D templates are certainly powerful, and are inarguably an improvement over C++ templates, but they are still based on C++ templates, and inherit a lot of their fundamental problems. The main problem is the whole duck typing thing. Duck typing is the cause of all the horrible error messages in C++ templates, and D carried it over. Consider this: auto s = chain(a,b,c,, d,e,f).splitter(,); Seems like a reasonable thing to do, but you get an error: std/algorithm.d(2020): Error: undefined identifier 'length' ... similar errors from inside std.algorithm ... This looks like a bug. There should be signature constraints to test for the existence of .length before attempting to use it. What am I supposed to make of that? D attempts to mitigate this by adding template constraints, but this just makes the error messages shorter, not more useful. Here's another example, this time trying to instantiate a constrained template: bool b = filter!(not!isPunctuation)(Hello, world!).endsWith(world); Again, seems reasonable. I want to remove all the punctuation from a string and then test if it ends with the word world. Again, I get an error: Error: template std.algorithm.endsWith does not match any function template declaration std/algorithm.d(4375): Error: template std.algorithm.endsWith cannot deduce template function from argument types !()(FilterResult!(not,string),string) I agree that this error message is stupid. I've found myself having to insert pragma(msg,...)'s into my code just to see what exactly were the types that failed to match the template constraints. But to me, this is more of an implementational issue with the current dmd than a weakness of the language itself. If the templates were well-designed in the first place, the signature constraints ought to look something like: auto endsWith(R,S)(R range, S endswiththis) if (isInputRange!R isForwardRange!S ...) Now, if the compiler would just say something along the lines of: template std.algorithm.endsWith does not match arguments: FilterResult!(blahblah) fails constraints: isForwardRange, isInputRange, (or whatever) That would be much better. The constraint names themselves will already have told you what was wrong (assuming their names were well-chosen in the first place -- which I submit is a reasonable expectation, given that Phobos is the *standard* library). This error message is no more useful than saying you can't do that. Why doesn't any function match? Why can't it deduce the template parameters? I don't believe there's any easy way to solve these problems with the current template design. You really need something like concepts or typeclasses to get quality errors. These aren't things that are easily tacked on. [...] To me, the current template design already models concepts/typeclasses. Things like isInputRange, isForwardRange, etc., are self-documenting, and they describe concepts and type classes -- if the compiler would only _use_ them in the error message instead of the current encrypted Klingon. I chalk it up to a dmd enhancement request. T -- Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say Gosh! / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker
Re: 48 hour game jam
On Monday, 15 October 2012 at 17:58:13 UTC, H. S. Teoh wrote: Now try doing this in C++. It is in all likelihood plain impossible, or so extremely painful that it's not worth the suffering to implement. T Having read some Lisp recently, i was so lucky it was not my first language. It would have been a very frustrating experience having to adopt other languages, required to write code in them. I don't have experience on it and don't know how it scales with bigger projects but as someone who sees the importance of metaprogramming in D/C++, it is disturbing when you find out it was a 50 years old concept.
Re: 48 hour game jam
On Monday, 15 October 2012 at 19:52:44 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote: std/algorithm.d(2020): Error: undefined identifier 'length' ... similar errors from inside std.algorithm ... This looks like a bug. There should be signature constraints to test for the existence of .length before attempting to use it. It is, I've already created a pull request for it. Problem is, there's many more where that came from. And even if you fix everything in the standard library, you then have to worry about all the 3rd party libraries out there with inadequate constraints. Now, if the compiler would just say something along the lines of: template std.algorithm.endsWith does not match arguments: FilterResult!(blahblah) fails constraints: isForwardRange, isInputRange, (or whatever) That would be much better. The constraint names themselves will already have told you what was wrong (assuming their names were well-chosen in the first place -- which I submit is a reasonable expectation, given that Phobos is the *standard* library). It's not that simple. First, there are often multiple overloads, so you not only have to show why one overload failed, you have to show why all of them failed. Second, not all constraints are simply (isX isY isZ). They often contain things like complex is-expression and allSatisfy etc. Third, telling me that FilterResult failed a constraint isn't particularly enlightening either. Why isn't FilterResult a forward range (or whatever)? I didn't write it. I have to now go and look at the source of both isForwardRange and FilterResult to figure out where the mismatch is (compare this to, for example, just checking that a class implements an interface). To me, the current template design already models concepts/typeclasses. Things like isInputRange, isForwardRange, etc., are self-documenting, and they describe concepts and type classes -- if the compiler would only _use_ them in the error message instead of the current encrypted Klingon. I chalk it up to a dmd enhancement request. This is a sufficiently smart compiler argument. Template constraints have been around for a long time, and the situation hasn't improved. To me, that's a hint that providing good error messages is a difficult task (like implementing export in C++). A simpler language design would enable a quicker and more robust implementation.
Re: 48 hour game jam
On Monday, 15 October 2012 at 19:18:34 UTC, Peter Alexander wrote: I'm going to start a bit of a rant now. ... On this one, i agree everything you say. D templates inherit quite a bit of errors. I have problem with the attitude of some people (not necessarily you). As they say D templates are just better because of things like syntax, other than that you could pretty much do everything you can do with C++ templates (you simply can't). And they just get away with this. For me it just shows how little they know about C++ or D.
Re: 48 hour game jam
On Monday, 15 October 2012 at 20:33:36 UTC, so wrote: On Monday, 15 October 2012 at 19:18:34 UTC, Peter Alexander wrote: I'm going to start a bit of a rant now. ... On this one, i agree everything you say. D templates inherit quite a bit of errors. I have problem with the attitude of some people (not necessarily you). As they say D templates are just better because of things like syntax, other than that you could pretty much do everything you can do with C++ templates (you simply can't). And they just get away with this. For me it just shows how little they know about C++ or D. Many people use C++ as better C. I was amazed to hear that are companies that forbid templates or STL code on the videos from Going Native conference organized by Microsoft. -- Paulo
Re: 48 hour game jam
On Monday, 15 October 2012 at 20:20:28 UTC, so wrote: On Monday, 15 October 2012 at 17:58:13 UTC, H. S. Teoh wrote: Now try doing this in C++. It is in all likelihood plain impossible, or so extremely painful that it's not worth the suffering to implement. T Having read some Lisp recently, i was so lucky it was not my first language. It would have been a very frustrating experience having to adopt other languages, required to write code in them. I don't have experience on it and don't know how it scales with bigger projects but as someone who sees the importance of metaprogramming in D/C++, it is disturbing when you find out it was a 50 years old concept. Now imagine those that have experimented how powerful Lisp and Smalltalk based OS were. It is so sad to see IDE makers still trying to replicate the experience from those environments. -- Paulo
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 10:40:12PM +0200, Paulo Pinto wrote: On Monday, 15 October 2012 at 20:33:36 UTC, so wrote: [...] I have problem with the attitude of some people (not necessarily you). As they say D templates are just better because of things like syntax, other than that you could pretty much do everything you can do with C++ templates (you simply can't). And they just get away with this. For me it just shows how little they know about C++ or D. Many people use C++ as better C. I did, even while knowing C++ has OO constructs like classes, polymorphism, etc.. The fact of the matter is, OO programming in C++ is a pain, because C++'s OO wasn't very well designed. It did get the basics right, mind you, but not much beyond that. There are just so many loopholes and flaws that trying to do _real_ OO design in C++ is an exercise in frustration. I've found that using C++ as C with classes is a much less painful experience than trying to do real OO in C++. For that, I'd recommend Java instead (even though I'm by no means a Java fan). (I do use polymorphism, etc., in C++ code, but only barely, in limited situations. I don't even dare to go near multiple inheritance with a sterilized 15-foot pole. Java had the right idea with interfaces, something that I'm glad D picked up.) I was amazed to hear that are companies that forbid templates or STL code on the videos from Going Native conference organized by Microsoft. [...] I can totally understand why, even though I don't agree with the reasons. I've seen C++ gone wrong, horribly horribly wrong, as a result of over-engineering a system that became unmaintainably complex (and should I say, unnecessarily so -- it was a case of premature generalization taken to the extremes). Templates, and by extension STL, are perceived by many as one of those unnecessarily complicated features of C++, which lets careless programmers write hopelessly complex and unmaintainable code, so I can totally see PTBs prohibiting it. I mean, even C++ code written to *be* maintainable often *looks* unmaintainable due to the horrible template syntax, among other things. It's the kind of stuff that drives PTBs to ban C++ outright. (I don't agree with the assessment of templates, of course, but I can understand the sentiment.) If you think forbidding templates/STL is crazy, wait till you hear about the people who insist that const is evil and ban it from their codebase. (That was from before C++11, though, I don't know what their reaction would be now that key parts of the language _require_ const. Maybe they've migrated to VB or something. :-P) T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Re: 48 hour game jam
On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote: If you think forbidding templates/STL is crazy, wait till you hear about the people who insist that const is evil and ban it from their codebase. (That was from before C++11, though, I don't know what their reaction would be now that key parts of the language _require_ const. Maybe they've migrated to VB or something. :-P) T I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too.
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 11:52:19PM +0200, so wrote: On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote: If you think forbidding templates/STL is crazy, wait till you hear about the people who insist that const is evil and ban it from their codebase. (That was from before C++11, though, I don't know what their reaction would be now that key parts of the language _require_ const. Maybe they've migrated to VB or something. :-P) T I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too. [...] I dunno, maybe they like struct names being specifiable without the struct keyword (I always find that awkward when switching back to C after dealing with C++ code). :-P It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article Giving it all away
Re: 48 hour game jam
On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 11:52:19PM +0200, so wrote: On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote: If you think forbidding templates/STL is crazy, wait till you hear about the people who insist that const is evil and ban it from their codebase. (That was from before C++11, though, I don't know what their reaction would be now that key parts of the language _require_ const. Maybe they've migrated to VB or something. :-P) T I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too. [...] I dunno, maybe they like struct names being specifiable without the struct keyword (I always find that awkward when switching back to C after dealing with C++ code). :-P It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) T You should talk with the Go guys which seem to be happy re-inventing the type of tools we used in C++, back in the days templates were still not available, somewhere around 1993 in my case. Does anyone remember the pre-processor hacks from Borland C++? -- Paulo
Re: 48 hour game jam
On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote: On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote: [...] It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) [...] You should talk with the Go guys which seem to be happy re-inventing the type of tools we used in C++, back in the days templates were still not available, somewhere around 1993 in my case. On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-) Does anyone remember the pre-processor hacks from Borland C++? [...] I remember Borland C++, yes... but I don't recall what preprocessor hacks were there. T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Re: 48 hour game jam
On 16 October 2012 01:47, H. S. Teoh hst...@quickfur.ath.cx wrote: On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote: On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote: [...] It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) [...] You should talk with the Go guys which seem to be happy re-inventing the type of tools we used in C++, back in the days templates were still not available, somewhere around 1993 in my case. On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-) Does anyone remember the pre-processor hacks from Borland C++? [...] I remember Borland C++, yes... but I don't recall what preprocessor hacks were there. Possibly one of the most epic thread hijack's I've seen in a while! ;)
Re: 48 hour game jam
On Monday, 15 October 2012 at 20:41:55 UTC, Paulo Pinto wrote: Now imagine those that have experimented how powerful Lisp and Smalltalk based OS were. It is so sad to see IDE makers still trying to replicate the experience from those environments. -- Paulo Thanks for mentioning that, checked lisp os and next thing was www.loper-os.org/?p=69. It might be offensive to some people but reading his posts/rants now, i kind of like what he says. This is what i was talking about when i say that i feel lucky because Lisp was not my first language. Looks like he experienced the language devolutions and very (rightly so) frustrated. An example: You will not find a “Thumbs Down for Python” essay in this blog, because Python users make no attempt to peddle their crock of shit as “the future of Lisp.” I have no quarrel with users of Python, Ruby, Dylan, and other shoddy “infix Lisps.” Because they are honest. It is the lying of Clojure users which upsets me, and their deliberate attempts to rewrite history, to make people forget that truly-interactive, advanced Lisp systems once existed
