Kernel in D
So, I've gotten interested in kernel programming in D.. And as much as I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any OS-specific issues are going to be a problem, but I'm willing to implement them into the kernel itself. So, I guess what I'm asking is this: What should I look out for, what should I avoid, and what should I use to my advantage? I'm not expecting this kernel to be Linux right off the bat, but I would like to see how far D can go with this. Any ideas? :P
Re: Parallel thread safety (fun fun)
On Saturday, 1 February 2014 at 19:26:03 UTC, TheFlyingFiddle
wrote:
On Friday, 31 January 2014 at 21:33:50 UTC, Mineko wrote:
So, I'm implementing some parallelism in my engine (maybe some
concurrency where appropriate later), and I'm having some
issues with thread safety, and synchronize ain't cutting it.
What I figure is that if I can get the IO class working within
a parallel thread then everything else should fall in place,
so, I need some help making the IO class thread-safe. (I'm new
to thread safety btw, like, yesterday new _)
Relevent file here:
https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/io.d
Feel free to drop any other suggestions on what to do with
that class if you want, always appreciated. :)
First of all you are using the synchronized statement
incorrecly.
synchronized bool addTime; -- This does absolutely nothing.
I am supprised this code is allowed.
You can only use synchronized on class methods
http://dlang.org/class.html#synchronized-functions or on an
abitrary
block of code
http://dlang.org/statement.html#SynchronizedStatement
If you want to synchronize access to data you will have to
either make them shared and use synchronized/atomic operations
on them or synchronize the use yourself. This is a quite
complex and bugprone activity and if your just getting started
i would not reccomend it. There is a simpler / better way that
i will describe later.
Secondly the only use of concurency that i see in the IO class
is the attempt to write to a file from multiple threads. In the
write() method. This is not a good idea. Firstly you will not
be able to write any faster to the file since it's IO bound in
any case. The only effect if any is that you will use more
resources and that the output will appear in the file in random
order. (Probably not what you want)
I would reccomend using message passing instead of even
attempting to synchronize things. This is ALOT simpler and if
your goal is to offload IO to another thread it's the way to go
IMHO.
Here is a very simple logging application that writes to a file
using std.concurrency through message passing. To make things
simple it can only log messages from the thread that started
it. This would probably be the main thread in a game.
module main;
import logger;
void main()
{
startLoggerThread(log.txt);
log(Hello);
log(World);
stopLoggerThread();
}
//logger.d
module logger;
import std.concurrency;
import std.file;
//This is a unique identifier for a thread.
Tid loggerTid;
//Starts the logger thread.
//(This must be done before any logging can take place.)
void startLoggerThread(string logFile)
{
loggerTid = spawn(loggerEntry, logFile);
}
//Stops the logger thread.
void stopLoggerThread()
{
send(loggerTid, Shutdown());
}
//Called by the thread that started the logger.
void log(string msg)
{
//Send the message to log to the logger thread
//identified by the loggerTid.
send(loggerTid, msg);
}
//A tag struct symbolising the message shutdown.
struct Shutdown { }
void loggerEntry(string logFile)
{
bool running = true;
//Recevie logging requests until stopLoggerThread is called.
while(running)
{
receive(
//We get a message here when log is called.
(string msg)
{
//Create file if it does not already exists
//otherwise append to it.
if(!exists(logFile))
write(logFile, msg ~ \n);
else
append(logFile, msg ~ \n);
},
//If we get this message we stop the logger thread.
(Shutdown _)
{
running = false;
});
}
}
The example works by first creating a logging thread. This
thread then listens to logging requests from the main thread.
And logs all messages it receives.
I would reccomend reading the TDPL chapter on concurrency if
you want to learn more.
//Hope this was all helpful
Yes it was, this was more or less what I was looking for,
especially about the synchronization part, thank you.
Parallel thread safety (fun fun)
So, I'm implementing some parallelism in my engine (maybe some concurrency where appropriate later), and I'm having some issues with thread safety, and synchronize ain't cutting it. What I figure is that if I can get the IO class working within a parallel thread then everything else should fall in place, so, I need some help making the IO class thread-safe. (I'm new to thread safety btw, like, yesterday new _) Relevent file here: https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/io.d Feel free to drop any other suggestions on what to do with that class if you want, always appreciated. :)
I don't even..
I'm completely lost on this one, here's the error message: Core plugin failed to compile: res/plugins/shared/shared.d(31): Error: Identifier expected following package res/plugins/shared/api.d(31): Error: Identifier expected following package res/plugins/core/settings.d(57): Error: identifier expected following package res/plugins/core/settings.d(57): Error: ';' expected res/plugins/core/settings.d(57): Error: identifier expected following '.' instead of 'shared' res/plugins/core/settings.d(57): Error: no identifier for declarator res/plugins/core/settings.d(57): Error: semicolon expected, not 'shared' res/plugins/core/settings.d(57): Error: no identifier for declarator Base Relevant files are here: https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d https://github.com/MinekoRox/Breaker-Engine/tree/master/res/plugins Sorry for being so vague, but as the title says.. I don't even..
Re: I don't even..
On Friday, 31 January 2014 at 02:26:51 UTC, Adam D. Ruppe wrote: On Friday, 31 January 2014 at 02:15:08 UTC, Mineko wrote: I'm completely lost on this one, here's the error message: I think it is because shared is a keyword in D, so your module name module whatever.shared.shared; is triggering the problem. If you rename the package and modules from sharedto something else you should be ok. (You don't necessarily have to change the filename, just the module declaration and any imports of it. But it is probably easier to rename the file and folder too.) Had a feeling.. Alright, thanks.
Linux dll struct class etc
I can't remember whether or not I've asked this.. But either way, is it possible to export a class or a struct or something like you do with a windows dll with a linux shared library (dll)?
Re: Linux dll - Windows dll
Ok thank both of you, looks like I really will have to wait on Windows DLL's.
Good ol' OpenGL D-C interfacing. :(
Alright.. For the record, I've been searching on how to fix this for 2 hours now, so yeah. Anyway, here's the issue, and it's probably half OpenGL being well.. OpenGL, and the other half being D-C interfacing. Point is, I'm trying to draw a triangle with a custom Triangle class I made, and I'm having issues, relevant code is here: https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/scene.d https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/graphics/primitives.d https://github.com/MinekoRox/Breaker-Engine/blob/master/res/shaders/testShader.glsl I assume this is probably me messing up with arrays and sizing, but I've done what I can as far as that goes so.. Maybe one of you know what to do.
Re: Good ol' OpenGL D-C interfacing. :(
On Sunday, 26 January 2014 at 02:39:29 UTC, Rikki Cattermole wrote: On Saturday, 25 January 2014 at 23:28:07 UTC, Mineko wrote: Alright.. For the record, I've been searching on how to fix this for 2 hours now, so yeah. Anyway, here's the issue, and it's probably half OpenGL being well.. OpenGL, and the other half being D-C interfacing. Point is, I'm trying to draw a triangle with a custom Triangle class I made, and I'm having issues, relevant code is here: https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/scene.d https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/graphics/primitives.d https://github.com/MinekoRox/Breaker-Engine/blob/master/res/shaders/testShader.glsl I assume this is probably me messing up with arrays and sizing, but I've done what I can as far as that goes so.. Maybe one of you know what to do. Try breaking it down into a single module. Basically on render call your file's function that you handle drawing of said triangle. Relying on as little as possible on other code. That way you should be able to use existing examples and tutorials straight. This is what really helped me with DOOGLE and working it out. I have an example for it if you want to check it out. From the module you'll have than you can start abstracting out and testing your own code base. I see what you're saying, and that's more or less what I've been doing, I'm asking what opengl function did I mess up to cause it not to render, because I've checked it over and over again.
Re: Good ol' OpenGL D-C interfacing. :(
On Sunday, 26 January 2014 at 03:39:37 UTC, TheFlyingFiddle wrote: On Saturday, 25 January 2014 at 23:28:07 UTC, Mineko wrote: Alright.. For the record, I've been searching on how to fix this for 2 hours now, so yeah. Anyway, here's the issue, and it's probably half OpenGL being well.. OpenGL, and the other half being D-C interfacing. Point is, I'm trying to draw a triangle with a custom Triangle class I made, and I'm having issues, relevant code is here: https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/scene.d https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/graphics/primitives.d https://github.com/MinekoRox/Breaker-Engine/blob/master/res/shaders/testShader.glsl I assume this is probably me messing up with arrays and sizing, but I've done what I can as far as that goes so.. Maybe one of you know what to do. Your init and finalize methods in primitives.d does not work. You need to send the vao, points_vbo and colors_vbo by ref. Thank you, that was exactly the problem.
Linux dll - Windows dll
Alright.. I've been having issues with getting windows DLL's to work with DMD, as in I can't make them and can't even compile without a bunch of errors. So, I need help on that, as the dll part of the site ain't helping. Also, any idea on how to convert some of the dll stuff on https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d to be windows compatible, I was having weird issues with that also.
Re: Shared objects aka dynamic libraries
On Tuesday, 21 January 2014 at 14:19:51 UTC, Russel Winder wrote: I appear to be unable to use Google the last couple of days :-( so I admit defeat, expose my current ignorance, hopefully to quickly become enlightened. Is it possible to easily with DMD, LDC and/or GDC create shared objects aka dynamic libraries from a D code base? Currently for me DMD and LDC refuse to accept the existence of a -shared flag, and GDC always fails with some deeply incomprehensible messages about not finding _tls.* functions. There should be a page better than http://dlang.org/dll-linux.html I'm making a game engine using shared objects as scripts, take a look at https://github.com/ICGCC/Breaker-Engine You should also check out my fork, which is a little more recent. Point in case, look at src/breaker/util/core.d and you'll see what you need to do. Oh, than and shared objects only REALLY work with DMD and linux atm, windows is dodgy, and I've tested it.
Shared library ld issue?
So, these are the commands I put in: ../gdc/x86_64/gdc -c -fPIC -B ../gdc/x86_64 -I ../gdc/x86_64/phobos test.d This one worked fine, as expected. The problem is here: ../gdc/x86_64/gdc -lgphobos2 -shared -B ../gdc/x86_64 test.o -o test.so And this is what the problem outputs: ld: /lib/../lib64/libgphobos2.a(minfo.o): relocation R_X86_64_32 against `_D32TypeInfo_APxS6object10ModuleInfo6__initZ' can not be used when making a shared object; recompile with -fPIC /lib/../lib64/libgphobos2.a: error adding symbols: Bad value I'm obviously compiling with -fPIC. I've been googling this for hours straight and still don't know what to do, perhaps someone here could impart on me some knowledge?
Multiple while-loops parallelism
Today I'm asking a more theoretical question, since I can't quite grasp this one too well. Let's say I want 3 while-loops running in parallel, without getting in the way of each other, how would I do that? With std.parallel of course, but that's where I get confused, perhaps someone could enlighten me?
Shared library string safety?
Alright, so I FINALLY got shared libraries somewhat working through my program, however I have some issues transferring data between the shared library and the main program, the problem is between https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/settings.d and https://github.com/MinekoRox/Breaker-Engine/blob/master/res/scripts/core/settings.d The settings script is loaded by https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d And, this is the error I get: +start(string[]) Starting up the program 800600 B Shutting off the program Writing logs to disk ERROR: Error(s) occured, check the error log -start(string[]) +stop() Segmentation fault (core dumped) The 800600 is width and height, the problem is the binary output of what's supposed to be a string.
Re: Shared library string safety?
Sorry for the double post, I should be more specific. .dup worked, I don't know how to have the GC proxy for shared libs though.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 06:40:52 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 05:50:37 UTC, Mineko wrote: Alright, so I FINALLY got shared libraries somewhat working through my program, however I have some issues transferring data between the shared library and the main program, the problem is between https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/settings.d and https://github.com/MinekoRox/Breaker-Engine/blob/master/res/scripts/core/settings.d The settings script is loaded by https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d And, this is the error I get: +start(string[]) Starting up the program 800600 B Shutting off the program Writing logs to disk ERROR: Error(s) occured, check the error log -start(string[]) +stop() Segmentation fault (core dumped) The 800600 is width and height, the problem is the binary output of what's supposed to be a string. are you set your gc proxies for shared libs, right? if not, i think it would be safer to do string.dup(as with other arrays) when moving them between shared lib boundaries. but still keep in mind that current GC may not handle properly multiple intances. p.s. i don't do shared libs for non-Windows platform for a long time now, so it may be outdated info for now... Wow, um, that actually worked, thank you.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 07:23:52 UTC, evilrat wrote:
the reason string.dup worked is due to GC on app side, right
after the moment your lib receive the original string it is may
be marked by GC for collection, so you need to save a copy on
lib side. but using the proxies it should work without copying.
for windows here is the topic about this
http://dlang.org/dll.html
for *nix platforms it should be the same.
in short(pseudocode):
==
app.d
extern(C) void* gc_getProxy();
void main()
{
loadlib();
initLib( gc_getProxy() );
... do something ...
libFinalize();
}
--
lib.d
extern (C)
{
void gc_setProxy(void* p);
void gc_clrProxy();
}
export void initLib(void* gc)
{
gc_setProxy(gc);
}
export void libFinalize()
{
gc_clrProxy();
}
==
as i said i don't know about current status of shared libs, but
there was some progress on linux and Windows, and
unfortunatelly not OS X...
I see, I'll have to look more into that, on a slightly unrelated
note, any idea what's going on with glfwCreateWindow, it keeps
wanting to be null while it's supposed to be an adddress.
this.get = glfwCreateWindow(settings.width, settings.height,
toStringz(settings.title), this.monitor, this.share);
writeln(this.get);
That writeln will give me null, is it related to all this stuff?
Shared library extern (C) variables
I keep getting mixed results searching for this. :\ Just as the title says, is it safe to extern (C) variables? Something like this: extern (C) auto foo = 800; And then call that from another program? Also, just because this has been bugging me for a while.. Is export broken, or it it not supposed to be used the same way as extern (C)?
Re: Shared library extern (C) variables
On Sunday, 5 January 2014 at 19:08:44 UTC, Jeremy DeHaan wrote:
On Sunday, 5 January 2014 at 18:22:54 UTC, Mineko wrote:
I keep getting mixed results searching for this. :\
Just as the title says, is it safe to extern (C) variables?
Something like this:
extern (C) auto foo = 800;
And then call that from another program?
Also, just because this has been bugging me for a while.. Is
export broken, or it it not supposed to be used the same way
as extern (C)?
I wouldn't do it that way. I would use extern(C) with struct
and function definitions/declarations, but I don't think it
makes sense to use it with individual variables.
Not sure if anything is wrong with export, but they are two
different things. Export allows something to be visible to
other programs(like in a shared library) and extern is(I
believe) more so for specifying how something outside the
program is meant to be linked in.
My program is a shared library, and it uses extern (C) to let
other programs access the extern (C)'d functions and such.
Could you give me a definition of export, as I believe I may have
the wrong meaning and use of it.
The reason being, is that I did some test with something like
this:
export int test(string[] args)
{
return 0;
}
and the program trying to find it couldn't, I suppose that's
where I went wrong?
Back the main topic, thank you, I wanted to use it for variables,
but if it's not safe I'll use getters and setters, or maybe ref
or something. The reason I wanted to is because I'm using it as a
sort of settings.
Re: Shared library extern (C) variables
On Sunday, 5 January 2014 at 19:47:46 UTC, FreeSlave wrote:
Some code snippets of what you try to do would help.
Maybe this example explain you something:
//mod.d
extern(C) int foo = 42;
void changeFoo(int val)
{
foo = val;
}
//main.d
import std.stdio;
import mod;
int main()
{
writeln(foo);
changeFoo(15);
writeln(foo);
return 0;
}
Compile:
dmd -H -c mod.d //to generate .di file (not required)
dmd -shared mod.d -oflibmod.so //to generate shared library
dmd -L-L. -L-lmod -L-rpath=. main.d //rpath is special argument
to linker, so executable will able to find shared library in
its directory. You can omit rpath, but then you must put your
.so file to one of standard directory like /usr/lib or
/usr/local/lib. That's all for Linux. On Windows you would have
different building steps.
Also probably you want to make your varialbe __gshared, so it
will not be thread-local. That's default D behavior to make all
global variables thread-local. And I don't know how other
languages will handle D thread-local variable.
Ahh I appreciate it, but I already have that part down and good.
:)
I was wondering about how to use export correctly, I apologize
for not being clear.
Also I'll keep in mind the __gshared, never even knew about it.
External modules
This is another short one, is it possible to export/extern (C) an
entire module, is it safe?
Also, how do you import said module, this one I don't quite get.
So, something like this:
dll.d:
extern (C) module test;
int foo() {...}
-
main.d
int main(string[] args)
{
...
(dl loading code for dll.so)
module dll = dlsym(lh, test);
...
}
So, aside from the crappy abstraction, something like that?
Re: External modules
On Friday, 3 January 2014 at 13:03:50 UTC, Jacob Carlborg wrote:
On 2014-01-03 14:00, Mineko wrote:
This is another short one, is it possible to export/extern (C)
an entire
module, is it safe?
Also, how do you import said module, this one I don't quite
get.
So, something like this:
dll.d:
extern (C) module test;
int foo() {...}
-
main.d
int main(string[] args)
{
...
(dl loading code for dll.so)
module dll = dlsym(lh, test);
...
}
So, aside from the crappy abstraction, something like that?
You can't import the whole module. You would need to use
dlsym on each symbol you're interested in.
Thank you.
Dub shared library issue
So, I can get a shared library compiled normally (Assuming it's already compiled first with -shared -fPIC etc) with: dmd -of'Breaker Engine.so' 'Breaker Engine.o' -shared -defaultlib=libphobos2.so -L-rpath=$PWD However, for some reason dub is having issues whenever I try to compile it as a shared library with dynamicLibrary. Any suggestions? I'd like to get this fixed because otherwise there's gonna be portability problems..
Re: Dub shared library issue
On Friday, 3 January 2014 at 15:03:27 UTC, Mathias LANG wrote:
On Friday, 3 January 2014 at 15:01:16 UTC, Mineko wrote:
So, I can get a shared library compiled normally (Assuming
it's already compiled first with -shared -fPIC etc) with: dmd
-of'Breaker Engine.so' 'Breaker Engine.o' -shared
-defaultlib=libphobos2.so -L-rpath=$PWD
However, for some reason dub is having issues whenever I try
to compile it as a shared library with dynamicLibrary.
Any suggestions? I'd like to get this fixed because otherwise
there's gonna be portability problems..
Could you provide some error message / output, and your
package.json ?
Sure, I thought I was missing some info..
Linking...
dmd
-of.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/libbreaker.so
.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/breaker.o
-L-ldl -shared -g
/usr/bin/ld: /usr/lib/libphobos2.a(object__a_58c.o): relocation
R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/libphobos2.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
{
name: breaker-engine,
description: A multi-dimensional engine with a stupid
amount of modularity,
homepage: https://github.com/ICGCC/Breaker-Engine;,
license: Zlib,
author: Jakob Austin Wimberly (Mineko),
targetName: breaker,
targetPath: lib,
targetType: dynamicLibrary,
dependencies:
{
gl3n: ~master,
derelict-gl3: ~master,
derelict-glfw3: ~master,
derelict-fi: ~master
}
}
Re: Dub shared library issue
libs: [ phobos2 ] worked perfectly, thank you so much. :)
Linux DLL
So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror.
Re: Linux DLL
On Friday, 3 January 2014 at 20:34:17 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 20:31:09 UTC, Mineko wrote: So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror. It says on top Preliminary and subject to change., although that might have just been put in. Oh, thank you, can't believe I missed that.. Other than that, are there any better ways of doing the aforementioned?
Re: Linux DLL
Thank you Jeroen, Dicebot's post was EXTREMELY helpful, and was more or less what I was looking for! :D
Re: DDOC- how to customize
On Tuesday, 31 December 2013 at 22:58:04 UTC, Jonathan M Davis wrote: On Tuesday, December 31, 2013 12:33:06 Charles Hixson wrote: In ddoc, if there is a way, how could I make, say, class names in the generated documentation be blue? Here I only want to change class and struct titles, and possibly enums; I'd also like to make functions be, say, green. (FWIW, I don't want to change the documentation text, only the titles.) http://stackoverflow.com/questions/18672679/richer-coloring-and-typesetting-in-ddoc-output - Jonathan M Davis I don't believe there's any parameters for that, you might wanna use ddox or customize ddoc's source code.
Re: Shared library ld issue?
I also get another strange error I can't solve, whenever I compile something with GDC without the standard library (-nostdlib) I get this whenever I try to access the shared library. (like the above but without libgphobos, with nostdlib instead) undefined symbol: _Dmodule_ref Any ideas?
Re: Shared library ld issue?
On Sunday, 29 December 2013 at 16:06:51 UTC, Dicebot wrote: AFAIK shared libraries are not yet supported by GDC / LDC, at least not as supported as in DMD. Thank you, at least now I know I mainly wasted my time, and can now move on to other ideas. Although I got some interesting stuff working with GDC for the most part, but yeah, as you say, it's not nearly as supported as DMD.
Re: GDC GCC backend
On Tuesday, 24 December 2013 at 08:24:09 UTC, Johannes Pfau wrote: Am Mon, 23 Dec 2013 06:20:51 + schrieb Mineko umineko...@gmail.com: This one's kinda short.. Is it possible to change the variable that gdc finds cc1d? Something like gdc -gcc=/whatever/gcc_backend? The -B option should do what you want. http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html Thank you, it seems to have helped the issue, however now there is another issue that'd I'd like conformation on, as my knowledge of GDC won't allow me to know what's happening with this. cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Run 'dmd -man' for installation instructions. If I'm not mistaken, this is basically saying GDC needs dmd, or something from dmd? As I will be distributing GDC with my application I need to make GDC as portable as possible, and of course, legal, seeing as I can't distribute DMD legally, I was considering LDC however if possible I would like to get GDC working. Usually, DMD works normally, however with this GDC seems to be making some call to DMD or one of it's files, that's where I'm confused. I appreciate you time and help. :)
Re: GDC GCC backend
confirmation*
Re: GDC GCC backend
Never mind, I fixed it. The one time I don't use google..
GDC GCC backend
This one's kinda short.. Is it possible to change the variable that gdc finds cc1d? Something like gdc -gcc=/whatever/gcc_backend?
Compiling D inside of a D program
This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)?
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 10:00:10 UTC, Kelet wrote: On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)? Hi, I was also interested in this topic. My research suggests that there is no easy or safe way to do this at the moment, as thedeemon suggests. Although I think it's worth offering a possible alternative: using a scripting language binding like LuaD[1], DerelictLua[2], or pyd[3]. From here, you can expose some functions/variables between them, and solve a lot of the same problems. That being said, I think it would be useful to have something like JavaCompiler[4]. It's not an optimal solution, but combined with a minimal compiler package it could help a lot. As far as I know, you need to ask permission to distribute DMD with your application, so it may be safer to include GDC or LDC if you want to go this route. Or ask Walter, of course. [1]: https://github.com/JakobOvrum/LuaD [2]: https://github.com/DerelictOrg/DerelictLua [3]: https://bitbucket.org/ariovistus/pyd [4]: http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html Regards, Kelet Would it be legal to have my program automatically download some dmd binary, that way I could always keep it up to date? Given Walter here doesn't absolutely forbid my program does that.
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?)
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 22:51:53 UTC, John Colvin wrote: On Saturday, 21 December 2013 at 22:18:58 UTC, Mineko wrote: On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?) How fast do you actually need it to be? Fast enough to where the engine is not spending 5 minutes compiling a heavily scripted (multiplayer usually) game, perhaps gdc -0fast would do it?
null this
So, I was doing some coding to my IO.d, and came across the strangest error, I looked it up and tried some different asserts, which is why it shows up as something different from null this now, anyway here, I seriously can't figure this out, the code is here: http://pastebin.com/bGiKMM4Y core.exception.AssertError@src/breaker/utility/io.d(167): (io.d:add) this is null bin/Breaker 3D Game Engine(_d_assert_msg+0x45) [0x5130e9] bin/Breaker 3D Game Engine(void breaker.utility.io.IO.add!(immutable(char)[], immutable(char)[], immutable(char)[]).add(immutable(bool), immutable(char)[], immutable(char)[], immutable(char)[])+0x66) [0x4c355e] bin/Breaker 3D Game Engine(immutable(char)[] breaker.utility.io.getDir(immutable(char[]))+0x1c2) [0x4c17ea] bin/Breaker 3D Game Engine(breaker.utility.io.IO breaker.utility.io.IO.__ctor(immutable(char[]), immutable(char[]), immutable(char[]))+0x1cf) [0x4c1e37] bin/Breaker 3D Game Engine(_Dmain+0x8b) [0x4c75bb] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1()+0x18) [0x514a20] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x51497a] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x5149e0] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x51497a] bin/Breaker 3D Game Engine(_d_run_main+0x1a3) [0x5148fb] bin/Breaker 3D Game Engine(main+0x25) [0x4c7d85] /usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7ff428219bc5] Exited: 256 Thank you for your time and help.
Re: null this
On Monday, 9 December 2013 at 19:53:09 UTC, Adam D. Ruppe wrote: When you used the class, did you remember to new it? Unlike C++, Io io; in D would be null. You have to create it with io = new Io(); You got me thinking in the right direction, turns out I was putting in a bad parameter at the places like Io session ... session = new IO(...) Thank you very much. :)
Re: I/O related question, and ini parsing
On Saturday, 7 December 2013 at 12:23:38 UTC, nazriel wrote: On Friday, 6 December 2013 at 04:43:44 UTC, Mineko wrote: So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice! imports are private by default. Also I noticed few overlaping private declarations, for example here: https://github.com/MinekoRox/Breaker-3D-Game-Engine/blob/master/src/breaker/utility/belt.d#L54 Ahh thank you for pointing that overlap. I know imports are private, only reason I put them at the bottom is because the public stuff is what you're referencing to when you import something, not the private stuff (usually) Although I've been thinking of at least moving the imports back to the top, since it does make more sense that way.
Re: I/O related question, and ini parsing
On Saturday, 7 December 2013 at 12:23:38 UTC, nazriel wrote: imports are private by default. Also I noticed few overlaping private declarations, for example here: https://github.com/MinekoRox/Breaker-3D-Game-Engine/blob/master/src/breaker/utility/belt.d#L54 Sorry for the double post, this just occured to me, and it'll keep me from getting lectured about scopes and imports. :P On Friday, 6 December 2013 at 17:32:24 UTC, Dicebot wrote: On Friday, 6 December 2013 at 16:56:29 UTC, bearophile wrote: Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. OP still has them global though, just in weird place, that is unusual for sure :) I'll probably just do that, actually, as I like having benefits.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:32:56 UTC, Mineko wrote: On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote: On 12/05/2013 08:43 PM, Mineko wrote: I might be missing out on some D-only features The first thing I've noticed is that you are not using UFCS, perhaps because you don't like it (yet ;) ) but look how natural the syntax becomes: existing code (my indentation): temp = findSplitAfter(findSplitBefore(find(source, var~ = ), ;)[0], = )[1]; code taking advantage of D's UFCS (I hope I got it right; I have not compiled it): temp = source .find(var~ = ) .findSplitBefore(;)[0] .findSplitAfter( = )[1]; Ali I didn't even know that existed, I'll jump on that right now. I went through 8 hours of hell for that.. But it was worth it, things do look nicer with UFCS stuffs. (No wonder why they say you don't need a scripting language with D..) It's on my fork if you wanna check it out: https://github.com/MinekoRox/Breaker-3D-Game-Engine Anyways, back to the main subject, anyone know anything that I could be missing D-only wise as far as file loading, parsing, creating, etc the stuff in /utility/io.d is doing?
Re: I/O related question, and ini parsing
Alright cool, I'll get on that real soon, I'm not too used to D's importing system anyway, so I appreciate it. I suppose I'll have to do some research on pure and nothrow too, I've never really bothered with those.
I/O related question, and ini parsing
So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice!
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote: On 12/05/2013 08:43 PM, Mineko wrote: I might be missing out on some D-only features The first thing I've noticed is that you are not using UFCS, perhaps because you don't like it (yet ;) ) but look how natural the syntax becomes: existing code (my indentation): temp = findSplitAfter(findSplitBefore(find(source, var~ = ), ;)[0], = )[1]; code taking advantage of D's UFCS (I hope I got it right; I have not compiled it): temp = source .find(var~ = ) .findSplitBefore(;)[0] .findSplitAfter( = )[1]; Ali I didn't even know that existed, I'll jump on that right now.
OpenGL rendering issue
Not quite sure how to explain this one, all I know is that a triangle won't render and it probably has something to do with bufferdata or one of it's inputs, since this is D I had to do some roundabout things to get it work with a C library like OpenGL so.. Yeah.. https://github.com/MinekoRox/Breaker-3D-Game-Engine loopIt() in engine.d and render.d are what needs to be looked at, I've been attempting to fix this for quite a few hours now but I just don't quite get it, maybe someone who knows a bit more about D can help me here? If I'm omitting some information please just ask. Watch this be happening because I don't understand pointers all that well.. _
Re: OpenGL rendering issue
On Saturday, 23 November 2013 at 22:41:41 UTC, Mikko Ronkainen wrote: Try moving glGenVertexArrays(1, vao); glBindVertexArray(vao); at the top. You're my new best friend, no, let's get married. Really though, thanks, this one's been eating at me a bit.
Re: D game engine -- Any suggestions?
I did a complete restructure of the engine, so it'd be a bit better for later use. If there's anything I missed or anything I should fix, please tell me. Ignore the opengl stuff though, right now it's more or less a placeholder so I can implement the base functions first and forthmost. https://github.com/ICGCC/Breaker-3D-Game-Engine
D game engine -- Any suggestions?
Yo, I'm starting off a new game engine designed around D, and I just wanted to know if some of you might be kind enough to review some of my base code and tell me if I need to change anything in it.. While it's small. ;_; I'm still learning D, I quite like it, the power of C++ in some parts, and the ease of Java in others. (Good job Walter!) Anyway here, check it out, only ones you really need to pay attention to are main.d, time.d, and input.d. https://github.com/ICGCC/Breaker-3D-Game-Engine Thanks for helping out a newbie, and if you want to contribute to it, even better! ..That and if I'm using the GPL right. _
Re: D game engine -- Any suggestions?
Wow! You guys are really helpful, I wouldn't have thought about a lot of that, I'll pounce on all of this right after breakfast! Thanks! :D
Re: D game engine -- Any suggestions?
On Wednesday, 20 November 2013 at 15:30:32 UTC, Geancarlo Rocha wrote: You should fix your LICENSE following these instructions http://www.gnu.org/licenses/gpl-howto.html. I hope you understand the virality of GPL and why most people won't touch your code for real work. Yeah I know, have any better ideas that is at least similar enough to the GPL?
Re: D game engine -- Any suggestions?
On Wednesday, 20 November 2013 at 10:20:06 UTC, Rene Zwanenburg wrote: On Wednesday, 20 November 2013 at 09:15:41 UTC, Rene Zwanenburg wrote: Hi, A few things jumped out at me: Camera.d: ... Oops, I have to run.. Will take a look at the rest later. Still regarding camera.d: - The glfw3 import appears to be unused and can be removed. - the call to Math.perspectiveGL modifies OpenGL state. Your math functions _really_ shouldn't interact with OpenGL. - Taking the previous point a bit further, your Camera class doesn't need to know about OpenGL either. In your rendering routine, get the camera matrices from a camera and pass them to OpenGL. - Like Paulo said, don't use the fixed function pipeline. If you're not familiar with 3D yet the FFP is easier to use at first, but using modern OpenGL will pay for itself in the long run. I don't know where to find a good introduction to modern OpenGL though, perhaps someone else around here.. - rotate, move are unnecessary. Once you switch to gl3n, move becomes: camera.position += someVector; Same thing with rotate, only you multiply: camera.rotation *= someQuaternion; math.d: - D allows free functions. There's no need to use hacks like completely static classes. You can remove the Math class and put it's functions in the module. - I'd also make std.math a public import, so you only have to import your math to get both in another module. - perspectiveGL doesn't belong here, but this is fixed by using gl3n. time.d - Same thing with the statics as in math. Though personally I'd call Time Timer, and make instances. You'll probably want to have more than one timer. - Sleeping doesn't belong in the timer. It should only calculate total running time and delta time in update. Later on you'll probably find out it needs more features, but these two will be fine for now. If anywhere, sleeping belongs in the game loop. That being said I'd advise against sleeping at all. It's usually better to use vsync, or run at max fps if the user disables it. That's all I could find during a quick peek.. If you'd like me to clarify some of these points, please don't hesitate to ask! Interesting, would you give me an example of the @property and the timer stuff, if that's all right with you? I've attempted doing the @property stuff, but I run into lots of problems, so maybe your example will show me what I've done wrong.
Re: D game engine -- Any suggestions?
On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote: I would suggest dual license. GPL for open source projects and something else for commercial projects. It all depends how you see companies using your code, without any kind of retribution or recognition. I see this happening all the time in the SaaS enterprise space I work on. For many companies open source means free beer. I wonder how much Sony was given back to the open source projects that make up the PS4 besides the license note, for example. http://www.scei.co.jp/ps4-license/ Anyway it is your project, so it is up to you to decide what license to use. -- Paulo Ahh ok, I was worried when you said that the GPL was viral, I was planning on a dual license, GPL for the actual engine, and maybe boost or something for the actual assets, of course that depends on who uses the code, as long as the engine itself is free and redistributed intact then everything is fine.
Re: D game engine -- Any suggestions?
On Wednesday, 20 November 2013 at 20:57:11 UTC, Franz wrote: On Wednesday, 20 November 2013 at 20:00:17 UTC, Mineko wrote: On Wednesday, 20 November 2013 at 19:38:09 UTC, Paulo Pinto wrote: as long as the engine itself is free and redistributed intact then everything is fine. Then you are probably looking at a LGPL license. I'm not gonna explain in deep the differences but keeping it short: If a library is GPL, then the whole project must be redistributed as GPL software. If someone uses your code and uses in a broader project, the whole project would need to be GPL too. If a library is LGPL, then the modified library must be redistributed as LGPL library. If someone uses and/or modifies your library in a broader project, only the library will need to be redistributed as open. EG: one takes your game engine and links it against some other libraries to make a full game (eg: adding networking, scripting engine, etc). If the license is LGPL, everything is fine. If license is GPL, he will need to release everything as GPL. Something this isn't even possible due to license incompatibilities. However, if he modifies your library (like, adds something to rendering routines), he has to release the modified code, doesn't matter if it's GPL or LGPL. Last but not least, the copyright holder (you) can relicense the work at any time. Finally.. I finally got a clear explanation of the LGPL, I was on the fence about it but ended up going with GPl, now that I know though I'll convert it to LGPL, much thanks.
Re: D game engine -- Any suggestions?
On Wednesday, 20 November 2013 at 09:15:41 UTC, Rene Zwanenburg wrote: Hi, A few things jumped out at me: Camera.d: - The use of x, y, z and rx, ry, rz. These should really be in some vector struct. Since you're using Dub, you can easily use gl3n [1][2]. While it's still pretty basic, should be more than enough to get you started. - Use Quaternions to store your rotations instead of euler angles. - You can use @property instead of trivial getters and setters - You may want to store your camera matrices in the camera class, and pass them to OpenGL when rendering. These matrices can be useful, and you don't want to use glGet* functions ever if you care about performance ;). gl3n provides matrix structs and facilities to create projection matrices and the like. Oops, I have to run.. Will take a look at the rest later. [1] http://dav1dde.github.io/gl3n/index.html [2] http://code.dlang.org/packages/gl3n After a bit of careful study I figured out how @property works, I just implemented it wrong last time, very helpful, thanks.
