Re: Cast to left hand side
On Monday, 10 November 2014 at 05:00:25 UTC, tcak wrote: On Sunday, 9 November 2014 at 21:47:03 UTC, eles wrote: On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote: Because I am auto casting with a keyword, compiler shouldn't complain about it as well. This can also solve uncast thing. Is not the same. Auto or not, this is still an explicit cast. I was asking for a cast to be limited to the attribute that is targeted, and let data format unchanged. The two are fairly different notions, because one specifies the format of the data, the other specifies permissions on that data.
Re: status of D optimizers benefiting from contracts ?
Meta: On the other hand, making assert a built-in that provides optimization hints has been proposed for C++17: Thank you for the link. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4154.pdf But that behavour is on request (using NDEBUG = strong), it's not suddenly becoming the default for D as Walter suggested: To satisfy as many users as possible, four levels of assertion are provided: • Default: assert evaluates its condition and generates a diagnostic upon failure. • NDEBUG = strong: assert has no side effects, but the implementation may use the condition, and if it would fail, the behavior is undefined. This provides optimal hints. • NDEBUG = strict: The assert expression is fully parsed and semantically checked, but no evaluation occurs. The behavior is still defined even if it would evaluate as false, but this may be considered unlikely. • NDEBUG defined as empty or an integer literal: The assert operands are syntactically a balanced-token-seq. Otherwise this is the same as strict mode. • Other identifiers in the expansion of NDEBUG are reserved to the standard for future expansion, except for identifiers usually reserved to the library. If you write a program from the start using NDEBUG=strong you are relying on a different semantics for assert. It's essentially a different kind of assert. You can't take D programs and silently change the basic semantics of all asserts under them. And still, in many cases you don't want to use NDEBUG=strong, that's why there are also other available behaviours like NDEBUG=strict that is an intermediate point. I think this proposal n4154 is a bit over-engineered (as it often happens to C++), but it avoids most of the faults in Walter ideas: it avoids breaking existing code (because the default behavour doesn't change), allows optimizations on request, etc. In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better. Walter is right in his very strong engineer desire to keep designs as simple as possible; but often giving the same name to things with different semantics doesn't reduce the complexity, it just increases the confusion. I greatly prefer when things with different semantics have cleanly distinct names. Bye, bearophile
Re: Live without debugger?
On Sunday, 9 November 2014 at 08:26:59 UTC, Suliman wrote: I know that a lot of people are using for programming tools like Sublime. I am one of them. But if for very simple code it's ok, how to write hard code? Do you often need debugger when you are writing code? For which tasks debugger are more needed for you? I don't use a debugger for D. Most of the code I deal with is my own code anyway so I usually have a good idea of where things go wrong when they go wrong. But I think that it is also down to D being debug-friendly by nature (and I usually insert simple debug statements and / or unittests). In my experience, it doesn't even need an IDE. I think that's a sign of quality.
Re: Access Violation Tracking
On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 09 Nov 2014 09:33:29 -0500 Etienne via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I've seen a lot more invalid memory operation errors since the GC calls destructors. Letting the GC destroy objects out of order can be the issue. We might have to make an associative array of static global flags (debug bool[void*]) for each object to see if it was destroyed, and use asserts in the destructors / update the associative array, as a new idiom. that's where i want precise GC to come into play. i really want it to nullify all internal pointers to finalized objects before calling destructor. sure, this can modify alot of members, so it must be opt-in feature. ah, and stop calling class finalizers destructors helps too. they are... well... finalizers, not destructors. ;-) I once suggested to introduce dedicated finalizers that get called instead of the destructor by the GC, and nobody argued against it ;-) They would be applicable to both classes and structs. A finalizer may only perform a subset of what's allowed in destructors, and the compiler might be able to verify that. For DRYness, the finalizer can optionally be called by the destructor, because everything that is valid in a finalizer should also be valid in a destructor.
Re: Access Violation Tracking
On Mon, 10 Nov 2014 11:13:11 + via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Sunday, 9 November 2014 at 14:45:11 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 09 Nov 2014 09:33:29 -0500 Etienne via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I've seen a lot more invalid memory operation errors since the GC calls destructors. Letting the GC destroy objects out of order can be the issue. We might have to make an associative array of static global flags (debug bool[void*]) for each object to see if it was destroyed, and use asserts in the destructors / update the associative array, as a new idiom. that's where i want precise GC to come into play. i really want it to nullify all internal pointers to finalized objects before calling destructor. sure, this can modify alot of members, so it must be opt-in feature. ah, and stop calling class finalizers destructors helps too. they are... well... finalizers, not destructors. ;-) I once suggested to introduce dedicated finalizers that get called instead of the destructor by the GC, and nobody argued against it ;-) They would be applicable to both classes and structs. A finalizer may only perform a subset of what's allowed in destructors, and the compiler might be able to verify that. For DRYness, the finalizer can optionally be called by the destructor, because everything that is valid in a finalizer should also be valid in a destructor. by the way, constructors are essentially initializers, 'cause they called with already constructed objects. and not only constructed, but even initialized with default values. i was always disappointed by the fact that i can't change the way object *constructed* in *constructor*. signature.asc Description: PGP signature
Re: status of D optimizers benefiting from contracts ?
On Sunday, 9 November 2014 at 22:41:29 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Sun, Nov 09, 2014 at 09:57:21PM +, eles via Digitalmars-d-learn wrote: On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: H. S. Teoh: It's only a bad idea because people abuse assert() where it's not appropriate. It's a bad idea because Walter seems unable to understand the difference between verifying and proving. I fail to see the difference between assert() and a hypothetical assume(). The original meaning of assert() is what assume() means nowadays, whereas nowadays what people think of as assert() is actually what enforce() does in Phobos. No, enforce() is obviously intended for verifying user input, not for checking program logic, that's why it throws an Exception, not an Error. The documentation even says so explicitly: http://dlang.org/phobos/std_exception.html#.enforce
Instructions for compilation from multiple source files
I wanted to know how to compile a D program that has multiple source files. I looked under Modules in the language reference, but there isn't anything there about compilation, or anything about where to put the source files, or anything about how the compiler finds the files to use. I'm currently using the GDC compiler, because I don't trust the DMD Debian package enough to install it, considering it has Google adsense ads in its HTML pages, which is against even Google's policy. I looked around the D Wiki for instructions on compilation, and it doesn't seem that there are any instructions other than for DMD on Windows and for compiling a hello world with one source file. The GDC site has no instructions or documentation on how to do compilation. The GDC man page is the same as the GDC info page. It lists some options for the compiler without listing what they do in the case of D. I'm not getting any .o or .a files out of the compiler, only a.out or whatever file name I choose with the -o option. I don't want to have to guess how to do it and experiment, as if it's all implementation defined and in flux to the degree that that's the only way to compile anything. If there aren't instructions or documentation on how to compile more than one file into a finished D runnable project in a correct way that can grow with larger projects, then I'll have to take it as implied that D is just not ready or not welcoming and I shouldn't use it.
Re: Instructions for compilation from multiple source files
Solomon E: I don't want to have to guess how to do it and experiment, as if it's all implementation defined and in flux to the degree that that's the only way to compile anything. It's not in flux. A simple way to compile more than one file is to put them in the same compilation unit (almost the same if you want to create a lib): dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Bye, bearophile
Re: Instructions for compilation from multiple source files
dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Am I right understand that if I will put all needed files at src folder and name main file App.d dub will add all needed files to App.d ?
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 12:10:36 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: If there aren't instructions or documentation on how to compile more than one file into a finished D runnable project in a correct way that can grow with larger projects, then I'll have to take it as implied that D is just not ready or not welcoming and I shouldn't use it. you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 12:21:51 UTC, bearophile wrote: It's not in flux. A simple way to compile more than one file is to put them in the same compilation unit (almost the same if you want to create a lib): dmd a.d b.d Otherwise you can also use ddmd and let it find the module dependencies by itself. Bye, bearophile That's not applicable because I'm not using DMD. Also that doesn't answer where a .o or .a file comes from, whether there's any difference between them besides the name, and if so what. I've compiled a lot of little examples and tests of D from single source files, but I haven't seen any .o or .a files yet. I was hoping there were instruction pages or documentation pages on how to compile D projects that have multiple source files.
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 12:49:46 UTC, ketmar via Digitalmars-d-learn wrote: you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. So there's such a lack of documentation on D that I'm *supposed* to just guess and experiment about what .o and .a files might be, or hope that an IDE frontend writer guessed right? There's no specification whatsoever?
Re: Instructions for compilation from multiple source files
On Mon, 2014-11-10 at 12:10 +, Solomon E via Digitalmars-d-learn wrote: I wanted to know how to compile a D program that has multiple source files. I looked under Modules in the language reference, but there isn't anything there about compilation, or anything about where to put the source files, or anything about how the compiler finds the files to use. There are effectively two models of compilation for D codes: 1. Compile each module individually and then link all the object files together. This is the traditional C, C++, Fortran way of working. 2. Compile all module source files all at once. In this mode you can either list all the source files or just the main one and see if the compiler correctly find all the dependencies. For 1 you generally need a build tool. I will, of course (but this is left as an exercise for the reader), suggest using SCons and its magnificent D tool. There is also D support for CMake. I believe Waf has some D support. For Make and any other out of date system, you are on your own! I tend to use SCons for mode 2 as well as I can add extras. I'm currently using the GDC compiler, because I don't trust the DMD Debian package enough to install it, considering it has Google adsense ads in its HTML pages, which is against even Google's policy. If the deb file (or any of the packages) on the D web site have such things then they are broken, and you are quite right, should be ignored. I am using Debian Sid and get my packages from D-Apt, http://d-apt.sourceforge.net/ . This works very well. I looked around the D Wiki for instructions on compilation, and it doesn't seem that there are any instructions other than for DMD on Windows and for compiling a hello world with one source file. The GDC site has no instructions or documentation on how to do compilation. GDC is really just GCC in disguise, and rather usefully compiling D instead of C, C++, Fortran, Ada, Objective-C, etc. So if you have ever used gcc or g++ commands you more or less already know how to use gdc. The GDC man page is the same as the GDC info page. It lists some options for the compiler without listing what they do in the case of D. I'm not getting any .o or .a files out of the compiler, only a.out or whatever file name I choose with the -o option. I don't want to have to guess how to do it and experiment, as if it's all implementation defined and in flux to the degree that that's the only way to compile anything. Actually that is a shame. We should all be prepared to experiment, play (and have fun). I agree there is less documentation than would be good around D generally, but it is a FOSS project without a team of paid staff to work 100% on it. Because volunteers generally prefer to work on code, the documentation tends to get a little left behind. What is needed is for some of the companies using D to give back by in some way funding more work on the documentation. If there aren't instructions or documentation on how to compile more than one file into a finished D runnable project in a correct way that can grow with larger projects, then I'll have to take it as implied that D is just not ready or not welcoming and I shouldn't use it. I think that would be a huge over assumption. D has been ready for use for ages and is in use in many places, just not as many as would be good for D and for native programming in general. I hope you stay with D and discover how welcoming the community is. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Instructions for compilation from multiple source files
On Mon, 2014-11-10 at 13:01 +, Solomon E via Digitalmars-d-learn wrote: On Monday, 10 November 2014 at 12:49:46 UTC, ketmar via Digitalmars-d-learn wrote: you'd better not use command-line toolchain, they all aren't ready. if you can't figure out how to use some compiler of GCC suite, you'd better try some IDEs. So there's such a lack of documentation on D that I'm *supposed* to just guess and experiment about what .o and .a files might be, or hope that an IDE frontend writer guessed right? There's no specification whatsoever? ketmar was just being a teensy weensy bit over-dramatic. He was trying to point out that gdc is part of the GCC and so all the GCC documentation is relevant for gdc. D thus gets huge amounts of documentation for gdc for free. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 13:11:45 UTC, Russel Winder via Digitalmars-d-learn wrote: ketmar was just being a teensy weensy bit over-dramatic. He was trying to point out that gdc is part of the GCC and so all the GCC documentation is relevant for gdc. D thus gets huge amounts of documentation for gdc for free. The problem that I'm having with this seems to be with GDC, not the rest of the D community. The following is a quote of the entire amount of information in the GDC man page on the following compiler options and file extensions: SYNOPSIS gdc [-c] [-g] [-pg] [-Olevel] [-Idir...] [-Ldir...] [-o outfile] infile... For any given input file, the file name suffix determines what kind of compilation is done: file.d D source files. file.di D interface files. file.o Object files to link in. file.a Library files to link in So I could *guess* that a dot o file is the equivalent of a .obj file an Windows, and *guess* that a dot a file is the equivalent of a .lib file on Windows, then follow some Windows instructions as on the page http://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows but I would totally be guessing, and I still wouldn't know where to get any .a files, but I could *guess* that I would get a .o file by running the compiler and naming the output a .o file by using the -o switch. I would be totally guessing, and if I'm wrong, all my builds would be wrong and incompatible with other people's build systems. Again, I was hoping there would be some instruction pages or documentation pages or specifications on this subject.
Re: Instructions for compilation from multiple source files
On 11/10/2014 9:55 PM, Solomon E wrote: On Monday, 10 November 2014 at 12:21:51 UTC, bearophile wrote: That's not applicable because I'm not using DMD. Also that doesn't answer where a .o or .a file comes from, whether there's any difference between them besides the name, and if so what. I've compiled a lot of little examples and tests of D from single source files, but I haven't seen any .o or .a files yet. .o and .a have are not a D-specific thing. They are part of the ecosystem on Posix systems. If you are using C or C++, you would still be dealing with them. You input source files to a compiler, it creates object files (.o) and you feed those to a linker to get an executable binary or an archiver to get a library (.a), which is a collection of object files that can be linked to an executable. Please do not confuse this with having anything directly to do with D. Most of the D compiler implementations on Linux use the GNU compiler collection (gcc) toolchain to generate binaries, and gcc is a core part of the Linux ecosystem. If you are working on the command line in Linux, it's something you have to get your head around eventually. The same goes for any platform you use. I was hoping there were instruction pages or documentation pages on how to compile D projects that have multiple source files. Assume a directory structure like so: -project --source main.d foo --bar.d cd project/source gdc main.d foo/bar.d -o myapp No matter which compiler you are using, you have to pass every source file to it that you want it to compile into the final executable. The only way around this is to use a build tool like dub or rdmd, which will hand everything to the compiler for you. When using gdc, since it is based on gcc then the output for a binary is always named 'a.out'. The -o option will cause the binary to be named what ever you set it to, in this case 'myapp'. Notice that the paths are relative to the currently directory. If main.d imports foo.bar, then DMD will know do look for foo/bar.d from the current directory. You can change this up a bit like so: cd project gdc -Isource source/main.d source/foo/bar.d -o myapp Here, the -I option tells dmd to look for imports *in* the source directory. Now, when it fails when main.d imports foo.bar and the compiler fails to find the file foo/bar.d relative the the current directory, it will then look in source/foo/bar.d and find it. That's only for imports though and not for compilation. When using third-party libraries, you will usually need to pass the -I switch. No matter what compiler you use, you can usually run something like gdc --help to get a list of command line switches and what they do. For dmd, you can just type 'dmd' to print them. Since you are using gdc, I suggest you google for tutorials on how to the gcc tools, particularly compiling. The process in D is basically the same and the fundamentals of compiling and linking are the same across compilers. I don't use gdc, but I believe it supports most of the standard gcc compiler switches and adds some specific ones for D. Perhaps a page could be added to the Wiki explaining the basics of compilation with the different compilers, but most of the existing documentation assumes that users will know at least the basics of using a compiler from the command line. Ali Çehreli has put together a fantastic book [1] that is targeted at beginners. It has a section introducing DMD. That would also be a good place for you to start. If you understand the fundamentals of one compiler, you can pick them all up. [1] http://ddili.org/ders/d.en/index.html
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 13:29:02 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: The problem that I'm having with this seems to be with GDC, not the rest of the D community. The following is a quote of the entire amount of information in the GDC man page on the following compiler options and file extensions: SYNOPSIS gdc [-c] [-g] [-pg] [-Olevel] [-Idir...] [-Ldir...] [-o outfile] infile... For any given input file, the file name suffix determines what kind of compilation is done: file.d D source files. file.di D interface files. file.o Object files to link in. file.a Library files to link in So I could *guess* that a dot o file is the equivalent of a .obj file an Windows, and *guess* that a dot a file is the equivalent of a .lib file on Windows, then follow some Windows instructions as on the page http://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows but I would totally be guessing, and I still wouldn't know where to get any .a files, but I could *guess* that I would get a .o file by running the compiler and naming the output a .o file by using the -o switch. I would be totally guessing, and if I'm wrong, all my builds would be wrong and incompatible with other people's build systems. you'd better use some IDE if you have to guess such things. gdc manpage documents gdc-specific options. it even gives you some directions in see also section, which you are supposed to follow to read more about GCC suite. GCC also has extensive on-line documentation. yes, you are supposed to know how to use GCC, part of which gdc is. if you don't want to think about that, you can use IDE which does all this for you automatically. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 13:44:26 UTC, ketmar via Digitalmars-d-learn wrote: you'd better use some IDE if you have to guess such things. gdc manpage documents gdc-specific options. it even gives you some directions in see also section, which you are supposed to follow to read more about GCC suite. GCC also has extensive on-line documentation. yes, you are supposed to know how to use GCC, part of which gdc is. if you don't want to think about that, you can use IDE which does all this for you automatically. I keep saying I want documentation or specifications. If there isn't any, how would the people who write the IDE frontends for languages know whether they're doing it right? Maybe they aren't and they're just guessing and naming output files whatever way sounds and looks right to them, so it sort of fits with what output people expect, without actually being the right format of files! (I quoted from the GDC man page. How do you think I did that if it wasn't for reading it?) Some pages say to rename output files with .a if you want a library type file, other pages say they're an archive format for library files. So this isn't idle speculation that there might be some confusion by tool writers or there might be a lack of enough officially specified standards or accessible enough documentation. http://rainers.github.io/visuald/visuald/Installation.html quote when building a library you should change the output file name extension to .a. end quote
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 14:12:12 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I keep saying I want documentation or specifications. and i keep saying that if you can't find those for you case, you'd better stick with IDE. you keep ignoring the fact that gdc is a part of GCC and you have to read GCC documentation to understand the process. ok, it's your right to insist that gdc must include GCC documentation, but don't expect it to happen, as this will be a useless duplication. any person that is familiar with GCC suite immediately groks how to use gdc, 'cause it's not different from other GCC frontends. sure, it has some specific options, and those options are documented in manpage. if you don't want to see gdc as a part of GCC suite... oh, well, it's your choice. other gdc users has no problems with that and they aren't refusing to understand how GCC should be used, what files it produces and how. as you obviously don't want to learn that, i keep recommending you to use IDE for working with your code, 'cause IDE knows how to call requred tools from the toolchain. signature.asc Description: PGP signature
Strictness of language styling
I'm translating the library Botan and I'm at a point where I have to ask myself if I'm going to change functions and object names respectively from snake_case and Camel_Case to camelCase and CamelCase. Same goes for file names. Is this a strict rule for D libraries?
ODBC Library?
Hi guys, I've been looking and haven't found any libraries for ODBC or MSSQL. I saw some for D v1, but nothing for v2. Anyone know of any, or anyone know of a tutorial that I could use to create this myself? Thanks, Charles
Re: ODBC Library?
I kinda slapped one together but idk if it actually works. https://github.com/adamdruppe/arsd database.d and mssql.d from that repo. I haven't even tried to compile it for a while though, so it might not work at all. The way I made it was to write the extern(C) function declarations and then call it like in C.
Re: Strictness of language styling
Etienne: I'm translating the library Botan and I'm at a point where I have to ask myself if I'm going to change functions and object names respectively from snake_case and Camel_Case to camelCase and CamelCase. Same goes for file names. Is this a strict rule for D libraries? Take a look: http://dlang.org/dstyle.html Bye, bearophile
Re: Strictness of language styling
Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc.
Re: Strictness of language styling
On 2014-11-10 11:16 AM, Adam D. Ruppe wrote: Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc. I was thinking the same but sure am glad to hear you say it :D
Memory usage of dmd
I develop a web site with vibe, but because I am using a Virtual Private Server I get some memory issues. The server only has 1Go of memory ( 900Mo free) and it seems I can't compile directly on it a simple static page (70 lines). I get the following message when building with dub : Running dmd... FAIL ../../../.dub/packages/vibe-d-master/.dub/build/libevent-release-linux.posix-x86_64-dmd_2066-EB47C82EE359A00A02828E314FCE5409/ vibe-d staticLibrary Error executing command build: Orphan format specifier: %%s failed with exit code %s. This may indicate that the process has run out of memory. So for the moment I build the web site on a physical machine, and I saw the compilation takes around 1.6Go of memory. Is there some options can help me to reduce the memory consumption? As it's for production purpose I don't think that is a good idea to remove compiler optimizations. Are gdc or ldc better in this case?
Re: ODBC Library?
On Monday, 10 November 2014 at 16:01:21 UTC, Charles wrote: Hi guys, I've been looking and haven't found any libraries for ODBC or MSSQL. I saw some for D v1, but nothing for v2. Anyone know of any, or anyone know of a tutorial that I could use to create this myself? Assuming you're using ODBC on Windows, here's an old port of an even older C++ wrapper I used to use for ODBC work. It includes an ODBC header and library, so should serve as a good basis for whatever you're trying to do. If you're on Unix, you may have to update the ODBC header a bit. I got partway through that project back in the day but never finished: http://invisibleduck.org/sean/tmp/sql.zip
Re: Memory usage of dmd
On 2014-11-10 11:32 AM, Xavier Bigand wrote: Is there some options can help me to reduce the memory consumption? As it's for production purpose I don't think that is a good idea to remove compiler optimizations. The memory issues are probably related to diet templates. LDC and GDC won't help. You should definitely work and build on a machine with 4GB of ram. The server application could use as low as 8mb of ram, but compiling requires a workstation. Perhaps renting an amazon instance a few minutes for compilation would be a better idea?
Re: ODBC Library?
Oh, here's a sample, since it doesn't look like that zip includes
one:
import sql.Connection;
import sql.Exception;
import sql.ResultSet;
import sql.Statement;
import core.stdc.stdio;
pragma( lib, odbc32.lib );
pragma( lib, sql.lib );
void main()
{
try
{
auto conn = new Connection( driver={SQL Server};
server=(local);
trusted_connection=no;
database=test;
uid=sa;
pwd=hello; );
//network=dbmssocn; );
auto stmt = conn.prepare( SELECT Name FROM Person WHERE
PersonID = ? );
stmt[0] = 1;
//auto stmt = conn.prepare( SELECT Name FROM Person );
auto rs = stmt.open();
printf( %.*s\n\n, rs[0].name );
while( rs.next() )
printf( %.*s\n, rs[0].asUtf8 );
}
catch( SQLException e )
{
foreach( rec; e )
{
printf( %.*s - %d: %.*s\n, rec.state, rec.code,
rec.msg );
}
}
}
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote: I don't trust the DMD Debian package enough to install it, considering it has Google adsense ads in its HTML pages, which is against even Google's policy. Could you point to the exact page your looking at?
Re: Memory usage of dmd
Xavier Bigand: So for the moment I build the web site on a physical machine, and I saw the compilation takes around 1.6Go of memory. Compiling the whole Phobos as a single compilation unit on 32 bit DMD requires a little more than 1 GB. Bye, bearophile
Re: Memory usage of dmd
Le 10/11/2014 17:41, Etienne a écrit : On 2014-11-10 11:32 AM, Xavier Bigand wrote: Is there some options can help me to reduce the memory consumption? As it's for production purpose I don't think that is a good idea to remove compiler optimizations. The memory issues are probably related to diet templates. Yes I think it too. LDC and GDC won't help. You should definitely work and build on a machine with 4GB of ram. The server application could use as low as 8mb of ram, but compiling requires a workstation. Perhaps renting an amazon instance a few minutes for compilation would be a better idea? I already have a computer with a linux to build it, so amazon won't improve situation. As I know to be able to have no down time with vibe we need to be able to build directly on the server where the program runs. Maybe I just need to wait that I have some users to pay a better server with more memory.
Re: Memory usage of dmd
On 2014-11-10 12:02 PM, Xavier Bigand wrote:
As I know to be able to have no down time with vibe we need to be able
to build directly on the server where the program runs.
Maybe I just need to wait that I have some users to pay a better server
with more memory.
With a low number of users, there's no reason to worry about a 1 second
downtime from closing the process and replacing the application file.
You should use a bash script to keep the process open though:
# monitor.sh
nohup ./autostart.sh stdout.log 2 crash.log /dev/null
# autostart.sh
while true ; do
if ! pgrep -f '{processname}' /dev/null ; then
sh /home/{mysitefolder}/start.sh
fi
sleep 1
done
# start.sh
nohup ./{yourapplication} --uid={user} --gid={group} stdout.log 2
crash.log stdout.log
# install.sh
pkill -f '{processname}'
/bin/cp -rf {yourapplication} /home/{mysitefolder}/
Using a console, run monitor.sh and the autostart.sh script will
re-launch your server through start.sh into a daemon. Verifications will
be made every second to ensure your server is never down because of a
badly placed assert.
If you need to replace your server application with an update, run the
install.sh script from the folder where the update is.
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 15:35:54 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 10 Nov 2014 14:12:12 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I keep saying I want documentation or specifications. and i keep saying that if you can't find those for you case, you'd better stick with IDE. you keep ignoring the fact that gdc is a part of GCC and you have to read GCC documentation to understand the process. ok, it's your right to insist that gdc must include GCC documentation, but don't expect it to happen, as this will be a useless duplication. any person that is familiar with GCC suite immediately groks how to use gdc, 'cause it's not different from other GCC frontends. sure, it has some specific options, and those options are documented in manpage. if you don't want to see gdc as a part of GCC suite... oh, well, it's your choice. other gdc users has no problems with that and they aren't refusing to understand how GCC should be used, what files it produces and how. as you obviously don't want to learn that, i keep recommending you to use IDE for working with your code, 'cause IDE knows how to call requred tools from the toolchain. I do know about how to use GCC and where the documentation for that is. I know what .o files and .a files are in terms of GCC for C, because there's tons of documentation about that. I thought that there might be a little bit of documentation about what they are for D, or a specification. A language that's about grokking things (I've read Stranger in a Strange Land, so I grok what it means) is not the sort of language that I want to use. I prefer that a language that specifies what a computer is to do be specified itself. That is all. I don't want to use an IDE that pretends to have AI about what to do for me, just because a language doesn't have enough documentation to let me know what to do for myself. That's like the opposite of learning to program. In this case it's about the tiny amount of documentation for GDC, which assumes that users will know about using GCC for C or C++ and will apply a diff of how D differs from those to use it for D. In other cases I've seen all over the Language Reference it's the same thing: D is described roughly as a diff of C and C++ and not as a language in its own right, with examples that may or may not be complete and who can tell where they are complete enough and where they aren't?
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 16:49:27 UTC, John Colvin wrote: On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote: I don't trust the DMD Debian package enough to install it, considering it has Google adsense ads in its HTML pages, which is against even Google's policy. Could you point to the exact page your looking at? Gdebi Package Installer gave privacy-breach-google-adsense as a Lintian output for about a hundred pages in dmd_2.066.0-0_amd64.deb (as well as a lot of other problems I don't know about.) https://lintian.debian.org/tags/privacy-breach-google-adsense.html I tried extracting the pages in question and viewing them, and yes, they do serve Google ads from online while browsing local html files.
Re: ODBC Library?
I kinda slapped one together but idk if it actually works. https://github.com/adamdruppe/arsd database.d and mssql.d from that repo. I haven't even tried to compile it for a while though, so it might not work at all. The way I made it was to write the extern(C) function declarations and then call it like in C. It didn't compile, says, mssql.d(12): Error: module sql is in file 'win32\sql.d' which cannot be read and then lists the import paths, of which none of them have the win32 directory. Database.d was able to compile though. Assuming you're using ODBC on Windows, here's an old port of an even older C++ wrapper I used to use for ODBC work. It includes an ODBC header and library, so should serve as a good basis for whatever you're trying to do. If you're on Unix, you may have to update the ODBC header a bit. I got partway through that project back in the day but never finished: http://invisibleduck.org/sean/tmp/sql.zip I'll look into this, thanks for the example.
Re: Memory usage of dmd
Le 10/11/2014 18:17, Etienne a écrit :
On 2014-11-10 12:02 PM, Xavier Bigand wrote:
As I know to be able to have no down time with vibe we need to be able
to build directly on the server where the program runs.
Maybe I just need to wait that I have some users to pay a better server
with more memory.
With a low number of users, there's no reason to worry about a 1 second
downtime from closing the process and replacing the application file.
You should use a bash script to keep the process open though:
# monitor.sh
nohup ./autostart.sh stdout.log 2 crash.log /dev/null
# autostart.sh
while true ; do
if ! pgrep -f '{processname}' /dev/null ; then
sh /home/{mysitefolder}/start.sh
fi
sleep 1
done
# start.sh
nohup ./{yourapplication} --uid={user} --gid={group} stdout.log 2
crash.log stdout.log
# install.sh
pkill -f '{processname}'
/bin/cp -rf {yourapplication} /home/{mysitefolder}/
Using a console, run monitor.sh and the autostart.sh script will
re-launch your server through start.sh into a daemon. Verifications will
be made every second to ensure your server is never down because of a
badly placed assert.
If you need to replace your server application with an update, run the
install.sh script from the folder where the update is.
Thank you for tips. I'll start from your scripts.
Re: status of D optimizers benefiting from contracts ?
On 11/09/2014 11:39 PM, H. S. Teoh via Digitalmars-d-learn wrote: The original meaning of assert() is what assume() means nowadays, whereas nowadays what people think of as assert() is actually what enforce() does in Phobos. T No.
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 17:18:05 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I do know about how to use GCC and where the documentation for that is. I know what .o files and .a files are in terms of GCC for C, because there's tons of documentation about that. I thought that there might be a little bit of documentation about what they are for D, or a specification. as for D... they are compiled object files. exactly the same thing as for c++, gnu pascal or any other language in GCC that produces .o. are you expecting them to be something special? then you'll read about that in gdc manpage. A language that's about grokking things (I've read Stranger in a Strange Land, so I grok what it means) is not the sort of language that I want to use. I prefer that a language that specifies what a computer is to do be specified itself. That is all. how this belongs to particular D compiler? you are *expected* to understand what is being part of GCC suite for GNU D compiler. it's not about language at all, it's about toolchain. and this is not the only one compiler available, and there inevitably will be more. do you expecting to read about every specific compiler implementation in language dox? DMD happens to be special one 'cause it's a reference compiler for D. yet there is nothing special in DMD, it's an ordinary command-line compiler. if you know how to use one of them, you know how to use all of them. I don't want to use an IDE that pretends to have AI about what to do for me, just because a language doesn't have enough documentation to let me know what to do for myself. should D documentation include all all POSIX documentation for core utils, 'cause some of them can be needed to work with source files? and for VIM, and for Emacs and for all other editors, 'cause, ahem, they can be used to edit D sources? you are *expected* to know how your system works, what file and directory is, what is compiling to object file, what is linking and so on. if there is something that deviates from common system way of doing things, only then it is documented. like gdc-specific command line arguments. In this case it's about the tiny amount of documentation for GDC, which assumes that users will know about using GCC for C or C++ and will apply a diff of how D differs from those to use it for D. it's the easiest way to describe such things. i don't see how it is necessary to copy and paste all GCC documentation for gdc. In other cases I've seen all over the Language Reference it's the same thing: D is described roughly as a diff of C and C++ you realised that language reference is not meant for those who learning how to program, didn't you? there is the excellent book by Ali Çehreli which is not diff and targeted to those who learning D, for example. and then you are expected to read documentation for GCC if you are planning to use gdc, as gdc is a part of GCC. there is nothing unsusual in not finding the information you want if you are looking for it in the wrong place. physics textbook will not start with teaching you simple math. signature.asc Description: PGP signature
Re: is there any reason UFCS can't be used with 'new'?
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName
{
string name;
this(string name)
{
this.name = name;
}
void sayHello(string name)
{
writeln(name);
}
}
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 16:49:26 + John Colvin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Monday, 10 November 2014 at 12:10:37 UTC, Solomon E wrote: I don't trust the DMD Debian package enough to install it, considering it has Google adsense ads in its HTML pages, which is against even Google's policy. Could you point to the exact page your looking at? i remember that there was commit that removes adsense from default documentation pages. that was left by accident and nobody pays attention to it, partially due to adblockers, and partially due to using dlang.org for reading documentation. signature.asc Description: PGP signature
Re: status of D optimizers benefiting from contracts ?
On 11/09/2014 05:24 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Sun, Nov 09, 2014 at 04:12:06PM +, bearophile via Digitalmars-d-learn wrote: H. S. Teoh: Walter *did* mention recently that he was planning to eventually take advantage of information in assert()'s as optimizer hints. Not sure when this will happen, though, but it seems inevitable at some point. And it caused a storm, because it's an awfully bad idea. [...] It's only a bad idea because people abuse assert() where it's not appropriate. T Some do, but that's basically orthogonal to why this is a bad idea.
Re: practicality of empirical cache optimization in D vs C++
I would also be curious to see projects in D that involved cache optimization.
practicality of empirical cache optimization in D vs C++
Dear D community (and specifically experts on cache optimization), I'm a C++ programmer and was waiting for a while to do a project in D. I'd like to build a cache-optimized decision tree forest library, and I'm debating between D and C++. I'd like to make it similar to atlas, spiral, or other libraries that partially use static optimization with recompilation and meta-programming to cache optimize the code for a specific architecture (specifically the latest xeons / xeon phi). Given D's compile speed and meta-programming, it should be a good fit. The problem that I might encounter is that C++ has a lot more information on the topic, which might be significant bottleneck given I'm just learning cache optimization (from a few papers and what every programmer should know about memory). From my understanding, cache optimization mostly involves breaking data and loops into segments that fit in cache, and making sure that commonly used variables (for example sum in sum+=i) stay in cache. Most of this should be solved by statically defining sizes and paddings of blocks to be used for caching. It's more related to low level -- C, from my understanding. Are there any hidden stones? The other question is how mature is the compiler in terms of optimizing for cache comparing to C++? I think gnu C++ does a few tricks to optimize for cache and there are ways to tweak cache line alignment. My knowledge on the subject is not yet concrete and limited but I hope this gave an idea of what I'm looking for and you can recommend me a good direction to take. Best regards, --Kirill
Re: Strictness of language styling
On Mon, 10 Nov 2014 16:16:04 + Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc. +1 to this. it's better to use camelCase for shiny new code, but for ports it's desirable to keep names unchanged where appropriate, for easy googling and so. signature.asc Description: PGP signature
Re: is there any reason UFCS can't be used with 'new'?
On Mon, 10 Nov 2014 19:07:38 + Suliman via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: /// How to use UFCS here? userName.name.sayHello(); /// you can't. a little explanation: UFCS substitutes only the first argument. and for class methods first argument is hidden 'this'. so you can't do it in this way, you have to write `userName.sayHello(name);` here. on the very low level calling class methods looks like this: // what you see: myobj.method(arg); // what compiler does: // method(myobj, arg); so in your example compiler sees this: sayHello(userName.name); which is obviously not what you want, 'cause you need this: sayHello(userName, name); or, taking it the easier way: UFCS is for *functions*, not for *methods*. that's why it uniform *function* call syntax. it's not expected to work with methods, as the name suggests. maybe it will be easier to remember this way, rather than diving into compiler code transformations. ;-) signature.asc Description: PGP signature
Re: Strictness of language styling
On Mon, Nov 10, 2014 at 09:19:58PM +0200, ketmar via Digitalmars-d-learn wrote: On Mon, 10 Nov 2014 16:16:04 + Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Personally, I don't really care about naming conventions. I prefer the camelCase and it seems most D people do, but if you're translating another library, there's value it keeping it the same for ease of documentation lookups from the original etc. +1 to this. it's better to use camelCase for shiny new code, but for ports it's desirable to keep names unchanged where appropriate, for easy googling and so. I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. And since Phobos is all camelCased, and almost all D code uses Phobos, writing your own code with something else makes it doubly ugly. So nowadays I just use Phobos style for my own code. :-P Nevertheless, I still dislike camelCase. But as in any group project, especially large ones, the best policy is to follow the coding style of the surrounding code, even if it clashes with your own. Even worse than mixing camelCase with non_camel_case, is a source file that looks like a mosaic (or complete jumble) of multiple, incompatible coding styles all thrown together. An unfortunately frequent occurrence in large group projects without an adopted set of coding conventions. :-( T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: is there any reason UFCS can't be used with 'new'?
On Mon, 10 Nov 2014 19:07:38 +, Suliman wrote:
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName {
string name;
this(string name)
{
this.name = name;
}
void sayHello(string name)
{
writeln(name);
}
}
This has nothing to do with new--you're trying to use a virtual function
scoped
to class userName with a string. Rewrite it to a static module-scoped
function:
class userName {
string name;
this(string name)
{
this.name = name;
}
}
void sayHello(string name)
{
writeln(name);
}
void main()
{
string name = Suliman;
userName username = new userName(name);
userName.name.sayHello();
}
Re: is there any reason UFCS can't be used with 'new'?
On 11/10/2014 11:07 AM, Suliman wrote:
I can't understand how to use UFCS with instance of class:
void main()
{
string name = Suliman;
userName username = new userName(name);
/// How to use UFCS here?
userName.name.sayHello();
///
}
class userName
{
string name;
this(string name)
{
this.name = name;
}
void sayHello(string name)
{
writeln(name);
}
}
UFCS is about calling a free-standing function like a member function.
The following example makes more sense to me:
void main()
{
string name = Suliman;
userName username = new userName(name);
username.sayHello();// UFCS
}
// Does not have a sayHello() member function
class userName
{
string name;
this(string name)
{
this.name = name;
}
}
void sayHello(userName u)
{
import std.stdio;
writeln(u.name);
}
Ali
Re: Strictness of language styling
Hard styling rules only apply to Phobos contributions. Any other project can have their own, for example, vibe.d requires own style which is incompatible with Phobos. For ported 3d party library value of minimizing the diff is indeed more important than styling.
Re: Memory usage of dmd
If your server runs systemd, I would strongly recommend to use that instead of a shell script. You can use Restart=always or Restart=on-failure in the unit file. It also provides socket activation, which will allow you to restart the program without downtime.
Re: is there any reason UFCS can't be used with 'new'?
Thanks! Ali Çehreli, could you add this mention and possible the example to your book?
Re: ODBC Library?
On Monday, 10 November 2014 at 18:13:58 UTC, Adam D. Ruppe wrote: On Monday, 10 November 2014 at 17:57:21 UTC, Charles wrote: It didn't compile, says, mssql.d(12): Error: module sql is in file 'win32\sql.d' which cannot be read Oh, I forgot I used those. You can download the win32 folder from here https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI The Windows bindings that come with phobos are pathetically incomplete so a separate download or a bunch of copy/pasted declarations is needed for any serious windows api work. Thanks for that. For anyone in the future: I needed odbc32.lib, so I created the following odbc32.def and used implib. LIBRARY odbc32 EXETYPE NT SUBSYSTEM WINDOWS EXPORTS _SQLAllocEnv@4 = SQLAllocEnv _SQLAllocConnect@8 = SQLAllocConnect _SQLAllocHandle@12 = SQLAllocHandle _SQLColAttribute@28 = SQLColAttribute _SQLConnect@28 = SQLConnect _SQLDisconnect@4 = SQLDisconnect _SQLDescribeCol@36 = SQLDescribeCol _SQLDriverConnect@32 = SQLDriverConnect _SQLDrivers@32 = SQLDrivers _SQLDataSources@32 = SQLDataSources _SQLExecDirect@12 = SQLExecDirect _SQLFetch@4 = SQLFetch _SQLFreeConnect@4 = SQLFreeConnect _SQLFreeHandle@8 = SQLFreeHandle _SQLFreeEnv@4 = SQLFreeEnv _SQLEndTran@12 = SQLEndTran _SQLFreeStmt@8 = SQLFreeStmt _SQLGetData@24 = SQLGetData _SQLGetDiagField@28 = SQLGetDiagField _SQLGetDiagRec@32 = SQLGetDiagRec _SQLGetInfo@20 = SQLGetInfo _SQLNumResultCols@8 = SQLNumResultCols _SQLSetConnectOption@12 = SQLSetConnectOption _SQLSetEnvAttr@16 = SQLSetEnvAttr _SQLSetStmtOption@12 = SQLSetStmtOption I've only tested it on a couple select statements and the fieldNames, but so far its working.
Re: Memory usage of dmd
On 2014-11-10 2:52 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: If your server runs systemd, I would strongly recommend to use that instead of a shell script. You can use Restart=always or Restart=on-failure in the unit file. It also provides socket activation, which will allow you to restart the program without downtime. I totally agree, I couldn't find a good resource about this though. The shell script method is quite literally rudimentary but it took me a few minutes to put together and it's been working great during 6 months so far. I'll go out and read a systemd tutorial eventually to get this done the right way, if anyone had anything ready and compatible with vibe.d apps I'd be happy about it. For the install script, I guess the best way would be to put together an RPM script and upgrade through that. I'd have to explore that solution, it's quite a lot more than 2 lines of code though :)
Re: Strictness of language styling
On Mon, 10 Nov 2014 11:35:04 -0800 H. S. Teoh via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. And since Phobos is all camelCased, and almost all D code uses Phobos, writing your own code with something else makes it doubly ugly. So nowadays I just use Phobos style for my own code. :-P Nevertheless, I still dislike camelCase. that's why i recommending camelCase. not because it's better, it's just happens. ;-) yet i can't go that far to drop my egyptian brackets or use four spaces for indentation. signature.asc Description: PGP signature
Re: Instructions for compilation from multiple source files
On Monday, 10 November 2014 at 19:09:45 UTC, ketmar via Digitalmars-d-learn wrote: as for D... they are compiled object files. exactly the same thing as for c++, gnu pascal or any other language in GCC that produces .o. are you expecting them to be something special? then you'll read about that in gdc manpage. That's nice. That implies all those compiled object files are compatible regardless of language. I don't know if that's true. It seems doubtful to me. how this belongs to particular D compiler? you are *expected* to understand what is being part of GCC suite for GNU D compiler. it's not about language at all, it's about toolchain. and this is not the only one compiler available, and there inevitably will be more. do you expecting to read about every specific compiler implementation in language dox? DMD happens to be special one 'cause it's a reference compiler for D. yet there is nothing special in DMD, it's an ordinary command-line compiler. if you know how to use one of them, you know how to use all of them. I thought part of learning D would be learning to compile larger programs than hello world. So I thought D.learn would be the correct forum to ask a question about where the documentation or specifications are for the files types involved in D on Linux, if any. I disagree that knowing how to use one command line compiler means knowing how to use all command line compilers. Maybe there have been a few more command line compilers in computer history than you're taking account of. should D documentation include all all POSIX documentation for core utils, 'cause some of them can be needed to work with source files? and for VIM, and for Emacs and for all other editors, 'cause, ahem, they can be used to edit D sources? you are *expected* to know how your system works, what file and directory is, what is compiling to object file, what is linking and so on. if there is something that deviates from common system way of doing things, only then it is documented. like gdc-specific command line arguments. I've run across a similar attitude before. When I tried MinGW and GCC the first time to use C, there were no instructions on the whole MinGW site for how to compile even a hello world using it for C, only for C++ instead. When I sent a message about that, also mentioning that I was somewhat confused by what sort of shell MinGW produced, what was it exactly, I was told it was bash and directed to the Beginner's Guide to Bash, which I found I couldn't use according to that guide's own instructions, because I wasn't already experienced in installing and running programs on a Unix-like system, which that guide says is a prerequisite. (Of course I got going and did what I wanted to do with C anyway. Those were just some learner's questions, normal for learning a different computer program with incomplete instructions, I thought. Apparently some experienced Unix-like system users have a different attitude.) It's true, you are expected to know your system, even if it's brand new to you and the instructions are only for experienced users and warn you away from using them if you aren't an experienced user yet. This is a problem. Why not just somewhere have a few lines of examples and type signatures for the various elementary commands for a compiler, as part of the documentation or specification that it's supposed to meet in order to be considered functional? I'm not asking for that to be in the D language specifications, because it is about GDC. it's the easiest way to describe such things. i don't see how it is necessary to copy and paste all GCC documentation for gdc. In other cases I've seen all over the Language Reference it's the same thing: D is described roughly as a diff of C and C++ you realised that language reference is not meant for those who learning how to program, didn't you? there is the excellent book by Ali Çehreli which is not diff and targeted to those who learning D, for example. and then you are expected to read documentation for GCC if you are planning to use gdc, as gdc is a part of GCC. there is nothing unsusual in not finding the information you want if you are looking for it in the wrong place. physics textbook will not start with teaching you simple math. I already downloaded and started working through the examples in that book a couple of weeks ago. The sort of assumption I'm talking about is here again, that doing the simplest things with a compiler is like simple math in your analogy. If someone has been using similar compilers for years and years, I suppose it seems so. People seem to lose sight of the fact that computer programs allow fully arbitrary interpretation of commands and their results. So whatever a person guesses about how it works or reads in a textbook about some other program or a related program with a similar name or similar commands might not apply to the program a person wants to use. In this whole thread, I
Reason for mypackage/package.d instead of mypackage.d
I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d I was wondering why a package module had to be called package.d instead of just being the package name. For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well? My first thought was that maybe it let's the compiler know that all package modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons? Also are there other reasons? Thanks in advance.
Re: Reason for mypackage/package.d instead of mypackage.d
On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote: I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d I was wondering why a package module had to be called package.d instead of just being the package name. For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well? My first thought was that maybe it let's the compiler know that all package modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons? Also are there other reasons? Thanks in advance. You can't have both module and package of the same name AFAIR. Thus std/range.d + std/range/something.d simply won't work
Re: Strictness of language styling
On Monday, 10 November 2014 at 19:37:06 UTC, H. S. Teoh via Digitalmars-d-learn wrote: I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. Ah, but here I disagree. I like to use different formatting for different levels of semantics. I prefer lower case for ADT structs and CamelCasedClassesToSignifyDomainSpecificity. Basically distinguishing high level from low level. It makes sense to give more EMPHASIS to high level constructs. (but camelCase in ADTs and generic libraries suck ;-)
Re: Reason for mypackage/package.d instead of mypackage.d
On 11/10/14 4:33 PM, Dicebot wrote: On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote: I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d I was wondering why a package module had to be called package.d instead of just being the package name. For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well? My first thought was that maybe it let's the compiler know that all package modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons? Also are there other reasons? Thanks in advance. You can't have both module and package of the same name AFAIR. Thus std/range.d + std/range/something.d simply won't work I don't think this is it, although that was the rule, we could easily have allowed it. I think the reasons package.d were chosen are: 1. Logically, you want all to be within the same package, and std/range.d is in a different package from std/range/x.d 2. package is a keyword, and cannot be a module name Incidentally, allowing this idiom gives new life to the package keyword :) -Steve
Re: Instructions for compilation from multiple source files
On Mon, 10 Nov 2014 21:27:20 + Solomon E via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: (There is a dlang page http://wiki.dlang.org/GDC/Using_GDC that gives some instructions, including how to compile hello world and how to get a .o file, but strangely to me doesn't include any examples or abstracted formulas of how to use more input files or any mention of .a files.) So I guess the answer is, no, there isn't any documentation or specification that covers it, and not even any official instructions or beginner's guide that covers it. I wish people would just be honest and up front about saying, no, sorry, we don't have that; instead of people always seeming to want to put down people who ask questions about the essentials. you've been told several times that gdc is a part of GCC suite. there are extensive documentation and howtos for GCC. you are expected to read and understand that. there is nothing special in gdc which renders GCC documentation unusable for it. yet you keep ignoring that and insisting that GCC documentation should be duplicated for gdc. GCC is GNU Complier Collection, thus it means that GCC compilers have similar interfaces. you can also read about ABI in GCC documentation to discover the extents to which object files from one language are compatible with object files from another language. you are also expected to read binutils documentation to learn what .a files for, how they are created and used. there is no point to duplicate this information for each part of the suite. if you are insisting on using command-line tools, you are expected to be expirienced enough. and if you don't want to learn how to use them, you are free to use some IDE, which will do most of the dirty work for you. so the answer is no, there aren't any copies of GCC and binutils documentation in gdc. they aren't required. signature.asc Description: PGP signature
Re: Strictness of language styling
On Mon, Nov 10, 2014 at 11:27:13PM +0200, ketmar via Digitalmars-d-learn wrote:
On Mon, 10 Nov 2014 11:35:04 -0800
H. S. Teoh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I have to say that I *hate* camelCase... it looks really ugly. But
what looks uglier is a mixture of camelCase and something else. And
since Phobos is all camelCased, and almost all D code uses Phobos,
writing your own code with something else makes it doubly ugly. So
nowadays I just use Phobos style for my own code. :-P Nevertheless,
I still dislike camelCase.
that's why i recommending camelCase. not because it's better, it's
just happens. ;-)
I'd rather use underscore_separated_words any day, than
havingAllWordsSmushedTogetherIntoOverlyLongIdentifiers that makes my
eyes bleed.
But mixing Phobos camelCase with underscored_identifiers makes my eyes
bleed even more, so it's at least tolerable.
yet i can't go that far to drop my egyptian brackets or use four
spaces for indentation.
I used to be an Egyptian-braces / tabs-only-indentation advocate. That
works reasonably well in C/C++, but I find that with idiomatic D, Phobos
style actually works much better. (Well, except that horrid camelCasing,
but hey, you can't win every battle.) D code tends to require many more
levels of indentation than C/C++, so using tabs can be quite cumbersome.
also, Egyptian braces tend to work better when the leading line of
nested blocks is simple, but in D, esp. with the complexity of function
declarations, the opposite is true.
But at least none of us use the following bracing style, which I had the
misfortune of coming across many years ago (I kid you not, people
actually exist who write code like this):
int my_func(int arg) {
if (arg==1) {
printf(One\n);
}
else {
printf(Not one\n);
}
for (i=0; i10; i++) {
int x = i*2;
do_something_else(x);
}
}
I think I needed therapy after encountering this. :-P
T
--
Let's eat some disquits while we format the biskettes.
Re: Strictness of language styling
On Mon, Nov 10, 2014 at 09:36:18PM +, via Digitalmars-d-learn wrote: On Monday, 10 November 2014 at 19:37:06 UTC, H. S. Teoh via Digitalmars-d-learn wrote: I have to say that I *hate* camelCase... it looks really ugly. But what looks uglier is a mixture of camelCase and something else. Ah, but here I disagree. I like to use different formatting for different levels of semantics. I prefer lower case for ADT structs and CamelCasedClassesToSignifyDomainSpecificity. Basically distinguishing high level from low level. It makes sense to give more EMPHASIS to high level constructs. (but camelCase in ADTs and generic libraries suck ;-) No idea what you're talking about, but I was referring to squishingAllWordsIntoOneUnreadableMess vs. keeping_them_visually_separate_and_readable. T -- Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. -- Gene Wirchenko
Re: Strictness of language styling
On Monday, 10 November 2014 at 22:04:20 UTC, H. S. Teoh via Digitalmars-d-learn wrote: No idea what you're talking about, but I was referring to squishingAllWordsIntoOneUnreadableMess vs. keeping_them_visually_separate_and_readable. I like the keeping_the_visually_separate_and_readable when it used for something generic that basically extends the language, but SquishingWordsTogether when is a classification related to the domain, e.g.: database.for_all_valid_entities(somelambda); string list!nodetype vs class Car… class RacingCar…
Re: is there any reason UFCS can't be used with 'new'?
On 11/10/2014 12:04 PM, Suliman wrote: Thanks! Ali Çehreli, could you add this mention and possible the example to your book? Of course. Perhaps I should rephrase some of the descriptions here? http://ddili.org/ders/d.en/ufcs.html Please email me at acehr...@yahoo.com if you have specific suggestions. Thank you, Ali
Re: Strictness of language styling
On Mon, 10 Nov 2014 14:00:32 -0800
H. S. Teoh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I used to be an Egyptian-braces / tabs-only-indentation advocate. That
works reasonably well in C/C++, but I find that with idiomatic D, Phobos
style actually works much better. (Well, except that horrid camelCasing,
but hey, you can't win every battle.) D code tends to require many more
levels of indentation than C/C++, so using tabs can be quite cumbersome.
also, Egyptian braces tend to work better when the leading line of
nested blocks is simple, but in D, esp. with the complexity of function
declarations, the opposite is true.
i HATE tabs. i hate tabs so much that all of my scripting languages
considers tab character as fatal syntax error.
But at least none of us use the following bracing style, which I had the
misfortune of coming across many years ago (I kid you not, people
actually exist who write code like this):
int my_func(int arg) {
if (arg==1) {
printf(One\n);
}
else {
printf(Not one\n);
}
for (i=0; i10; i++) {
int x = i*2;
do_something_else(x);
}
}
I think I needed therapy after encountering this. :-P
please, make me unsee that!
signature.asc
Description: PGP signature
Re: Strictness of language styling
On 11/10/2014 02:00 PM, H. S. Teoh via Digitalmars-d-learn wrote:
(I kid you not, people
actually exist who write code like this):
I know one of those people! They are from a different era. :)
int my_func(int arg) {
if (arg==1) {
printf(One\n);
}
else {
printf(Not one\n);
}
for (i=0; i10; i++) {
int x = i*2;
do_something_else(x);
}
}
Note especially how that last brace is there to get the unwary! :)
I think I needed therapy after encountering this. :-P
Same here! At least they used curly brackets for single-statements in
the code above. In my case, they are truly optional. :(
(By the way, do you happen to know whether there are Emacs coding styles
that help with that syntax? I could use one.)
Ali
Re: Instructions for compilation from multiple source files
ketmar, I understand that GDC documentation can be as terse as it wants to be, especially in the man page, which is supposed to be the shortest, for quick command line reference. It still seems a little odd to me that there wouldn't be additional instructions somewhere in the introductory pages to D on the D Wiki or somewhere else conveniently linked, on compiling multiple input files that are applicable to GDC or to all three compilers, rather than just specific to DMD on Windows. There's a joke in mathematics that sometimes a hard, unsolved problem is passed over in a paper with the words the rest is left as an exercise for the reader. Leaving the subtleties of multiple file GDC usage as an exercise, whatever those may be for D, if any, is certainly better than omitting language documentation or development or bugfixes, and also better than not having multiple compilers to choose from. So on reflection, I agree with leaving multiple file command line GDC usage as an exercise for anyone who wants to do it, in order to conserve limited development resources for improving more important things about D. So I'm sorry about all the fuss. I would delete the thread if I could. I understand that you're implying multiple file compilation should go smoothly the same for D as it does for any other GCC supported language, without any particular difficulties for D that you've seen about it, and I hope it goes smoothly for me as well.
Re: Instructions for compilation from multiple source files
It all works fine for me so far. I wrote a trivial test project of four d files, and compiled it all together, directly from d files, which took a couple of seconds to compile. Then instead I compiled it as two o files in an a file (using ar to archive), plus a d file, plus another o file for good measure, and that was faster on the final compile time.
