Re: Error: function declaration without return type.
On Wednesday, 7 January 2015 at 08:58:35 UTC, Suliman wrote:
thanks!
Am I right understand that in next code scope(exit)
stmt.close(); occur after this execution? And it will close
connection so stmt in function become unavailable.
this(parseConfig parseconfig)
{
[]
auto conn = ds.getConnection();
scope(exit) conn.close();
stmt = conn.createStatement();
scope(exit) stmt.close(); //HERE
} void InsertData()
{
auto rs = stmt.executeUpdate(sqlinsert); // stmt now unreachable
}
scope(exit) executes at the exit of the inner most scope. Scopes
end at '}'. Which is the very next line in this case.
Re: Sargon library gets Ddoc macro processor
On 1/6/2015 11:42 PM, Jacob Carlborg wrote: On 2015-01-07 05:06, Walter Bright wrote: I've wanted to do this for a while. The Ddoc macro system should work on any piece of text you'd like to add macro support to. http://digitalmars.com/sargon/textmac.html Hmm, I wonder how good name textmac is. When I read mac I was thinking of Apple Mac, not mac short for macro. Eh, mac as short for macro is at least as old as the PDP-11 :-)
Re: DConf 2015 Call for Submissions is now open
On 1/7/2015 12:06 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wednesday, January 07, 2015 07:37:10 Mengu via Digitalmars-d-announce wrote: is it crazy to think that there are some people somewhere who can't stand D and anything D related? Well, _I_ wouldn't want to see a D on my report card. ;) I got a D in programming!
Re: DlangUI project update
On Friday, 26 December 2014 at 12:33:04 UTC, Vadim Lopatin wrote: Hello! DlangUI project is alive and under active development. https://github.com/buggins/dlangui Recent changes: - new controls: ScrollWidget, TreeView, ComboBox, ... - new dialogs: FileOpenDialog, MessageBox - a lot of bugfixes - performance improvements in software renderer - killer app: new example - Tetris game :) Try Demos: # download sources git clone https://github.com/buggins/dlangui.git cd dlangui # example 1 - demo for most of widgets dub run dlangui:example1 --build=release # tetris - demo for game development dub run dlangui:tetris --build=release DlangUI is cross-platform GUI library written in D. Main features: - cross platform: uses SDL for linux/macos, Win32 API or SDL for Windows - hardware acceleration: uses OpenGL for drawing when built with version USE_OPENGL - easy to extend: since it's native D library, you can add your own widgets and extend functionality - Unicode and internationalization support - easy to customize UI - look and feel can be changed using themes and styles - API is a bit similar to Android - two phase layout, styles Screenshots (a bit outdated): http://buggins.github.io/dlangui/screenshots.html See project page for details. I would like to get any feedback. Will be glad to see advises, bug reports, feature requests. Best regards, Vadim Hi Vadim, When I follow the building and the running of the demo app using DUB I get the following error: C:\D\dmd2\srcgit clone https://github.com/buggins/dlangui.git Cloning into 'dlangui'... remote: Counting objects: 5700, done. remote: Compressing objects: 100% (56/56), done. remote: Total 5700 (delta 21), reused 0 (delta 0) Receiving objects: 100% (5700/5700), 5.33 MiB | 1.51 MiB/s, done. Resolving deltas: 100% (/), done. C:\D\dmd2\srccd dlangui C:\D\dmd2\src\dlanguidub run dlangui:example1 --build=release Building package dlangui:example1 in C:\D\dmd2\src\dlangui\examples\example1\ WARNING: A deprecated branch based version specification is used for the dependency derelict-ft. Please use numbered ver sions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a b ranch instead. WARNING: A deprecated branch based version specification is used for the dependency derelict-sdl2. Please use numbered v ersions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. WARNING: A deprecated branch based version specification is used for the dependency derelict-fi. Please use numbered ver sions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a b ranch instead. WARNING: A deprecated branch based version specification is used for the dependency dlangui:dlanguilib. Please use numbe red versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. WARNING: A deprecated branch based version specification is used for the dependency derelict-gl3. Please use numbered ve rsions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Target derelict-util 1.9.0 is up to date. Use --force to rebuild. Target derelict-ft ~master is up to date. Use --force to rebuild. Target derelict-sdl2 ~master is up to date. Use --force to rebuild. Target derelict-fi ~master is up to date. Use --force to rebuild. Target dlib ~master is up to date. Use --force to rebuild. Target derelict-gl3 ~master is up to date. Use --force to rebuild. Building dlangui:dlanguilib 0.2.2+commit.2.g15226e8 configuration library, build type release. Running dmd... Building dlangui:example1 0.2.2+commit.2.g15226e8 configuration application, build type release. Compiling using dmd... src\dlangui\core\files.d(114): Error: module windows is in file 'win32\windows.d' which cannot be read import path[0] = examples\example1\src import path[1] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\derelict-ft-master\source import path[2] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\derelict-util-1.9.0\source import path[3] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\derelict-sdl2-master\source import path[4] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\derelict-fi-master\source import path[5] = src import path[6] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master import path[7] = ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\derelict-gl3-master\source import path[8] = C:\D\dmd2\windows\bin\..\..\src\phobos import path[9] = C:\D\dmd2\windows\bin\..\..\src\druntime\import FAIL examples\example1\.dub\build\application-release-windows-x86-dmd_2066-A150B7CA4D2F564C56024EE584D1E13A\ example1 ex ecutable Error executing command run: dmd failed
Re: Ready to make page-per-item ddocs the default?
On 1/7/2015 12:41 AM, Vladimir Panteleev wrote: On Wednesday, 7 January 2015 at 07:12:33 UTC, Walter Bright wrote: I find dman.exe to be very handy and use it all the time, but since it is a hand-built index, it is always hopelessly out of date. Why not reuse the index built by chmgen? It's very inclusive and mostly accurate. There seems to be a lack of documentation on it :-( Anyhow, dman is pretty simple. It maps the command line argument to a url and opens the browser on the url. If the argument is not in its index, it reverts to using google. It would be much improved if it were combined with chmgen somehow.
Re: Error: function declaration without return type.
thanks!
Am I right understand that in next code scope(exit) stmt.close();
occur after this execution? And it will close connection so stmt
in function become unavailable.
this(parseConfig parseconfig)
{
[]
auto conn = ds.getConnection();
scope(exit) conn.close();
stmt = conn.createStatement();
scope(exit) stmt.close(); //HERE
}
void InsertData()
{
auto rs = stmt.executeUpdate(sqlinsert); // stmt now unreachable
}
Re: Ready to make page-per-item ddocs the default?
On 2015-01-07 00:44, weaselcat wrote: Is it intentional for all of the stdc pages to be empty? Why is even std.c.* still available. These should all be replaced with core.stdc.*. -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On 2015-01-06 23:43, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. What about all those suggestions in the thread Improving ddoc [1]? Some of those suggestions might require to redesign the documentation. Is it still worth updating to the new layout? [1] http://forum.dlang.org/thread/m81k2p$k47$1...@digitalmars.com -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 08:46:41 UTC, Vladimir Panteleev wrote: * Overzealous linking of words in the documentation that happen to coincide with symbols in the same module. This should only be done for text in $(D ...) tags. According to the specs: Identifiers in documentation comments that are function parameters or are names that are in scope at the associated declaration are emphasized in the output. This emphasis can take the form of italics, boldface, a hyperlink, etc. How it is emphasized depends on what it is - a function parameter, type, D keyword, etc. To prevent unintended emphasis of an identifier, it can be preceded by an underscore (_). The underscore will be stripped from the output. So it's conforming. However, I think this specific part of the spec cause more problems than it solves. Just think about using `any`, `all`, `find` and so on in `std.algorithm. Maybe it's time to update the specs ? :)
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 01:13:21 UTC, Andrei Alexandrescu wrote: On 1/6/15 4:26 PM, Robert burner Schadek wrote: std.string looks fine only the indexOfNeither and lastIndexOfNeither are missing Could you please fix -- thanks! -- Andrei I think I just did. Does the webpage show 2.066? If so indexOfNeither must not be part as it was merged after the release.
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 12:22 AM, Tobias Pankrath wrote: On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Has it been generated from an up-to-date version? Where are the sub modules of std.container? http://dlang.org/library/std/container.html Try http://dlang.org/library-prerelease/std/container.html -- Andrei
Re: Ready to make page-per-item ddocs the default?
On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Has it been generated from an up-to-date version? Where are the sub modules of std.container? http://dlang.org/library/std/container.html
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 12:24 AM, Andrei Alexandrescu wrote: On 1/7/15 12:22 AM, Tobias Pankrath wrote: On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Has it been generated from an up-to-date version? Where are the sub modules of std.container? http://dlang.org/library/std/container.html Try http://dlang.org/library-prerelease/std/container.html -- Andrei Apparently the links exist, but don't work, e.g. http://dlang.org/library-prerelease/std/std_container_array is not to be found. -- Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/6/15 2:43 PM, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Many thanks to those who provided feedback on the new layout! I've fixed a few issues, but it looks like there are quite a few more problems than I had anticipated. I encourage any and all of you to build the documentation locally (make -j should work nicely) and help with pull requests to github. Let's get this off the ground together. Thanks, Andrei
Re: DConf 2015 Call for Submissions is now open
On Wednesday, January 07, 2015 07:37:10 Mengu via Digitalmars-d-announce wrote: is it crazy to think that there are some people somewhere who can't stand D and anything D related? Well, _I_ wouldn't want to see a D on my report card. ;) - Jonathan M Davis
Re: DConf 2015 Call for Submissions is now open
On Tuesday, January 06, 2015 15:24:19 Andrei Alexandrescu via Digitalmars-d-announce wrote: Hello, Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley University in Orem, UT. LOL. My brother is graduating from there about a month before that. The call for submissions is now open at http://dconf.org. Please mind the submission deadline: February 27, 2015. We are hoping to build a strong program with the help of D established luminaries who spoke at previous editions of DConf, as well as up-and-coming contributors. So please send us your submissions soon. There's a good deal of progress and strength building in our community as of late, and you can make the conference reflect it. Oh no, now I'm going to have to come up with submissions again! ;) - Jonathan M Davis
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 07:12:33 UTC, Walter Bright wrote: On 1/6/2015 10:48 PM, Andrei Alexandrescu wrote: Another one; I tried to use the search box on the top right corner... it just resulted in a google search. Can we do better than that? When people go to the documentation page, they want to search the docs, not get a standard google results page. That would be quite an involved project. -- Andrei I find dman.exe to be very handy and use it all the time, but since it is a hand-built index, it is always hopelessly out of date. Why not reuse the index built by chmgen? It's very inclusive and mostly accurate.
Re: Copy only frame pointer between objects of nested struct
On Tuesday, 6 January 2015 at 23:32:25 UTC, Artur Skawina via That shows a static struct, so I'm not sure it's the same problem. static structs with template alias parameters to local symbols count as nested structs. Your solution would likely work, but yes, I'm looking for something less hacky :-)
Re: Ready to make page-per-item ddocs the default?
On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. From my last complain thread: http://forum.dlang.org/post/zazgfoxjwhjbdrgdi...@forum.dlang.org I see that many of the issues with my example got fixed. Remaining issues: * Overzealous linking of words in the documentation that happen to coincide with symbols in the same module. This should only be done for text in $(D ...) tags. * Compile-time expressions are expanded to their computed variant. For example, `size_t.max` is expanded to `18446744073709551615LU`, which is not informative, and wrong on 32-bit systems. `Config.none` is now `cast(Config)0`, which sucks. I guess this is a compiler issue rather than a DDox one. More issues I noticed now from a quick look: * http://dlang.org/library/std/process.html : The comparison table is gone, replaced with an unstructured blob of text. * http://dlang.org/library/std/parallelism.html : More overzealous linking (e.g.: These include _parallel_ foreach, _parallel_ reduce, _parallel_ eager map, ...). * http://dlang.org/library/core/time.html : More overzealous linking - symbols within D string literals should not be linked. * I still have reservations about using Disqus.
Re: Ready to make page-per-item ddocs the default?
Apparently the links exist, but don't work, e.g. http://dlang.org/library-prerelease/std/std_container_array is not to be found. -- Andrei It works from the tree on the left.
Re: Phobos colour module?
On Wednesday, 7 January 2015 at 00:30:20 UTC, Manu via Digitalmars-d wrote: On 7 January 2015 at 09:22, via Digitalmars-d digitalmars-d@puremagic.com wrote: For inspiration: http://golang.org/pkg/image/color/ Umm, is there something about this that you like? This looks... really terrible. Not particularly like, but it is the colour module for a comparable language. It reflects what they needed to implement other modules for image file formats. JPEG uses YCbCr: http://www.w3.org/Graphics/JPEG/jfif3.pdf I think it might be a good idea to do a survey of what other libraries provide and figure out why the provide it. That should give good coverage.
Shouldn't the pointers be different
When i try to run the following code
import std.stdio;
void main(){
auto a= new test!int();
a.add(0);
a.add(1);
}
class test(T){
void add(T e){
auto temp= new node();
writeln(new node, temp);
}
class node{
T v;
}
}
http://dpaste.dzfl.pl/c8e56b5954b8
The two nodes have the same address, is this right?
Re: Shouldn't the pointers be different
On Wednesday, 7 January 2015 at 10:37:18 UTC, Nick wrote:
When i try to run the following code
import std.stdio;
void main(){
auto a= new test!int();
a.add(0);
a.add(1);
}
class test(T){
void add(T e){
auto temp= new node();
writeln(new node, temp);
}
class node{
T v;
}
}
http://dpaste.dzfl.pl/c8e56b5954b8
The two nodes have the same address, is this right?
I don't know the mechanism by which they are the same (optimiser
or garbage collector), but there's not reason why they shouldn't
be.
By the time you get to the second `new node()` the first one is
completely unreachable, so why not just reuse the memory?
Considering you don't initialise them differently, the object
could even just be reused as-is.
Re: Shouldn't the pointers be different
Nick:
The two nodes have the same address, is this right?
What you are printing is the address of the reference in the
stack frame of add(). If you want to print the reference you can
use this:
import std.stdio;
class Test(T) {
static class Node {
T v;
}
void add(T e) {
auto n = new Node;
writeln(New node address: , cast(void*)n);
}
}
void main() {
auto t = new Test!int;
t.add(0);
t.add(1);
}
Note also that class/struct/enum/union names in D start with an
upper case. I have also used a static class instead.
Bye,
bearophile
Re: Shouldn't the pointers be different
On Wednesday, 7 January 2015 at 10:56:09 UTC, John Colvin wrote:
On Wednesday, 7 January 2015 at 10:37:18 UTC, Nick wrote:
When i try to run the following code
import std.stdio;
void main(){
auto a= new test!int();
a.add(0);
a.add(1);
}
class test(T){
void add(T e){
auto temp= new node();
writeln(new node, temp);
}
class node{
T v;
}
}
http://dpaste.dzfl.pl/c8e56b5954b8
The two nodes have the same address, is this right?
I don't know the mechanism by which they are the same
(optimiser or garbage collector), but there's not reason why
they shouldn't be.
By the time you get to the second `new node()` the first one is
completely unreachable, so why not just reuse the memory?
Considering you don't initialise them differently, the object
could even just be reused as-is.
Sorry, my mistake, bearophile is correct. Nonetheless, you
shouldn't be surprised to see memory being re-used.
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
What you want is some kind of code obfuscation. The easiest thing for you is to use exe compression. It is not going to stop a dedicated attacker, but ordinary people will not be able to extract any information from it. And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup.
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
Dne 7.1.2015 v 12:00 Laeeth Isharc via Digitalmars-d-learn napsal(a): What you want is some kind of code obfuscation. The easiest thing for you is to use exe compression. It is not going to stop a dedicated attacker, but ordinary people will not be able to extract any information from it. And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup. I don't think you would really need any compile time capabilities. You could just xor your strings and xor them again before using them to make it reasonably unreadable. But the thing is that doing these changes inside the code adds unnecessary complexity and is a potential source of bugs. Using an exe packer has the advantage of being practically a one-click solution. smime.p7s Description: Elektronicky podpis S/MIME
Re: An idea for commercial support for D
On Wednesday, 7 January 2015 at 12:16:39 UTC, Iain Buclaw via Digitalmars-d wrote: I feel that the same is for the reverse too. If you remove features, you again enter the realm of being another language. Yes, but would a business care? What they care about is productivity and risk assessment. Going with a reduced feature set means they can move to open source D later on. So the risk is low. You also have source-to-source compilation as an alternative (introduce new features, but provide source-to-source utility to mitigate perceived risk). There may be many implementation details that you can omit or improve, such as how you go about dealing with closures, moduleinfo, thread-local GC - but features listed in the D specification are not optional. It is optional until you have an installed base. Specifications mean nothing unless it is backed up with a valuable (for the business) corpus that depends on it. For a game developer the features used by the selected third party physics engine means more than what the C++11 standard says...
Re: For the lulz: ddmd vs libdparse lexer timings
On Wednesday, 7 January 2015 at 13:02:20 UTC, Daniel Murphy wrote: Iain Buclaw via Digitalmars-d wrote in message news:mailman.4250.1420635158.9932.digitalmar...@puremagic.com... No, that assert should never fail. And yet for some reason it does. Every type has at least a size of one byte. So a and b occupy different stack slots due to padding. The default op== does a memcmp and compares the padding as well. My guess.
Re: An idea for commercial support for D
On Wednesday, 7 January 2015 at 02:16:47 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote: On 06/01/15 23:32, uri via Digitalmars-d wrote: The dmd backend is not under an OSS license, why haven't they left? I suspect there are not very many of the type of people you're talking about in the D community. It's possible that you're right but I don't see it happening. The backend doesn't provide any benefit to GDC and LDC and Walter has a very good reason for closing the backend sources which is understood by all. Small point: the DMD backend may not be released under a free software license, but it is not closed -- the source is available, development happens in the open, and in a de facto (rather than de jure) sense there is little to distinguish from an open source project. The licensing situation is obviously unfortunate, but it makes little practical difference considering that the vast majority of D language development is in the freely-licensed frontend, runtime or standard library, and there are two excellent free backends available. This is a pretty good example of what I have referred to elsewhere in this thread, about the contextual nature of objections to non-free. Thanks for the correction, and a very important one at that in the context of this thread. I wasn't aware the backend was open source. Cheers, uri
Re: An idea for commercial support for D
On 7 January 2015 at 12:00, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via Digitalmars-d wrote: That is where the value-for-money factor comes in. I cannot see any traction occurring in Joakim's badly thought out idea unless you have some *new* to give. I somehow feel that there is a commercial closed source opportunity in reducing the feature set somewhat (and fix critical bugs) then redo the memory model so that it performs well in production. I feel that the same is for the reverse too. If you remove features, you again enter the realm of being another language. There may be many implementation details that you can omit or improve, such as how you go about dealing with closures, moduleinfo, thread-local GC - but features listed in the D specification are not optional.
Re: For the lulz: ddmd vs libdparse lexer timings
Tobias Pankrath wrote in message news:sdturuippuqoqvbuq...@forum.dlang.org... Every type has at least a size of one byte. So a and b occupy different stack slots due to padding. The default op== does a memcmp and compares the padding as well. My guess. Haha yes, you're spot on. I was asking more like, why does dmd do something so stupid? https://issues.dlang.org/show_bug.cgi?id=13947
Re: An idea for commercial support for D
On Wednesday, 7 January 2015 at 11:46:19 UTC, Iain Buclaw via Digitalmars-d wrote: That is where the value-for-money factor comes in. I cannot see any traction occurring in Joakim's badly thought out idea unless you have some *new* to give. I somehow feel that there is a commercial closed source opportunity in reducing the feature set somewhat (and fix critical bugs) then redo the memory model so that it performs well in production. It makes sense for a business that have 5 developers working on a product to pay $10.000/year to get more productive. Of course, this is a shaky business model since the ROI could go out the window if the D community decides that a stable polished version of D is a worthy goal...
Re: Ready to make page-per-item ddocs the default?
On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei I think there needs to a clear separation between the end of the overview (e.g. the cheat sheet in std.algorithm) and the rather arbitrarily organised content beneath. A big header saying API Reference or similar would do the trick. I guess it makes sense in a way, but should an end user care that std.algorithm.map happens to be written as a function nested in a template and std.algorithm.find is a function template? I'm not sure. The name column in the variable reference tables is often far too narrow. It is *much* harder to get the general feel of a module in the new format, unless it has a comprehensive overview. Previously I would just scan down the page, seeing which symbols had more documentation and examples (probably major entry points to the API), quickly gaining context by having glanced at things on the way through. Now I'd have to go through symbols individually, without context, by laboriously clicking on links. Awful. Overall it's a good idea, but while it will make std.algorithm, std.range and some other well-documented modules with extensive summaries and tables easier to use, it makes less well documented modules even worse than they were before.
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 06:48:23 UTC, Andrei Alexandrescu wrote: That would be quite an involved project. -- Andrei http://dpldocs.info/
Re: For the lulz: ddmd vs libdparse lexer timings
On 7 January 2015 at 12:35, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Iain Buclaw via Digitalmars-d wrote in message
news:mailman.4248.1420631820.9932.digitalmar...@puremagic.com...
I'd say bug in dmc.
Yeah I'm thinking so, fun. It looks like dmc sets up the code to copy the
struct into the variable but never bothers emitting the loop/movsds.
What about this:
struct S
{
}
void main()
{
S a = void;
S b = void;
assert(a == b); // Should this ever fail?
}
No, that assert should never fail.
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wednesday, 7 January 2015 at 14:18:53 UTC, FrankLike wrote: On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote: What you want is some kind of code obfuscation. The easiest thing for you is to use exe compression. It is not going to stop a dedicated attacker, but ordinary people will not be able to extract any information from it. And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup. Thank you,but it's not easy to do,can you show me some detail? http://dpaste.dzfl.pl/3bbdecfefa5c
Re: GSOC - Holiday Edition
03-Jan-2015 08:25, Mike пишет: On Friday, 2 January 2015 at 15:28:58 UTC, Craig Dillabaugh wrote: Thanks for all the links, and sorry to hear that things haven't gone well. Do you think it would be worthwhile having a 'Bare Metal D' project for this year, or do you think we would just be wasting the time of some student? I think, without a few fundamental changes to the language and the runtime, bare-metal programming in D will always be playing second fiddle to C, and that significantly diminishes its appeal. As I and others have shown, it can be done, but without the aforementioned changes, it will always feel hackish and be viewed as little more than an interesting experiment. The changes I'm thinking of would be very few, but fundamental breaking changes, Truth be told none of listed in this thread feel fundamental to me. It looks more like a set of patches to each specific problem in the compiler or run-time. Yeah, run-time would better be more customizable, but it's just our *current* run-time it's not the language. and that doesn't sit well with this community. Anyone pursuing bare-metal programming in D will need to create a slightly different dialect of the language if they want it to be a tool rather than a toy. The only difference of this to e.g. AVR-GCC (used in Arduinos and such) toolkits is that all hacks (most are upstream but not all) are already done, and packaged in a nice shrink-wrapped box. ...and perhaps that would be a better GSOC project. That is, to fork the compiler and runtime and try to make it more suitable for systems programming, with systems programming being defined as creating the first layer of hardware abstraction. Unfortunately, such a project would probably not be very interesting to those who enjoy bare-metal programming, but rather more for those that have interest in compilers. I would not market it as bare-metal programming in D, but as creating a bare-metal dialect of D. To clarify a bit my original intents on this project. In short the goal is to make a toolkit to program a popular range of MCU (the list may grow with time) in a subset of D (aka Bare-Metal D). There is no denying the fact that embedded C/C++ is nothing like normal desktop/server ones. C library is barbarically truncated, I'm not even saying STL and RTTI, and then countless vendor extensions. Thus I do not believe that immediate upstreaming of everything bare-metal is even a good thing in principle. In my opinion a Bare-Metal D project can live its life along the upstream D by providing bare-metal versions of each successive version. In fact, we do not have all that many embedded guys in core team. All generally useful patches should find their way in upstream, of course, but it takes time and should *not* be a prerequisite. A toolkit will need to provide e.g build/fetch with a bootstrap script: - a ready to-go D cross-compiler(s) might be with some patches to disable language features for better experience etc. - a stripped run-time instead of Phobos (come on C/C++ folks use something much unlike standard library either) - linker scripts for a (growing) set of MCUs - I/O library and register definitions for MCUs (preferably a tool to auto-generate such) - a modified driver that passes all kinds of right options for a given MCU That's a minimum for other Bare Metal D projects to even start to take off. Ideally other tools include debugger, high-level libraries for peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on. Speaking of GSOC: a student is not fighting this fight alone, so mentor ought to bring issues to the core team. Secondly a project may consider completing top priority goals and secondary goals(goodies). Depending on student it can be geared more towards language or more towards embedded stuff. Filing an issues and getting community to help with compiler is totally expected. That's unfortunate, because if D were designed with bare-metal in mind from the start, it would scale well to all programming disciplines. But since it was designed more as an efficient applications programming language, you have to hammer to fit, weld to fill, paint to cover to get it to scale down to bare-metal. Forth would be excellent then ;) Yet somehow it didn't scale up. Long story short: Bare-metal programming in the current state of D would be a fun and educational experiment, but would not be something you could sell seriously to industry. If fun and education is all you're after then go for it. but a bare-metal dialect of D is what's really needed for it to be taken seriously. That's more or less the goal. Though I'd rather stay on the subset of D line rather then dialect. -- Dmitry Olshansky
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Wednesday, 7 January 2015 at 15:04:24 UTC, Paulo Pinto wrote:
On Wednesday, 7 January 2015 at 15:02:34 UTC, Laeeth Isharc
wrote:
Not true. If you're using a tree structure, you *should* use
pointers.
Unless you're using classes, which are by-reference, in which
case you
can just use the class as-is. :-)
Thanks v much.
I just came to that realization also when I stepped away.
class node
{
string name;
node ref;
}
what's wrong with the code above ? i get an error no
identifier for declarator node. (I have not used classes
much, since structs often seem to be enough for what I need to
do mostly).
ref is a reserved keyword.
--
Paulo
this conversation is so funny: well what's wrong with this . It's
a keyword...
Aa Ha ha ha ha , rol.
Seriously, is it so complicated to use a D editor ? I mean with
syntax color...
Re: setup problem wih dub
On 8/01/2015 4:48 p.m., Jason den Dulk wrote:
Hi.
Package in question: fpdf
Dub version I'm using: 0.9.22
DMD version: 2.066.1 (64 bit)
Platform: Fedora 19 (64-bit).
I created the fpdf package, and it is dependant on the imageformats
package, but it won't compile. When I place a copy of imageformats.d
into the project source directory, it compiles fine. However when I rely
on dub dependancy, the linker complains that it cannot find the
functions in imageformats. Following is a copy of the dub package. Any
insight would be appreciated.
Thanks in advance.
{
name: fpdf,
description: Minimalist class for generating PDF documents.,
authors: [ Jason den Dulk ],
license: BSL-1.0,
platforms: [posix],
targetType: sourceLibrary,
dependencies: { imageformats : =3.0.3 },
importPaths: [ src ],
configurations:
[
{
name: sample,
targetType: executable,
platforms: [posix],
mainSourceFile: src/sample.d
}
]
}
1) Ignoring it only works for 64bit
2) targetType: sourceLibrary
Is only for when you don't want the source to be built as a .lib/.so
file but provided to packages as source files when used as a dependency
3) imageformats package is used as a sourceLibrary. And never provides
any source files to compile with.
This is a rather big no no. As dub does not know what to compile with
your code.
Re: Conditional Compilation for Specific Windows
On 2015-01-07 20:48, Jonathan Marler wrote: I've looked up the windows version helper functions (http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx). The problem is that these functions are not defined in DMD's user32.lib. I could use the operating system's user32.lib but it is in COFF format, so I would have to convert my D object files to COFF and then compile using MSVC or GNU GCC for windows (or I could try converting the OS user32.lib to OMF). Or, I could add the functions to DMD's user32.lib but as far as I know this is a private binary managed by Digital Mars that I can't contribute to? Am I wrong? Does anyone else have a solution or an idea on this? Note: I've wanted to use other windows function in the past that were missing from DMD's user32.lib file. A solution to solve this for multiple functions would be ideal, thanks. You can either: 1. Convert an up to date user32.lib to OMF 2. Create your own user32.lib from the DLL 3. Compile using the COFF format and use the Visual Studio runtime instead. This has been recently added (I'm not sure if it's released yet) and requires using a flag -- /Jacob Carlborg
Re: DConf 2015 Call for Submissions is now open
On 1/7/15, Ali Çehreli digitalmars-d-announce@puremagic.com wrote: I loved it too! :) Andrej, I am going to use it but without the redundant happy on the last line: :D = A D programmer Ali As always, my smileys are Boost-licensed. Feel free to do whatever you want with them. :P
Re: Ready to make page-per-item ddocs the default?
On 2015-01-07 23:35, Andrei Alexandrescu wrote: The way I see this, these items are good to have and by nature of our process will be deployed (if at all) incrementally by whomever is interested in implementing them. We can't afford to block progress of docs layout on this possibility. -- Andrei I guess that's a fair point. -- /Jacob Carlborg
setup problem wih dub
Hi.
Package in question: fpdf
Dub version I'm using: 0.9.22
DMD version: 2.066.1 (64 bit)
Platform: Fedora 19 (64-bit).
I created the fpdf package, and it is dependant on the
imageformats package, but it won't compile. When I place a copy
of imageformats.d into the project source directory, it compiles
fine. However when I rely on dub dependancy, the linker complains
that it cannot find the functions in imageformats. Following is a
copy of the dub package. Any insight would be appreciated.
Thanks in advance.
{
name: fpdf,
description: Minimalist class for generating PDF documents.,
authors: [ Jason den Dulk ],
license: BSL-1.0,
platforms: [posix],
targetType: sourceLibrary,
dependencies: { imageformats : =3.0.3 },
importPaths: [ src ],
configurations:
[
{
name: sample,
targetType: executable,
platforms: [posix],
mainSourceFile: src/sample.d
}
]
}
[Issue 6613] Can't use empty tuple as default value for variadic template function parameter
https://issues.dlang.org/show_bug.cgi?id=6613 Issue 6613 depends on issue 13950, which changed state. Issue 13950 Summary: [REG2.062] zero-length tuple does not work on function default argument https://issues.dlang.org/show_bug.cgi?id=13950 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: @api: One attribute to rule them All
On Monday, 5 January 2015 at 21:15:00 UTC, Zach the Mystic wrote: https://github.com/D-Programming-Language/dmd/pull/1877 Deep into the discussion on the above pull, Walter responds to this comment of Kenji's: I think this kind of optimization should be hidden after the semantic phase - as like inlining and backend optimizations. ...with this: The trouble with doing this is that it is extremely dangerous in a language that supports separate compilation. It means that a function can be treated as pure, but its mangled signature says its impure. Then, the build system swaps in another version of that function, with the same signature, but is impure. Now the code that calls it is silently broken - the worst kind of runtime error. This is why attribute inference is limited to those functions where the definitions are guaranteed to be available - templates, lambdas, nesteds and autos - then there can be no runtime mismatch. What bothers me about this is that the compiler could *know* that a function is pure any time it has the function body available to it, regardless of what kind of function it is. The above quote suggests, however, that it's just completely impossible for the compiler to know if the function which will be called is the one that it has just compiled, or if it will be swapped in by a linker with another function with the same name from somewhere else. I honestly don't know enough about how linking works to know if this cancels my proposal. Wouldn't it cause an error if the linker found two of the exact same function? My naive assumption about it is that when the compiler has the body, it can treat it as pure from within, even if it gets expressed by 'extern(noinfer)' as impure. That is, from within the singly compiled program, it can be treated as if it *is* pure, being one-hundred percent certain that the function it compiles will be the one that gets called at binary time, but for anyone reading the expressed interface, it can only be compiled as if it's *not* pure, since that's all the information the interface tells them.
Re: @api: One attribute to rule them All
Martin Nowak is the one who created the issue for this enhancement request: https://issues.dlang.org/show_bug.cgi?id=10979 He proposes a different solution though - creating two mangled names for each function. The advantage, as far as I can see it, is that you wouldn't even have to add @api or extern(noinfer) to link properly. I see two disadvantages: the binary would suffer bloat, and the generated .di signatures would have to default to the conservative explicit signature, since is could not include both signatures without causing a duplicate definition.
Re: @api: One attribute to rule them All
On Thursday, 8 January 2015 at 04:43:50 UTC, Zach the Mystic wrote: https://issues.dlang.org/show_bug.cgi?id=10979 Whoops! The link is: https://issues.dlang.org/show_bug.cgi?id=10924
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Wednesday, 7 January 2015 at 23:27:19 UTC, anonymous wrote: Don't do this without `dup`ing. Quoting the documentation: Oh, whoops. I thought those special variadic args were always allocated on the heap.
Re: Phobos colour module?
Ah yeah, supporting w3c standards is probably a sensible move. On 08/01/2015 9:55 am, via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote: I think it can be interesting to provide some string formats can be directly converted into color structures. For example : - plain color names : red, blue, light gray,... - hexadecimal : #FF3CBB, #FF3CBBAA (same with alpha) - decimal : 255, 158, 200, 255, 158, 200, 170 ... I think to that cause I saw many times tools using pretty close syntax for color definitions but with boring variations (generally for the alpha position). It is defined in a w3c standard and refined in a draft, but probably does not belong in the colour module, but a media-file parser module? However, the at least the following colour spaces are mentioned as supported in w3c documents: L*ab, L*CHab, HSL, HWB http://www.w3.org/TR/SVGColorPrimer12/ http://dev.w3.org/csswg/css-color/
Re: What does dmd 2.066 want from me?
If you have just installed a newer compiler and trying to link with older compiled code, then linking and other things can get wrong. I suggest recompiling all of your code using the new compiler.
Re: We need a DConf 2015 logo
On Wednesday, 7 January 2015 at 22:36:28 UTC, Andrei Alexandrescu wrote: On 1/7/15 12:26 PM, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Thanks! But shouldn't it read DConf 2015? -- Andrei I was assuming the website would do that. I see now that in 2014 and 2013 site the logo is appended the text in an image http://dconf.org/2013/images/logo.png which is great for reproducibility, but it does seem possible with CSS.
Re: Error: function declaration without return type.
On 01/06/2015 01:25 PM, Suliman wrote: On Tuesday, 6 January 2015 at
21:19:38 UTC, bearophile wrote:
Suliman:
void foo()
{
writeln(test);
writeln(mystring);
}
foo();
}
I guess you have to remove that line.
Bye,
bearophile
Why? I can't call function in instance of class?
Instances of classes are objects that are created by 'new'. So, yes, you
can call member functions on instances of classes. There are two
instances of Test in the following main():
import std.stdio;
class Test
{
string mystring;
this(string mystring)
{
this.mystring = mystring;
}
void foo()
{
writeln(test);
writeln(mystring);
}
}
void main()
{
auto a = new Test(hello);
auto b = new Test(hi);
a.foo();
b.foo();
}
Ali
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Wednesday, 7 January 2015 at 20:25:10 UTC, Meta wrote:
struct Tree
{
this(string data, Tree[] children...)
{
this.data = data;
this.children = children;
Don't do this without `dup`ing. Quoting the documentation:
An implementation may construct the object or array instance on
the stack. Therefore, it is an error to refer to that instance
after the variadic function has returned:
[...]
int[] test(int[] a ...)
{
return a; // error, array contents invalid after return
return a[0..1]; // error, array contents invalid after return
return a.dup; // ok, since copy is made
}
http://dlang.org/function#variadic
}
string data;
Tree[] children;
}
Re: Even better navigation - thanks Nick Treleaven!
On 1/7/2015 3:18 PM, Andrei Alexandrescu wrote: We just deployed Nick's work at https://github.com/D-Programming-Language/dlang.org/pull/726, which enables jump-to navigation for structures. For example, from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Schweet!
Re: Even better navigation - thanks Nick Treleaven!
On Wednesday, 7 January 2015 at 23:18:03 UTC, Andrei Alexandrescu wrote: ... from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Well done! I just think that would be nice to have a link to go back (Like a Up Arrow on the right corner for example) of each method. Matheus.
Re: Even better navigation - thanks Nick Treleaven!
On Wed, Jan 07, 2015 at 03:18:02PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: We just deployed Nick's work at https://github.com/D-Programming-Language/dlang.org/pull/726, which enables jump-to navigation for structures. For example, from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Thanks, Nick! OTOH, there's yet more to fix. The most blatant being, can we please, pretty please with a cherry on top, REMOVE nested symbols like front, back, and empty from the blob of links at the top of the page??! They are completely meaningless when put out of the context of their containing struct/class (a module like std.range may have several fronts, and nobody knows which one points to which), and now with Nick's fix they are also redundant. T -- Outlook not so good. That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net)
Re: DConf 2015 Call for Submissions is now open
On 01/07/2015 01:08 PM, Walter Bright wrote: On 1/7/2015 5:45 AM, Andrej Mitrovic via Digitalmars-d-announce wrote: :( = A C programmer :(++ = A C++ programmer with bandages from the pain of using C++. :D= A happy D programmer Ok, you made me laugh out loud! I loved it too! :) Andrej, I am going to use it but without the redundant happy on the last line: :D = A D programmer Ali
Re: We need a DConf 2015 logo
On 1/7/15 3:08 PM, ponce wrote: On Wednesday, 7 January 2015 at 22:36:28 UTC, Andrei Alexandrescu wrote: On 1/7/15 12:26 PM, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Thanks! But shouldn't it read DConf 2015? -- Andrei I was assuming the website would do that. I see now that in 2014 and 2013 site the logo is appended the text in an image http://dconf.org/2013/images/logo.png which is great for reproducibility, but it does seem possible with CSS. Yah, a logo styled after those with the new dates would be awesome. -- Andrei
Even better navigation - thanks Nick Treleaven!
We just deployed Nick's work at https://github.com/D-Programming-Language/dlang.org/pull/726, which enables jump-to navigation for structures. For example, from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Andrei
Re: Another init() bug, can we deprecate yet?
On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via Digitalmars-d wrote: https://issues.dlang.org/show_bug.cgi?id=13806 For the lazy: BitArray has an init() method, which hides the property BitArray.init This, or something similar, appears every few months. Walter has said in the past that the ability to override init is a feature. As far as I can tell, no one is using it as a feature; it only seems to cause trouble. Can we just deprecate it? At the very least deprecate functions named init(). https://github.com/D-Programming-Language/phobos/pull/2854 Destroy! T -- You have to expect the unexpected. -- RL
Re: Even better navigation - thanks Nick Treleaven!
On Wed, Jan 07, 2015 at 03:33:23PM -0800, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 07, 2015 at 03:18:02PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: We just deployed Nick's work at https://github.com/D-Programming-Language/dlang.org/pull/726, which enables jump-to navigation for structures. For example, from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Thanks, Nick! OTOH, there's yet more to fix. The most blatant being, can we please, pretty please with a cherry on top, REMOVE nested symbols like front, back, and empty from the blob of links at the top of the page??! They are completely meaningless when put out of the context of their containing struct/class (a module like std.range may have several fronts, and nobody knows which one points to which), and now with Nick's fix they are also redundant. [...] Actually, I take that back. In this particular case front, empty, and friends are actually module-level UFCS functions. So actually, this is no longer a problem. Hooray! And sorry for the noise. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: Phobos colour module?
On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote: I think it can be interesting to provide some string formats can be directly converted into color structures. For example : - plain color names : red, blue, light gray,... - hexadecimal : #FF3CBB, #FF3CBBAA (same with alpha) - decimal : 255, 158, 200, 255, 158, 200, 170 ... I think to that cause I saw many times tools using pretty close syntax for color definitions but with boring variations (generally for the alpha position). It is defined in a w3c standard and refined in a draft, but probably does not belong in the colour module, but a media-file parser module? However, the at least the following colour spaces are mentioned as supported in w3c documents: L*ab, L*CHab, HSL, HWB http://www.w3.org/TR/SVGColorPrimer12/ http://dev.w3.org/csswg/css-color/
Re: Even better navigation - thanks Nick Treleaven!
On Wednesday, 7 January 2015 at 23:30:01 UTC, MattCoder wrote: On Wednesday, 7 January 2015 at 23:18:03 UTC, Andrei Alexandrescu wrote: ... from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Well done! I just think that would be nice to have a link to go back (Like a Up Arrow on the right corner for example) of each method. Matheus. Agreed, a little up arrow next to the functions to take you back to the parent struct would be nice.
Re: import std.random fails
On Tuesday, 6 January 2015 at 20:49:34 UTC, Rene Zwanenburg wrote: On Tuesday, 6 January 2015 at 20:26:25 UTC, ixid wrote: Dmd latest non-beta, with the latest VisualD. Debug build. Debug build and no additional or non default settings. Hmm.. Did you verify that the D installation directory was completely empty after uninstalling? Does VisualD have some kind of verbose mode to show the exact command used to invoke DMD? What happens if you run rdmd on your main file? It seems to work fine with RDMD. I don't know if VisualD has a verbose mode. Would this suggest the issue is with VisualD or with DMD settings in some way?
Re: Even better navigation - thanks Nick Treleaven!
On 1/7/15 3:30 PM, MattCoder wrote: On Wednesday, 7 January 2015 at 23:18:03 UTC, Andrei Alexandrescu wrote: ... from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Well done! I just think that would be nice to have a link to go back (Like a Up Arrow on the right corner for example) of each method. Matheus. Thought of the same, but then figured the Back button works well. One other comment: the font and styling of the phrase Jump To: and the respective targets could be nicer - e.g. smaller and sleeker. -- Andrei
Re: Conditional Compilation for Specific Windows
On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg wrote: On 2015-01-07 19:27, Jonathan Marler wrote: I'm looking at the Windows multicast API. It has different socket options depending on if you are on Windows XP or Windows Vista (and later). Is there a way to tell at runtime which version of windows you are on? Note: I'm specifically talking about runtime because I want the same binary to run on all windows versions so I have to support both and determine which one I am running on at runtime. Use the regular system API's as you would in C. Should be easy to find if you search the web. I've looked up the windows version helper functions (http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx). The problem is that these functions are not defined in DMD's user32.lib. I could use the operating system's user32.lib but it is in COFF format, so I would have to convert my D object files to COFF and then compile using MSVC or GNU GCC for windows (or I could try converting the OS user32.lib to OMF). Or, I could add the functions to DMD's user32.lib but as far as I know this is a private binary managed by Digital Mars that I can't contribute to? Am I wrong? Does anyone else have a solution or an idea on this? Note: I've wanted to use other windows function in the past that were missing from DMD's user32.lib file. A solution to solve this for multiple functions would be ideal, thanks.
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Wednesday, 7 January 2015 at 16:17:47 UTC, Tobias Pankrath
wrote:
A slice seems overkill to refer to just one object, but is that
the best way ?
struct Tree
{
Tree[] children;
}
Is one way to do it.
You can add some nice sugar for this as well:
struct Tree
{
this(string data, Tree[] children...)
{
this.data = data;
this.children = children;
}
string data;
Tree[] children;
}
http://dpaste.dzfl.pl/76a8a4c44345
What does dmd 2.066 want from me?
I'm trying to compile my software with the latest compiler, and it spits out the following error: $ make ... rdmd --force --build-only -IBioD -g -L-Lhtslib -L-l:libhts.a -L-l:libphobos2.a -ofbuild/sambamba.o main.d ... /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x30): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead9__xtoHashFNbNeKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZm' /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x38): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead11__xopEqualsFKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZb' What the heck do these lines mean? Presumably they come from the recent change in hash implementation, but I don't use this struct in any dictionary whatsoever! It doesn't have opCmp either and perfectly worked until now.
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wednesday, 7 January 2015 at 17:57:18 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Jan 07, 2015 at 05:16:13PM +, FrankLike via Digitalmars-d-learn wrote: To hide the infos you can also (I've seen people say that you can use a packer) encrypt the strings and decode them at run-time (e.g base64, a simple XOR, etc) and use the import() idiom: https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable to import the compiled things. I've made a simple software in this spirit, even if it's not made to encrypt/hide (it's more globally a resource manager), it can be used to hide the strings since it encodes in base 85 and base 64: https://github.com/BBasile/Resource.d Good job. Thank you. Note that these encryption/decryption schemes can only serve as deterrent to the casual user, they do not prevent a determined attacker from decrypting the sensitive data. As long as the data is decrypted on the user's machine, the user can read it. For example, an encrypted executable has to decrypt itself at some point, since otherwise it couldn't run on the user's machine in the first place. So, in theory, all the user has to do is to run it inside a VM or a debugger and stop it immediately after the point where it decrypts itself, and the code will be in cleartext for all to read. Similarly, if a piece of sensitive data is decrypted by the program at some point during execution, a user can just run it inside a debugger and break it immediately past the point where the data is decrypted, and just read off the cleartext. Basically, the only way to be 100% safe with sensitive data that the user shouldn't read, is to never transmit said data to the user's machine in the first place. If the program needs to read something from a database, and the database has a password, don't store the password anywhere in any form on the user's computer (this includes inside the executable). Instead, use a database server that the program talks to; the server knows the DB password, the program doesn't (and shouldn't). T You're right, it works against static analysis (disassembly) but in a debugger, the attacker can track the content of the stack because before being used, the data **have** to be decripted somewhere, so before a CALL he detects the data put as parameter, then he tries to find where they are generated (e.g put a breakpoint on each dword ... or by putting a breakpoint on memory access for a particular address). As said before by other people in this topic, you cant do anything againt someone who really wants to get the thing, but you can reduce the amount of people able to to do it.
Re: Phobos colour module?
I think it can be interesting to provide some string formats can be directly converted into color structures. For example : - plain color names : red, blue, light gray,... - hexadecimal : #FF3CBB, #FF3CBBAA (same with alpha) - decimal : 255, 158, 200, 255, 158, 200, 170 ... I think to that cause I saw many times tools using pretty close syntax for color definitions but with boring variations (generally for the alpha position).
Re: Enumerator Alias-Skipping Dynamic Iteration of Enum Members
On Wednesday, 7 January 2015 at 18:27:48 UTC, bearophile wrote: foreach (immutable e; [EnumMembers!T].sort().uniq) Thanks!
Re: An idea for commercial support for D
On 07/01/15 13:08, uri via Digitalmars-d wrote: Thanks for the correction, and a very important one at that in the context of this thread. I wasn't aware the backend was open source. Er, I have to clarify again :-) The backend license is not an open source one; it is, strictly speaking, proprietary: https://github.com/D-Programming-Language/dmd/blob/master/src/backendlicense.txt However, the code is available, development on it is public, and Walter is very liberal in giving permissions to use, distribute and so on. I think that it's only constraints on Walter himself that mean it is not under an open source licence. That's what I mean when I say it is de facto open, rather than de jure. But in practice, not in law is an important distinction.
Re: DConf 2015 Call for Submissions is now open
On 1/7/2015 11:05 AM, Maxime Chevalier-Boisvert wrote: We'd like your presentation proposal, too! It's an honor to be reinvited :) I'm honored you're a member of our community. Truly the best thing about working on D is the type of people it attracts. Are there specific topics you'd like covered in my talk? I've found over and over that when people give talks about something they're excited about, that excitement gets transmitted to the audience and they enjoy it, too! Will the talks be filmed this year too? Chuck Allison is going to arrange this with the university students. I hope we can get it live streamed as well.
Re: Sargon library gets Ddoc macro processor
On 1/7/2015 3:46 AM, Tobias Pankrath wrote: I guess those where the times when unmount has been abbreviated to umount. Typing must have been really hard. It had to do with file extensions for macro assembler being .MAC, and people just wound up calling them mac files. Just like people call assembler files asm files today. umount likely is related to max 6 character filenames in older systems.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
FrankLike: But now I want to know in a string (like hello.exe or hello.a,or hello.dll or hello.lib ) whether contains any of them: [exe,dll,a,lib]. Seems this: http://rosettacode.org/wiki/File_extension_is_in_extensions_list#D Bye, bearophile
Re: An idea for commercial support for D
On 7 January 2015 at 02:08, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On 06/01/15 07:14, Joakim via Digitalmars-d wrote: I don't think such people matter, ie they're a very small but vocal minority. Also, these people are deeply irrational, as every piece of hardware they're using comes with many closed binary blobs. They are either ignorant of this fact or just choose to make silly demands anyway. This is a pretty bad habit you have, to just dismiss people rather than to try and understand the substance and detail of their concerns and requirements. You seem to see non-free is a deal-breaker as some sort of fundamentalist position. In fact, it's almost invariably contextual and highly dependent on the particular use-case and the particular needs that someone has in a particular piece of software. Frankly, I gave up reading at - The alternative is to use the bug-ridden OSS implementation you're using now for free, and not have a paid version for those who want those bugs fixed. No use talking to someone who is convinced that OSS means bug-ridden. And really, if you want to sell a business model to people, don't go dismissing people who tell you this won't work for me. Those people are your potential customers. Find out what _will_ work for them, and give it to 'em. ;-) I can see an opportunity - but not with any existing compilers we have at the moment. Giving away closed-but-free software occasionally works in certain consumer markets, but you are really going to struggle with this if your consumers are comprised of mostly RD. No - you can't reverse a project into a closed source one. History can tell you that (read up on The Cautionary Tale of XFree86) If you are going to make this work, the specification of D needs to be rubber stamped either with an ANSI or ISO sticker. This will allow interested parties to start their own competing compiler - ground up or forked from the existing implementation, it doesn't matter which. This will have a desired effect that said group/company will not be able to invent new features of D. They are free however to add any __extensions__ or pragmas to the language. This does not mean that they have no say in the direction of the language (popular extensions could still become standardised), but it gives the current community security that our current procedures for language changes don't get bypassed by some closed-source party. This then leads up to second point in matter. If our D spec is set in stone, there would be little compelling differences between the paid and OSS versions of the compiler. So why in the first place would people bother going down the proprietary route? Nope, you need something to blow the others out the water that attracts the non-RD community. I would proposed that such a killer thing would need to be an integrated IDE to tied in with your closed compiler. Whilst being a good editor, you need a tool that automates/simplifies complex processes - highlight build errors whilst you type, tell the IDE to go build ARM binaries for my project. That is where the value-for-money factor comes in. I cannot see any traction occurring in Joakim's badly thought out idea unless you have some *new* to give. Iain.
Re: Shouldn't the pointers be different
On Wednesday, 7 January 2015 at 10:56:07 UTC, bearophile wrote:
Nick:
The two nodes have the same address, is this right?
What you are printing is the address of the reference in the
stack frame of add(). If you want to print the reference you
can use this:
import std.stdio;
class Test(T) {
static class Node {
T v;
}
void add(T e) {
auto n = new Node;
writeln(New node address: , cast(void*)n);
}
}
void main() {
auto t = new Test!int;
t.add(0);
t.add(1);
}
Note also that class/struct/enum/union names in D start with an
upper case. I have also used a static class instead.
Bye,
bearophile
It works!
And thanks for the comments on the code :)
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote: What you want is some kind of code obfuscation. The easiest thing for you is to use exe compression. It is not going to stop a dedicated attacker, but ordinary people will not be able to extract any information from it. And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup. Thank you,but it's not easy to do,can you show me some detail?
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wednesday, 7 January 2015 at 14:33:16 UTC, Tobias Pankrath wrote: On Wednesday, 7 January 2015 at 14:18:53 UTC, FrankLike wrote: On Wednesday, 7 January 2015 at 11:00:54 UTC, Laeeth Isharc wrote: What you want is some kind of code obfuscation. The easiest thing for you is to use exe compression. It is not going to stop a dedicated attacker, but ordinary people will not be able to extract any information from it. And I guess as an alternative to the utility you linked to, you could use D's ability to run code at compile time to encrypt your sensitive literals during compilation and then decrypt them on program startup. Thank you,but it's not easy to do,can you show me some detail? http://dpaste.dzfl.pl/3bbdecfefa5c I'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
ref is a reserved keyword. doh! Thanks.
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 12:46 AM, Vladimir Panteleev wrote: Remaining issues: * Overzealous linking of words in the documentation that happen to coincide with symbols in the same module. This should only be done for text in $(D ...) tags. Yah, I'm quite unhappy about that, too. * Compile-time expressions are expanded to their computed variant. For example, `size_t.max` is expanded to `18446744073709551615LU`, which is not informative, and wrong on 32-bit systems. `Config.none` is now `cast(Config)0`, which sucks. I guess this is a compiler issue rather than a DDox one. Hrm, not sure how easy it would be to fix this. More issues I noticed now from a quick look: * http://dlang.org/library/std/process.html : The comparison table is gone, replaced with an unstructured blob of text. * http://dlang.org/library/std/parallelism.html : More overzealous linking (e.g.: These include _parallel_ foreach, _parallel_ reduce, _parallel_ eager map, ...). * http://dlang.org/library/core/time.html : More overzealous linking - symbols within D string literals should not be linked. Could you please fix or file these. Thanks! * I still have reservations about using Disqus. I did keep that in mind. The long and short of it it it's impossible to make a change that everybody likes. We must move forward. Andrei
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Wednesday, 7 January 2015 at 15:11:57 UTC, John Colvin wrote:
On Wednesday, 7 January 2015 at 14:54:51 UTC, FrankLike wrote:
I want to know whether the string strs contains
'exe','dll','a','lib',in c#,
I can do : int index =
indexofany(strs,[exe,dll,a,lib]);
but in D: I must to do like this:
findStr(strs,[exe,lib,dll,a]))
bool findStr(string strIn,string[] strFind)
{
bool bFind = false;
foreach(str;strFind)
{
if(strIn.indexOf(str) !=-1)
{
bFind = true;
break;
}
}
return bFind;
}
phobos 's string.d can add this some function to let the
indexOfAny to better?
Thank you.
Frank
std.algorithm.canFind will do what you want, including telling
you which of [exe,lib,dll,a] was found.
If you need to know where in strs it was found as well, you can
use std.algorithm.find
Sorry, 'std.algorithm.find' do this work:Finds an individual
element in an input range,and it's Parameters: InputRange
haystack The range searched in.
Element needle The element searched for.
But now I want to know in a string (like hello.exe or
hello.a,or hello.dll or hello.lib ) whether contains any of
them: [exe,dll,a,lib].
My function 'findStr' works fine. If the string.d's function
'indexOfAny' do this work,it will happy.(but now 'IndexOfAny'
and 'indexOf' do the same work) .
Thank you.
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 11:12 AM, Jacob Carlborg wrote: Most of the ideas I had might require some redesign of the documentation layout, these are: * Summary of symbols * Documentation for private symbols * Simplified signatures * Links to all base classes and interfaces of a class * Links to all symbols from all base classes and interfaces * Links to all known subclasses BTW the thing that have bothered me the most when writing documentation is there's no good way to even manually cross-reference symbols. We really should have a special syntax for that as well. The way I see this, these items are good to have and by nature of our process will be deployed (if at all) incrementally by whomever is interested in implementing them. We can't afford to block progress of docs layout on this possibility. -- Andrei
Re: We need a DConf 2015 logo
On 1/7/15 12:26 PM, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Thanks! But shouldn't it read DConf 2015? -- Andrei
Re: Another init() bug, can we deprecate yet?
On Wednesday, 7 January 2015 at 22:03:01 UTC, Peter Alexander wrote: Can we just deprecate it? At the very least deprecate functions named init(). There's a check for that: https://github.com/Hackerpilot/Dscanner/blob/master/src/analysis/builtin_property_names.d
Re: Conditional Compilation for Specific Windows
On Wednesday, 7 January 2015 at 19:48:16 UTC, Jonathan Marler wrote: On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg wrote: On 2015-01-07 19:27, Jonathan Marler wrote: I'm looking at the Windows multicast API. It has different socket options depending on if you are on Windows XP or Windows Vista (and later). Is there a way to tell at runtime which version of windows you are on? Note: I'm specifically talking about runtime because I want the same binary to run on all windows versions so I have to support both and determine which one I am running on at runtime. Use the regular system API's as you would in C. Should be easy to find if you search the web. I've looked up the windows version helper functions (http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx). The problem is that these functions are not defined in DMD's user32.lib. I could use the operating system's user32.lib but it is in COFF format, so I would have to convert my D object files to COFF and then compile using MSVC or GNU GCC for windows (or I could try converting the OS user32.lib to OMF). Or, I could add the functions to DMD's user32.lib but as far as I know this is a private binary managed by Digital Mars that I can't contribute to? Am I wrong? Does anyone else have a solution or an idea on this? Note: I've wanted to use other windows function in the past that were missing from DMD's user32.lib file. A solution to solve this for multiple functions would be ideal, thanks. You could bypass user32.lib by using directly user32.dll via LoadLibrary()/GetProcAddress(). -- Paulo
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wed, Jan 07, 2015 at 08:36:19PM +, Baz via Digitalmars-d-learn wrote: On Wednesday, 7 January 2015 at 17:57:18 UTC, H. S. Teoh via Digitalmars-d-learn wrote: [...] Note that these encryption/decryption schemes can only serve as deterrent to the casual user, they do not prevent a determined attacker from decrypting the sensitive data. As long as the data is decrypted on the user's machine, the user can read it. [...] You're right, it works against static analysis (disassembly) but in a debugger, the attacker can track the content of the stack because before being used, the data **have** to be decripted somewhere, so before a CALL he detects the data put as parameter, then he tries to find where they are generated (e.g put a breakpoint on each dword ... or by putting a breakpoint on memory access for a particular address). As said before by other people in this topic, you cant do anything againt someone who really wants to get the thing, but you can reduce the amount of people able to to do it. Right, like I said, it deters a casual user, but won't stop a determined attacker. Unfortunately, all it takes is for *one* determined attacker to publish his findings, and your secret data is no longer so secret. There *are* ways to make things hard even for a determined attacker, though it comes at an increasingly higher cost that may not be worth the effort, depending on what your program is doing. If it's just an online game, it's probably not worth it. But if it's a banking app, you probably wanna think about it reeeally hard... T -- My program has no bugs! Only undocumented features...
Another init() bug, can we deprecate yet?
https://issues.dlang.org/show_bug.cgi?id=13806 For the lazy: BitArray has an init() method, which hides the property BitArray.init This, or something similar, appears every few months. Walter has said in the past that the ability to override init is a feature. As far as I can tell, no one is using it as a feature; it only seems to cause trouble. Can we just deprecate it? At the very least deprecate functions named init().
[Issue 13895] Declaration grammar is insufficient
https://issues.dlang.org/show_bug.cgi?id=13895 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/16957d1ce071c478206f963c1352a7c8ed943960 fix Issue 13895 - Declaration grammar is insufficient https://github.com/D-Programming-Language/dlang.org/commit/7ffcabd0159e47527d2808446d0ba2141ea5f91e Merge pull request #728 from 9rnsr/fix13895 Issue 13895 - Declaration grammar is insufficient --
Re: What does dmd 2.066 want from me?
On 8/01/2015 9:10 a.m., Artem Tarasov wrote: I'm trying to compile my software with the latest compiler, and it spits out the following error: $ make ... rdmd --force --build-only -IBioD -g -L-Lhtslib -L-l:libhts.a -L-l:libphobos2.a -ofbuild/sambamba.o main.d ... /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x30): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead9__xtoHashFNbNeKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZm' /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x38): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead11__xopEqualsFKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZb' What the heck do these lines mean? Presumably they come from the recent change in hash implementation, but I don't use this struct in any dictionary whatsoever! It doesn't have opCmp either and perfectly worked until now. Have you got opEqual's defined? Its wanting that and toHash I think.
idiomatic D: what to use instead of pointers in constructing a tree data structure?
Another schoolboy question. Suppose I am constructing a tree (in this case it is an AST). In C I would have a pointer for the child to find the parent, and an array or linked list of pointers to find the children from the parent. Obviously, I could still use pointers, but that would not be idiomatic. I also could just use integer array index references. A slice seems overkill to refer to just one object, but is that the best way ?
Why do the same work about 'IndexOfAny' and 'indexOf' function?
I want to know whether the string strs contains
'exe','dll','a','lib',in c#,
I can do : int index = indexofany(strs,[exe,dll,a,lib]);
but in D: I must to do like this:
findStr(strs,[exe,lib,dll,a]))
bool findStr(string strIn,string[] strFind)
{
bool bFind = false;
foreach(str;strFind)
{
if(strIn.indexOf(str) !=-1)
{
bFind = true;
break;
}
}
return bFind;
}
phobos 's string.d can add this some function to let the
indexOfAny to better?
Thank you.
Frank
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Wednesday, 7 January 2015 at 14:54:51 UTC, FrankLike wrote:
I want to know whether the string strs contains
'exe','dll','a','lib',in c#,
I can do : int index =
indexofany(strs,[exe,dll,a,lib]);
but in D: I must to do like this:
findStr(strs,[exe,lib,dll,a]))
bool findStr(string strIn,string[] strFind)
{
bool bFind = false;
foreach(str;strFind)
{
if(strIn.indexOf(str) !=-1)
{
bFind = true;
break;
}
}
return bFind;
}
phobos 's string.d can add this some function to let the
indexOfAny to better?
Thank you.
Frank
std.algorithm.canFind will do what you want, including telling
you which of [exe,lib,dll,a] was found.
If you need to know where in strs it was found as well, you can
use std.algorithm.find
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 1:06 AM, Jacob Carlborg wrote: On 2015-01-07 00:44, weaselcat wrote: Is it intentional for all of the stdc pages to be empty? Why is even std.c.* still available. These should all be replaced with core.stdc.*. Please fix or file so this isn't forgotten. -- Andrei
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Wednesday, 7 January 2015 at 16:23:38 UTC, John Colvin wrote: On Wednesday, 7 January 2015 at 16:15:49 UTC, Tobias Pankrath wrote: http://dpaste.dzfl.pl/3bbdecfefa5c I'm not sure about some of that. Bad casts w.r.t. immutability etc. How about: http://dpaste.dzfl.pl/706ab2db9ce1 I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE. Why would that be a problem? Because the plain text will be in the object file. http://dpaste.dzfl.pl/95b17fff42c6 Take a look at the object file and you will find “Sailor Moon” in it - which is what we wanted to avoid in the first place. I'd prefer the API that prevents something like that.
Re: string concatenation with %s
On Wed, 07 Jan 2015 16:38:23 +, Suliman wrote: I except that writefln have some behavior as string concatenation, but it does not. IS there any way to put needed values in place of %s in string? std.string.format interpolates string with the same behavior as writefln but returns the resulting string instead of printing it.
Re: string concatenation with %s
On Wednesday, 7 January 2015 at 16:38:25 UTC, Suliman wrote:
I need to construct complex SQL request, like:
string sql = (INSERT INTO test.geomagnetic (`date`,
`a_fredericksburg`, `fredericksburg`, `a_college`, `college`,
`a_planetary`, `planetary`) VALUES ('%s', '%s', '%s', '%s',
'%s', '%s', '%s');, date[i], a_fredericksburg[i],
fredericksburg[i], a_college[i], college[i], a_planetary[i],
planetary[i]);
I except that writefln have some behavior as string
concatenation, but it does not.
IS there any way to put needed values in place of %s in string?
Just FYI use prepared statements instead of string concatenation
for SQL queries.
http://en.wikipedia.org/wiki/Prepared_statement
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
std.algorithm.find has several overloads, one of which takes multiple needles. The same is true for std.algorithm.canFind Quoting from the relevant std.algorithm.find overload docs: Finds two or more needles into a haystack. string strs =hello.exe; string[] s =[lib,exe,a,dll]; auto a = canFind!(string,string[])(strs,s); writeln(a is ,a); string strsb =hello.; auto b = canFind!(string,string[])(strsb,s); writeln(b is ,b); Get error: does not match template declaration canFind(alias pred = a ==b) you can test it. Thank you.
Re: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
I would keep the encryption inside a template to prevent users from assigning it to a variable without triggering CTFE. Why would that be a problem? Because the plain text will be in the object file. http://dpaste.dzfl.pl/95b17fff42c6 Take a look at the object file and you will find “Sailor Moon” in it - which is what we wanted to avoid in the first place. I'd prefer the API that prevents something like that. Yes.
