Re: std.xml2 (collecting features)
On 06/05/2015 07:31, Jacob Carlborg wrote: On 2015-05-06 01:38, Walter Bright wrote: I haven't read the Tango source code, but the performance of it's xml was supposedly because it did not use the GC, it used slices. That's only true for the pull parser (not sure about the SAX parser). The DOM parser needs to allocate the nodes, but if I recall correctly those are allocated in a free list. Not sure which parser was used in the test. The direct comparisons were with the DOM parsers (I was playing with a D port of some C++ code at work at the time, and that is DOM based). xmlp has alternate parsers (event driven etc) which were faster in some simple tests i did, but I don't recall if I did a direct comparison with Tango there.
Re: std.xml2 (collecting features)
On 05/05/2015 11:41, Mario =?UTF-8?B?S3LDtnBsaW4i?= linkr...@github.com wrote: Recently, I compared DOM parsers for an XML files of 100 MByte: 15.8 s tango.text.xml (SiegeLord/Tango-D2) 13.4 s ae.utils.xml (CyberShadow/ae) 8.5 s xml.etree (Python) Either the Tango DOM parser is slow compared to the Tango pull parser, or the D2 port ruined the performance. fwiw I did some tests a couple of years back with https://launchpad.net/d2-xml on 20 odd megabyte files and found it faster than Tango. Unfortunately that would need some work to test now, as xmlp is abandoned and wouldn't build last time I tried it :-( I also had some success with https://github.com/opticron/kxml, though it had some issues with chuffy entity decoding performance. Also, profiling showed a lot of time spent in the GC, and the recent improvements in that area might have changed things by now.
Re: Review Candidates awaited!
On 02/02/2014 01:35, Jonathan M Davis wrote: I believe that the last time that Michael Rynn posted in the newsgroup was towards the beginning of 2012, and I don't think that he posted very many times before that, so I question that his proposal is ever going to go anywhere, even if it's completed and fantastic. He doesn't look like he's active enough to even see this call for review candidates let alone actually active enough to go through the review process. - Jonathan M Davis xmlp was looking pretty good, but the last change made to the source was in April last year, so I have to guess that Michael has abandoned it :-(
Re: Embed Windows Internet Explorer
On 18/12/2013 20:48, Andre wrote: = myURL.bstrVal = SysAllocString(cast(const(wchar*))url); Looks like the problem there is casting a string to a wchar* - I guess the resulting BSTR will contain garbage instead of the intended value. It only works with statement: myURL.bstrVal = cast(wchar*)http://www.google.de;; Treating a wchar* as a BSTR might cause unexpected things to happen - converting the string to a wchar* and then passing that to SysAllocString would be safer.
Re: DMD 2.064 alpha windows build
On 01/09/2013 13:46, Andrej Mitrovic wrote: On 9/1/13, dennis luehring dl.so...@gmx.net wrote: it seems that the old malloc implementation was the source of the 2x speed difference between dmc and msvc build Not really, the MSVC build is still faster. :) It made up the bulk of the difference for the algorithm unit tests at least - The MSVC build is still faster, but only a bit rather than several times.
Re: Replacing std.xml
On 31/08/2013 16:43, ilya-stromberg wrote: It's the fastest Xml parser in the world, so may be you can find it useful: dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/ Has anyone done any benchmarks recently to see if that is still the case? I did some (admitedly brief) tests last year and found that xmlp was actually faster at building large XML docs into a DOM. There have been lots of changes since then, so i don't know if that is still the case.
Re: Decrease DMD memory usage
On 29/08/2013 23:35, Temtaime wrote: I have ICC license and compiled DMD by it. I've tried to compile some my projects with it. Some stats: Original DMD: 20 sec. DMD compiled by ICC: 11 sec. x64 DMD compiled by ICC: 14 sec. It might be that a big chunk of that difference is down to memory handling, as it was for MSVC builds (I think ICC uses the MS C runtimes?). If that is the case, then the difference would be a lot smaller with all the latest bits. Might be interesting to see if the ICC build is any faster than the MSVC build?
Re: Article: Increasing the D Compiler Speed by Over 75%
Another little observation: Dsymbol::toPrettyChars() potentially calls toChars() twice on each symbol (so it creates 2 copies of the string representation). Some instances of toChars() just return a literal string, but for templates it can do a bunch of work. Doesn't sounds like the most efficient approach? Saying that though, it looks like a lot of the calls to that are to build error strings that are never displayed because errors are gagged, which doesn't sound ideal either?
Re: std.algorithm unittest OOM package.d
On 08/08/2013 18:30, H. S. Teoh wrote: After the latest Phobos update, I can't run the Phobos unittests anymore; std.algorithm runs out of memory. It seems ok here (on Windows, building with the new snn.lib), but it's taking measurably longer to compile the algorithm unit tests than it was last week (I was seeing it take about 11.2 seconds to compile, and now it's back to near 12 seconds) :-(
Re: How do you profile your apps under windows?
The Very Sleepy profiler works ok (if you run the apps through cv2pdb to get the debug symbols in the right format at least)
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
On 05/08/2013 18:52, Walter Bright wrote: This is hardly the first time the culprit was a library routine It's possible that other library routines are causing some of the remaining difference from the MSVC build (e.g. the profiler suggests that the DMC build spends somewhat more time inside memcpy than the MSVC build). Not sure if it's down to implementation or optimization though - might be down to intrinsics/inlining and such? (the proflie for the DMC build says it's using ~1% of its time inside strlen and the profile for the MSVC build doesn't mention it at all, which i guess is because it's using an intrinsic version).
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
On 03/08/2013 22:55, Walter Bright wrote: The execrable existing implementation was scrapped, and the new one uses Windows HeapAlloc(). http://ftp.digitalmars.com/snn.lib This is for testing porpoises, and of course for those that Feel Da Need For Speed. Using the latest DMD and this snn.lib, i'm seeing it take about 11.5 seconds to compile the algorithm unit tests (when i tried it last week, it was taking closer to 17 seconds). For comparison, the MSVC build takes about 10 seconds on the same machine (Athlon 64X2 6000+). Keep up the good work :-)
Re: Article: Increasing the D Compiler Speed by Over 75%
On 02/08/2013 14:16, Dmitry Olshansky wrote: Function CPU clocks DC accesses DC misses RTLHeap::Alloc 51638 552 3538 Obj::ledata 9936 1346 3290 Obj::fltused 7392 2948 6 cgcs_term 3892 1292 638 TemplateInstance::semantic 3724 2346 20 Obj::byte 3280 548 676 vsprintf 3056 3006 4 Random lunchtime observation: A lot of the calls to vsprintf are from TypeStruct::toDecoBuffer/TypeClass::toDecoBuffer/TypeEnum::toDecoBuffer which all do OutBuffer-printf(%s, name); Is that needed, or would changing them to OutBuffer-writestring(name); be more efficient? (it seems like it might, albeit only very slightly).
Re: Article: Increasing the D Compiler Speed by Over 75%
On Monday, 5 August 2013 at 17:53:48 UTC, Walter Bright wrote: On 8/5/2013 6:21 AM, Richard Webb wrote: Is that needed, or would changing them to OutBuffer-writestring(name); be more efficient? Yes. https://github.com/D-Programming-Language/dmd/pull/2450
Re: Increasing D Compiler Speed by Over 75%
On 01/08/2013 00:32, Walter Bright wrote: Thanks for doing this, this is good information. On 7/31/2013 2:24 PM, Rainer Schuetze wrote: I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): Debug build dmd_dmc: 23 sec, std new 43 sec Debug build dmd_msc: 19 sec, std new 20 sec That makes it clear that the dmc malloc() was the dominator, not code gen. It still appears that the DMC malloc is a big reason for the difference between DMC and MSVC builds when compiling the algorithm unit tests. (a very quick test suggests that changing the global new in rmem.c to call HeapAlloc instead of malloc gives a large speedup).
Re: memory allocation in dmd
On 02/07/2013 11:30, Don wrote: $ dmd -c -unittest std.algorithm CTFE Performance max call depth = 20max stack = 63 array allocs = 356assignments = 45356 That's actually not so terrible. The number of assignments gives a rough idea of how many CTFE statements are executed (almost everything interesting is an assignment). Most of the assignments are IntegerExpressions, of about 8 bytes, so it's under a megabyte in total. Note that there are very few array allocations, they are the thing that can really chew up memory quickly in CTFE. So although CTFE generally leaks memory like the Exxon Valdez leaks oil, I don't think it's to blame in this particular case. I had another go at running memory validator on an MSVC build of the latest source, and that says that there are 619008 instances of IntegerExp, at 30 bytes each (it's the 3rd most numerous named object, though only uses 2.3% of the memory). I'm not sure how accurate that is as the wrapping of malloc etc in DMD confuse the results - e.g. it just lists 2159119 instances of 'rmem.c:46' rather than saying what they actually are. fwiw, it says there are 14,828,139 allocations totalling 814.7MB from '-c 'unittest' algorithm.d .
Re: memory allocation in dmd
On 24/06/2013 13:11, Richard Webb wrote: On Sunday, 23 June 2013 at 12:23:14 UTC, dennis luehring wrote: http://www.softwareverify.com/cpp-memory.php - i like this one I've used that at work, though mainly for looking for leaks rather than memory profiling. Might try running DMD thruogh it if i get some time. I had a go at running the VC build of DMD through Memory Validator, using -release -unittest -c D:\DTesting\dmd.2.063\src\phobos\std\algorithm.d. It ran for about 45 mins, completed, and then locked up :-( I've put a screen shot of the object types list @ http://tinyurl.com/qybudb4 as an example of what it shows - didn't get a chance to look at anything else before it fell over.
Re: memory allocation in dmd
On Sunday, 23 June 2013 at 12:23:14 UTC, dennis luehring wrote: http://www.softwareverify.com/cpp-memory.php - i like this one I've used that at work, though mainly for looking for leaks rather than memory profiling. Might try running DMD thruogh it if i get some time.
Re: top time wasters in DMD, as reported by gprof
On Monday, 24 June 2013 at 15:04:37 UTC, dennis luehring wrote: i know - my question was - how does that look using msvc... I just did a very quick test using the latest DMD source: Using the command line -release -unittest -c D:\DTesting\dmd.2.063\src\phobos\std\algorithm.d DMD built with DMC takes ~49 seconds to complete, but DMD build with VC2008 only takes ~12 seconds. (Need to get a proper VC build done to test it properly). Looks like the DMC build spends far more time allocating memory, even though the peak memory usage is only slightly lower in the VS version?
Re: what keeps a COM object alive?
On Wednesday, 12 June 2013 at 14:41:05 UTC, finalpatch wrote: This feels even more cumbersome than in C++ because in C++ we can simply delete this in the Release() method, there's no need to store a reference in a global place. Juno does this by allocating the object on the non-gc heap, adding it as a GC root, and then deleting it when the refcount reaches 0. It works ok, though I think the current implementation has some issues.
Re: what keeps a COM object alive?
I was referring to the COM server support stuff in the Juno library, which allocates COM objects outside the GC heap so the GC will never collect them. See https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/juno/com/core.d#L3147 for an example.
Re: COM Example work for anyone?
I haven't tried to run it, but as a random guess, does the user your running it as have permissions to write to HKEY_CLASSES_ROOT ?
Re: Accessing CoInit [is Troubleshooting Linker error]
I haven't tried to use DMD 2.060 yet, will see if i've got time later.
Re: Troubleshooting Linker error (Symbol Undefined)
On Monday, 1 October 2012 at 15:22:20 UTC, Jesse Phillips wrote: On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote: Find oleaut32.dll in your Windows folder, and run implib on it: $ implib oleaut32.lib oleaut32.dll /s Thanks, I'll to play with this more because my first attempt did not resolve the issue and instead has resulted in even more missing symbols. I didn't change export type or anything else so we'll see. From what i recall, i think i worked around this issue by using coffimplib.exe on the version of oleaut32.lib from the platform sdk, rather than trying to generate a lib from the dll.
Re: Visula D fails to build after Windows updates
On 26/09/2012 15:56, Mike James wrote: Hi, After a recent Windows update cycle the Visual D projects now fail to build - it can't find the D source files - the output from compiler is below. === OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Error 118: Filename Expected Path=C:\D\dmd2\windows\bin;C:\Program Files\Microsoft SDKs\Windows\v7.0\bin;C:\Program Files\GTK+-Runtime-3.4.2\bin;C:\D\dmd2\windows\bin;C:\D\dm\bin;c:\MinGW\;C:\Program Files\CVSNT\;C:\lazarus\fpc\2.4.0\bin\i386-Win32;c:\dmd2\windows\bin;c:\dm\bin;c:\opt\gtk\bin;c:\bud\bin;c:\program files\mercurial;c:\program files\cmake\bin;c:\d\dmd2\dsss\bin;C:\D\dmd2\gtkD ^ --- errorlevel 1 Building Debug\dgen.exe failed! This has occured on 2 PCs, one Vista and one Win7 straight after recent updates. Has this occured to anybody else and whats the fix for it? Thanks. Regards, Mike. I don't know what the error would have to do with Windows update, but it might be caused by this: http://d.puremagic.com/issues/show_bug.cgi?id=5860 ?
Re: Visula D fails to build after Windows updates
Oops, didn't notice that this had already been mentioned in the other copy of the post :-(
Re: cast oddities - void* - AA
fwiw, I raised a bug about this on Orange a while back: https://github.com/jacob-carlborg/orange/issues/17. I thought it a bit odd that it compiled in DMD at the time, but i don't think i opened a bug about it.
Re: OPTLINK : Error 118: Filename Expected
On 09/08/2012 01:34, Walter Bright wrote: On 8/8/2012 4:11 PM, anon wrote: Yet another obscure error message that makes no sense. I suspect it's the ( ) you have in the file names. I've seen optlink failures before due to the '+' in GTK+ (don't recall the exact error message though).
Re: OPTLINK : Error 118: Filename Expected
Sounds like http://d.puremagic.com/issues/show_bug.cgi?id=5860 ?
Re: DFL?
For what it's worth, building the code from https://github.com/Rayerd/dfl with the included makelib.bat seems to work fine for me with DMD 2.059.
Re: DFL?
Try using the version from https://github.com/Rayerd/dfl instead of the one from the official site.
Re: CTFE and DI: The Crossroads of D
On Thursday, 10 May 2012 at 14:50:22 UTC, H. S. Teoh wrote: This is, to date, the most complex MALBOLGE program _ever_ written. This one looks a bit more complex: http://www.99-bottles-of-beer.net/language-malbolge-995.html
Re: Map with maintained insertion order
I've done that in C++ before using Boost.MultiIndex, and i saw a post about a D port of that recently (I don't have the link to hand though).
Re: [xmlp] the recent garbage collector performance improvements
On 02/02/2012 04:53, a wrote: It looks like someone wrote it a year ago, but it was never added to phobos: http://www.digitalmars.com/d/archives/digitalmars/D/announce/std.xml2_candidate_19804.html . Thats the one - http://www.dsource.org/projects/xmlp/ (the modules are under std. ).
Re: [xmlp] the recent garbage collector performance improvements
Out of interest, i just tried loading the same file with std.xml, and the performance there is pretty similar in each version, possibly slightly slower in 2.058 (~21-22 seconds in each case). Disabling the GC during the load gets 9 seconds, though task manager reports a peak memory usage of almost 600 megabytes in that case! It looks like most of the time here is spent in Gcxmark whereas with xmlp it was in Gcxfullcollect (and fullcollect is the one that is faster in 2.058). The profiler makes it look like things are spending more time in Gcxmark than they were before. Is that the case? I'll try to have a go with Tango when i get some more time.
Re: [xmlp] the recent garbage collector performance improvements
On 02/02/2012 19:32, H. S. Teoh wrote: But the day may come when your smartphone *can* literally have a 22 monitor (that folds into a pocket sized card). Nah, what you really need are those holographic displays they use on CSI Miami. No need for physical displays at all ;-)
Re: [xmlp] the recent garbage collector performance improvements
On 02/02/2012 17:11, Jesse Phillips wrote: for me disabling the GC during load doesn't change load time, but I'm not using the document loader. The GC hit is related to the number of dom nodes that exist at one i think - the visitor approach doesnt allocate the whole dom tree, so there are far fewer items (and less allocated memory for the gc to scan). For comparison, parsing my test file using XmlVisitor takes less than 3 seconds (over twice as fast as the DOM version). I looked in to it a bit and found this: http://www.dsource.org/projects/xmlp/ticket/10 Seems that it's calling GC.qmalloc 35+ times, mostly for 16byte blocks, when normalizing attributes. This doesn't seem hugely clever :-(
[xmlp] the recent garbage collector performance improvements
Last night I tried loading a ~20 megabyte xml file using xmlp (via the DocumentBuilder.LoadFile function) and a recent dmd build, and found that it took ~48 seconds to complete, which is rather poor. I tried running it through a profiler, and that said that almost all the runtime was spent inside the garbage collector. I then tried the same test using the latest Git versions of dmd/druntime (with pull request 108 merged in), and that took less than 10 seconds. This is a rather nice improvement, though still somewhat on the slow side. Some profiler numbers, if anyone is interested: Old version: Gcxfullcollect: 31.14 seconds, 69.26% runtime. Gcxmark: 4.84 seconds, 10.77% runtime. Gcxfindpool: 2.10 seconds, 4.67% runtime. New version: Gcxmark: 11.67 seconds, 50.77% runtime. Gcxfindpool: 3.58 seconds, 15.55% runtime. Gcxfullcollect: 1.69 seconds, 7.37% runtime. (Assuming that Sleepy is giving me accurate numbers. The new version is definately faster though).
Re: [xmlp] the recent garbage collector performance improvements
On 01/02/2012 20:02, Jesse Phillips wrote: Interesting, I've been using XmlVisitor on two 30meg and one 10meg, load time for all files being 30secs, this is actually an improvement from an older version of xmlp which took 60secs. Not sure if DocumentBuilder would be much different. For reference, the file i was testing with has ~5 root nodes, each of which has several children. The number of nodes seems to have a much larger effect on the speed that the amount of data. I tried it with an old version of KXML and that seems somewhat faster, although the latest version doesn't seem to build with 2.058 and it's a more basic library.
Re: [xmlp] the recent garbage collector performance improvements
On 01/02/2012 19:35, dsimcha wrote:
I'd be very
interested if you could make a small, self-contained test program to use
as a benchmark.
The 'test' is just
/
import std.xml2;
void main()
{
string xmlPath = rtest.xml;
auto document = DocumentBuilder.LoadFile(xmlPath, false, false);
}
/
It's xmlp that does all the work (and takes all the time).
I'll see about generating a simple test file, but basically:
5 top level nodes
each one has 6 child nodes
each node has a single attribute, and the child nodes each have a short
text value.
Parsing the file with DMD 2.057 takes ~25 seconds
Parsing the file with DMD 2.058(Git) takes ~6.1 seconds
Parsing the file with DMD 2.058, with the GC disabled during the
LoadFile call, takes ~2.2 seconds.
For comparison, MSXML6 takes 1.6 seconds to load the same file.
Re: Calling a C++ Object from D
I've never used the Windows update API, but isn't it a COM interface rather than a C++ interface? You can call those directly from D.
Re: Calling a C++ Object from D
How about something like this (using Juno):
///
import juno.com.core, std.stdio;
abstract final class SystemInformation {
mixin(uuid(C01B9BA0-BEA7-41BA-B604-D0A36F469133));
mixin Interfaces!(ISystemInformation);
}
interface ISystemInformation : IDispatch
{
mixin(uuid(ade87bf7-7b56-4275-8fab-b9b0e591844b));
int get_OemHardwareSupportLink(wchar* retval);
int get_RebootRequired(out VARIANT_BOOL retval);
};
void main()
{
//auto systemInformation =
coCreate!(ISystemInformation)(uuidof!(SystemInformation));
auto systemInformation = SystemInformation.coCreate!ISystemInformation;
if (systemInformation !is null)
{
scope(exit) tryRelease(systemInformation);
VARIANT_BOOL b;
int result = systemInformation.get_RebootRequired(b);
if (SUCCEEDED(result))
{
writefln(Reboot Required: %s, b);
}
}
}
///
Re: 64Bit compatibility warnings
On 21/01/2012 13:33, Vladimir Panteleev wrote: On Saturday, 21 January 2012 at 12:53:27 UTC, Nick Sabalausky wrote: Trass3r u...@known.com wrote in message news:op.v8flqsr63ncmek@enigma... Couldn't it be handled by a special switch on 64 bit compilers, and disabled normally? Theoretically yes, but it would destroy the original intention. Ensuring 64 bit compatibility is as easy as compiling with -m64 from time to time, but some people can't be bothered. Or they're on windows. -m64 -o- should work on Windows regardless. I got an ICE last time i tried that with DMD (haven't tried the latest version though). I've just been making some changes to Juno to fix 64bit issues found by GDC, and that will do 64bit builds even on 32bit hosts, so it's pretty straight forward to give it a try.
Re: Program size, linking matter, and static this()
On 16/12/2011 18:29, Andrei Alexandrescu wrote: Here's a list of all files in std using static cdtors: std/__fileinit.d std/concurrency.d std/cpuid.d std/cstream.d std/datebase.d std/datetime.d std/encoding.d std/internal/math/biguintcore.d std/internal/math/biguintx86.d std/internal/processinit.d std/internal/windows/advapi32.d std/mmfile.d std/parallelism.d std/perf.d std/socket.d std/stdiobase.d std/uri.d On a slightly related note: http://d.puremagic.com/issues/show_bug.cgi?id=5614 Basically, do the static constructors in __fileinit and mmfile need to exist on a (hypothetical) 64bit Windows build?
Re: Juno for D2 (Working status unknown)
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article Oh I had no idea. I used SVN, expecting it to have the latest version. Ill have to look into merge that then. 0.5.1 does contain a degree of D2 support, though it's rather out of date and there are lots of language change related breakages (mostly just things like const and operator type stuff, but a few others as well). There are several new modules as well. Though I'm definitely interested in a much narrower scope than the original author. Same here - i've only really used the COM stuff (and i did have a working COM server dll in DMD2 around 2.052).
Re: Any othe options for inserting into associative array?
I just looked at my local Juno source, and it does have the change that i
mentioned in that forum post. I just added an extra version of opAssign:
void opAssign(R)(R dg) if (is (R : MethodProxy) )
{
method = dg.method;
returnType = dg.returnType;
paramTypes = dg.paramTypes;
}
I forgot about that ;-)
Re: Juno for D2 (Working status unknown)
Hi, Does this include the latest 'official' Juno changes? (the latest downloadable version is 0.5.1, but the SVN version is only 0.4). I have a version of Juno that was working with some COM stuff a few versions of DMD2 back but is broken with the latest one (a combination of language changes and at least one compiler ICE). I'll have a look at the changes when i get some time. There were also a few other issues mentioned on the Juno forum in the past that could do with being merged in. Thanks, Richard Webb.
Re: Any othe options for inserting into associative array?
On 07/11/2011 20:27, Jesse Phillips wrote:
Came across this when trying to get Juno to work. Is there a good workaround
for it?
http://d.puremagic.com/issues/show_bug.cgi?id=6906
test.d(6): Error: function test.S.opAssign (int i) is not callable using
argument types (S)
void main() {
S[string] ss;
S s;
ss[hello] = s;
}
struct S {
void opAssign(int i) {
}
}
I have a recollection that i replaced an opAssign with a custom assign
function when getting Juno to build with D2 a while ago because of
something like this (was in the MethodProxy struct in com.client). That
did hit a different DMD bug at the time as well though.
Not ideal, but it got it working at least.
Re: COM objects
You could try looking at the Juno or DWin projects on dsource. I've done a bit of COM stuff (both implementing com objects and using others) in Juno and it worked ok, though unfortunately it needs some changes to get it to work with the current D2.
Re: 64bit phobos on Windows?
Is a Windows 64 bit version of GDC any closer than a version of DMD? I guess that fixing Phobos will be useful there as well.
64bit phobos on Windows?
I know that 64bit support on Windows is behind Linux etc for various reasons, but i thought i'd tried building some things with -m64 just to test, and got a bunch of errors like std\file.d(223): Error: undefined identifier GetLastError std\file.d(2067): Error: undefined identifier WIN32_FIND_DATA Which appears to be because various things in Phobos use version(Win32), and only 'Win64' is set in 64bit builds. I guess that at least some of these should be using version(Windows) instead?
Re: Windows API Translation
fwiw, I've had more luck using coffimplib on the libs from the Windows platform SDK than i have using implib on the dlls.
Re: C# Interop
It overrides new and allocates class instances using malloc. The official version calls addRange from new, and removeRange/free from Release when the reference count is 0, but i changed my local version to use add/remove(Root) instead of range at some point. I'm only currently trying to use external com objects rather than creating my own, so this isn't an issue here. fwiw, i just marked some static variables in juno as __gshared to work around the problem for now, and it seems to be loading ok. Juno could really do with some official maintainance work to keep up with D2 changes, but the author seems to have left a while back :-(
Re: C# Interop
Also, DLLs can be used in multi-threading environments. On a related note, i'm having a bit of a problem with a D dll at the moment. I have an Outlook COM Addin that is written in D2 using the Juno library and that is running ok, but i'm now trying to use a D dll from a COM addin written in C++ and i'm getting a crash inside dll_process_attach. The only thing i get in the call stack is gcx.mark, but it appears that the crash is due to the GC running midway through the thread setup code. Disabling the GC during the thread_moduleTlsCtor() calls avoids the crash, but that might just be covering the problem up. This is with the latest druntime/phobos code from a couple of days ago plus your patch from #5382, running on Windows 2008. Any ideas?
Re: C# Interop
I assume that you do quite a lot of initialization for TLS I'm not directly, but Juno has a number of static class constructors that allocate static members, and Outlook creates lots of threads (for example, i see the static constructor of the module juno.com.core get called 20+ times on startup). The Juno lib predates the TLS changes in D2 so i guess that some of these static variables don't need to be thread local, but i haven't had chance to investigate that. Are you using callbacks into the C++ DLL from the module ctors The D dll just exports a couple of 'C' functions that the C++ dll calls. There are no calls in the other direction. that might work better if the C++ part also uses thread local storage The C++ dll uses ATL for it's COM stuff, and i'm not sure what that does with TLS in the background. I'll try your suggested change tommorow. Thanks, Richard Webb
Re: How does D handle null pointers?
Delight works like that, though i think that it's more strict than Vala about treating null dereferences as compile time errors. I think that bearophile suggested that references be marked as non-nullable because making them non-nullable by default is a breaking change in the language (i agree that that is a better approach though).
Re: Am I doing it wrong or is this a bug ?
Is returning a D string to a non-D language going to cause problems?
Re: cannot evalute mixin(uuid(bla)) at compile time
Dwin uses Tango and so only works in D1 anyway, so i don't know if thats the problem (Juno uses string already, and i've used that ok in D1 and D2). I've managed to get Juno working with a recent D2 before, but with the latest SVN version i get: /// phobos\std\range.d(645): Error: cannot evaluate empty((const(immutable(char)[]))) at compile time phobos\std\range.d(645): Error: Integer constant expression expected instead of cast(uint)(1 + cast(int)empty((const(immutable(char)[] /// I haven't worked out whats causing the problem yet, though looking at the Phobos code i'm not sure what the is(char[1 + Range.empty])) is supposed to be doing.
Re: cannot evalute mixin(uuid(bla)) at compile time
I don't have a minimal example, but i have found that the error only occurs with the most recent version of std.algorithm - the current SVN version of phobos with the previous revision of algorithm compiles ok.
Problems building druntime
I just tried building the latest (svn) version of druntime with the svn version of dmd2, and got the compile errors: src\core\dll_helper.d(372): Error: undefined identifier thread_detach src\core\thread.d(1856): Error: undefined identifier obj Is it broken, or am i doing something wrong? Thanks, Richard Webb
Re: spiritd, bug fix.
fwiw, i tried to work around this by changing the second conv function to:
T conv(T, U)(in Match!(U) arg) { return T(arg._len); }
and then got a bunch of errors like:
spiritd\impl\parse.d(36): Error: variable m cannot be read at compile time
Which looks like bug 3809.
If i change parseImpl to initialize 't' manually rather than using the struct
initializer, then the test app compiles and appears to work ok.
Re: spiritd, bug fix.
Hi, I just tried to build the spiritd test app with the current DMD2, and got the error: spiritd\primitives.d(46): Error: template instance conv!(Match!(char)) matches more than one template declaration, spiritd\match.d(70):conv(T) and spiritd\match.d(71):conv(T) Is the current D2 supposed to be supported? Thanks, Richard Webb
Problems with const/non-const overloads of member functions
Using the latest DMD2, the code:
//
class c1
{
void foo() const
{
}
void foo()
{
}
void bar() const
{
foo();
}
}
//
fails to compile with the error:
constest.d(15): Error: function constest.c1.foo () is not callable using
argument types () const
However, if i either:
1) Change bar() to call this.foo() or
2) switch the 2 foo()s so that the const version is defined second.
The it compiles ok.
There are various const related issues in the bug tracker, but i don't
immediately see this one. Anyone know if it's a known thing?
Thanks,
Richard Webb
Re: Price drop for TDPL on Amazon to $41.10eom
I pre-ordered it from http://www.bookdepository.co.uk/book/9780321635365/The-D-Programming-Language, who now have it listed as dispatched within 48 hours, so hopefully won't have to wait too long :-)
build problem with xfbuild
If i try to use DMD 2.047 and xfbuild to compile a file which just contains module arraytest; import std.array; I get the error: F:\development\DTesting\dmd2\windows\bin\..\..\src\phobos\std\format.d(1882): Error: template std.array.Appender!(string).Appender.put(U) if (isImplicitlyConvertible!(U,T) || isSomeChar!(T) isSomeChar!(U)) does not match any function template declaration F:\development\DTesting\dmd2\windows\bin\..\..\src\phobos\std\format.d(1882): Error: template std.array.Appender!(string).Appender.put(U) if (isImplicitlyConvertible!(U,T) || isSomeChar!(T) isSomeChar!(U)) cannot deduce template function from argument types !()(char[]) I don't have a simple repro just using DMD, but the error seems to originate from line 695 of array.d (at least, commenting it out or changing it to put!(Unqual!T[])(encoded[0 .. len]); allows it to compile. Anyone got any ideas? Thanks, Richard Webb
std.array.Appender with fixed size arrays
Hi,
While trying to get some things to build in D2, i noticed that the code:
import std.array;
void main (string[] args)
{
string s;
auto app = appender(s);
app.put(['a', 'b']);
}
/
works, but if it's changed to;
char[2] tmp = ['a', 'b'];
app.put(tmp);
then it fails. Seems to be because char[2] isn't a forward range, so it
doesn't match the version of put that takes a range.
Is this a bug?
Re: Phobos Proposal: replace std.xml with kxml.
RapidXML also uses the Boost license (it's included as part of the Boost PropertyTree library). I haven't used it though, so i can't say how i compares to the others.
Re: Is it time to deprecate COM compatibility through D interfaces?
I've done a bit of tinkering with the Juno library (http://www.dsource.org/projects/juno) to both automate Office applications, and to write a simple COM addin for Outlook. In both cases, that was using a tool that creates D interface definitions from a COM type library. My knowledge of D is still pretty slim though, and i haven't thought much about alternate approaches to this.
Re: Next release name: Tango 0.99.99 Rei?
Nick Sabalausky Wrote: downs default_357-l...@yahoo.de wrote in message news:hkusr4$ho...@digitalmars.com... /obscure nerd culture joke Neon Genesis? Higurashi?
Re: opEquals(const ref yadaYada)
Hi, I mentioned this problem in the thread @ http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=18405 I ran into the rvalue problem while trying to get Juno to compile, and found that it builds ok if you declare both bool opEquals(const ref Foo rhs) const and bool opEquals(Foo rhs) const
Re: [D2] const vs structs
Opened as 3606 and 3607. Thanks, Richard Webb
[D2] const vs structs
I just tried to build the Juno library with DMD 2.037, and got a bunch or
errors like:
juno\com\core.d(295): Error: function juno.com.core.GUID.opEquals type
signature should be const bool(ref const(GUID)) not bool(GUID other)
Which can be replicated with:
struct Foo
{
bool opEquals(Foo f) const
{
return true;
}
}
void Bar()
{
Foo f;
}
It built ok with DMD2 a few months ago. Is this an intentional change?
Also, while looking at the problem i noticed that code like:
struct Foo
{
~this()
{
}
}
void Bar()
{
const Foo f;
}
Produces the error:
Error: destructor Foo.~this () is not callable using argument types ()
which seems a bit wrong?
Thanks,
Richard Webb
Re: Startup from registry program doesn't work
Is the DWORD length=pFileName.sizeof; setting length to the size of the pointer, when you need the length of the string? That would explain why only 4 bytes have been written.
Problems when trying to write a Dll/COM object in D2
Hi, Whlie trying to write a COM object using D2 and the Juno library, i ran into the problem mentioned @ http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=17680. Basically, if i build the dll example shown @ http://www.digitalmars.com/d/2.0/dll.html with DMD 2.032 and try to LoadLibrary it on WindowsXP, then i get a couple of access violations (one from inside the Runtime.initialize() call and one from the g_hInst=hInstance line). If i try to load the same dll on Windows 2008 then all appears ok. Is this a known issue with D2? Thanks, Richard Webb
Re: DLLs and headaches
Don Wrote: If D2 -- I haven't been able to get D2 DLLs to work at all. They just crash during the initialization (something to do with initialising the thread-locals, I think, but I haven't been able to track it down completely). Hi, I've recently been having a go at writing a COM object in D, and have run into this when trying it in D2. Debugging through it, i get a crash on the void* pstart = cast(void*) _tlsstart; on line 1192 of thread.d, due to a null pointer access. This sounds like the issue described at http://www.nynaeve.net/?p=187 ? Is this a known problem with D2 ?
