Re: CTFE and -betterC
On Wednesday, 14 March 2018 at 01:17:54 UTC, rikki cattermole wrote: You will still need DllMain, that is a platform requirement. I am not sure about that because when DllAnalyser don't see it in the opengl32.dll from the system32 directory. And the documentation indicate that it is optional. I finally choose to put the entry points generation in a sub-project that put them in a d file, like that it is easier to make the CTFE working and will be much better for the debugging and compilation time. So I have also some few other questions : - Is it a bug that ctRegex doesn't with the return of allMembers? - What is the status of the new CTFE engine? - Will CTFE be able to write files or expose a way to see to resulting generated code for a debug purpose? - Is there a reason why CTFE is impacted by the -betterC option?
fix struct API with an interface
I add directx 9 support on DQuick and as some of renderer objects are declared as struct, it seems it can make them derives from an interface. Need I use final class instead to avoid virtual methods? PS: I am not planning to support run-time switch between OpenGL and directX renderers.
Re: fix struct API with an interface
On Thursday, 6 March 2014 at 13:35:13 UTC, John Colvin wrote: On Thursday, 6 March 2014 at 13:26:27 UTC, Flamaros wrote: I add directx 9 support on DQuick and as some of renderer objects are declared as struct, it seems it can make them derives from an interface. Need I use final class instead to avoid virtual methods? PS: I am not planning to support run-time switch between OpenGL and directX renderers. I'm not sure I understand the question, but here's some facts that might help: struct methods are never virtual. final class methods are never virtual. structs do not support inheritance. Is the indirection caused by using an interface+class going to be a performance problem? Ok, it's like I though final class and struct are equivalent when calling a method (except the pointer deference, but it's minor I think). I don't think there is a real performance problem for us, it's more about to learn how to have a clean design.
Re: DDMD as showcase?
On Tuesday, 11 February 2014 at 04:19:12 UTC, Daniel Murphy wrote: Xavier Bigand wrote in message news:ldbpum$1pov$1...@digitalmars.com... Firstly is there some progress on the DDMD project or maybe an other D boostrap? The old ddmd project is pretty much dead AFAIK (http://www.dsource.org/projects/ddmd) and was never up to date with the current compiler. For about a year I've been working on automatically converting the compiler source from C++ to D. The conversion has produced a working compiler on win32/linux32/linux64 (other platforms need trivial patches) that compiles druntime/phobos/the test suite without errors. The current effort is around cleaning up the C++ source to produce higher quality D code. The next major step is to actually switch development to the D version. Outstanding patches: https://github.com/D-Programming-Language/dmd/pull/1980 Conversion tool: https://github.com/yebblies/magicport2 You can see some of the recent patches (marked DDMD) here: https://github.com/yebblies?tab=contributionsperiod=monthly There is a lot of thread and debate around the GC of D, I interrogate me on the capacity of a project like DDMD to prove to every D users that the GC is perfectly usable for system applications. If not it will certainly be improve during the DDMD development to a point can satisfy almost everybody? There are no planned GC modifications for the DDMD project. It may result in some compiler devs taking more of an interest in the GC. That the idea. In all cases we need some proof of the validity of having a GC in a system language. As I know DMD doesn't release memory, these will have to be fixed in DDMD to match the memory management most application have to apply. Yes, DDMD will use the GC, although it currently has it disabled due to a segfault I haven't tracked down yet. I see many interesting points in DDMD : - prove GC based compiler isn't longer to optimize than the C++ version (and capable to reach same performances) - will reveal more language issues or phobos miss. Maybe, but so far additions to the language have been minimal, and DDMD does not currently use phobos. It is also slower than the C++ version, part of which is due to the GC being slower than the bump-pointer allocator used in the C++ dmd. - will be easier to maintain and update Exactly!
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
On Wednesday, 22 January 2014 at 02:11:02 UTC, TheFlyingFiddle
wrote:
On Saturday, 18 January 2014 at 19:40:38 UTC, Xavier Bigand
wrote:
I am not sure the issue come really from my code, cause it
just works fine on ATI cards, I do something Nvidia drivers
dislike.
I tried to replace GL_LINE_LOOP by triangles, increase buffer
size, put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right
before glDrawElements without success.
Crash only append when I fill text mesh before those ones. So
I need dig more.
From what i saw in your code you are not using Vertex Array
Objects. I have had similar problems that code ran fine on ATI
but crashed on nvidia. The problem went away for me when i just
created and bound a global VAO just after context creation.
Also i would recommend calling glGetError after every call, it
helps finding errors. Here is a simple trick to do this
automatically.
static gl
{
static ref auto opDispatch(string name, Args...)(Args args)
{
enum glName = gl ~ name[0].toUpper.to!string ~ name[1 ..
$];
debug scope(exit) checkGLError(); //Do glGetError and log
it or something.
mixin(return ~ glName ~ (args););
}
}
After this simply change all glFunctionName(args) to
gl.functionName or gl.functionName.
I will try the global VAO.
I already check glError with checkgl! function.
libdl issues with DUB
When I build our project with DUB under linux I get some link
errors about libdl, that is messing.
In my main I have the following lines :
version(Posix)
{
pragma(lib, dl);
}
This works well with MonoD, so it seems like version Posix isn't
defined with DUB or pragma ignored.
Re: [Font] Getting font folder on all platforms
On Tuesday, 15 October 2013 at 23:10:32 UTC, Flamaros wrote:
On Friday, 6 September 2013 at 20:54:53 UTC, Flamaros wrote:
On Friday, 6 September 2013 at 16:05:43 UTC, Tourist wrote:
On Thursday, 5 September 2013 at 19:48:07 UTC, Flamaros wrote:
I am searching the right way to find fonts folder for each
platforms (Windows, linux, macOS X)
On Windows it's generally C:\Windows\Fonts but a direct
access seems brutal, it's certainly expected to retrieve
this path by using some register keys?
Is someone know how it works for linux and/or macOS X?
I need to be able to retrieve fastest as possible the right
file from the font and family name.
Windows: call SHGetKnownFolderPath with FOLDERID_Fonts as
rfid.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%28v=vs.85%29.aspx
Nice, thx.
Do you know if there is a table of fonts and there family, or
need open all font file my self?
I need to do some more tests, but scanning the registry seems
working under Windows.
Here is my test code :
string fontPathFromName(in string name, in Font.Family family =
Font.Family.Regular)
{
version(Windows)
{
import std.windows.registry;
string fontPath = C:/Windows/Fonts/;
string fontFileName;
Key fontKey;
fontKey =
Registry.localMachine().getKey(Software\\Microsoft\\Windows
NT\\CurrentVersion\\Fonts);
if (family == Font.Family.Regular)
fontFileName = fontKey.getValue(name ~
(TrueType)).value_EXPAND_SZ();
else if (family == Font.Family.Bold)
fontFileName = fontKey.getValue(name ~ Bold
(TrueType)).value_EXPAND_SZ();
else if (family == Font.Family.Italic)
fontFileName = fontKey.getValue(name ~ Italic
(TrueType)).value_EXPAND_SZ();
else if (family == (Font.Family.Bold |
Font.Family.Italic))
fontFileName = fontKey.getValue(name ~ Bold
Italic (TrueType)).value_EXPAND_SZ();
return fontPath ~ fontFileName;
}
}
unittest
{
assert(fontPathFromName(Arial) ==
C:/Windows/Fonts/arial.ttf);
assert(fontPathFromName(arial) ==
C:/Windows/Fonts/arial.ttf); // Test with wrong case
assert(fontPathFromName(Arial, Font.Family.Bold |
Font.Family.Italic) == C:/Windows/Fonts/arialbi.ttf);
}
I did some progress with fontconfig under linux, I'll try to use
it for Windows too.
Re: Running unittests in a D library
On Thursday, 20 September 2012 at 18:31:38 UTC, Jacob Carlborg wrote: On 2012-09-20 13:14, Jonathan M Davis wrote: On Thursday, September 20, 2012 12:34:50 Johannes Pfau wrote: But it should be possible. I'm not arguing that it shouldn't be possible. I'm just pointing out that it wouldn't really be useful. You have to build at least two versions of your library anyway (one with -unittest and one without), so being forced to build your library as a binary for unit tests really isn't a big deal IMHO. But I have no problem with it working to link in a library built with -unittest and have its unit tests run. You'll most likely have a release and debug version anyway. Just put the unit tests in the debug version. I have the same issue. My point is related to IDE usage, I need provide a library for my samples projects and for users. I don't want have to create 2 projects of my library one with a main and one without, because in this case each time I add or remove a file I need do this manipulation for both projects. I try the -main option of dmd that need add default main() (e.g. for unittesting), reading it like that I though it was exactly to be able to put a library project as executable. PS : I am using VisualD and MonoD. I also searched if it is possible to create one d file that imports all my library sources just like we do with a #include build-all.c. Sadly we can't create a Visual project that contains only D sources without any building steps, instead we could put this project of files references as dependency. All samples projects would be build with the library code.
ddoc doesn't generate entries of function without any comments?
I need dig into some low level APIs regularly. Modules like std.c.window and std.c.linux doesn't have any documentation about what it's contains. I also try to generate some docs with ddoc on my project and it seems it doesn't create any functions/methods entries if there is no description on those. Is there any reason for that? Generally a function without any description can be considered as unstable, but maybe the visibility have to play a role here?
Re: DQuick a GUI Library (prototype)
On Thursday, 24 October 2013 at 19:51:14 UTC, Flamaros wrote: On Saturday, 7 September 2013 at 16:48:23 UTC, Flamaros wrote: On Saturday, 7 September 2013 at 15:03:22 UTC, Andrej Mitrovic wrote: On 9/7/13, Flamaros flamaros.xav...@gmail.com wrote: We choose the boost one. That's great, but your license file is empty: https://github.com/D-Quick/DQuick/blob/master/License.txt I fill the wrong file due to a wrong naming. Sorry. We are making some progress, but a lot of work need to be done. Recent changes : - Text wrapping (NoWrap, Any, Wrap, WordWrap) - Font loaded from name instead of path (Windows only for the moment) - Auto binding of Sub-Objects Coming : - A scrolling item - Adding clipping on Items with scissors So the project isn't dead :-) Clipping and Scrolling are done. Bruno will work on adding array support by Lua. I'll clean/fix code in the same time as adding new items/features.
Re: Dynamic loading
On Tuesday, 29 October 2013 at 04:28:24 UTC, evilrat wrote: On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote: On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote: Any progress? There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,... maybe our childrens will see it one day :) It makes me sad :( It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture. to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-
Re: Dynamic loading
On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote: Any progress? There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,... It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.
Re: DQuick a GUI Library (prototype)
On Saturday, 7 September 2013 at 16:48:23 UTC, Flamaros wrote: On Saturday, 7 September 2013 at 15:03:22 UTC, Andrej Mitrovic wrote: On 9/7/13, Flamaros flamaros.xav...@gmail.com wrote: We choose the boost one. That's great, but your license file is empty: https://github.com/D-Quick/DQuick/blob/master/License.txt I fill the wrong file due to a wrong naming. Sorry. We are making some progress, but a lot of work need to be done. Recent changes : - Text wrapping (NoWrap, Any, Wrap, WordWrap) - Font loaded from name instead of path (Windows only for the moment) - Auto binding of Sub-Objects Coming : - A scrolling item - Adding clipping on Items with scissors So the project isn't dead :-)
Re: [Font] Getting font folder on all platforms
On Friday, 6 September 2013 at 20:54:53 UTC, Flamaros wrote:
On Friday, 6 September 2013 at 16:05:43 UTC, Tourist wrote:
On Thursday, 5 September 2013 at 19:48:07 UTC, Flamaros wrote:
I am searching the right way to find fonts folder for each
platforms (Windows, linux, macOS X)
On Windows it's generally C:\Windows\Fonts but a direct
access seems brutal, it's certainly expected to retrieve this
path by using some register keys?
Is someone know how it works for linux and/or macOS X?
I need to be able to retrieve fastest as possible the right
file from the font and family name.
Windows: call SHGetKnownFolderPath with FOLDERID_Fonts as rfid.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%28v=vs.85%29.aspx
Nice, thx.
Do you know if there is a table of fonts and there family, or
need open all font file my self?
I need to do some more tests, but scanning the registry seems
working under Windows.
Here is my test code :
string fontPathFromName(in string name, in Font.Family family =
Font.Family.Regular)
{
version(Windows)
{
import std.windows.registry;
string fontPath = C:/Windows/Fonts/;
string fontFileName;
Key fontKey;
fontKey =
Registry.localMachine().getKey(Software\\Microsoft\\Windows
NT\\CurrentVersion\\Fonts);
if (family == Font.Family.Regular)
fontFileName = fontKey.getValue(name ~
(TrueType)).value_EXPAND_SZ();
else if (family == Font.Family.Bold)
fontFileName = fontKey.getValue(name ~ Bold
(TrueType)).value_EXPAND_SZ();
else if (family == Font.Family.Italic)
fontFileName = fontKey.getValue(name ~ Italic
(TrueType)).value_EXPAND_SZ();
else if (family == (Font.Family.Bold |
Font.Family.Italic))
fontFileName = fontKey.getValue(name ~ Bold Italic
(TrueType)).value_EXPAND_SZ();
return fontPath ~ fontFileName;
}
}
unittest
{
assert(fontPathFromName(Arial) ==
C:/Windows/Fonts/arial.ttf);
assert(fontPathFromName(arial) ==
C:/Windows/Fonts/arial.ttf); // Test with wrong case
assert(fontPathFromName(Arial, Font.Family.Bold |
Font.Family.Italic) == C:/Windows/Fonts/arialbi.ttf);
}
Re: [Proposal] Weak reference implementation for D
On Sunday, 13 October 2013 at 07:47:55 UTC, Denis Shelomovskij wrote: --- Proposal --- The proposal is to add weak reference functionality based on `unstd.memory.weakref`. It can be placed e.g. in `core.memory`. Source code: https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d Documentation: http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151 --- Reasons --- Reasons, why we do need weak reference functionality in D (Issue 4151 [1]): 1. It has a general use. I suppose no question here. 2. It's hard to implement correctly. As a proof here are incorrect implementations written by experienced developers: * Weak reference functionality in `std.signal` implementation: https://github.com/D-Programming-Language/phobos/blob/7134b603f8c9a2e9124247ff250c9b48ea697998/std/signals.d * Alex's one from MCI: https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d * Robert's one from his new `std.signals` implementation proposal: https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d * My implementation (fixed now, I hope): https://bitbucket.org/denis-sh/unstandard/src/cb9a835a9ff5/unstd/memory/weakref.d Everybody can check his knowledge of concurrent programming and D GC by trying to understand what exactly every implementation does and where are race conditions. It's recommended to read implementations in the order provided here going to the next one as soon as you see why previous one is incorrect. For now the only [probably] fixed implementation is mine so one can see spoiler here: https://bitbucket.org/denis-sh/unstandard/history-node/HEAD/unstd/memory/weakref.d (the first and the most fixing (spoiling you joy to understand everything yourself) commit is 6f59b33) 3. It's hard to create a good API design for it. No jokes. E.g. there are two different behaviours of .NET weak references and even more in Java library. 4. It is needed for correct signals implementation in D. The lack of correct signals implementation is one of [major?] disadvantages of D. Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9606 +1 having weakref in phobos
Re: Unable to use tradional tools to find memory leaks
On Tuesday, 24 September 2013 at 01:09:29 UTC, growler wrote: Might be related to or even the same issue reported here: http://forum.dlang.org/thread/bug-1005...@http.d.puremagic.com/issues/ This is a Valgrind issue though and not DMD related. It seems I had the same issue, but for Dr Memory there is no explanation because under Windows my application is build in 32bit.
Re: Download page needs a tidy up
On Thursday, 22 August 2013 at 13:14:01 UTC, Ludovit Lucenic wrote: On Thursday, 22 August 2013 at 03:23:57 UTC, Manu wrote: I got the latest GDC from dlang.org/download, but it doesn't work. libiconv-2.dll (and possibly others?) is not included in the package. If this depends on another package being present, there is no text anywhere along the download path to inform the user. On 22 August 2013 13:07, Manu turkey...@gmail.com wrote: So I'm trying to find windows binaries for GDC and LDC... First place I look is dlang.org/download. Appears to be for DMD... keep looking. I look at the GDC/LDC wiki pages. No links to binaries anywhere. GDC and LDC home pages... no links to binaries. Github doesn't host binaries anymore... Where are they? Turns out there are links to the GDC binaries (hosted on bitbucket) on dlang.org/download. ...I didn't previously notice they were there, never scrolled down far enough. The impression you get from the top of the page is that dlang.orgis just DMD related, and I quickly dismissed it previously _ But there's still no LDC binary there... where is it? This needs to be fixed. You can argue I'm retarded and ignorant, but as an end user, it should take me no more than 5 seconds to find the download button. I suggest, on the front page of dlang.org, there should be a MASSIVE button: DOWNLOAD D COMPILERS, and the download page should be tweaked to be more obviously compiler agnostic. D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC (surely basically nobody is looking for those?), perhaps they should be reduced to small test links with the other links down the bottom of the page? This will allow room to present GDC and LDC without scrolling. And why is there no LDC binary? I am completely with you, Manu. Same with me with GDC under Windows. Missing libiconv-2.dll... The same happened to me when looking around for the other two D compilers. It took me a couple of days until I found the link on the dlang.org's download page. Any suggestions on where to get a working copy of GDC to run on Windows, please? Thanks, Ludovit I want to try gdc and I get the same error on libiconv-2.dll
Re: Unable to use tradional tools to find memory leaks
On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote: I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Do I need do something particular, to have a chance to see one of those tool working fine with my application? It can be really hard to find leaks manually, maybe some option of the gc can help me? Here is my Valkyrie output : ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#253: static bool VkCfg::checkConfigDir(const QString): ===valkyrie:3014=== No existing config dir '/tmp/valkyrie_flamaros/' = creating. ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#702: void VkCfgProj::openProject(const QString): ===valkyrie:3014=== Can't open project: File doesn't exist, or is not readable: '/home/flamaros/development/personnal/dquick/data/dquick.cfg' ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#636: void VkCfgProj::replaceConfig(QSettings*): ===valkyrie:3014=== Replacing current config with: /home/flamaros/development/personnal/dquick/dquick.cfg ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) Valkyrie::runTool( 0, 0) Current path: /home/flamaros/development/personnal/dquick/. [OpenGLContext] OpenGL Version: 2.1 Mesa 9.1.4 rootItem main vex amd64-IR: unhandled instruction bytes: 0x48 0xDF 0x1C 0x24 0x48 0xD9 0x6C 0x24 vex amd64-IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64-IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64-IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==3017== valgrind: Unrecognised instruction at address 0x5bad9a. ==3017== Your program just tried to execute an instruction that Valgrind ==3017== did not recognise. There are two possible reasons for this. ==3017== 1. Your program has a bug and erroneously jumped to a non-code ==3017==location. If you are running Memcheck and you just saw a ==3017==warning about a bad jump, it's probably your program's fault. ==3017== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3017==i.e. it's Valgrind's fault. If you think this is the case or ==3017==you are not sure, please let us know and we'll try to fix it. ==3017== Either way, Valgrind will now raise a SIGILL signal which will ==3017== probably kill your program. ToolObject::processDone( 0, 1 ) ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#687: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== Error running VgProcess: process failed (1) ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#714: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== VgProcess finished with error: stop VgReader ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#440: void ToolObject::stopProcess(): ===valkyrie:3014=== Stopping VgProcess ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#488: void ToolObject::stopProcess(): ===valkyrie:3014=== VgProcess already stopped (or never started). ===valkyrie:3014=== PS : Code was generated with gdc, my application crash exactly like with dmd, so it doesn't seems to be a linker issue. Maybe a D spec issue or Valgrind one.
Re: Unable to use tradional tools to find memory leaks
On Monday, 23 September 2013 at 20:06:20 UTC, Flamaros wrote: On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote: I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Do I need do something particular, to have a chance to see one of those tool working fine with my application? It can be really hard to find leaks manually, maybe some option of the gc can help me? Here is my Valkyrie output : ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#253: static bool VkCfg::checkConfigDir(const QString): ===valkyrie:3014=== No existing config dir '/tmp/valkyrie_flamaros/' = creating. ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#702: void VkCfgProj::openProject(const QString): ===valkyrie:3014=== Can't open project: File doesn't exist, or is not readable: '/home/flamaros/development/personnal/dquick/data/dquick.cfg' ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#636: void VkCfgProj::replaceConfig(QSettings*): ===valkyrie:3014=== Replacing current config with: /home/flamaros/development/personnal/dquick/dquick.cfg ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) Valkyrie::runTool( 0, 0) Current path: /home/flamaros/development/personnal/dquick/. [OpenGLContext] OpenGL Version: 2.1 Mesa 9.1.4 rootItem main vex amd64-IR: unhandled instruction bytes: 0x48 0xDF 0x1C 0x24 0x48 0xD9 0x6C 0x24 vex amd64-IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64-IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64-IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==3017== valgrind: Unrecognised instruction at address 0x5bad9a. ==3017== Your program just tried to execute an instruction that Valgrind ==3017== did not recognise. There are two possible reasons for this. ==3017== 1. Your program has a bug and erroneously jumped to a non-code ==3017==location. If you are running Memcheck and you just saw a ==3017==warning about a bad jump, it's probably your program's fault. ==3017== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3017==i.e. it's Valgrind's fault. If you think this is the case or ==3017==you are not sure, please let us know and we'll try to fix it. ==3017== Either way, Valgrind will now raise a SIGILL signal which will ==3017== probably kill your program. ToolObject::processDone( 0, 1 ) ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#687: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== Error running VgProcess: process failed (1) ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#714: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== VgProcess finished with error: stop VgReader ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#440: void ToolObject::stopProcess(): ===valkyrie:3014=== Stopping VgProcess ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#488: void ToolObject::stopProcess(): ===valkyrie:3014=== VgProcess already stopped (or never started). ===valkyrie:3014=== PS : Code was generated with gdc, my application crash exactly like with dmd, so it doesn't seems to be a linker issue. Maybe a D spec issue or Valgrind one. I found some leaks, but not the critical one. It seems my objects aren't correctly released when I simply set variables on a class to null. Calling explicitly clear() force immediate call of destructors. I certainly need dig into that way to find my issue. PS : MTuner can launch my application without make it crash, but it doesn't see memory of GC.
Re: Unable to use tradional tools to find memory leaks
On Monday, 23 September 2013 at 21:35:21 UTC, Flamaros wrote: On Monday, 23 September 2013 at 20:06:20 UTC, Flamaros wrote: On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote: I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Do I need do something particular, to have a chance to see one of those tool working fine with my application? It can be really hard to find leaks manually, maybe some option of the gc can help me? Here is my Valkyrie output : ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#253: static bool VkCfg::checkConfigDir(const QString): ===valkyrie:3014=== No existing config dir '/tmp/valkyrie_flamaros/' = creating. ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#702: void VkCfgProj::openProject(const QString): ===valkyrie:3014=== Can't open project: File doesn't exist, or is not readable: '/home/flamaros/development/personnal/dquick/data/dquick.cfg' ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) ===valkyrie:3014=== DEBUG: utils/vk_config.cpp#636: void VkCfgProj::replaceConfig(QSettings*): ===valkyrie:3014=== Replacing current config with: /home/flamaros/development/personnal/dquick/dquick.cfg ===valkyrie:3014=== MainWindow::runTool( tool: 0, proc: 0 ) Valkyrie::runTool( 0, 0) Current path: /home/flamaros/development/personnal/dquick/. [OpenGLContext] OpenGL Version: 2.1 Mesa 9.1.4 rootItem main vex amd64-IR: unhandled instruction bytes: 0x48 0xDF 0x1C 0x24 0x48 0xD9 0x6C 0x24 vex amd64-IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64-IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64-IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==3017== valgrind: Unrecognised instruction at address 0x5bad9a. ==3017== Your program just tried to execute an instruction that Valgrind ==3017== did not recognise. There are two possible reasons for this. ==3017== 1. Your program has a bug and erroneously jumped to a non-code ==3017==location. If you are running Memcheck and you just saw a ==3017==warning about a bad jump, it's probably your program's fault. ==3017== 2. The instruction is legitimate but Valgrind doesn't handle it, ==3017==i.e. it's Valgrind's fault. If you think this is the case or ==3017==you are not sure, please let us know and we'll try to fix it. ==3017== Either way, Valgrind will now raise a SIGILL signal which will ==3017== probably kill your program. ToolObject::processDone( 0, 1 ) ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#687: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== Error running VgProcess: process failed (1) ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#714: void ToolObject::processDone(int, QProcess::ExitStatus): ===valkyrie:3014=== VgProcess finished with error: stop VgReader ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#440: void ToolObject::stopProcess(): ===valkyrie:3014=== Stopping VgProcess ===valkyrie:3014=== ===valkyrie:3014=== DEBUG: objects/tool_object.cpp#488: void ToolObject::stopProcess(): ===valkyrie:3014=== VgProcess already stopped (or never started). ===valkyrie:3014=== PS : Code was generated with gdc, my application crash exactly like with dmd, so it doesn't seems to be a linker issue. Maybe a D spec issue or Valgrind one. I found some leaks, but not the critical one. It seems my objects aren't correctly released when I simply set variables on a class to null. Calling explicitly clear() force immediate call of destructors. I certainly need dig into that way to find my issue. PS : MTuner can launch my application without make it crash, but it doesn't see memory of GC. OK I just found my leak. That was not a real leak!!! A piece of code was turn off the GC and never put it back on.
Unable to use tradional tools to find memory leaks
I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Do I need do something particular, to have a chance to see one of those tool working fine with my application? It can be really hard to find leaks manually, maybe some option of the gc can help me?
Re: Unable to use tradional tools to find memory leaks
On Saturday, 21 September 2013 at 16:01:17 UTC, Maxim Fomin wrote: On Saturday, 21 September 2013 at 14:30:19 UTC, Flamaros wrote: I tried to used Valgrind (Linux) and Dr Memory (Windows) without success to find a big leak I have in my application. But both tools can't launch my application without make it crash. Is application crashing without these tools? Probably you have some bug which is detected by valgrind. Application run correctly without Valgring or Dr Memory. By the way, some pitfalls of using valgrind for testing D code: 1) Its implementation of float numbers at compile time is buggy (for example, there may be static asserts which are true when running under native envorionment and false under valgrind) 2) Dmd's codegen is sometimes not supported by valgrind (cannot execute some instructions which is rare case when something from D beats some tool outside) 3) It has some false positives regarding using uninitialized values especially during execution of GC code. Yes, I think it's normal, I got also some false leaks from graphics drivers. Sadly Valgrind make my application crash before the initialization is finished. I think I am in you 2 point. Do I need do something particular, to have a chance to see one of those tool working fine with my application? If you run into #2 then you cannot fix it. It can be really hard to find leaks manually, maybe some option of the gc can help me? If you look into gc sources, you can found some testing code, but it needs druntime recompilation.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 17 September 2013 at 13:03:46 UTC, Manu wrote: On 17 September 2013 21:48, Bruno Medeiros brunodomedeiros+...@gmail.comwrote: On 17/09/2013 12:37, Bruno Medeiros wrote: On 16/09/2013 22:39, Brad Roberts wrote: On 9/16/13 8:52 AM, Bruno Medeiros wrote: Correct me if I'm wrong, but I think Manu's point with regards with IDE official endorsement was more to try to have the D language organization devs (Walter, Andrei, etc.) *use* VisualD or another IDE and understand the issues around it (especially with regards to compiler/debugger integration). If that's the definition of official endorsement, then sorry, not likely to ever happen. Demanding that the core devs develop with specific tools is ridiculous in concept. Would you switch because someone told you to? Me either. I've been using vi(m) for about 20 years now. My fingers know what to do without conscious control.. I don't have the free time nor the desire to retrain myself like that. I agree, I don't think it's a realistic to expect that. I was just pointing out Manu's idea, not agreeing with it. Clarification: I think it's unrealistic to expected the core devs to use the IDE for all of their D development, yes. But it would be good to have them *try* it, to see how it works, to understand how others users would develop in D, what quality issues there could be with it, etc. In this regard I agree with Manu's comments. I'll happily wear that my assertion was heavy handed, mostly due to long-term frustration, and to some extent, this is just the way I talk (which never comes across in text to people who don't know me). Regardless of how I phrased it however, I'm encouraged to see the message was generally well received and actions have been taken. I'm keen to see if/how it affects the ecosystem in the future. I hope it does increase the overall attention/awareness. It's certains if the D language organization devs use official IDEs the quality will be improve greatly. Good reports can only come from real usages, IDEs are critical for productivity the GUI polish is something important but hard to achieved. On my project DQuick, VisualD just can't find members of classes aren't directly defined in the current module. I also try the beta of next version for code coverage with unittest without any success.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. Mainly VisualD and for linux Mono-D. Mono-D have a great auto completion.
Re: Move VisualD to github/d-programming-language ?
On Tuesday, 10 September 2013 at 06:18:16 UTC, Joseph Rushton Wakeling wrote: On 09/09/13 21:26, Flamaros wrote: Personally I think that phobos contains some parts that are in Qt base, so a wrapper isn't a perfect solution for D. It's certainly the fastest way to extend the D framework and add a GUI library, but Qt phylosophy doesn't match perfectly with D. Just take a look to moc, in D it's possible and preferable to do without it. That why we started DQuick to create a complete adaption of QtQuick to D, this is much hard to do but DQuick has the potential to be much more suitable for D. I've just had a read through your DQuick announcement thread. It looks like a really nice project -- I wish you a lot of success with this. Now, that said, while Qt may have some issues with respect to D, supporting it isn't just a matter of wanting a GUI solution. It's not just a graphical toolkit -- it's THE most important cross-platform toolkit, and has been chosen as a first-class SDK component by various platforms. I'd say that makes good and up-to-date QtD bindings a very important strategic goal. All parts of Qt that are non about GUI, like strings, io, network, regexp,... are or certainly will be in phobos. So for D applications started from ground I don't really see the benefits. But if D is compatible with Qt/C++ existing code, it will be great win. In this case QtD is clearly a strategic goal.
Re: LLVM progress
On Tuesday, 10 September 2013 at 08:36:21 UTC, Chris wrote: On Monday, 9 September 2013 at 15:56:17 UTC, Flamaros wrote: On Monday, 9 September 2013 at 10:29:56 UTC, Chris wrote: Not to mention the importance of ARM support. It's an evidence that is a major target today. :-) I work only on ARM compatible application for my day job, that why DQuick is tough to be easy to port those devices. We'll need ARM support too for our applications, sooner or later. Are you telling it's a need for D community or for your company? If it's for D community I hope be able to help a little when compilers will be ready.
Re: LLVM progress
On Monday, 9 September 2013 at 10:29:56 UTC, Chris wrote: Not to mention the importance of ARM support. It's an evidence that is a major target today. :-) I work only on ARM compatible application for my day job, that why DQuick is tough to be easy to port those devices.
Re: Move VisualD to github/d-programming-language ?
On Monday, 9 September 2013 at 09:31:59 UTC, Joseph Rushton Wakeling wrote: On 09/09/13 10:29, Russel Winder wrote: It also appears that Microsoft are beginning to think the whole CLR thing is on it's last legs. The whole all non-Windows users have to hate C# thing has some basis in fact but also had a lot of FUD associated with it. The Mono hatred stemmed from that. So will Microsoft go after Mono with patent suits if they are not themselves using C# and CLR? They possibly might as an income stream, but it is unlikely to be profitable and so may be not. I think the Mono hatred/fear stemmed from a particular time in Linux history which involved a combination of Novell's role as a major driver of Mono in GNOME, Microsoft's very aggressive patent posturing (although no actual lawsuits), and the close relationship between Novell and Microsoft that culminated in their patent agreement. I don't think Microsoft would ever bother suing over Mono patents just for money -- the concern was always that Novell's pushing of Mono was a Trojan Horse that would enable Microsoft to take down the wider Linux community and Novell to clean up on the business Linux side. Without solid support from Microsoft the C#F#/CLR culture is unlikely to remain strong, despite the serious success F# has had in making people interested in CLR. And C# is not a bad language, in many ways much better than Java. But Java has staying power in ways C#/F# do not. First-mover advantage, cross-platform for longer, less patent fear ... I gave Mono-D a whirl, but as I don't do any C# or F#, it has brought in a huge amount of dependencies. My problem is I do not understand how the Solution system is the same or different to everyone else's Project system. I guess I do not have much enthusiasm to find out as I can just use Emacs. Yes, the number of dependencies is very, very annoying if you don't want to work with C#/F#. GNOME vs. Qt may be religious to certain parties, but most people choose either GNOME or KDE for the desktop and then load the other widget set as well. I use GNOME but I have a many Qt-based things on here and indeed develop PySide and PyQt5 based systems since GNOME is a non-starter on Windows and OS X. Pragmatism is the order of the day here not religious fervour. Yes, GNOME vs. KDE is the issue, not GTK vs Qt. Installing a specifically GNOME or KDE app will pull in a ton of dependencies from the other desktop, installing a purely Qt- or GTK-based app is much less heavy (it's almost unavoidable I'd say to have both Qt- and GTK-based code on your system). I found this out recently when trying to install kcachegrind, which wanted to pull in a ton of stuff from the KDE desktop that really didn't seem necessary. It does apparently include a qcachegrind package that's purely Qt-based, but it's not packaged separately for Debian or Ubuntu :-( I think that now that Qt has escaped from Microsoft^H^H^H^H^H^H^H^H^HNokia, it will return to being one of the two primary system for cross-platform GUI systems, wxWidgets being the other. Thus I think QtD (fot Qt4 and Qt5) should be seen as an essential component of the D milieu. wxD should also get some presence. It is great we have GtkD, but I cannot see it ever having any cross-platform traction. I think that move is already happening and has been for some time -- in fact I think the resurgence of Qt has been happening ever since it was LGPL'd. My impression is that GTK/GNOME won out historically because the Qt GPL/commercial dual licence meant that there were licensing compatibility issues even for free software, and that there was a single commercial gatekeeper for proprietary software. That was an undesirable situation to have for the core graphical toolkit of an operating system, so GTK was preferred. I completely agree that QtD should be a priority project -- I think Qt's importance is only going to grow. Perhaps this is a nice point to re-iterate my earlier plea for consideration of Qt Creator as a potential cross-platform D IDE? :-) Personally I think that phobos contains some parts that are in Qt base, so a wrapper isn't a perfect solution for D. It's certainly the fastest way to extend the D framework and add a GUI library, but Qt phylosophy doesn't match perfectly with D. Just take a look to moc, in D it's possible and preferable to do without it. That why we started DQuick to create a complete adaption of QtQuick to D, this is much hard to do but DQuick has the potential to be much more suitable for D.
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 11:24:32 UTC, Russel Winder wrote: And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. I think that D visibility isn't enough for the moment to be able to convince Java or C# dev to take a look in. Those developers that build work oriented applications certainly also wait for much bigger frameworks than phobos in this actual state. The c++ developers are used to develop a lot of thing from scratch and use tiny libraries for specifics things. It will certainly take years before seeing much developers coming from Java or C# to D.
LLVM progress
I read an interesting news about LLVM : http://www.phoronix.com/scan.php?page=news_itempx=MTQ1NjI It's certainly a great things for ldc too. Is there a hope to see ldc as the main D compiler if it's full featured under Windows?
Re: DQuick a GUI Library (prototype)
On Saturday, 7 September 2013 at 15:03:22 UTC, Andrej Mitrovic wrote: On 9/7/13, Flamaros flamaros.xav...@gmail.com wrote: We choose the boost one. That's great, but your license file is empty: https://github.com/D-Quick/DQuick/blob/master/License.txt I fill the wrong file due to a wrong naming. Sorry.
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Andrei, myself and Rainer (VisualD's champion) are all in agreement on this. What do you think? It would be great.
Re: LLVM progress
On Saturday, 7 September 2013 at 19:35:47 UTC, Russel Winder wrote: On Sat, 2013-09-07 at 10:08 -0700, Walter Bright wrote: […] Having 3 different D compilers with different strengths and weaknesses spurs improvements in all of them. When I was at GoingNative2013, it was pretty obvious to me that the playful and friendly competition between gcc, clang, and vc has improved all three greatly. As has been proved in many areas of life, having multiple players in a game validates the game. Having multiple compilers, books, IDEs etc. for D programming is a mark that D is player in the programming languages game. Sadly D is still not competing against C++ in the way it deserves. Of course C++ is now a niche language. The primary war just now is native vs. VM, and VM remains in the ascendency. Go and Rust are the poster children for native due to their backers. The questions is whether D should position itself in this war. I say yes. There needs to be more books on D, and use of D in various areas. QtD, GtkD, (wxD?), D drivers for SQL, Mongo, Couch, Redis, Neo, Riak, etc. all need to be high quality and pushed via reports and talks at non-D conferences. Vibe.d is a huge possibility now that Node.js is losing it's lustre and Vert.x and Go are getting serious traction. (At least in the small start-ups arena.) D in GCC and D on LLVM are, for me, far more important than DMD, since they provide penetration into the market via the market leaders. D on Linux via GCC and LLVM, D on OX S via LLVM, (and on Windows, I suppose, via any route :-). That also my concern, LLVM tends to replace gcc as C/C++ compiler. LLVM promise to simplify languages compatibility, Apple show us how much is important to improve developers productivity. Google think in the same way with the Go. I think the LLVM message is : developers would be more productive if compiler generate better reports, can aggregate more pieces of software and have better tools (IDE, static analyzer, debugger). In this way D and LLVM philosophies seems compatible. The issue for me is to stop worrying about internal contemplative reflection on 10 years of D evolution, and get knowledge of the real-world use of D out there and in people's faces. Stop looking inward and start looking outward. This is the trick Go and Rust have picked up, albeit not as well as they could. D is a major player in the GCC and LLVM worlds, let's take this as read and exploit it for the future of high-quality, effective and pleasurable native code development.
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 22:50:45 UTC, Joseph Rushton Wakeling wrote: On 08/09/13 00:35, Paulo Pinto wrote: Well, if you want a production quality multi-platform IDE the only options are InteliJ and Eclipse, both of which are not that well received by most C and C++ guys. The target audience for D. That is my humble opinion, regarding the type of tooling I expect from an IDE. For a cross-platform IDE, I can't say I have that much experience, but I'd be inclined to give Qt Creator some serious consideration. Seemed nice in and of itself, it's properly cross-platform -- if I was writing much C/C++ these days I'd probably be using it. I'm not sure how easy it is to write plugins for other languages and compilers, but I think it'd be worth looking into. I had try, it seems feasible, but it's an huge amount of work. It's preferable to let contributors choose for which IDE they want add D support. If you want try with QtCreator is a good thing, but it will certainly best to concentrate effort on projects that are already usable. I hope to see MonoD on github/d-programming-language too if it's the case of VisualD.
Re: Add support implicit conversion between types
On Friday, 6 September 2013 at 10:33:07 UTC, ilya-stromberg wrote:
Do you have any plans to support implicit conversion between
types?
I have some code like this:
struct Foo
{
this(int i)
{
//do something useful
}
}
void bar(Foo f)
{
//do something else
}
void main()
{
Foo f = 5;//works
bar(f);//works
bar(Foo(5));//works
I think that the good way, to do
bar(5);//Error: function app.bar (Foo f) is not callable using
argument types (int)
}
So, D can't use constructor to convert int to Foo
implicitly.
Can we add implicit keyword to allow do this:
struct Foo
{
implicit this(int i)
{
//do something useful
}
}
C++ allows this, but have explicit keyword.
C# doesn't allow this, but have operator overloading for both
implicit and explicit cases.
It's difficult to never forget the explicit keyword in c++, and
this little mistake can make you loose a lot of time.
I prefer to only have explicit conversions with cast or
constructors calls, that all make the code easier to understand.
Re: DQuick a GUI Library (prototype)
On Friday, 6 September 2013 at 15:25:25 UTC, Andrej Mitrovic wrote: On 8/22/13, Flamaros flamaros.xav...@gmail.com wrote: After the publication of our sources : https://github.com/D-Quick/DQuick P.S.: You should really add license headers in your files and/or a license file. Certainly, I'll try to do it this weekend.
Re: DQuick a GUI Library (prototype)
On Friday, 6 September 2013 at 20:56:25 UTC, Flamaros wrote: On Friday, 6 September 2013 at 15:25:25 UTC, Andrej Mitrovic wrote: On 8/22/13, Flamaros flamaros.xav...@gmail.com wrote: After the publication of our sources : https://github.com/D-Quick/DQuick P.S.: You should really add license headers in your files and/or a license file. Certainly, I'll try to do it this weekend. We choose the boost one.
Re: DQuick a GUI Library (prototype)
On Thursday, 5 September 2013 at 17:52:25 UTC, Flamaros wrote: On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality A little news : We works on text rendering and D objects binding. PS : D objects means that an instance of a D class can be accessible from Lua scripts. Only method with supported types are accessible, we will add the possibility to declare D classes for non Lua Types. https://github.com/D-Quick/DQuick
Re: DQuick a GUI Library (prototype)
On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality A little news : We works on text rendering and D objects binding. https://github.com/D-Quick/DQuick
[Font] Getting font folder on all platforms
I am searching the right way to find fonts folder for each platforms (Windows, linux, macOS X) On Windows it's generally C:\Windows\Fonts but a direct access seems brutal, it's certainly expected to retrieve this path by using some register keys? Is someone know how it works for linux and/or macOS X? I need to be able to retrieve fastest as possible the right file from the font and family name.
Re: [Font] Getting font folder on all platforms
On Thursday, 5 September 2013 at 19:59:20 UTC, Justin Whear wrote: On Thu, 05 Sep 2013 21:48:03 +0200, Flamaros wrote: I am searching the right way to find fonts folder for each platforms (Windows, linux, macOS X) On Windows it's generally C:\Windows\Fonts but a direct access seems brutal, it's certainly expected to retrieve this path by using some register keys? Is someone know how it works for linux and/or macOS X? I need to be able to retrieve fastest as possible the right file from the font and family name. For linux, see fontconfig: http://en.wikipedia.org/wiki/Fontconfig http://www.freedesktop.org/software/fontconfig/fontconfig-user.html Thx
Re: XML RPC Client and Server - meet xmlrpc-d
On Sunday, 1 September 2013 at 19:50:47 UTC, Pavel Kirienko wrote:
Hi everyone,
I am working on some D-based project that needs to call and
serve XML-RPC procedures with multiple output parameters. Quick
lookaround revealed that:
1. There are no XML-RPC servers implemented in D, or wrapped in
D;
2. There are some simple XML-RPC clients, but no one supports
methods with multiple output parameters.
So I decided to write ultimate XML-RPC library that could
follow XML-RPC standard as close as ... well, as I could manage
it. :)
Grab your copy here: https://github.com/pavel-kirienko/xmlrpc-d
D's compile-time introspection is utterly amazing, it enables
such features as automatic conversion of a value which type is
not known at compile-time to something predefined. This makes
possible to define XML-RPC methods in the simplest way possible
(as regular functions), all the boring job of turning the
function parameters into XML-RPC types and vice versa is
carried out by compiler with the help of the Variant type:
--
real multiply(real a, real b) { return a * b; }
xmlrpcServer.addMethod!multiply();
--
Which also makes possble such weird things like that:
--
// multiply() expects two arguments of type 'real' and returns
'real',
// but we call it with strings:
string ret = client.call!(multiply, string)(6, 9);
--
Take a look into the 'example' directory on the Github page to
see more examples.
It is worth to mention that this is my first project in D - I
was concurrently studying The D Programming Language by
Andrei Alexandrescu (great book Andrei!), thus the code may
need some review.
Good luck with your projects,
Pavel.
We'll need RPC for our projects, we are interested.
I hope you'll made pull requests for an integration to phobos.
Good luck.
Re: XML RPC Client and Server - meet xmlrpc-d
On Monday, 2 September 2013 at 15:54:12 UTC, Pavel Kirienko wrote: On Monday, 2 September 2013 at 15:37:16 UTC, ilya-stromberg wrote: On Monday, 2 September 2013 at 15:12:24 UTC, Pavel Kirienko wrote: So, the question is: shall I make a pull request for xmlrpc-d with no HTTP server included? Is there anyone who have a solid HTTP server which is good enough for the standard library? We could cooperate. As I know, the Vibe.d is good: https://github.com/rejectedsoftware/vibe.d But I don't know if it will be useful for you. I know vibe.d, but it does not seem to be going into phobos, does it? I should warn - it won't be easy and is likely to require lot of work from contributor. Recent trend in Phobos contribution is to require good integration with existing modules and approaches - you can have a look at `std.serialization` threads to see what Jacob is going to go through to get to voting. Yeah it is not so easy I know, and I'm not sure I can make time for that right now. However, if someone wants to volunteer I'd glad to help. I don't think a real server is needed here. A simple listen on a port is sufficient.
Iterate over a string to get unicode codes
Is there a simple way to extract from a string all Unicode codes as uint values?
Re: Iterate over a string to get unicode codes
On Sunday, 1 September 2013 at 14:11:54 UTC, Adam D. Ruppe wrote:
On Sunday, 1 September 2013 at 14:07:00 UTC, Flamaros wrote:
Is there a simple way to extract from a string all Unicode
codes as uint values?
string foo = whatever;
foreach(dchar ch; foo) {
// ch is the code point as a 32 bit number
// use it directly or cast to uint here
}
Thx, it's easier than I thought.
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 19:11:25 UTC, Ramon wrote: On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote: On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote: On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: Right now, having no way to actually update that site to add a notice to this effect On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person. He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R By reading this thread I just learn that dsource.org is dead. And by going deeper in the wiki I found a page that replace dsource.org as an entry point to D related projects : http://wiki.dlang.org/Libraries_and_Frameworks I think this page should be more visible on dlang to show how much the community is large to the newcomers. Maybe a Dquick will have a little place near others GUI Libraries when it will be more than a protytpe. I can see that all multi-platforms ones are wrappers and others only support Windows. I am a Windows user, but I don't understand why others platforms are forgotten.
Re: obsolete D libraries/modules
On Saturday, 31 August 2013 at 23:03:48 UTC, Andrej Mitrovic wrote: On 9/1/13, Flamaros flamaros.xav...@gmail.com wrote: I am a Windows user, but I don't understand why others platforms are forgotten. I think it's because win32 is the easiest to create a native library for, since the standard API functions for creating windows and widgets has been the same for many years. On OSX you probably have to interact with Objective-C code, which IIRC is hard to do from D without some extra language support (there's some pull request for it). And on Posix you basically don't have a standard API, so front-end libraries typically use GTK or Qt as the backend. Yep, I know that for linux it's hard to use X11 or XCB direcly. Today linux window manager (unity, KDE) seems want migrate form gtk to QML that can interact efficiently with modern window compositors (wayland, Mir). Old GUI systems are to different on platforms that why we made the choice of doing something like QML which is based on a 3D renderer. If I am not wrong that so much hard to wrap native GUI systems in a portable way than QtWidgets is manually written to mimic native GUI.
Re: DQuick a GUI Library (prototype)
On Friday, 30 August 2013 at 10:12:25 UTC, Gour wrote: On Thu, 29 Aug 2013 19:08:09 +0200 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Anyway, as a simple GUI library it might even be worth wrapping. But I think the DQuick devs and D programmers want something much more. Based on what I've seen, Tk-8.6 is quite good and available *today*, while DQuick is still prototype only. Sincerely, Gour The way will be very long for DQuick, I only start working on font rendering. It would certainly took years before seeing something usable for production with DQuick, and only if the development doesn't stop before this point.
Re: DQuick a GUI Library (prototype)
On Thursday, 29 August 2013 at 17:08:22 UTC, Andrej Mitrovic wrote: On 8/22/13, goughy and...@goughy.org wrote: Could I recommend you evaluate IUP first? (http://www.tecgraf.puc-rio.br/iup/) I've had another look at this, and the documentation tells me there's limitations and generally a requirement to handle platform-specific behavior in many cases, which could get in the way. For most widgets, after you create them, you can't change their behavior except maybe their appearance (e.g. text and image). That's a big limitation imo. There's platform-dependent behavior that you need to be aware of, such as: - When you change the active tab the focus is usually not changed. If you want to control the focus behavior call IupSetFocus in the TABCHANGE_CB callback. Unfortunately this does not works in GTK and in Motif, because in both systems the focus will be set by the system after the callback is called. - There's a lot of these GTK/Windows specific notes, I'd hate to end up writing a lot of code wrapped inside of version(GTK) statements. There's basic features not supported such as: - Notice that there is no attribute to disable a single tab. This is a design decision of all native toolkits, not a IUP decision. It is so because a disabled tab is a confusing interface situation. - Tcl's Tk does it, as does Qt, and probably other libraries. Here's the Tkinter version: http://www.pyinmyeye.com/2012/08/tkinter-notebook-demo.html. Anyway, as a simple GUI library it might even be worth wrapping. But I think the DQuick devs and D programmers want something much more. As DQuick isn't based on OS native GUI libraries and it's intend to have exactly the same behaviors of those native libraries, the user will have the responsibility to customize those kind of behaviors. In the default package there will be no support for focus for sample. I don't know how is it on other OS, but on windows buttons and scroll-bars have really weird behaviors, for scroll-bars you'll loose control on it if your mouse cursor is too far (button always down), but when the cursor come back to an acceptable distance the scroll-bar move appropriately,... With DQuick it will not a problem to have larger mouse area than a button which is really useful for interfaces controlled by fingers. To have some controls (around widget) that have simple behaviors acceptable for almost all OS/platform, we'll certainly do something like QtQuick Controls. This is an add-on which provide a simple way to support focus.
Re: DQuick a GUI Library (prototype)
On Friday, 23 August 2013 at 06:29:53 UTC, Jacob Carlborg wrote: On 2013-08-22 15:43, Flamaros wrote: A lot of GUI system that respect the MVC system put the controller in the native code. And you don't want that? Or what has that do to with anything? With DQuick the Controller is in the script side, it's more flexible. Imagine a list of thumbnail of projects, to put a special thumbnail in the list that will allow creation of a new one. This special '+' thumbnail is created completely on the script side. If GUI designer want to go back on this design the developer will not be impacted because he can modify the controller with the view.
Re: DQuick a GUI Library (prototype)
On Friday, 23 August 2013 at 07:19:39 UTC, Gour wrote: On Tue, 20 Aug 2013 23:22:45 +0200 Flamaros flamaros.xav...@gmail.com wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. The state of GI bindings in D was the main reason I gave up idea to use D for writing multi-platform GUI app in this nice language. Gtk(D) does not look good on anything which is non-Linux and the state of the GTK support on both Mac OS X Windows is pretty poor. There are no Qt bindings and nothing, afaik, happened from the attempt to provide wx bindings, so your project might provide some light at the end of the tunnel giving hope to use D as 'general programming language'. Wishing you all the best! Sincerely, Gour Thank you for your encouragements.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 07:24:10 UTC, Jacob Carlborg wrote: On 2013-08-22 01:35, Sebastian Graf wrote: +1 from me too. I had exactly the same idea some time ago, but was overwhelmed by the shear complexity. If you go the lua route, you should look into MoonScript.org (CoffeeScript for lua = nicer function literals) and dig into reactive programming and my take on it: https://github.com/sgraf812/push CoffeeScript is nice too. But I don't see a reason to use something other than a markup language if only a GUI builder should read and write those files. The GUI editor will allow to write expression in addition of a classic value setter. It's really useful to have few pieces of code directly on the GUI side notably when it's only related to the organisations of GUI elements.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 09:15:27 UTC, Jacob Carlborg wrote: On 2013-08-22 10:29, Flamaros wrote: The GUI editor will allow to write expression in addition of a classic value setter. What do you mean with expression ? something like : function() return parent.width end That the way of how works property binding.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 11:39:29 UTC, Jacob Carlborg wrote: On 2013-08-22 11:28, Flamaros wrote: something like : function() return parent.width end That the way of how works property binding. Can't you bind that to a named method in a controller, or similar? Then you would store the name of the controller/class and the name of the method. That not always so simple. With DQuick the D application is like a slave that contains data, and the GUI is free to display the data in many ways. Property binding act like a part of the controller if we are talking about the MVC model. Notice that if a data in the application side change, depending properties binding will be updated, so the GUI too. At my office we port an application from iOS to Android, Windows and MacOSX. We actually rewrite the GUI for other platforms in QtQuick, which allow us to let the main code has it. We only add few wrappers because QtQuick support only Qt types for objects we need to bind in QML (javascript language used for GUI).
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 12:34:20 UTC, Andrej Mitrovic wrote: But otherwise I agree starting from scratch is really difficult. That the reason we only tell that is a prototype, we firstly want to test the property binding concept, and we choose D because we like it.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 13:20:25 UTC, Jacob Carlborg wrote: On 2013-08-22 15:01, Flamaros wrote: That not always so simple. With DQuick the D application is like a slave that contains data, and the GUI is free to display the data in many ways. Property binding act like a part of the controller if we are talking about the MVC model. Notice that if a data in the application side change, depending properties binding will be updated, so the GUI too. If I understand you correctly that's how it work on using Xcode on Mac OS X as well. But Apple manage without a script language for the GUI code. It's XML and a binary format. A lot of GUI system that respect the MVC system put the controller in the native code.
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 13:29:10 UTC, Andrej Mitrovic wrote: On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: It doesn't seem to support OSX, Unicode, cascading menus: http://www.tecgraf.puc-rio.br/iup/en/to_do.html But otherwise I agree starting from scratch is really difficult. Plus it seems to flicker on resize. It's not looking good. Yep, it's a known issue. I don't know why the resize event of window come so late, it seems to be a SDL issue. I began a direct win32 implementation, but their is no display for the moment, something seems to be wrong with the opengl context.
Re: DQuick a GUI Library (prototype)
On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality After the publication of our sources : https://github.com/D-Quick/DQuick I have migrate our bugs report too : https://github.com/D-Quick/DQuick/issues?state=open
Re: DQuick a GUI Library (prototype)
On Thursday, 22 August 2013 at 13:08:46 UTC, Jakob Ovrum wrote: On Tuesday, 20 August 2013 at 21:22:48 UTC, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality If you do decide to use Lua, I strongly recommend checking out LuaD[1]. Shameless self-promotion, yes; but the goal of LuaD is to be an uncompromising, superior alternative to using the Lua C API directly, for any project. [1] https://github.com/JakobOvrum/LuaD As we decided to open our code, we'll accept pull request. All Lua related code is in the folder : src/dquick/script Entry point of those object is dmlEngine.d repo : https://github.com/D-Quick/DQuick
Re: DQuick a GUI Library (prototype)
On Wednesday, 21 August 2013 at 08:04:23 UTC, Jacob Carlborg wrote: On 2013-08-20 23:22, Flamaros wrote: I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing I don't think Lua will work in this community. I've tried with Ruby and people didn't like it. Although it might be different with Lua. My experience is you have two choices: a markup language, i.e. JSON, YAML and so on or using D. Markup languages can't be used in our case, we need to provide scripting capabilities. It's a prototype essentially cause of Lua, that why we think to add a front-end to simplify the Lua syntax like removing function() ... end for property binding. For the moment we can't use D as script language for our project, just because there is no API to parse and execute a d file as script.
Re: DQuick a GUI Library (prototype)
On Wednesday, 21 August 2013 at 09:23:27 UTC, Jacob Carlborg
wrote:
On 2013-08-21 11:10, Flamaros wrote:
For the moment we can't use D as script language for our
project, just
because there is no API to parse and execute a d file as
script.
You can do something like this:
import dquick.dsl;
import std.stdio;
void executeSciprt ()
{
mixin(import(foo.d));
}
void main ()
{
initialize();
executeSciprt();
writeln(DQuickDsl.serialize());
}
When you want to execute the D script you use the above as a
template and only need to replace the file name, in this case
foo.d, and create a file. Compile that file run the resulting
executable, this is easily done using rdmd. Retrieve the
serialized data, deserialized it and do want you need with the
data structures.
Maybe something can be done with a load of a compiled dll
resulting of the compilation of script files. But it doesn't
seems to be a really good way.
I am not sure to understand correctly your suggestion, I don't
see how the application will be able to create GUI items from
foo.d. Need foo.d embed a code to serialize the GUI items
structure to a file that the application will load?
Re: DQuick a GUI Library (prototype)
On Wednesday, 21 August 2013 at 10:30:59 UTC, Andrej Mitrovic wrote: On 8/21/13, dennis luehring dl.so...@gmx.net wrote: why use scripting at all - D is blasting fast compiled - so whats the benefit of using another language - i understand the need for C++ based systems but in D... I still don't understand what DQuick has to do with D if you end up having to use a separate scripting language to use it. Wouldn't it then be more appropriate to post about DQuick in the Lua newsgroups? DQuick is for D applications, scripts are just for interfaces. Interfaces have to be separate from the application to be edited by artists or other non developer persons. Here is a link to our model (QtQuick samples) : http://www.youtube.com/watch?v=8G4U7QWRajg The main advantage of D is the traits that simplify the binding of D objects to the script language. Qt use moc to do this and it's really intrusive, because it extend the c++ syntax. Our solution is directly based on primitive types of D. Instead of QtQuick if DQuick isn't ported to a platform, it will easier to use the native GUI library for this particular platform. With Qt wrappers have to be create to convert types (QList = std::list,...)
Re: DQuick a GUI Library (prototype)
On Wednesday, 21 August 2013 at 11:28:23 UTC, dennis luehring wrote: Am 21.08.2013 13:18, schrieb Flamaros: On Wednesday, 21 August 2013 at 10:30:59 UTC, Andrej Mitrovic wrote: On 8/21/13, dennis luehring dl.so...@gmx.net wrote: why use scripting at all - D is blasting fast compiled - so whats the benefit of using another language - i understand the need for C++ based systems but in D... I still don't understand what DQuick has to do with D if you end up having to use a separate scripting language to use it. Wouldn't it then be more appropriate to post about DQuick in the Lua newsgroups? DQuick is for D applications, scripts are just for interfaces. and why not use D as the scripting language as the remedygames guys do? or just using Lua because its already running? The remedy solution isn't portable and/or to hard to put in place for a prototype. Yes Lua is a easier to use for us.
Re: DQuick a GUI Library (prototype)
On Wednesday, 21 August 2013 at 11:44:19 UTC, Jacob Carlborg wrote: On 2013-08-21 12:30, Andrej Mitrovic wrote: I still don't understand what DQuick has to do with D if you end up having to use a separate scripting language to use it. Wouldn't it then be more appropriate to post about DQuick in the Lua newsgroups? I assume: A. It's written in D B. You can write GUI code in D as well. This syntax is just something that should be easier, possibly something that a GUI builder can generate and parse D syntax isn't an issue. We want do a GUI editor that can generate and parse GUI files. We need take a deeper look to your proposition.
Re: DQuick a GUI Library (prototype)
I may forget to tell that we want to be able to reload the GUI dynamically for the editor. It have to be possible to edit a property binding code without reloading the application.
DQuick a GUI Library (prototype)
I want to share a short presentation of the project I am working on with friends. It's a prototype of a GUI library written in D. This pdf contains our vision of what the project would be. Samples are directly extracted from our prototype and works. We are not able to share more than this presentation for the moment because a lot of things are missing and it's plenty of bugs. The development is really slow, so don't expect to see a real demonstration a day. The link : https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing PS : Download it for a better quality
Re: working on the dlang.org website
I found a nice documentation website : http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/index.html?url=cpp_ref/_common_2_common_8cxx-example.html,topicNumber=cpp_ref__common_2_common_8cxx_example_htmlc507b7ce-aa2f-4c44-b08f-90c94f43730b There is all sources of sample, and code is highlighted with link to methods docs. I think it will be a good thing to have real unittest linked with the documentation of D, just because instead embedded samples we are sure that is executable as it (no missing import, syntax error,...). It seems that is a bad idea to have specific code samples for the documentation, it's generally out of date,... Is it feasible to have docs that extract chunks of real unittest as samples?
Re: dsource.org down
On Sunday, 4 August 2013 at 15:36:36 UTC, Tobias Pankrath wrote:
On Saturday, 3 August 2013 at 21:31:57 UTC, MattCoder wrote:
On Saturday, 3 August 2013 at 18:12:03 UTC, Flamaros wrote:
I am getting an internal error on page :
http://www.dsource.org/
Just one note: early morning I was trying to access:
http://dlang.org/lex.html but it was too slow.
Try to disable javascript.
For dsource.org it seems to be a server error.
I get this :
If you think this really should work and you can reproduce it,
you should consider reporting this problem to the Trac team.
Go to http://trac.edgewall.org/ and create a new ticket where you
describe the problem, how to reproduce it. Don't forget to
include the Python traceback found below.
Python Traceback
Traceback (most recent call last):
File /usr/lib64/python2.5/site-packages/trac/web/main.py,
line 484, in dispatch_request
dispatcher.dispatch(req)
File /usr/lib64/python2.5/site-packages/trac/web/main.py,
line 208, in dispatch
req.authname = self.authenticate(req)
File /usr/lib64/python2.5/site-packages/trac/web/main.py,
line 172, in authenticate
authname = authenticator.authenticate(req)
File build/bdist.linux-x86_64/egg/dsource/auth.py, line 49,
in authenticate
db = self.env.get_central_db_cnx()
File build/bdist.linux-x86_64/egg/dsource/env.py, line 45, in
get_central_db_cnx
return CentralDatabaseManager(self).get_connection()
File /usr/lib64/python2.5/site-packages/trac/db/api.py, line
74, in get_connection
return connector.get_connection(**args)
File
/usr/lib64/python2.5/site-packages/trac/db/postgres_backend.py,
line 40, in get_connection
return PostgreSQLConnection(path, user, password, host, port,
params)
File
/usr/lib64/python2.5/site-packages/trac/db/postgres_backend.py,
line 112, in __init__
cnx = psycopg.connect(' '.join(dsn))
OperationalError: FATAL: could not access status of transaction 0
DETAIL: could not write to file pg_subtrans/BE1B at offset
24576: No space left on device
Re: Template functions, can we make it more simple?
On Friday, 2 August 2013 at 20:34:04 UTC, SteveGuo wrote:
I'm not an expert on programming language, if I made a naive
issue, just forgive me:p
Can we declare a template function like this?
auto Add(a, b) // Note a, b do not have type, that means a and
b use template type
{
return a + b;
}
auto Sub(a, int b) // a uses template type, b is fixed to int
{
return a - b;
}
When we call the function,
Add(1, 2); // deduced to be Add(int, int);
Add(1.5, 2.3); // deduced to be Add(double, double);
Add(1.5, Hello); // compiler error!
Sub(1.5, 1); // deduced to be Add(double, int);
Sub(1, 1.1); // deduced to be Add(int, int); compiler error,
double can not converted to int automatically
I prefer the current template syntax, it's nice to want to reduce
the number of keywords/syntax, but generally to understand the
code it's better for productivity to have something really
explicit.
When you read an old code or something written by someone else
it's really important to see at the first sight what the code is
intended to do.
auto keyword hide too much how variables are used, is it ref?
const?,...
dsource.org down
I am getting an internal error on page : http://www.dsource.org/
Re: working on the dlang.org website
On Sunday, 14 July 2013 at 04:56:46 UTC, Val Markovic wrote: There's some low-hanging fruit with the site that shouldn't be too hard to fix: there's an incredibly annoying content flash after any page is loaded (it loads fine, you see the text, then the text disappears for a second, then appears again). The flash content bother me, because it breaks my scroll. I think this web site is too much oriented on documentation. The home page must display news about D language, it will be great to have videos of DConf on it directly. The documentation need to be a specific section that allow us to browse all versions (documentation is related to a specific version of the compiler).
atomic Weapons: The C++ Memory Model and Modern Hardware
http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/ Is D and DMD aware of those kind of issues with atomic?
Re: Slow performance compared to C++, ideas?
On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote: On 8 June 2013 13:25, Walter Bright newshou...@digitalmars.com wrote: On 6/7/2013 5:15 PM, Manu wrote: I can tell you that in my case, we export a lot(/most) things. Renderer api, sound api, etc are often all in their own libraries. So none of them are ever eligible for optimisation. I'm curious why these exports all must be classes, and cannot be structs? Because they embody functionality, not just data. That's just how many many programmers write code. Go to university for a couple of years, see what they tell you... ;) Some of these systems can effectively be considered plugins. Consider OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to choose from. I can see why many people feel it's natural to design their API's/systems that way, right or wrong. I don't agree with it personally, I would write it differently, but I'll never win that argument. Tech/systems programmers are vastly outnumbered in most studios. And of course, most programmers are junior-mid experience, that's just commercial reality. Personally, I never understood why portability must pass by a plugin architecture. In our game engine we use macro to build the right implementation depending on the target platform and pure interfaces to be sure that API are respected. It's not an issue, because the user don't have to be able to choose the sound backend, and developer can do it for testing but it requires a full rebuild (a real issue due to the C++ slow compilation).
Re: Path as an object in std.path
On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote: Hello, I'd like to open up the idea of Path being an object in std.path. I've submitted a pull (https://github.com/D-Programming-Language/phobos/pull/1333) that adds a Path struct to std.path, which exposes a much more palatable interface to path string manipulation. As jmdavis points out, this has previously been discussed. However, I can't find that discussion, and I think that the benefits of including an OO way to deal with paths is a serious gain for the standard library. Why I think it should be reconsidered for inclusion in the std (listed in the pull): * Adds a (more) platform independent abstraction for path strings. * Path provides a type safe way to pass, compare, and manipulate arbitrary path strings. * It wraps over the functions defined in std.path, so behavior of methods on Path are, in most cases, identical to their corresponding module function. I'd like some feedback on what others think about this; I'd hate to see this commit closed due to a discussion that happened at a different point in D's development when the language had different needs. Thank you. I like the idea to manipulate paths trough an object. API that taking path as parameter as better typed than with string. It's really usefull for file loaders, it's affirm the method will do path related operation and expect a particular string format. Some methods seems miss like completeBaseName and completeSuffix. You can take a look to : Qt API http://qt-project.org/doc/qt-4.8/qfileinfo.html The bad thing with the Qt API it's we can't know which method do a file system access, that why I prefer having 2 separated ojects. It would be good to have the FileInfo object.
Re: Path as an object in std.path
On Thursday, 6 June 2013 at 07:26:53 UTC, Flamaros wrote: On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote: Hello, I'd like to open up the idea of Path being an object in std.path. I've submitted a pull (https://github.com/D-Programming-Language/phobos/pull/1333) that adds a Path struct to std.path, which exposes a much more palatable interface to path string manipulation. As jmdavis points out, this has previously been discussed. However, I can't find that discussion, and I think that the benefits of including an OO way to deal with paths is a serious gain for the standard library. Why I think it should be reconsidered for inclusion in the std (listed in the pull): * Adds a (more) platform independent abstraction for path strings. * Path provides a type safe way to pass, compare, and manipulate arbitrary path strings. * It wraps over the functions defined in std.path, so behavior of methods on Path are, in most cases, identical to their corresponding module function. I'd like some feedback on what others think about this; I'd hate to see this commit closed due to a discussion that happened at a different point in D's development when the language had different needs. Thank you. I like the idea to manipulate paths trough an object. API that taking path as parameter as better typed than with string. It's really usefull for file loaders, it's affirm the method will do path related operation and expect a particular string format. Some methods seems miss like completeBaseName and completeSuffix. You can take a look to : Qt API http://qt-project.org/doc/qt-4.8/qfileinfo.html The bad thing with the Qt API it's we can't know which method do a file system access, that why I prefer having 2 separated ojects. It would be good to have the FileInfo object. Having an object will also remove format normalization, with a string as parameter the normalization method have to always be called.
Re: Slow performance compared to C++, ideas?
On Thursday, 6 June 2013 at 23:48:33 UTC, Walter Bright wrote: On 6/6/2013 3:12 PM, Jonathan M Davis wrote: On Thursday, June 06, 2013 14:57:00 Walter Bright wrote: On 6/6/2013 2:23 PM, Andrei Alexandrescu wrote: (The tool I'm envisioning would add final annotations or prompt the user to add them.) Sorry, that's never going to fly. It could tell the programmer which functions it _thinks_ don't need to be virtual, but it can't be 100% correct. So, it would effectively be a lint-like tool targeting possible devirtualization opportunities. It would actually be potentially useful regardless of whether virtual or non-virtual is the default, since programmers may have needlessly marked functions as virtual. But if it's a question of whether it's a good solution for optimizing away virtuality instead of making functions non-virtual, then I don't think that it would fly - not if optimization is a prime concern. It would just be a nice helper tool for static analysis which could give you suggestions on things you might be able to improve in your program. I know. But people are never going to use that tool. I think it depend of his simplicity and integration in the common D process development. Maybe because D build fast we can add some extra steps during build of the release? And developers of companies that develop the biggest application will be aware of this tool and certainly have script or advanced tools to build their software release, adding a line during the building process seems acceptable.
Re: Slow performance compared to C++, ideas?
On Tuesday, 4 June 2013 at 07:12:34 UTC, Walter Bright wrote: On 6/3/2013 11:49 PM, deadalnix wrote: We can do it in a D specific way (using our own metadata and providing an optimization pas for LLVM) but most likely we won't even need to as the same feature is planned to be added to clang and we can most likely simply reuse clang's metadata. There is another way. D can be made aware that it is building an executable (after all, that is why it invokes the linker). If you shove all the source code into the compiler in one command, for an executable, functions that are not overridden can be made final. I think is interesting, because all open source software can be build from sources and can also be done on some commercial products in certain conditions. And compiling the world with D is realistic, due to small compilation time. I also don't understand why compilers don't generate executable directly and use a linker, as they already know the binary format and do optimization. I case of DMD which take all source file in a raw, I don't see any issues. Do DMD do best inlining optimizations than the linker when it get all sources as parameter?
Re: Nested class defined in another file
On Monday, 3 June 2013 at 22:39:39 UTC, Ali Çehreli wrote: On 06/03/2013 03:20 PM, Bruno Deligny wrote: I began to separate them by hand by passing a parent reference but it's ugly because i need to make the parent members accessible in public to have acces. Is there any friend like in C++ to keep them private to others? Have you considered the 'package' access specifier? It allows access to the modules of the same package but not to others. Ali It seems exactly what we are looking for. Thx.
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote: On Thursday, 30 May 2013 at 12:55:29 UTC, Rainer Schuetze wrote: On 17.05.2013 19:43, Rainer Schuetze wrote: On 12.05.2013 20:48, Walter Bright wrote: On 5/11/2013 3:39 AM, Rainer Schuetze wrote: a new version of Visual D is long overdue, so finally it is released. In addition to the usual fixes of bugs and regressions, the major highlights of this version are This deserves a much higher profile. Few people know about it. Can you write a brief article about Visual D? Then we can link to it, and post it on Reddit. I'm lagging behind on documentation anyway, so if I find the time, I'll try to do it as an article. Probably a bit late, but here is a short article about the new version with some bias towards Unittesting and code coverage analysis with Visual D: http://www.dsource.org/projects/visuald/wiki/News36 I missed that, it's a good remainder, thank you. It certainly help a lot the community. I followed indications, lst files are correctly generated for the code coverage, but I don't have the coloration in the editor. Can be because my application crash when exiting?
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote: On 01.06.2013 12:45, Flamaros wrote: On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote: I followed indications, lst files are correctly generated for the code coverage, but I don't have the coloration in the editor. Can be because my application crash when exiting? If your application crashed, the lst file might be from a previous run and is considered out of sync. Please check whether it is newer than the source file. Also, it has to be in the same folder with the same base name as the source. I've recently noticed that the lst files generation seem to replace '/' with '-' in path names making it pretty unpredictable were to look for files when all you know the source file name. I'll have to add a workaround for that. When I check last modification of lst files it seems good. Effectively files name contains '-' characters (ex : ..-src-dquick-item-mouseAreaItem.lst) Source file naming prevent '-' characters, so if everybody follow this rule replacing '-' by '/' will allow you to get right paths.
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On Thursday, 30 May 2013 at 12:55:29 UTC, Rainer Schuetze wrote: On 17.05.2013 19:43, Rainer Schuetze wrote: On 12.05.2013 20:48, Walter Bright wrote: On 5/11/2013 3:39 AM, Rainer Schuetze wrote: a new version of Visual D is long overdue, so finally it is released. In addition to the usual fixes of bugs and regressions, the major highlights of this version are This deserves a much higher profile. Few people know about it. Can you write a brief article about Visual D? Then we can link to it, and post it on Reddit. I'm lagging behind on documentation anyway, so if I find the time, I'll try to do it as an article. Probably a bit late, but here is a short article about the new version with some bias towards Unittesting and code coverage analysis with Visual D: http://www.dsource.org/projects/visuald/wiki/News36 I missed that, it's a good remainder, thank you. It certainly help a lot the community.
Re: D based build system to replace current makefile
On Thursday, 30 May 2013 at 07:50:11 UTC, Timothee Cour wrote: We should move to a D-based build system to build dmd/druntime/phobos/d-programming-language/tools. Reasons, in case it's not obvious: 1) DRY: makefile is full of repetitions 2) cross platform: different makefiles for different architectures are needed (even win32 vs win64!) 3) safety: makefile happily ignores that $VAR variables are not set, and can create havoc; likewise tools/update.sh is a bash script and may not stop on 1st error. 4) tools/update.sh doesn't work out of the box on OSX last i checked (I made a pull request for that some time back: https://github.com/timotheecour/d-programming-language.org/commit/557a2befa74ddfe99ee5c0e12e7c3d028f27d276) Even a bad D-based build system will be better than a makefile, but it's not hard to write a reasonable one at least for the particular task of building dmd/druntime/phobos/d-programming-language/tools. It'll lower the entry point for people to contribute to dmd/phobos by making rebuilding trivial. Here's how it'd work: 1) a mixed D-based/makefile build that'll work 'from scratch' via bootstrapping: 1a) dmd: first uses a makefile to build dmd+druntime 1b) rdmd built from a D file using dmd 1c) phobos, d-programming-language, tools built from a D file using rdmd 2) a pure D-based build that'll work using an existing dmd binary (eg distributed binary) that's the one most will use. You may want take a look at Qbs, it will the next build system of Qt in replacement of QMake. http://qt-project.org/wiki/Qbs-Quick-Reference Using a full featured language is good cause, there is no restriction and build aren't just build, it's also packaging/testing issues. Doing something that just have to call compiler binaries is finaly the simple thing, and provide more control to users.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 07:56:19 UTC, Denis Shelomovskij wrote: 29.05.2013 1:25, Flamaros пишет: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about? As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ for my apps so I tried to use Glade a long time ago but finished manually writing all the code as it: 1. It is not complicated and not time-wasted at all. 2. It gives you more control on the application. 3. It saves you time (!) as you can use you own functions for common widgets creation/location patterns. So if your library isn't that silly one where you have to manually specify widget location/size in parent don't waste your time on GUI editor. Our GUI library will be interesting for modern Interfaces with animations. I really think that it's easier to tweak animations and positions of items in real time. The editor will not hide script code, so manual edition will be possible too.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote: On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about? I always hold Delphi and C++ Builder as examples of a what a good UI editor should offer. Currently Blend + VS are also another good examples for proper tooling for making good UIs. -- Paulo It seems Blend can directly run on top of the application. Are you using this feature?
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 09:51:04 UTC, Jacob Carlborg wrote:
On 2013-05-28 23:25, Flamaros wrote:
Hi,
I and a friend are developing a GUI library, and now our
script engine
is ready to start a prototype (but far to be finished). We
think to try
to create a GUI editor based on our library.
In this way, we'll see which features are need.
My concern is about how the editor have to works, we see two
different
ways to do it :
1) Classic editor external to the user applications
a) Good :
- Lightweight (easy to deploy and test)
- No need to modify application code
- Stable due to isolation of application
- Real-time edition but limited on one view (bad to
preview menus
transitions)
b) Bad :
- Limited, plugins needed to extend editor components and
his
knowledge of application (can't predict size of unknown
application
specific items)
2) Integrated editor (launch with the user application in a
second Window)
a) Good :
- Preview is the final result with real data
- All application components accessible to the editor
without
complex plugin system (in this way all editors components will
be well
placed in the preview)
- Full real-time edition (can preview menus
transitions,...)
- User can customize the editor
b) Bad :
- Intrusive in the application code
- Force the user to port application on a desktop OS
(Linux, Mac or
Windows), not friendly if he target only embedded devices (can
be
bypassed with a remote system)
- Less stable editor?
The second solution is commonly used in the video game
industry, but is
the best choice for a larger usage?
What do you think about?
I would go with the first approach because I would guess it's
easier. The editor creates the controls. When saving it will
serialize all the controls to some format. This format is then
read by the application.
For serialization you could have a look at Orange:
https://github.com/jacob-carlborg/orange
You think it's easier to do or to use?
We can't do serialization because our GUI files are lua scripts.
It looks like :
[CODE]
Image {
id = image,
source = images/pngtest.png,
x = 50,
y = 50,
titi = 0,
toto = function()
return image.width + image.height
end,
onTotoChanged = function()
image.titi = image.toto
print(onTotoChanged = ..image.titi)
end,
Button {
width = function()
return image.width
end,
height = function()
return image.height
end,
}
}
[/CODE]
Button isn't a D Object :
[CODE]
function Button(t)
print(t.width)
local Buttonimage3 = Image {
id = Buttonimage,
width = 100, -- property binding, when image change width is
automatically updated
height = 50,
-- opGet = function(propertyName)
-- return ButtonmouseArea[propertyName]
-- end,
-- opSet = function(propertyName, value)
-- ButtonmouseArea[propertyName] = value
-- end,
source = function ()
if ButtonmouseArea.pressed then -- property binding, when
mouseArea state change this condition is updated directly
return images/Alpha-blue-trans.png
else
return images/pngtest.png
end
end,
MouseArea { -- parent/child
object encapsulation
id = ButtonmouseArea,
width = function ()
return Buttonimage.width
end,
height = function ()
return Buttonimage.height
end,
},
}
for key, value in pairs(t) do
print(value)
Buttonimage3[key] = value
end
return Buttonimage3
end
[/CODE]
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 11:11:36 UTC, Jakob Ovrum wrote: On Wednesday, 29 May 2013 at 10:22:21 UTC, Flamaros wrote: We can't do serialization because our GUI files are lua scripts. Just curious, but, are you using LuaD? Nop, I use lua directly (but loaded with derelict). Can LuaD manage metatables and other advanced features?
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote: On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote: On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote: On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about? I always hold Delphi and C++ Builder as examples of a what a good UI editor should offer. Currently Blend + VS are also another good examples for proper tooling for making good UIs. -- Paulo It seems Blend can directly run on top of the application. Are you using this feature? What you mean by run on top ? I use it to have a look if everything looks like and for some stuff I need to execute the application but it requires runtime information. Blend can work with VS solutions and also invoke MSBuild, but if you are doing custom controls and stuff it is better to do certain parts from VS side, hence using both. -- Paulo Do blend works with C++? I don't know how it run on top but on the documentation page tell that it can be aware of states that are normally only on run-time. Maybe with a static introspection or like we propose with the intrusive way.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 12:37:51 UTC, Jakob Ovrum wrote: On Wednesday, 29 May 2013 at 12:31:51 UTC, Flamaros wrote: Nop, I use lua directly (but loaded with derelict). Can LuaD manage metatables and other advanced features? Yes! :) it's intended as a no-compromise wrapper of the C API. Maybe you'll do a pull request to migrate to luaD when we'll open the repository. For the moment, we prefer to restrict such modifications because we have some features to add the declaration engine. We also think to create a converter from a simplified syntax to the full lua syntax.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 13:52:31 UTC, Paulo Pinto wrote: Do blend works with C++? Yes, in Windows 8 Apps when doing XAML with C++/CX. After 16 years, Microsoft finally catches up with Borland's C++ Builder. I don't know how it run on top but on the documentation page tell that it can be aware of states that are normally only on run-time. Maybe with a static introspection or like we propose with the intrusive way. Yes, that is possible, but not for everything. Like in most UI toolkits, your components need to be aware of a design mode. -- Paulo The intrusive method we think about, will allow use to get a full control of all items derived from our basics objects. So I imagine your prefer this solution?
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 17:28:52 UTC, Martin Nowak wrote: On 05/28/2013 11:25 PM, Flamaros wrote: 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? I think an integrated editor has a huge benefit because of the instant feedback. You could use IPC and have the editor in a separate application. That is probably more difficult to implement but it mitigates your negative points. https://developers.google.com/chrome-developer-tools/docs/remote-debugging Yes that just what I think about this evening, developing the editor with an Object reflection trough a network API. If the API of the protocol is enough good it will certainly possible to implement something trough USB too. I think we'll need use more __traits :-). It will like remote debugging on JVM too.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 17:58:19 UTC, Jesse Phillips wrote: On Wednesday, 29 May 2013 at 12:51:24 UTC, Jakob Ovrum wrote: On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote: Maybe you'll do a pull request to migrate to luaD when we'll open the repository. I will, I imagine it would be a pleasure. Deleting all that tedious, bug-prone stack-based code and replacing it with spurious, declarative one-liners sounds like a lot of fun ;) I concur, LuaD makes Lua an excellent extension to D. At the beginning of the project we tough of using a javascript engine like QML, but all are in c++ and we already know well Lua. D would be nice too, but maybe not really good for declarations language and not ready for our use.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 19:35:31 UTC, Jacob Carlborg wrote: On 2013-05-29 12:22, Flamaros wrote: You think it's easier to do or to use? I would think it's easier to develop such editor. Probably just as easy to use as a built in editor. We can't do serialization because our GUI files are lua scripts. I assume you will have some kind of objects floating around in memory. Serialize those to whatever format you use, in this case Lua. We'll have nothing else than Lua declarations, and Items properties aren't simple values because we are using propety bindings pattern (you make take a look at http://en.wikipedia.org/wiki/QML). With that their is nothing static, to illustrate if you size the window all can be adapted efficiently by user defined behaviors.
Re: Need some opinions for a GUI editor
On Wednesday, 29 May 2013 at 19:38:57 UTC, Martin Nowak wrote: On 05/28/2013 11:25 PM, Flamaros wrote: Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). What do you use for rendering? We use OpenGL 2.1, we target this particular version for intel drivers and stay close to OpenGLES.
Need some opinions for a GUI editor
Hi, I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library. In this way, we'll see which features are need. My concern is about how the editor have to works, we see two different ways to do it : 1) Classic editor external to the user applications a) Good : - Lightweight (easy to deploy and test) - No need to modify application code - Stable due to isolation of application - Real-time edition but limited on one view (bad to preview menus transitions) b) Bad : - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items) 2) Integrated editor (launch with the user application in a second Window) a) Good : - Preview is the final result with real data - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview) - Full real-time edition (can preview menus transitions,...) - User can customize the editor b) Bad : - Intrusive in the application code - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system) - Less stable editor? The second solution is commonly used in the video game industry, but is the best choice for a larger usage? What do you think about?
Re: D on next-gen consoles and for game development
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote: While there hasn't been anything official, I think it's a safe bet to say that D is being used for a major title, Remedy's Quantum Break, featured prominently during the announcement of Xbox One. Quantum Break doesn't come out until 2014 so the timeline seems about right (Remedy doesn't appear to work on more than one game at a time from what I can tell). That's pretty huge news. Now I'm wondering what can be done to foster this newly acquired credibility in games. By far the biggest issue I hear about when it comes to people working on games in D is the garbage collector. You can work around the GC without too much difficulty as Manu's experience shared in his DConf talk shows but a lot of people new to D don't know how to do that. We could also use some tools and guides to help people identify and avoid GC use when necessary. @nogc comes to mind (I believe Andrei mentioned it during one of the talks released). [1][2] Johannes Pfau's work in progress -vgc command line option [3] would be another great tool that would help people identify GC allocations. This or something similar could also be used to document throughout phobos when GC allocations can happen (and help eliminate it where it makes sense to). There was a lot of interesting stuff in Benjamin Thaut's article about GC versus manual memory management in a game [4] and the discussion about it on the forums [5]. A lot of this collective knowledge built up on manual memory management techniques specific to D should probably be formalized and added to the official documentation. There is a Memory Management [6] page in the documentation but it appears to be rather dated at this point and not particularly applicable to modern D2 (no mention of emplace or scoped and it talks about using delete and scope classes). Game development is one place D can really get a foothold but all too often the GC is held over D's head because people taking their first look at D don't know how to avoid using it and often don't realize you can avoid using it entirely. This is easily the most common issue raised by newcomers to D with a C or C++ background that I see in the #d IRC channel (many of which are interested in game dev but concerned the GC will kill their game's performance). 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219 2: http://wiki.dlang.org/DIP18 3: https://github.com/D-Programming-Language/dmd/pull/1886 4: http://3d.benjamin-thaut.de/?p=20#more-20 5: http://forum.dlang.org/post/k27bh7$t7f$1...@digitalmars.com 6: http://dlang.org/memory.html As a game developer I will be really enjoyed to be able to develop our games in D, and for kind of games we do the major issue isn't the GC but the portability and links with 3-party libraries (mostly for our internal tools). We essentially works on Point Click games : https://www.facebook.com/pages/Koalabs-Studio/380167978739812?ref=stream A lot of games companies target many architectures like ARM, X86, or PowerPC,... And for our internal tools we essentially use Qt, but for the moment I didn't try QtD. I don't have the chance for the moment to work on D during my work time.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 22:48:01 UTC, Adam Wilson wrote: On Mon, 20 May 2013 15:35:57 -0700, Flamaros flamaros.xav...@gmail.com wrote: On Monday, 20 May 2013 at 21:47:56 UTC, Andrej Mitrovic wrote: 1) A core for a GUI library written in D that people can start hacking on (meaning you can create windows, and draw in a pixel buffer, capture device input, all platform-independent), and Dereclit and SDL already does that. Rewrite SDL isn't needed, for my work it's already something I do and can tell you that it's really hard to support many platforms as Android, iOS, Windows, MacOS, consoles,... It's too long to learn all specifications and issues. Well I talked to Mike Parker (Derelict maintainer) at DConf and even he seemed to think that Derelict wasn't up to the task. The general consensus was that Derelict is primarily targeted at games. Which poses a number of issues in terms of UI toolkits, most of the relating to font rendering. Specifically: Font rendering is allowed to be vastly different across platforms. Much of what we would require in UI's of the font rendering engine is not available at all, wrapping, line spacing, layout, etc. Sub-pixel font hinting. Almost no games use this, and almost every OS toolkit does. There was more that I am forgetting... Derelict may be useful as a binding to OpenGL, but that's about where it ends, there is still MUCH work to be done on top of it. QML do sub pixel with a shader, but us think to start with a pixel perfect alignment. In games we works on, we don't have issues specifics to OS with fonts. Default font can't be the same but FreeType support many types of font files. As our games are mainly on smartphone we use kerning to save spacing, and space character to automatic wrapping. An advanced wrapping can only be done with dictionaries. My vision is actually to start something to see if it's a valid choice. After other questions will find answers with the communauty.
Re: Ideal D GUI Toolkit
With a friend/coworker we work on a prototype of a GUI system like QML. QML is not native and visual aspect can't follow platform specific style efficiently, but today GUI style changes often and fast. Old Windows Widget style seems dying. Microsoft now use Aero and Office don't looks close to old Widgets applications. An other important point is that smallest devices now support OpenGL more and more. We choose to do something like QML because it's a relatively to implement, the user have to create it's own components and give a fine control of GUI behavior. http://en.wikipedia.org/wiki/QML Techno we use : - OpenGL 2.1 (to support older hardware) - SDL2 - Lua for ui declaration (QML use a javascript engine, JIT cause some issues on iOS for exemple, a move to D should be great in a future) - __traits to generate bindings - D signals (we don't use thread for the moment) Status of DQuick : The major features actually missing in the script engine are components and user defined properties to allow user to declare it's own virtual types, without this it's not possible to create a Button because it's not a base type. Property binding just works fine. For other part of DQuick a lot of objects are missing, like State, Animation, Loader. Our item can't be loaded asynchronously and for images it can be an issue. Issues : - Remote desktop doesn't seems work under Windows (due to OpenGL? or bad driver?) - Realtime resize doesn't works (investigation need to be done) We may open our code when components will be implemented plus the addition of a better demonstration. We are really far of a production release and a schedule can't be done for the moment, don't hope to much on it :-).
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 21:47:56 UTC, Andrej Mitrovic wrote: 1) A core for a GUI library written in D that people can start hacking on (meaning you can create windows, and draw in a pixel buffer, capture device input, all platform-independent), and Dereclit and SDL already does that. Rewrite SDL isn't needed, for my work it's already something I do and can tell you that it's really hard to support many platforms as Android, iOS, Windows, MacOS, consoles,... It's too long to learn all specifications and issues.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 22:26:39 UTC, Flamaros wrote: With a friend/coworker we work on a prototype of a GUI system like QML. QML is not native and visual aspect can't follow platform specific style efficiently, but today GUI style changes often and fast. Old Windows Widget style seems dying. Microsoft now use Aero and Office don't looks close to old Widgets applications. An other important point is that smallest devices now support OpenGL more and more. We choose to do something like QML because it's a relatively to implement, the user have to create it's own components and give a fine control of GUI behavior. http://en.wikipedia.org/wiki/QML Techno we use : - OpenGL 2.1 (to support older hardware) - SDL2 - Lua for ui declaration (QML use a javascript engine, JIT cause some issues on iOS for exemple, a move to D should be great in a future) - __traits to generate bindings - D signals (we don't use thread for the moment) Status of DQuick : The major features actually missing in the script engine are components and user defined properties to allow user to declare it's own virtual types, without this it's not possible to create a Button because it's not a base type. Property binding just works fine. For other part of DQuick a lot of objects are missing, like State, Animation, Loader. Our item can't be loaded asynchronously and for images it can be an issue. Issues : - Remote desktop doesn't seems work under Windows (due to OpenGL? or bad driver?) - Realtime resize doesn't works (investigation need to be done) We may open our code when components will be implemented plus the addition of a better demonstration. We are really far of a production release and a schedule can't be done for the moment, don't hope to much on it :-). I forgot that we don't support text for the moment, but we'll use FreeType library, but we already have some experiences with it.
Re: Get difficulties with variadics
On Sunday, 12 May 2013 at 01:22:16 UTC, evilrat wrote:
On Saturday, 11 May 2013 at 22:01:33 UTC, Flamaros wrote:
Thanks a lot, I think using Variant[] is a better way. For the
moment (maybe for few minutes) it's necessary to always give
the Variant array to the getResource method, but it can be
null.
I actually use derelict3, but for this VBO isn't not necessary
to have something much more advanced as it's only for a Quad
generated by hand. I am sharing the indexes VBO of Quads.
The operational parameters can be useful to load a Texture
from an Image instance instead of only the filePath for
exemple. filePath also act as key to be able to get resources.
you don't even need to always pass null when you don't need
anything, use default parameters.
void someFunc(Variant[] array = null) {...}
or
void anotherFunc(Variant[] array = Variant[].init) {...}
ok, if this is just a part of tutorial or demo i don't bother
with my tips about api design anymore.
We hope to open our code in few weeks, and as it will be a
library, help on API design will be welcome. For the moment we
are working a doing a prototype, with core features to see if the
project is viable.
