Re: Rosettacode: program termination
On Monday, 14 April 2014 at 09:58:09 UTC, bearophile wrote:
I have added a D entry regarding how to terminate D programs.
What's missing?
http://rosettacode.org/wiki/Program_termination#D
Bye,
bearophile
I think notInifnite is too contrived, you would always just use
`else` there. This is more realistic:
int notInfinite(in int b) pure nothrow {
if (b 0)
return 10;
if (b 10)
return 20;
// In release mode this becomes a halt, and it's sometimes
// necessary. If you remove this the compiler gives:
// Error: function test.notInfinite no return exp;
//or assert(0); at end of function
assert(false);
}
Rosettacode: program termination
I have added a D entry regarding how to terminate D programs. What's missing? http://rosettacode.org/wiki/Program_termination#D Bye, bearophile
Re: Local function overloading
On Sunday, April 13, 2014 08:40:17 Philpax wrote: Is not being able to overload functions in local scope intended behaviour? Yes. IIRC, I complained about it at one point, and Walter didn't like the idea of having overloaded nested functions. I don't remember what his reasoning was, but I don't remember agreeing with it either. You can certainly always open up an enhancement request for it. Maybe one of the compiler devs can implement it and talk Walter into accepting it: https://issues.dlang.org/ - Jonathan M Davis
Uncaught exception while running redis-pubsub-example of vibe.d
Running ./redis-pubsub-example Callback subscribe([test1]) Task terminated with uncaught exception: expected of $ or * The error message gives no hint of where the exception is raised.How do you guys debug this type of error?
Re: Implicit conversions through purity
On Sunday, April 13, 2014 01:52:13 bearophile wrote: Jonathan M Davis: Honestly, I would have considered that to be a bug. Converting the return type to a different level of mutability based on purity is one thing. Automatically casting the return value just because the function is pure is another matter entirely. Clearly, it can work, but it seems incredibly sloppy to me. In foo1 D is working as designed, as this was a desired feature, it has passed the Kenji and Walter review, and it was implemented several months ago. It's a very handy way to create immutable data with pure functions and it's safe, it's safer than assumeUnique that is just a convention. Very recently Walter has further improved this feature, allowing more implicit conversion cases. So it's the opposite of a bug, it saves you from bugs in three different ways. Well, it's the first I've heard of it, and I certainly don't like the idea, but if it's intended and implemented, then that's the way it is, I guess. Maybe I'll come to agree after thinking about it more. But my question was about the successive foo functions :-) Well, if I don't like the first example, I'm not about to be in favor of making more examples follow suite. - Jonathan M Davis
Re: Implicit conversions through purity
On Sunday, April 13, 2014 21:21:02 Daniel Murphy wrote: Jonathan M Davis wrote in message news:mailman.112.1397351369.5999.digitalmars-d-le...@puremagic.com... Honestly, I would have considered that to be a bug. Converting the return type to a different level of mutability based on purity is one thing. Automatically casting the return value just because the function is pure is another matter entirely. Clearly, it can work, but it seems incredibly sloppy to me. It's not a bug, and it's not another matter entirely - it's the same thing as converting a call expression, just on the inside instead of the outside. Doing the conversion on the caller's side enables code that wouldn't otherwise work - particularly if you're not intimately familiar with what guarantees pure really gives you. Doing the conversion inside the function doesn't really buy you much of anything IMHO and promotes being lazy with types. It may not be a big deal, but I don't think that it's really a good idea either. So, while from the perspective of what the compiler can guarantee, it may be the same from both sides, I don't think that it's the same at all with regards to how it affects the programmer or what code they need to write (or should write). - Jonathan M Davis
Re: Local function overloading
On Monday, 14 April 2014 at 10:35:20 UTC, Jonathan M Davis wrote: On Sunday, April 13, 2014 08:40:17 Philpax wrote: Is not being able to overload functions in local scope intended behaviour? Yes. IIRC, I complained about it at one point, and Walter didn't like the idea of having overloaded nested functions. I don't remember what his reasoning was, but I don't remember agreeing with it either. You can certainly always open up an enhancement request for it. Maybe one of the compiler devs can implement it and talk Walter into accepting it: https://issues.dlang.org/ - Jonathan M Davis https://issues.dlang.org/show_bug.cgi?id=12578
Re: Rosettacode: program termination
John Colvin:
I think notInifnite is too contrived, you would always just use
`else` there. This is more realistic:
int notInfinite(in int b) pure nothrow {
if (b 0)
return 10;
if (b 10)
return 20;
// In release mode this becomes a halt, and it's sometimes
// necessary. If you remove this the compiler gives:
// Error: function test.notInfinite no return exp;
//or assert(0); at end of function
assert(false);
}
OK, I have improved the code:
http://rosettacode.org/wiki/Program_termination#D
Bye,
bearophile
A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D?
Hello,everyone: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D? So lots of people want to use D,who can help them? They want to connect MS SQL Server in D,then they will connect other DataBase, because it's a good idea that nice thing come from the small and familiar things always. Sql driver or ODBC driver, for win7 in D, who can help them? Thank you,everyone.
Re: Implicit conversions through purity
On Mon, 14 Apr 2014 06:37:18 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Sunday, April 13, 2014 01:52:13 bearophile wrote:
Jonathan M Davis:
Honestly, I would have considered that to be a bug. Converting
the return type
to a different level of mutability based on purity is one
thing. Automatically
casting the return value just because the function is pure is
another matter
entirely. Clearly, it can work, but it seems incredibly sloppy
to me.
In foo1 D is working as designed, as this was a desired feature,
it has passed the Kenji and Walter review, and it was implemented
several months ago. It's a very handy way to create immutable
data with pure functions and it's safe, it's safer than
assumeUnique that is just a convention. Very recently Walter has
further improved this feature, allowing more implicit conversion
cases. So it's the opposite of a bug, it saves you from bugs in
three different ways.
Well, it's the first I've heard of it, and I certainly don't like the
idea,
but if it's intended and implemented, then that's the way it is, I guess.
Maybe I'll come to agree after thinking about it more.
Here is how I consider it...
The foo1 function for reference:
string foo1(in string s) pure nothrow {
auto s2 = s.dup;
s2[0] = 'a';
return s2; // OK.
}
The compiler accepts only immutable references. Any mutable references
inside a pure function that only accepts immutable references can ONLY be
data that is uniquely referenced from this function. In other words,
there's no possible way that data is referenced outside this function,
because a pure function cannot access globals.
So it's logical to assume that any mutable data inside the function can be
implicitly cast to immutable. In fact, I would say in general, mutable
data can be cast to immutable inside any pure function that only accepts
immutable parameters. However, it cannot use the mutable references after
casting. This would confuse the optimizer, which thinks that immutable
data is still immutable.
For that reason, I would disallow out parameters from casting implicitly.
e.g.:
pure string mkcopy(string s) pure nothrow { return s.idup; }
void foo2(in string s, ref string r, ref string r2) pure nothrow {
auto s2 = s.dup;
r2 = s2;
auto s3 = mkcopy(r2); // should be a pure copy of s
s2[0] = 'a'; // modified immutable data referenced by r2!
r = mkcopy(r2); // ???
}
At the line marked ???, note that the compiler has already called mkcopy
on r2, which hasn't itself changed, and data r2 references is immutable.
The compiler is fully allowed to change that line to:
r = s3;
which would mean that r != r2, even though the last line says otherwise.
I think the point of restricting to the return value is not only that you
are sure nothing else can refer to the data, but also that nothing else
happens to the mutable copy after the cast.
I wonder if scope(exit) usage could compromise the current rule...
-Steve
Re: Implicit conversions through purity
Steven Schveighoffer: For that reason, I would disallow out parameters from casting implicitly. If you think the proposal is not good, can you please copy what you have written here in the issue thread? https://issues.dlang.org/show_bug.cgi?id=12573 Bye, bearophile
Re: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D?
On Monday, 14 April 2014 at 15:21:33 UTC, FrankLike wrote: Hello,everyone: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D? So lots of people want to use D,who can help them? They want to connect MS SQL Server in D,then they will connect other DataBase, because it's a good idea that nice thing come from the small and familiar things always. Sql driver or ODBC driver, for win7 in D, who can help them? Thank you,everyone. First thing a D programmer MUST do is 1) To port FreeTDS to D, or write a binding/wrapper for it (should not be too difficult). or 2) Use ODBC directly, or maybe also write some wrapper around it. or 3) Implement D connector to MS SQL server directly (I would advise against that, such project would probably be 10x bigger than the DMD project itself) My advice - use ODBC, it is the fastest way you may connect to the SQL server, and you already have everything you need for that. :) Regards
I test move the DFL to x64,there are some things,who will help me?
I test move the DFL to x64,there are some things,who will help me? When I move the DFL to x64,then find some error: internal\com.d(36):Error: cannot implicitly convert expression)C_refCountInc(cast(void*)this)) of type ulong to uint . I'm not sure that x86 to x64,the type ulong to uint? who can help me ? And the bat file has some error? Thank you. -- MakeDFLLIBx64.bat-- @rem Make DFL x64. @rem http://www.dprogramming.com/dfl.php @rem Requires DMD and DMC's libs @rem Free downloads from http://www.digitalmars.com/d/dcompiler.html and http://www.digitalmars.com/download/freecompiler.html @echo off @cls @rem Either set the environment variables dmd_path and dmc_path @rem or fix the paths below. if not %dmd_path% == goto dmd_set set dmd_path=d:\d\dmd2 :dmd_set set dmd_path_windows=%dmd_path%\windows if not exist %dmd_path_windows%\bin\dmd.exe set dmd_path_windows=%dmd_path% if not %dmc_path% == goto dmc_set set dmc_path=d:\d\dm :dmc_set if exist %dmc_path% goto got_dmc @rem @echo DMC not found; using DMD path (if you get errors, install DMC) set dmc_path=%dmd_path_windows% :got_dmc set _stdcwindowsd= set _stdcwindowsobj= if not %dlib% == Tango goto dfl_not_tango_files set _stdcwindowsd=internal/_stdcwindows.d set _stdcwindowsobj=_stdcwindows.obj :dfl_not_tango_files set dfl_files=package.d all.d base.d application.d internal/dlib.d internal/clib.d internal/utf.d internal/com.d control.d clippingform.d form.d registry.d drawing.d menu.d notifyicon.d commondialog.d filedialog.d folderdialog.d panel.d textbox.d richtextbox.d picturebox.d listbox.d groupbox.d splitter.d usercontrol.d button.d label.d collections.d internal/winapi.d internal/wincom.d event.d socket.d timer.d environment.d messagebox.d tooltip.d combobox.d treeview.d tabcontrol.d colordialog.d listview.d data.d clipboard.d fontdialog.d progressbar.d resources.d statusbar.d imagelist.d toolbar.d %_stdcwindowsd% set dfl_objs=package.obj all.obj base.obj application.obj dlib.obj clib.obj utf.obj com.obj control.obj clippingform.obj form.obj registry.obj drawing.obj menu.obj notifyicon.obj commondialog.obj filedialog.obj folderdialog.obj panel.obj textbox.obj richtextbox.obj picturebox.obj listbox.obj groupbox.obj splitter.obj usercontrol.obj button.obj label.obj collections.obj winapi.obj wincom.obj event.obj socket.obj timer.obj environment.obj messagebox.obj tooltip.obj combobox.obj treeview.obj tabcontrol.obj colordialog.obj listview.obj data.obj clipboard.obj fontdialog.obj progressbar.obj resources.obj statusbar.obj imagelist.obj toolbar.obj %_stdcwindowsobj% @rem Also update link pragmas for build. set dfl_libs_dfl=user64_dfl.lib shell64_dfl.lib olepro64_dfl.lib set dfl_libs=%dmc_path%\lib\gdi32.lib %dmc_path%\lib\comctl32.lib %dmc_path%\lib\advapi32.lib %dmc_path%\lib\comdlg32.lib %dmc_path%\lib\ole32.lib %dmc_path%\lib\uuid.lib %dmd_path_windows%\lib\ws2_32.lib %dfl_libs_dfl% @rem -version=NO_DRAG_DROP -version=NO_MDI @rem -debug=SHOW_MESSAGE_INFO -debug=MESSAGE_PAUSE @rem set dfl_flags=%dfl_flags% -debug=SHOW_MESSAGENFO set _dfl_flags=%dfl_flags% -wi if not %dfl_debug_flags% == goto dfl_debug_flags_set set dfl_debug_flags=-debug -g :dfl_debug_flags_set if not %dfl_release_flags% == goto dfl_release_flags_set @remif not %dlib% == Tango goto dfl_not_release_tango @rem echo Due to a bug in DMD, release mode dfl lib will not include -inline; use environment variable dfl_release_flags to override. @remset dfl_release_flags=-O -release @remgoto dfl_release_flags_set @rem:dfl_not_release_tango set dfl_release_flags=-O -inline -release :dfl_release_flags_set @echo on @if %dfl_ddoc% == goto after_dfl_ddoc @echo. @echo Generating ddoc documentation... %dmd_path_windows%\bin\dmd %_dfl_flags% %dfl_options% -c -o- -Dddoc %dfl_files% @if errorlevel 1 goto oops @if %dfl_ddoc% == only goto done @if not %dfl_ddoc_only% == goto done :after_dfl_ddoc @rem DMC's Basic Utilities required to make these libs. @rem %dmc_path%\bin\implib user64_dfl.lib user32_dfl.def @rem @if errorlevel 1 goto oops @rem %dmc_path%\bin\implib shell64_dfl.lib shell32_dfl.def @rem @if errorlevel 1 goto oops @rem @echo. @rem @echo Generating headers... @rem @del *.di @rem %dmd_path_windows%\bin\dmd -m64 -H -o- -c -I.. %_dfl_flags% %dfl_options% %dfl_files% @rem @if errorlevel 1 goto oops @echo. @echo Compiling debug DFL... %dmd_path_windows%\bin\dmd -m64 -c %dfl_debug_flags% %_dfl_flags% %dfl_options% -I.. %dfl_files% @if errorlevel 1 goto oops @echo. @echo Making debug lib... %dmd_path_windows%\bin\dmd -m64 -lib -c -n dfl_debug64.lib %dfl_libs% %dfl_objs% @if errorlevel 1 goto oops @echo. @echo Compiling release DFL... %dmd_path_windows%\bin\dmd -m64 -c %dfl_release_flags% %_dfl_flags% %dfl_options% -I.. %dfl_files% @if errorlevel 1 goto oops
Re: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D?
First thing a D programmer MUST do is 1) To port FreeTDS to D, or write a binding/wrapper for it (should not be too difficult). or 2) Use ODBC directly, or maybe also write some wrapper around it. or 3) Implement D connector to MS SQL server directly (I would advise against that, such project would probably be 10x bigger than the DMD project itself) My advice - use ODBC, it is the fastest way you may connect to the SQL server, and you already have everything you need for that. :) Regards Thank you. 1) I have used the binding/wrapper for FreeTDS,I have tested , but can't get the OMF lib,and can't get the ctlib's dll,so no end. 2) I test the ODBC32 ON WIN7,but not have the right OMF lib, I test the implib , but do not get the right OMF lib ,then I not get any thing. Maybe my implib tool is error? The implib tool's created time is 2000-05-05,I know it's old,but I can't get any lastest. Hope you can help to me, Thank again.
Re: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D?
My advice - use ODBC, it is the fastest way you may connect to
the SQL server, and you already have everything you need for
that. :)
Regards
I have test the d\dmd2\windows\lib\odbc32.lib,the size is 4.5kb,
I test it by test.d(build :dmd test.d)
but find the error:
Error 42:Symbol Undefined _SQLFreeHandle@8
Error 42:Symbol Undefined _SQLSetEnvAttr@16
Error 42:Symbol Undefined _SQLAllocHandle@12
Error 42:Symbol Undefined _SQLGetDiagRec@32
-- errorlevel 4
build mssql.lib :dmd -lib mssql.d database.d -Itrunk/win32/sql.d
-Itrunk/win32/sqlext.d -IODBC32.lib -Iwin32.lib
build test.exe :dmd test.d
-module test.d
module test;
import std.stdio;
import arsd.mssql;
pragma(lib,mssql);
void main() {
try{
//auto db = new MsSql(Driver={SQL
Server};Server=host[\\optional-instance-name];Database=dbtest;Trusted_Connection=Yes);
auto db = new MsSql(Driver={SQL Server Native Client
10.0};Server=127.0.0.1;Database=test;Trusted_Connection=Yes);
//db.query(INSERT INTO users (id, name) values (30, 'hello
mang'));
db.query(SELECT top 10 * FROM testa);
}
catch(Exception e){
auto f = new File(err.text,w);
scope(exit)f.close();
f.writeln(e.info);
}
}
module
mssql.d---
// NOTE: I haven't even tried to use this for a test yet!
// It's probably godawful, if it works at all.
module arsd.mssql;
pragma(lib, odbc32);
public import arsd.database;
import std.string;
import std.exception;
import win32.sql;
import win32.sqlext;
class MsSql : Database {
// dbname = name is probably the most common connection string
this(string connectionString) {
SQLAllocHandle(SQL_HANDLE_ENV, cast(void*)SQL_NULL_HANDLE,
env);
enforce(env !is null);
scope(failure)
SQLFreeHandle(SQL_HANDLE_ENV, env);
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, cast(void *)
SQL_OV_ODBC3, 0);
SQLAllocHandle(SQL_HANDLE_DBC, env, conn);
scope(failure)
SQLFreeHandle(SQL_HANDLE_DBC, conn);
enforce(conn !is null);
auto ret = SQLDriverConnect(
conn, null, cast(ubyte*)connectionString.ptr, SQL_NTS,
null, 0, null,
SQL_DRIVER_NOPROMPT );
if ((ret != SQL_SUCCESS_WITH_INFO) (ret != SQL_SUCCESS))
throw new DatabaseException(Unable to connect to ODBC object:
~ getSQLError(SQL_HANDLE_DBC, conn)); // FIXME: print error
//query(SET NAMES 'utf8'); // D does everything with utf8
}
~this() {
SQLDisconnect(conn);
SQLFreeHandle(SQL_HANDLE_DBC, conn);
SQLFreeHandle(SQL_HANDLE_ENV, env);
}
override void startTransaction() {
query(START TRANSACTION);
}
ResultSet queryImpl(string sql, Variant[] args...) {
sql = escapedVariants(this, sql, args);
// this is passed to MsSqlResult to control
SQLHSTMT statement;
auto returned = SQLAllocHandle(SQL_HANDLE_STMT, conn,
statement);
enforce(returned == SQL_SUCCESS);
returned = SQLExecDirect(statement, cast(ubyte*)sql.ptr,
SQL_NTS);
if(returned != SQL_SUCCESS)
throw new DatabaseException(error());
return new MsSqlResult(statement);
}
string escape(string sqlData) { // FIXME
return ; //FIX ME
//return ret.replace(', '');
}
string error() {
return null; // FIXME
}
private:
SQLHENV env;
SQLHDBC conn;
}
class MsSqlResult : ResultSet {
// name for associative array to result index
int getFieldIndex(string field) {
if(mapping is null)
makeFieldMapping();
if (field !in mapping)
return -1;
return mapping[field];
}
string[] fieldNames() {
if(mapping is null)
makeFieldMapping();
return columnNames;
}
// this is a range that can offer other ranges to access it
bool empty() {
return isEmpty;
}
Row front() {
return row;
}
void popFront() {
if(!isEmpty)
fetchNext;
}
int length()
{
return 1; //FIX ME
}
this(SQLHSTMT statement) {
this.statement = statement;
SQLSMALLINT info;
SQLNumResultCols(statement, info);
numFields = info;
fetchNext();
Re: Converting function pointers to delegates
On Monday, 14 April 2014 at 17:45:52 UTC, Ryan Voots wrote: src/yage/core/misc.d(164): Error: e2ir: cannot cast this of type S to type void* Try taking the address of this before casting it. So more like cast(void*)this IIRC in D1 this was a pointer, whereas in D2 this is a reference. You can't cast a reference to pointer directly (at least not without overloading the cast operator) but you can take its address to fetch a pointer out of it and then work with that. BTW see also: http://dlang.org/phobos/std_functional.html#toDelegate
Converting function pointers to delegates
I'm porting some code from D1 to D2 and this is the final error
i'm getting from DMD and GDC. I have no idea what is going on
with it though.
/**
* Convert any function pointer to a delegate.
* _ From:
http://www.digitalmars.com/d/archives/digitalmars/D/easily_convert_any_method_function_to_a_delegate_55827.html
*/
R delegate(P) toDelegate(R, P...)(R function(P) fp)
{ struct S
{ R Go(P p) // P is the function args.
{ return (cast(R function(P))(cast(void*)this))(p);
}
}
return (cast(S*)(cast(void*)fp)).Go;
}
DMD tells me:
src/yage/core/misc.d(164): Error: e2ir: cannot cast this of type
S to type void*
The code itself you can see at:
https://bitbucket.org/simcop2387/yage/src/0542cea5eefabf4c90b822cf26ec1062ed0fcb64/src/yage/core/misc.d?at=default#cl-161
and where it gets called:
https://bitbucket.org/simcop2387/yage/src/0542cea5eefabf4c90b822cf26ec1062ed0fcb64/src/yage/core/repeater.d?at=default#cl-47
To be perfectly honest I'm not sure what it's doing to figure out
how to fix it.
Re: Converting function pointers to delegates
On Monday, 14 April 2014 at 17:48:31 UTC, Adam D. Ruppe wrote: On Monday, 14 April 2014 at 17:45:52 UTC, Ryan Voots wrote: src/yage/core/misc.d(164): Error: e2ir: cannot cast this of type S to type void* Try taking the address of this before casting it. So more like cast(void*)this IIRC in D1 this was a pointer, whereas in D2 this is a reference. You can't cast a reference to pointer directly. That's not true. And I think the issue in his diagnostic is that he used it with a struct. You can't cast 'this' of a struct to a pointer (you'd have to use this), but you can cast a class reference to a pointer.
Re: Converting function pointers to delegates
On Monday, 14 April 2014 at 17:45:52 UTC, Ryan Voots wrote: /** * Convert any function pointer to a delegate. * _ From: http://www.digitalmars.com/d/archives/digitalmars You can replaced it with std.functional.toDelegate. As for its use-case, if some API or function supports only delegates but you want to pass in a function, you would wrap the function with toDelegate and then pass the delegate to the API/function.
aliases and .stringof
I noticed something odd with code of mine with recent D builds (recent from-git
dmd, 2.065-branch ldc2). I have a loop in my graph library which goes:
foreach (G; TypeTuple!(IndexedEdgeList, CachedEdgeList))
{
foreach (directed; TypeTuple!(false, true))
{
alias Graph = G!directed;
StopWatch watch;
writeln(Graph type: , (Graph.directed) ? directed :
undirected , Graph.stringof);
// ... etc.
}
}
Now, with earlier compiler versions, that would have resulted in output,
Graph type: undirected IndexedEdgeList
Graph type: directed IndexedEdgeList
Graph type: undirected CachedEdgeList
Graph type: directed CachedEdgeList
But with more recent compiler versions, what I'm seeing instead is:
Graph type: undirected G!(false)
Graph type: directed G!(true)
Graph type: undirected G!(false)
Graph type: directed G!(true)
Is this a bug, or an intended change in behaviour with respect to aliases? I
have to say that in this case at least it feels very problematic, as it
completely obfuscates the actual types being used, and the whole point of what's
being output is to display the type.
Re: aliases and .stringof
On Monday, 14 April 2014 at 19:01:22 UTC, Joseph Rushton Wakeling wrote: alias Graph = G!directed; ... writeln(Graph type: , (Graph.directed) ? directed : undirected , Graph.stringof); // ... etc. isn't this should be Graph.typeof.stringof ?
Re: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D?
On Monday, 14 April 2014 at 15:21:33 UTC, FrankLike wrote: Hello,everyone: A lot of people want to use D,but they only know MS SQL Server,what will help them to Learn D? So lots of people want to use D,who can help them? They want to connect MS SQL Server in D,then they will connect other DataBase, because it's a good idea that nice thing come from the small and familiar things always. Sql driver or ODBC driver, for win7 in D, who can help them? Thank you,everyone. There is another option. Using OpenDBX[0]. My binding here[1]. Its not exactly tested but since OpenDBX is a c library there shouldn't be any issues as long as you can grab the appropriate shared library version. [0] http://www.linuxnetworks.de/doc/index.php/OpenDBX/Support [1] https://github.com/rikkimax/Derelict_Extras---OpenDBX
