Re: package.d
On 12/17/13, Leandro Motta Barros l...@stackedboxes.org wrote: Is there any documentation describing the expected to behavior in regard to the fully-qualified names of the publicly imported symbols in package.d? It might have been an oversight, but we'll have to wait for (I think Kenji) to reply since he implemented packages.
Re: package.d
On 17/12/13 01:51, Leandro Motta Barros wrote: I have some code using the old all.d idiom, which I am changing to use the new package.d feature. Related question -- it seems like rdmd doesn't like package-based code, and can't resolve dependencies as it can with regular modules. Is there any kind of timeframe/roadmap for fixing this?
Re: package.d
Here's another rather interesting case:
// mylib/util.d
module mylib.util;
class Foo { }
// mylib/package.d
module mylib;
public import mylib.util;
// main.d
import std.stdio;
import mylib;
void main()
{
auto f = new mylib.Foo;
writefln(%s, f.classinfo.name);
}
This prints 'mylib.util.Foo'. So far so good, that's the name I originally
expected.
Then I try to instantiate a 'Foo' using this very fully-qualified name the
compiler told me:
auto f = new mylib.util.Foo;
And DMD doesn't like it anymore:
main.d(6): Error: undefined identifier 'util'
main.d(6): Error: mylib.util.Foo is used as a type
Fishy, isn't it? Maybe I should report this as a bug?
Cheers,
LMB
On Wed, Dec 18, 2013 at 6:09 AM, Andrej Mitrovic andrej.mitrov...@gmail.com
wrote:
On 12/17/13, Leandro Motta Barros l...@stackedboxes.org wrote:
Is there any documentation describing the expected to behavior in regard
to
the fully-qualified names of the publicly imported symbols in package.d?
It might have been an oversight, but we'll have to wait for (I think
Kenji) to reply since he implemented packages.
Re: package.d
On Wed, Dec 18, 2013 at 6:56 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 17/12/13 01:51, Leandro Motta Barros wrote: I have some code using the old all.d idiom, which I am changing to use the new package.d feature. Related question -- it seems like rdmd doesn't like package-based code, and can't resolve dependencies as it can with regular modules. Is there any kind of timeframe/roadmap for fixing this? With these simple examples I sent, rdmd seem to resolve dependecies correctly. For example, with this last example I sent (which prints the class name): $ rdmd main.d mylib.util.Foo $ dmd main.d main.o: In function `_Dmain': main.d:(.text._Dmain+0xb): undefined reference to `_D5mylib4util3Foo7__ClassZ' collect2: error: ld returned 1 exit status --- errorlevel 1 $ dmd main.d mylib/util.d $ ./main mylib.util.Foo In this case, at least, rdmd correctly resolved, compiled and linked mylib/util.d, which was imported through a package. LMB
Can't isolate ICE
I have an internal compiler error in my code. I can't reduce code to reproduce this problem, but I remember there was a tool that can do this, what's its name? Where can I download that tool?
Re: Can't isolate ICE
On 12/18/2013 12:27 PM, Andrea Fontana wrote: I have an internal compiler error in my code. I can't reduce code to reproduce this problem, but I remember there was a tool that can do this, what's its name? Where can I download that tool? https://github.com/CyberShadow/DustMite
Re: Using threads on Mac OS X using D1 and Tango
On 2013-12-15 16:28, Jacob Carlborg wrote:
I'm trying to use threads on Mac OS X using D1 and Tango. I have this
very simple example:
import tango.core.Thread;
void main ()
{
Thread thread = new Thread({ });
thread.start();
thread.join();
}
I'm using DMD 1.076 to compile the above example on Mac OS X 10.8.5 as
32bit. When I run that example I get a segmentation fault. The example
works fine on Linux.
If anyone is interested I found the problem. I added the following code:
version( linux )
{
cleanup.pop( 0 );
}
else version( darwin )
{
cleanup.pop( 0 );
}
else version( solaris )
{
cleanup.pop( 0 );
}
else
{
pthread_cleanup_pop( 0 );
}
Here:
http://www.dsource.org/projects/tango/browser/trunk/tango/core/Thread.d#L275
--
/Jacob Carlborg
Re: how to detect OS architecture?
On Wed, 18 Dec 2013 04:28:57 -, Hugo Florentino h...@acdam.cu wrote:
On Tue, 17 Dec 2013 13:21:30 -, Regan Heath wrote:
Is GetNativeSystemInfo your other solution? On the MSDN page for
GetNativeSystemInfo it recommends using IsWow64Process to detect if
you're running under WOW64, at which point you would then call
GetNativeSystemInfo.
I am not sure what GetNativeSystemInfo does if called from a 32 bit
exe on a 32 bit OS..
It seems to work. After all it makes sense, the native system is
actually 32 bits.
Cool. The reason I was unsure and the reason I do not agree that it
makes sense that it works, is the first paragraph on the MSDN page:
Retrieves information about the current system to an application
**running under WOW64**. If the function is called from **a 64-bit
application**, it is equivalent to the GetSystemInfo function.
**emphasis mine**
It doesn't actually address the situation of calling it from a 32 bit
application NOT running under WOW64.
GetSystemInfo is callable from both 32 and 64 bit so I assume now, that
given that it works for you, that it is doing what it mentions above for a
64 bit application, and actually just calling GetSystemInfo.
You will probably find that calling GetSystemInfo works just as well as
what you're already doing.
I /know/ that the code in std.internal.windows.advapi32 which
dynamically loads and calls IsWow64Process will work, because we use
it here at work for this very purpose. It's also the simplest most
direct way to answer this specific question and it's already present,
tested and working in phobos .. so I would be inclined to use it, in
preference over GetNativeSystemInfo.
R
If after using IsWOW64Process a GetNativeSystemInfo must still be issued
like you mentioned earlier, I don't see the advantage over calling that
function directly in the first place.
Or am I missing something?
Yes, you're missing something :)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139(v=vs.85).aspx
IsWow64Process returns (in the output parameter) if the 32 bit application
is running in WOW64. WOW64 *only* exists on a 64 bit OS. So, if true
this tells you you're on a 64 bit OS. You don't need an additional call
to GetNativeSystemInfo at all.
Further, the code is already in phobos so all you actually need to do is
check the isWow64 global boolean defined by
std.internal.windows.advapi32. So, your code is as simple as:
import std.stdio;
import std.internal.windows.advapi32;
void main(string[] args)
{
writefln(isWow64 ? yes : no);
}
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: how to detect OS architecture?
On Tue, 17 Dec 2013 15:13:20 -, Marco Leise marco.le...@gmx.de wrote: Am Tue, 17 Dec 2013 13:30:25 - schrieb Regan Heath re...@netmail.co.nz: On Mon, 16 Dec 2013 21:27:13 -, Hugo Florentino h...@acdam.cu wrote: On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote: On 2013-12-16 17:46, Marco Leise wrote: Hehe, I guess the whole purpose of the launcher is to run in 32-bit and detect at runtime if the 64-bit main executable can be run or the 32-bit version must be used. The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea. It is. :) Process Explorer by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries. I don't see why that changes things? Sure, you cannot extract your *static* dependent dlls (those linked at compile time with libs), those have to exist before you can execute your 32 bit launcher. But, if you really wanted to, you could extract and runtime load dlls no problem. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Can't isolate ICE
On Wednesday, 18 December 2013 at 11:47:16 UTC, Timon Gehr wrote: On 12/18/2013 12:27 PM, Andrea Fontana wrote: I have an internal compiler error in my code. I can't reduce code to reproduce this problem, but I remember there was a tool that can do this, what's its name? Where can I download that tool? https://github.com/CyberShadow/DustMite Yes! Thanks :) A bug will be opened in the next hours :P
Re: how to detect OS architecture?
On Wed, 18 Dec 2013 04:22:23 -, Hugo Florentino h...@acdam.cu wrote: On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote: Make sure you handle if users have a 32bit OS installed on a 64bit PC. As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works. It works because the SYSTEM_INFO member wProcessorArchitecture is defined to be The processor architecture of the installed operating system .. note, *installed operating system*, not processor architecture. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Wrong output of quotes in Windows (encoding?)
Hi,
A short while ago I had minor difficulties escaping quotes, and noticed
(I don't remember where) a simple function by a D user which I have now
tried to enhance. The problem is that output is incorrect in Windows
(even with unicode-supporting fonts). I tried to use transcode but could
not get it to work.
Check the following code, and please advise me what to do in order to
get the correct output:
import std.stdio, std.string, std.encoding;
@trusted string quote(in string str, in char chr = 'd') pure {
switch(chr) {
case 'b': return '`' ~ str ~ '`'; // backtick
case 'd': return `` ~ str ~ ``; // double
case 'f': return `«` ~ str ~ `»`; // french
case 's': return `'` ~ str ~ `'`; // single
case 't': return `“` ~ str ~ `”`; // typographic
default: return `` ~ str ~ ``; // double
}
}
void main() {
char[] a = ['b', 'd', 'f', 's', 't'];
auto input = just a test;
foreach(char type; a)
writeln(format(Quote type %s:\t%s, type, quote(input, type)));
}
Re: how to detect OS architecture?
On Wed, 18 Dec 2013 13:20:45 -, Regan Heath wrote: On Wed, 18 Dec 2013 04:22:23 -, Hugo Florentino h...@acdam.cu wrote: On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote: Make sure you handle if users have a 32bit OS installed on a 64bit PC. As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works. It works because the SYSTEM_INFO member wProcessorArchitecture is defined to be The processor architecture of the installed operating system .. note, *installed operating system*, not processor architecture. Well, isn't that what I needed to begin with? That's why I said OS architecture instead of CPU architecture. Unless you are refering to something else.
Re: how to detect OS architecture?
On Wed, 18 Dec 2013 13:16:35 -, Regan Heath wrote: IsWow64Process returns (in the output parameter) if the 32 bit application is running in WOW64. WOW64 *only* exists on a 64 bit OS. So, if true this tells you you're on a 64 bit OS. You don't need an additional call to GetNativeSystemInfo at all. Cool, thanks for clarifying. BTW, how could I benchmark the performance of both solutions (lets say for a few thousand runs) to see if one is more efficient than the other?
Re: package.d
On 18/12/13 10:41, Leandro Motta Barros wrote: With these simple examples I sent, rdmd seem to resolve dependecies correctly. For example, with this last example I sent (which prints the class name): $ rdmd main.d mylib.util.Foo If I create an example analogous to yours, it seems OK. However, I was dealing with a case where the package is at the 2nd level of the subdirectory hierarchy: std/random2/package.d std/random2/generator.d std/random2/distribution.d and so on. That might have something to do with it. $ dmd main.d main.o: In function `_Dmain': main.d:(.text._Dmain+0xb): undefined reference to `_D5mylib4util3Foo7__ClassZ' collect2: error: ld returned 1 exit status --- errorlevel 1 Well, quite. dmd doesn't resolve dependencies, it expects you to pass it all the necessary source or object files ... $ dmd main.d mylib/util.d $ ./main mylib.util.Foo ... like this. In this case, at least, rdmd correctly resolved, compiled and linked mylib/util.d, which was imported through a package. I think that there must be a problem with packages that are in the 2nd rather than 1st level of the subdirectory hierarchy.
Re: Can't isolate ICE
On Wed, Dec 18, 2013 at 12:27:01PM +0100, Andrea Fontana wrote: I have an internal compiler error in my code. I can't reduce code to reproduce this problem, but I remember there was a tool that can do this, what's its name? Where can I download that tool? Dustmite, by Vladimir Panteleev. It's actually packaged with the 'tools' repository in Dlang's github organization now; you can get it here: https://github.com/D-Programming-Language/tools.git T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Re: Wrong output of quotes in Windows (encoding?)
On 12/18/2013 05:32 AM, Hugo Florentino wrote:
output is incorrect in Windows (even with unicode-supporting
fonts).
Is the code page also set to UTF-8? I think you must issue the command
'chcp 65001'.
I have changed your program to print the code units individually in hex.
I changed the test string to a single space character so that you can
identify it easily on the output:
import std.stdio, std.string, std.encoding;
@trusted string quote(in string str, in char chr = 'd') pure {
switch(chr) {
case 'b': return '`' ~ str ~ '`'; // backtick
case 'd': return `` ~ str ~ ``; // double
case 'f': return `«` ~ str ~ `»`; // french
case 's': return `'` ~ str ~ `'`; // single
case 't': return `“` ~ str ~ `”`; // typographic
default: return `` ~ str ~ ``; // double
}
}
void main() {
char[] a = ['b', 'd', 'f', 's', 't'];
auto input = ;
foreach(char type; a)
writeln(format(Quote type %s:\t%(%02x %), type,
cast(ubyte[])quote(input, type)));
}
Does the output of the program look correct according to UTF-8? Then
your compiler has produced a correct program. :) Here is the output I
get on SL6.1 compiled with dmd v2.065-devel-41ebb59:
Quote type b: 60 20 60
Quote type d: 22 20 22
Quote type f: c2 ab 20 c2 bb
Quote type s: 27 20 27
Quote type t: e2 80 9c 20 e2 80 9d
I trust the correctness of this feature of D so much that I am too lazy
to check whether those code units correspond to the intended Unicode
characters. :)
Ali
std.regex literal syntax (the \Q…\E escape sequence)
I'm reading through http://www.regular-expressions.info, and there's a feature that's missing from std.regex, quoted: - All the characters between the \Q and the \E are interpreted as literal characters. E.g. \Q*\d+*\E matches the literal text *\d+*. The \E may be omitted at the end of the regex, so \Q*\d+* is the same as \Q*\d+*\E. - This would translate to the following needing to work (which fails at runtime with an exception): writeln(r*\d+*.match(r\Q*\d+*\E)); Should this feature be added? I guess there's probably more regex features missing (I just began reading the page), I'm not sure how Dmitry feels about adding X number of features though.
Re: std.regex literal syntax (the \Q…\E escape sequence)
18-Dec-2013 22:33, Andrej Mitrovic пишет: I'm reading through http://www.regular-expressions.info, and there's a feature that's missing from std.regex, quoted: - All the characters between the \Q and the \E are interpreted as literal characters. E.g. \Q*\d+*\E matches the literal text *\d+*. The \E may be omitted at the end of the regex, so \Q*\d+* is the same as \Q*\d+*\E. [snip] Should this feature be added? I guess there's probably more regex features missing (I just began reading the page), I'm not sure how Dmitry feels about adding X number of features though. All in all I wanted to be principled about what set of features to support. The initial design was: 1. Choose a syntax flavor (ECMAScript) 2. Add some powerful stuff (e.g. unlimited lookbehind, full unicode-support) 3. Add some convenient stuff that is popular enough/easy to implement (named captures). 4. Avoid extensions that complicate engine and preclude optimizations, or heavily depend on implementation. (So no recursion and similar madness) In that light 'missing' might be on purpose. For instance std.regex doesn't provide 'atomic'(possessive) groups simply because it's a kludge invented for poor (performance of) backtracking engines. By the end of day any feature is interesting as long as we carefully weight: - how useful a feature is - how widespread the syntax/how many precedents in other libraries against - how difficult to implement - does it affect backwards compatibility - any other hidden costs I'd be glad to implement well motivated enhancement requests. P.S. This reminds me to put a roadmap of sorts on where std.regex is going and what to expect. -- Dmitry Olshansky
Re: std.regex literal syntax (the \Q…\E escape sequence)
On 12/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: By the end of day any feature is interesting as long as we carefully weight: - how useful a feature is - how widespread the syntax/how many precedents in other libraries against - how difficult to implement - does it affect backwards compatibility - any other hidden costs I'd be glad to implement well motivated enhancement requests. Excellent, that's what I'm hoping for from any library dev. Weigh the odds before adding random features. :)
Re: std.regex literal syntax (the \Q…\E escape sequence)
On 12/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: P.S. This reminds me to put a roadmap of sorts on where std.regex is going and what to expect. Btw one thing I'm not fond of is the format specifiers, in particular: $` part of input preceding the match. $' part of input following the match. ` and ' are very hard to tell apart. But I guess this was based on an existing standard? Personally I'd prefer $ and $.
Re: std.regex literal syntax (the \Q…\E escape sequence)
18-Dec-2013 23:54, Andrej Mitrovic пишет: On 12/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: P.S. This reminds me to put a roadmap of sorts on where std.regex is going and what to expect. Btw one thing I'm not fond of is the format specifiers, in particular: $` part of input preceding the match. $' part of input following the match. ` and ' are very hard to tell apart. But I guess this was based on an existing standard? Personally I'd prefer $ and $. The precedent is Perl. A heavy influencer on the (former) std.regex design. http://perldoc.perl.org/perlre.html#Capture-groups (grep for $') Personally I'd prefer both simply gone :) Reasoning is that you can't support these while pattern matching on the fly (say on a network stream). Since we can't do that - anything better that is popular enough is acceptable. -- Dmitry Olshansky
Re: Embed Windows Internet Explorer
Am 16.12.2013 19:44, schrieb Andre: Hi, I try to embed Windows Internet Explorer into my application. Most of the coding should be availabe. During method navigate2 I get an empty white screen. No errors is thrown but also the web page is not loaded. Do you have some ideas? = Is use the windows headers from DSource and the dgui forms library. I attached the source code. Kind regards André The issue was related to SysAllocString: VARIANT myURL; VariantInit(myURL); myURL.vt = cast(VARTYPE)VARENUM.VT_BSTR; = myURL.bstrVal = SysAllocString(cast(const(wchar*))url); webBrowser2.Navigate2( myURL, null, null, null, null); It only works with statement: myURL.bstrVal = cast(wchar*)http://www.google.de;;
Re: std.regex literal syntax (the \Q…\E escape sequence)
On 12/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: The precedent is Perl. A heavy influencer on the (former) std.regex design. http://perldoc.perl.org/perlre.html#Capture-groups (grep for $') Ah, classic Perl. Write once - don't bother to read ever again. :p
Re: std.regex literal syntax (the \Q…\E escape sequence)
19-Dec-2013 01:05, Andrej Mitrovic пишет: On 12/18/13, Dmitry Olshansky dmitry.o...@gmail.com wrote: The precedent is Perl. A heavy influencer on the (former) std.regex design. http://perldoc.perl.org/perlre.html#Capture-groups (grep for $') Ah, classic Perl. Write once - don't bother to read ever again. :p Or rather - if it's so fast to (re)write, why bother reading at all? :) -- Dmitry Olshansky
Re: Wrong output of quotes in Windows (encoding?)
On Wed, 18 Dec 2013 10:05:49 -0800, Ali Çehreli wrote:
On 12/18/2013 05:32 AM, Hugo Florentino wrote:
output is incorrect in Windows (even with unicode-supporting
fonts).
Is the code page also set to UTF-8? I think you must issue the
command 'chcp 65001'.
I have changed your program to print the code units individually in
hex. I changed the test string to a single space character so that
you
can identify it easily on the output:
import std.stdio, std.string, std.encoding;
@trusted string quote(in string str, in char chr = 'd') pure {
switch(chr) {
case 'b': return '`' ~ str ~ '`'; // backtick
case 'd': return `` ~ str ~ ``; // double
case 'f': return `«` ~ str ~ `»`; // french
case 's': return `'` ~ str ~ `'`; // single
case 't': return `“` ~ str ~ `”`; // typographic
default: return `` ~ str ~ ``; // double
}
}
void main() {
char[] a = ['b', 'd', 'f', 's', 't'];
auto input = ;
foreach(char type; a)
writeln(format(Quote type %s:\t%(%02x %), type,
cast(ubyte[])quote(input, type)));
}
Does the output of the program look correct according to UTF-8? Then
your compiler has produced a correct program. :) Here is the output I
get on SL6.1 compiled with dmd v2.065-devel-41ebb59:
Quote type b: 60 20 60
Quote type d: 22 20 22
Quote type f: c2 ab 20 c2 bb
Quote type s: 27 20 27
Quote type t: e2 80 9c 20 e2 80 9d
I trust the correctness of this feature of D so much that I am too
lazy to check whether those code units correspond to the intended
Unicode characters. :)
Ali
Changing the codepage worked indeed. Thanks.
Now, how could I do that programmatically, so that if my application
runs on a system with a different codepage, the output looks correct?
After all, not all users feel comfortable typing unknown commands.
Re: Wrong output of quotes in Windows (encoding?)
On 12/18/2013 01:17 PM, Hugo Florentino wrote: Changing the codepage worked indeed. Thanks. Now, how could I do that programmatically, so that if my application runs on a system with a different codepage, the output looks correct? It is not solvable in general because stdout is nothing but a stream that accepts characters. (Well, UTF-8 code units when it comes to Unicode). The program can detect or assume that it is running in a console and change that environment if it is allowed to do so. Google searches like change code page console programmatically windows produce some answers but I don't have any experience. :) Ali
Re: [OT] Re: How to read fastly files ( I/O operation)
On Friday, 8 February 2013 at 06:22:18 UTC, Denis Shelomovskij wrote: 06.02.2013 19:40, bioinfornatics пишет: On Wednesday, 6 February 2013 at 13:20:58 UTC, bioinfornatics wrote: I agree the spec format is really bad but it is heavily used in biology so i would like a fast parser to develop some D application instead to use C++. Yes, lets also create 1 GiB XML files and ask for fast encoding/decoding! The situation can be improved only if: 1. We will find and kill every text format creator; 2. We will create a really good binary format for each such task and support it in every application we create. So after some time text formats will just die because of evolution as everything will support better formats. (the second proposal is a real recommendation) There is a binary resource format for emf models, which normally use xml files, and some timing improvements stated at this link. It might be worth looking at this if you are thinking about writing your own binary format. http://www.slideshare.net/kenn.hussey/performance-and-extensibility-with-emf There is also a fast binary compression library named blosc that is used in some python utilities, measured and presented here, showing that it is faster than doing a memcpy if you have multiple cores. http://blosc.pytables.org/trac On the sequential accesses ... I found that windows writes blocks of data all over the place, but the best way to get it to write something in more contiguous locations is to modify the file output routines to use specify write through. The sequential accesses didn't improve read times on ssd. Most of the decent ssds can read big files at 300MB/sec or more now, and you can raid 0 a few of them and read 800MB/sec.
Re: How to read fastly files ( I/O operation)
On Wednesday, 13 February 2013 at 17:39:11 UTC, monarch_dodra wrote: On Tuesday, 12 February 2013 at 22:06:48 UTC, monarch_dodra wrote: On Tuesday, 12 February 2013 at 21:41:14 UTC, bioinfornatics wrote: Some time fastq are comressed to gz bz2 or xz as that is often a huge file. Maybe we need keep in mind this early in developement and use std.zlib While working on making the parser multi-threaded compatible, I was able to seperate the part that feeds data, and the part that parses data. Long story short, the parser operates on an input range of ubyte[]: It is not responsible any more for acquisition of data. The range can be a simple (wrapped) File, a byChunk, an asynchroneus file reader, or a zip decompresser, or just stdin I guess. Range can be transient. However, now that you mention it, I'll make sure it is correctly supported. I'll *try* to show you what I have so far tomorow (in about 18h). Yeah... I played around too much, and the file is dirtier than ever. The good news is that I was able to test out what I was telling you about: accepting any range is ok: I used your ZFile range to plug it into my parser: I can now parse zipped files directly. The good news is that now, I'm not bottle necked by IO anymore! The bad news is that I'm now bottle necked by CPU decompressing. But since I'm using dmd, you may get better results with LDC or GDC. In any case, I am now parsing the 6Gig packed into 1.5Gig in about 53 seconds (down from 61). I also tried doing a dual-threaded approach (1 thread to unzip, 1 thread to parse), but again, the actual *parse* phase is so ridiculously fast, that it changes *nothing* to the final result. Long story short: 99% of the time is spent acquiring data. The last 1% is just copying it into local buffers. The last good news though is that CPU bottleneck is always better than IO bottleneck. If you have multiple cores, you should be able to run multiple *instances* (not threads), and be able to process several files at once, multiplying your throughput. I modified the library unzip to make a parallel unzip a while back (at the link below). The execution time scaled very well for the number of cpus for the test case I was using, which was a 2GB unzip'd distribution containing many small files and subdirectories. The parallel operations were by file. I think the execution time gains on ssd drives were from having multiple cores scheduling the writes to separate files in parallel. https://github.com/jnorwood/file_parallel/blob/master/unzip_parallel.d
Unique IDs for each template instantiation at compile-time?
I was wondering if it was possible to generate unique(in order)
IDs for each template instantiation of a class at compile-time.
A short example of what I'm trying to do:
static int counter = 0;
class A(T)
{
enum id = counter++;
}
class B : A!B
{
}
Ofcourse, this doesn't compile because the counter variable
can't be read at compile-time.
Re: Unique IDs for each template instantiation at compile-time?
Weasel: I was wondering if it was possible to generate unique(in order) IDs for each template instantiation of a class at compile-time. I think you can't do this. (It's usually named gensym). Bye, bearophile
casting between structs
I'd like to reinterpret data as different type without copying.
extern(C) struct A{ /* */ }
struct B
{
A a;
alias a this;
}
extern(C) A* f1(){ /* */ }
B* f2()
{
return cast(B*) f1();
}
Assuming that i cast() correct state, i'd like to know if:
* it's currently safe
* it's guaranteed to be safe in the future
* there any precautions in using this pattern
Most important thing for me is a type-check, but defining
operators ( since they can't be external ) would be nice too.
I'm asking because i'd like to use this pattern a lot in my code,
and with my limited knowledge it's good to get some feedback of
more experienced.
Ps.
In situations when i return by value instead of pointer - will
memory copying be optimized away ?
Re: casting between structs
Mariusz `shd` Gliwiński: * it's currently safe One thing to remember when casting, is that when you cast const/immutable to mutable, then you can't mutate the data. Bye, bearophile
Re: Unique IDs for each template instantiation at compile-time?
On Thu, Dec 19, 2013 at 12:01:03AM +0100, Weasel wrote: I was wondering if it was possible to generate unique(in order) IDs for each template instantiation of a class at compile-time. [...] You could use the built-in .mangleof property to get the mangled name of the template, which can then be used as a unique string for that particular template instantiation. The disadvantage is that this is a string, which may be inefficient depending on what you want to do with it. So you may want to take advantage of CTFE by using the hash of this string instead, say using the hashOf function, and use the resulting hash value as your ID. Assuming that the hash function isn't so horrible that two template instantiations' hash values will collide, this ID should be unique. T -- Famous last words: I *think* this will work...
