Re: Testing D database calls code for regression
On Friday, 16 March 2018 at 20:17:49 UTC, aberba wrote: How will you test D code which makes calls to database to detect bugs and regression. Unlike where you can inject data like assert (2+1 == 3), database interfacing code will be crazy... Or there's some mocking available for such cases. Especially when more features are developed on top. Well, I am not really sure what you are looking for but to test database code, there are frameworks for this Check for example tsqlt ( http://tsqlt.org/ ) this framework is ms sql specific and is the one I have experience with There is also dbfit ( http://dbfit.github.io/dbfit/ ) which seem to support more database management frameworks tsqlt is very good for unit testing, sql procedures or statements at a high this is how it was setup to be used 1. you prepare sql procedure to create your tables that will be used in testing 2. you prepare sql procedure with insert statements to create the data sample you want to be used for testing 3. you write a script execute the two procedures from the first two step then executed the procedure or statement you want to test and then at the end of this script executed some assert statements that is basically your unit test how to setup used those scripts 1. the setup started a transaction 2. the setup dropped everything in the database 3. the setup executed the scripts from point 3 above to create your database, followed by the insert statements scripts or data creation script, followed by executing the statement to be tested and finally executing the assert statements 4. finally the setup rolled back everything this setup was support by the tsqlt framework, but honestly i dont know how much of this was specific to the environment where i worked but you can use tsqlt to have this D is not a database language, D is not sql You should clearly separate testing the D code that call the sql statements and testing the sql statements themselves The above frameworks, will help you test the sql code in isolation
Re: Testing D database calls code for regression
On Mon, Mar 19, 2018 at 06:45:49PM +, aberba via Digitalmars-d-learn wrote: [...] > The thing about functional programming where functions are > decoupled/testable doesn't seem to apply to database call code. I > guess its because databases introduces a different state...another > point of failure. Not necessarily; in some cases it may be possible to design code such that its logic can be tested independently of an actual database. But that may not be practical in your case since it will likely involve a major rewrite. Basically, it's pretty rare for an application to actually need the full range of the SQL language + *all* of the features your database backend provides. Usually, the "business logic", so to speak, boils down to just some simple primitives: uploadFile(), createAccount(), loginUser(), logoutUser(), deleteAccount(), retrieveFile(), etc.. Ideally, the business logic part of the code should not even care about whether there's a database in the back supporting these operations; it should be higher-level code built on top of these high-level primitives. There should definitely not be any literal SQL statements anywhere at this level. The "business logic" side of the code should be completely testable with a mock API (with stubs for uploadFile, createAccount, etc.), and should not need to touch a real database at all. In the middle level where these primitives are implemented, that's where you actually translate these high-level operations into SQL. If the high-level API is well-designed, each operation should be pretty well encapsulated and should not cause unexpected conflicts with other operations. [...] > My code logic is a mix of file uploads which leads to saving file info > into db. And some general queries... my worry has been adding a > feature which might cause a regression in another rearly executed > code...its feels like I have to test all features/rest calls after > every major change. Don't know how others do this...when there's some > tight coupling involved. [...] Sounds like you're not really doing *unit* testing anymore, but it's a large-scale application-wide regression test. For that, probably your best bet is to create test databases and use external testing with a mock network / test DB server. E.g., basically what the dmd testsuite does today: a directory of input files and expected output files, and some simple tools to automatically run through all of them. You could create a library of test cases that you run your program through before release, to make sure nothing that has worked in the past will stop working now. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Re: Does the compiler inline the predicate functions to std.algorithm.sort?
On Monday, 19 March 2018 at 12:45:58 UTC, tipdbmp wrote: the LLVM IR obtained with -output-ll might be easier to read than assembly.) I only seem to get assembly on d.godbolt.org, even with the -output-ll option. On d.godbolt.org, you can get LLVM IR with a trick: use `-output-s=false -output-ll`. -Johan
Re: Testing D database calls code for regression
On Monday, 19 March 2018 at 00:56:26 UTC, H. S. Teoh wrote:
On Sun, Mar 18, 2018 at 07:51:18PM +, aberba via
Digitalmars-d-learn wrote:
On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via
> Digitalmars-d-learn wrote:
> > [...]
>
> The usual way I do this is to decouple the code from the
> real database backend by templatizing the database driver.
> Then in my unittest I can instantiate the template with a
> mock database driver that only implements the bare minimum
> to run the test.
>
> [...]
Mocking a fake database can also be huge pain. Especially when
something like transactions and prepared statements are
involved.
It depends on what your test is looking for. The idea is that
the mock database only implements a (small!) subset of a real
database, basically just enough for the test to run, and
nothing more. Of course, sometimes it may not be easy to do
this, if the code being tested is very complex.
Imagine testing your mock for introduced by future extension.
If you find yourself needing to test your mock database, then
you're doing it wrong. :-D It's supposed to be helping you
test your code, not to create more code that itself needs to be
tested!
Basically, this kind of testing imposes certain requirements on
the way you write your code. Certain kinds of code are easier
to test than others. For example, imagine trying to test a
complex I/O pipeline implemented as nested loops. It's
basically impossible to test it except as a blackbox testing
(certain input sets must produce certain output sets). It's
usually impractical for the test to target specific code paths
nested deep inside a nested loop. The only thing you can do is
to hope and pray that your blackbox tests cover enough of the
code paths to ensure things are correct. But you're likely to
miss certain exceptional cases.
But if said I/O pipeline is implemented as series of range
compositions, for example, then it becomes very easy to test
each component of the range composition. Each component is
decoupled from the others, so it's easy for the unittest to
check all code paths. Then it's much easier to have the
confidence that the composed pipeline itself is correct.
I/O pipelines are an easy example, but understandably, in
real-world code things are rarely that clean. So you'll have
to find a way of designing your database code such that it's
more easily testable. Otherwise, it's going to be a challenge
The thing about functional programming where functions are
decoupled/testable doesn't seem to apply to database call code. I
guess its because databases introduces a different
state...another point of failure.
no matter what. No matter what you do, testing a function made
of loops nested 5 levels deep is going to be very hard.
Similarly, if your database code has very complex
interdependencies, then it's going to be hard to test no matter
how you try.
My code logic is a mix of file uploads which leads to saving file
info into db. And some general queries... my worry has been
adding a feature which might cause a regression in another rearly
executed code...its feels like I have to test all features/rest
calls after every major change. Don't know how others do
this...when there's some tight coupling involved.
Anyway, on the more practical side of things, depending on what
your test is trying to do, a mock database could be as simple
as:
struct MockDb {
string prebakedResponse;
auto query(string sql) {
if (sql == "SELECT * FROM data")
return prebakedResponse;
else if (sql == "UPDATE * SET ... ")
prebakedResponse = ...
else
assert(0, "Time to rewrite your unittest :-P");
}
}
I.e., you literally only need to implement what the test case
will actually invoke. Anything that isn't strictly required is
fair game to just outright ignore.
Also, keep in mind that MockDb can be a completely different
thing per unittest. Trying to use the same mock DB for all
unittests will just end up with writing your own database
engine, which kinda defeats the purpose. :-P But the ability
to do this depends on how decoupled the code is. Code with
complex interdependencies will generally give you a much harder
time than more modular, decoupled code.
T
Re: Incomprehensible error message
On Mon, 2018-03-19 at 10:54 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
>
> One wild guess is if some of the symbols come from different modules,
> such that you might have modA.dvb_entry vs. modB.dvb_entry, for
> example,
> which would be a type mismatch. Or if one symbol was declared in D
> linkage but the other in C linkage, which is perhaps a more likely
> cause. But since the compiler doesn't tell us the FQN of the
> identifiers, it's anybody's guess whether this is actually the
> problem,
> or which are the offending identifiers.
>
Prompted by this and Adam's emails, which gave me the moral support to
getting stuck in to doing something rather than just moaning :-)
I think the problem is with the instance of dvb_entry *.
The call is actually in a loop:
for (auto entry = ptr.c_ptr().first_entry; entry != null; entry = entry.next) {
if (entry.channel is null) { continue; } // TODO Shouldn't need this,
but it seems needed, why?
frontendParameters.logfunc(LOG_INFO, "\nChannel: %s", entry.channel);
try {
auto scanHandler = ScanHandler_Ptr(frontendParameters.c_ptr(),
entry, dmx_fd.value(), , other_nit, timeout_multiplier);
I tried replacing the auto with dvb_entry* and we have the answer:
../../Repositories/Git/Masters/DVBTune/source/channels.d(157): Error: cannot
implicitly convert expression `(*this.ptr.c_ptr()).first_entry` of type
`libdvbv5_d.dvb_file.dvb_entry*` to `libdvbv5_d.dvb_scan.dvb_entry*`
This is most likely an unintended consequence of using DStep: the
dvb_entry type is being defined in two distinct modules. Now everything
is clear and I just need to find a solution to why two definitions.
The error message is still incomprehensible as is though.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: Packages and module import
On Mon, 2018-03-19 at 11:56 -0600, Jonathan M Davis via Digitalmars-d- learn wrote: > > […] > Well, what's the module statement in linux_dmx.d look like? > There wasn't one, even though I knew there was one. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Packages and module import
On Mon, 2018-03-19 at 17:49 +, Adam D. Ruppe via Digitalmars-d- learn wrote: > […] > > Odds are, linux_dmx.d is missing the `module > libdvbv5_d.linux_dmx;` line. > […] You are right. I was certain I had correct module statements in all the modules, but I hadn't. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Incomprehensible error message
On Mon, Mar 19, 2018 at 05:01:32PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Monday, 19 March 2018 at 16:33:28 UTC, Russel Winder wrote: > > I have been staring at this message so long, I have clearly stopped > > actually reading it, hence outside assistance needed. > > So I would guess either there's two definitions of one of the types > like maybe `dvb_v5_fe_parms` and the constructor uses one and your > code uses another (may be the same struct defined in two different > modules, where the definition imported one and you imported another - > stupid compiler was (is?) liable to say "type A is not type A" when it > should say "type foo.A is not bar.A"), or something like a stray const > on the `this` pointer. > > > I almost remember that A != A bug was fixed but maybe not in function > call things, or maybe not pushed to your ldc version yet. Yeah, the compiler really ought to be outputting FQNs in error messages, since otherwise you get baffling A != A messages. Though outputting FQNs everywhere has the tendency of bloating error messages to unreadable lengths, esp. when templates are involved. :-( (Though fortunately, no templates are involved in this case.) On a higher level, though, these type mismatch errors really ought to be refactored to pinpoint the cause of the compiler's unhappiness more narrowly, i.e., instead of saying: function F(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v) is not callable with parameter types (a,b,c,d,e,f,g,h,j,i,k,l,m,n,o,p,q,r,s,t,u,v) which requires the poor user to parse *two* entire incomprehensibly long parameter/argument lists and diff them in his head, the compiler really should say something more along the lines of: cannot pass argument j of type J to parameter 9 of type I and argument i of type I to parameter 10 of type J in function call to F(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v) The incomprehensibly long parameter list is unfortunately probably still necessary to identify any overloads of F, but at least point out to the user *which* parameters aren't matching instead of leaving him to figure it out! T -- IBM = I'll Buy Microsoft!
Re: Packages and module import
On Monday, March 19, 2018 17:29:10 Russel Winder via Digitalmars-d-learn wrote: > I had assumed that a directory of modules was a package. So for > example: > > A/a.d > A/b.d > > were two modules in package A. Especially given there is a module > statement at the beginning of each module: > > A/a.d has module A.a; > A/b.d has module A.b; > > Now A.b needs to access something from A.a. I had assumed that the > import should be fully qualified. So in A.b.d: > > import A.a: thing; > > This all works when building the library. Yes packages are directories and modules are files, but that can be mucked with on some level by explicitly marking the module with a module path that doesn't match its directory structure. If you do that, that tends to cause problems with the compiler finding your module to import, and build tools like rdmd and dub assume that the module's import path matches the file structure, but it's unfortunately not actually required, much as conceptually, that's the idea. > ldc2 -of=Build/Release/libdvbv5_d.so -shared -defaultlib=phobos2-ldc > Build/Release/source/libdvbv5_d/linux_dmx.o > Build/Release/source/libdvbv5_d/dvb_v5_std.o > Build/Release/source/libdvbv5_d/dvb_frontend.o > Build/Release/source/libdvbv5_d/dvb_log.o > Build/Release/source/libdvbv5_d/dvb_demux.o > Build/Release/source/libdvbv5_d/dvb_fe.o > Build/Release/source/libdvbv5_d/dvb_file.o > Build/Release/source/libdvbv5_d/dvb_scan.o > Build/Release/source/libdvbv5_d/dvb_sat.o -L-ldruntime-ldc > > > However when trying to build the unit-tests: > > > ldc2 -I=source -unittest --main -of=Build/Test/libdvbv5_d > source/libdvbv5_d/linux_dmx.d source/libdvbv5_d/dvb_v5_std.d > source/libdvbv5_d/dvb_frontend.d source/libdvbv5_d/dvb_log.d > source/libdvbv5_d/dvb_demux.d source/libdvbv5_d/dvb_fe.d > source/libdvbv5_d/dvb_file.d source/libdvbv5_d/dvb_scan.d > source/libdvbv5_d/dvb_sat.d source/libdvbv5_d/dvb_demux.d(35): Error: > module linux_dmx from file source/libdvbv5_d/linux_dmx.d must be imported > with 'import linux_dmx;' > > > Am I just missing something simple? Well, what's the module statement in linux_dmx.d look like? For better or worse, while the compiler will infer a module's name from the file name if you don't give it one, it won't infer the pcakage name. So, if you have no module declaration in linux_dmx.d, then it's going to be inferred as being the module linux_dmx with no package. So, that may or may not be part of your problem. Based on what you posted, it's not at all clear to me how you're building this stuff. The first example without -unittest is just dealing with .o files and not having to deal with imports at all. To know how that's being dealt with would require the command-line associated with generating the .o files. Also, if the import that's being complained about is in a unit test and isn't imported outside of one, then the problem relating to the import wouldn't be found when building without -unittest. The same would frequently be true if it's a template, since often, templates aren't instantiated outside of unit tests when compiling a library. - Jonathan M Davis
Re: Incomprehensible error message
On Mon, Mar 19, 2018 at 04:33:28PM +, Russel Winder via Digitalmars-d-learn wrote: [...] > I have been staring at this message so long, I have clearly stopped > actually reading it, hence outside assistance needed. > > Can someone please explain to me (probably in words of one syllable > since I am clearly being very unintelligent) how any code can deliver > an error message such as: [...] Here's my reformatting of the error, that hopefully might be of assistance: > source/channels.d(161): Error: constructor > libdvbv5.ScanHandler_Ptr.this ( > dvb_v5_fe_parms* frontendParameters, > dvb_entry* entry, > const(int) dmx_fd, > extern (C) int function(void* args, dvb_v5_fe_parms* parms) > check_frontend, > const(uint) other_nit, > const(uint) timeout_multiplier) > is not callable using argument types ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void* _arguments, dvb_v5_fe_parms* > frontendParameters), > const(uint), > const(uint)) [...] Or, boiled down to the bare basics with extraneous identifiers removed: > source/channels.d(161): Error: constructor > libdvbv5.ScanHandler_Ptr.this ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void*, dvb_v5_fe_parms*), > const(uint), > const(uint)) > is not callable using argument types ( > dvb_v5_fe_parms*, > dvb_entry*, > const(int), > extern (C) int function(void*, dvb_v5_fe_parms*), > const(uint), > const(uint)) [...] Which is rather odd, since the parameter types correspond to each other exactly. So why the compiler would reject the code, I honestly have no idea. One wild guess is if some of the symbols come from different modules, such that you might have modA.dvb_entry vs. modB.dvb_entry, for example, which would be a type mismatch. Or if one symbol was declared in D linkage but the other in C linkage, which is perhaps a more likely cause. But since the compiler doesn't tell us the FQN of the identifiers, it's anybody's guess whether this is actually the problem, or which are the offending identifiers. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Re: Packages and module import
On Monday, 19 March 2018 at 17:29:10 UTC, Russel Winder wrote: I had assumed that a directory of modules was a package. So for example: [...] On Monday, 19 March 2018 at 17:29:10 UTC, Russel Winder wrote: To my amateur eyes, first command-line build looks like a linking of object files into a .so. The second command-line build looks like compilation is taking place. Seems like the command-line used to compile the library is missing.
Re: Packages and module import
On Monday, 19 March 2018 at 17:29:10 UTC, Russel Winder wrote: Especially given there is a module statement at the beginning of each module: It is not especially, it is ONLY because of the module statement. The directory layout is a convention so tools can find the module file, but only the module declaration line in the code itself defines the authoritative name. source/libdvbv5_d/dvb_demux.d(35): Error: module linux_dmx from file source/libdvbv5_d/linux_dmx.d must be imported with 'import linux_dmx;' Odds are, linux_dmx.d is missing the `module libdvbv5_d.linux_dmx;` line. Any import statements and module statements need to use the same name. The layout in the file system is secondary to this.
Re: Is there a way to pipeline program with random-access ranges in C#?
On Monday, 19 March 2018 at 14:41:27 UTC, rumbu wrote:
Sorry, but I fail to understand your requirements. Do you have
a practical example?
Doing this without writing a loop or using arrays for memoizing
half-finished calculations:
public static int Foo(int[] input)
{ int result = 10;
for (int i = input.Length / 4; i >= 0; i -= 4)
{ int sum = 0;
for (int j = i; j < i +4 && j < input.Length; j++) sum +=
input[j];
sum *= i;
result = (result + sum) / 2;
}
return result;
}
To be honest, this is as artificial as it looks. When I look
again at my code, it seems that my main problem was that I have
not made a habit to input.Zip(Enumerable.Range(0, inputLength),
Tuple.Create) or similar when I need indexing in C# :).
I'm still interested in the answer, though.
Packages and module import
I had assumed that a directory of modules was a package. So for example: A/a.d A/b.d were two modules in package A. Especially given there is a module statement at the beginning of each module: A/a.d has module A.a; A/b.d has module A.b; Now A.b needs to access something from A.a. I had assumed that the import should be fully qualified. So in A.b.d: import A.a: thing; This all works when building the library. ldc2 -of=Build/Release/libdvbv5_d.so -shared -defaultlib=phobos2-ldc Build/Release/source/libdvbv5_d/linux_dmx.o Build/Release/source/libdvbv5_d/dvb_v5_std.o Build/Release/source/libdvbv5_d/dvb_frontend.o Build/Release/source/libdvbv5_d/dvb_log.o Build/Release/source/libdvbv5_d/dvb_demux.o Build/Release/source/libdvbv5_d/dvb_fe.o Build/Release/source/libdvbv5_d/dvb_file.o Build/Release/source/libdvbv5_d/dvb_scan.o Build/Release/source/libdvbv5_d/dvb_sat.o -L-ldruntime-ldc However when trying to build the unit-tests: ldc2 -I=source -unittest --main -of=Build/Test/libdvbv5_d source/libdvbv5_d/linux_dmx.d source/libdvbv5_d/dvb_v5_std.d source/libdvbv5_d/dvb_frontend.d source/libdvbv5_d/dvb_log.d source/libdvbv5_d/dvb_demux.d source/libdvbv5_d/dvb_fe.d source/libdvbv5_d/dvb_file.d source/libdvbv5_d/dvb_scan.d source/libdvbv5_d/dvb_sat.d source/libdvbv5_d/dvb_demux.d(35): Error: module linux_dmx from file source/libdvbv5_d/linux_dmx.d must be imported with 'import linux_dmx;' Am I just missing something simple? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Incomprehensible error message
On Monday, 19 March 2018 at 16:33:28 UTC, Russel Winder wrote: I have been staring at this message so long, I have clearly stopped actually reading it, hence outside assistance needed. So I would guess either there's two definitions of one of the types like maybe `dvb_v5_fe_parms` and the constructor uses one and your code uses another (may be the same struct defined in two different modules, where the definition imported one and you imported another - stupid compiler was (is?) liable to say "type A is not type A" when it should say "type foo.A is not bar.A"), or something like a stray const on the `this` pointer. I almost remember that A != A bug was fixed but maybe not in function call things, or maybe not pushed to your ldc version yet.
Incomprehensible error message
Hi, I have been staring at this message so long, I have clearly stopped actually reading it, hence outside assistance needed. Can someone please explain to me (probably in words of one syllable since I am clearly being very unintelligent) how any code can deliver an error message such as: ldc2 -I=. -g -gc -d-debug -I/home/users/russel/Built/include/d -of=Build/Release/dvb-tune source/main.d source/libdvbv5.d source/channels.d -L-ldvbv5 source/channels.d(161): Error: constructor libdvbv5.ScanHandler_Ptr.this (dvb_v5_fe_parms* frontendParameters, dvb_entry* entry, const(int) dmx_fd, extern (C) int function(void* args, dvb_v5_fe_parms* parms) check_frontend, const(uint) other_nit, const(uint) timeout_multiplier) is not callable using argument types (dvb_v5_fe_parms*, dvb_entry*, const(int), extern (C) int function(void* _arguments, dvb_v5_fe_parms* frontendParameters), const(uint), const(uint)) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Is there a way to pipeline program with random-access ranges in C#?
On Monday, 19 March 2018 at 11:35:46 UTC, Dukc wrote: This topic is technically in wrong place, since the problem is with C#, not D. But because what I'm asking is more idiomatic in D than elsewhere, I think I have the best changes to get understood here. So, I'm looking for some library, or technique, that allows me to chain range-evaluating commands like Phobos, but on C# or JavaScript. Either does, because I'm using Bridge.Net to compile C# to JavaScript, but I would prefer C# because of the type system. LinQ is otherwise just what I described, except that it can work only with input ranges that can be reseted to their initial state. That leads me to do a lot of for loops. In D I virtually never need them. I am wondering, does anybody know an alternative which can forward forwarding/bidirectional/random-access capability of source ranges too? Sorry, but I fail to understand your requirements. Do you have a practical example?
Re: Static library building
On Monday, 19 March 2018 at 14:31:05 UTC, Adam D. Ruppe wrote: On Monday, 19 March 2018 at 14:07:52 UTC, Vindex wrote: dmd main.d -L-L. -L-l:mod.a It still needs to know where to find the import file to get D information like names and types out of it that aren't in the lib (well they sorta are but not exactly, in any case it isn't implemented to try it now). So either still pass it mod.d there, which makes the library useless, or pass `-Isomething` where there's a `pack/mod.d` or `pack/mod.di` file with the function prototypes. dmd -H can make mod.di out of mod.d for you in some cases automatically. Thank you. Sorry, the library does not save the requested information.
Re: Static library building
On Monday, 19 March 2018 at 14:07:52 UTC, Vindex wrote: dmd main.d -L-L. -L-l:mod.a It still needs to know where to find the import file to get D information like names and types out of it that aren't in the lib (well they sorta are but not exactly, in any case it isn't implemented to try it now). So either still pass it mod.d there, which makes the library useless, or pass `-Isomething` where there's a `pack/mod.d` or `pack/mod.di` file with the function prototypes. dmd -H can make mod.di out of mod.d for you in some cases automatically.
Static library building
'main.d':
import pack.mod;
void main() {
fn("Hello");
}
'mod.d':
module pack.mod;
void fn(string s) {
import std.stdio;
writeln("Hello");
}
Both files are in the same directory.
So all is well:
dmd main.d mod.d
So all is bad:
dmd mod.d -lib
dmd main.d -L-L. -L-l:mod.a
main.d(1): Error: module mod is in file 'pack/mod.d' which cannot
be read
Please answer why it happens.
Re: RBTree delegates and types
On Monday, 19 March 2018 at 11:30:13 UTC, Steven Schveighoffer wrote: Yes, you need a `this` pointer for it to work. However, we can do this by encapsulating the return type with an auto function: https://run.dlang.io/is/inSzaU Sorry I didn't get this right away. Interesting chicken-and-egg problem, but as usual, D delivers :) -Steve That's beautiful! Thanks!
Re: Build an AliasSeq from memberFunction return types
I couldn't have wished for a better answer! Thank you so much, Simen.
Re: Does the compiler inline the predicate functions to std.algorithm.sort?
On Monday, 19 March 2018 at 12:45:58 UTC, tipdbmp wrote: (@tipdbmp: The string gets turned into the function _D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.) I see. It seems that ldc 1.8.0 with "-release -O2|3" inlines it, but dmd 2.079.0 with "-release" (no -O option?) does not. DMD has a -inline flag to enable inlining - though LDC is a lot better in optimization than DMD and thus typically used for anything performance related. the LLVM IR obtained with -output-ll might be easier to read than assembly.) I only seem to get assembly on d.godbolt.org, even with the -output-ll option. You can get IR on run.dlang.io by simply selecting LDC and hitting the IR button.
Re: Does the compiler inline the predicate functions to std.algorithm.sort?
(@tipdbmp: The string gets turned into the function _D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.) I see. It seems that ldc 1.8.0 with "-release -O2|3" inlines it, but dmd 2.079.0 with "-release" (no -O option?) does not. the LLVM IR obtained with -output-ll might be easier to read than assembly.) I only seem to get assembly on d.godbolt.org, even with the -output-ll option.
Is there a way to pipeline program with random-access ranges in C#?
This topic is technically in wrong place, since the problem is with C#, not D. But because what I'm asking is more idiomatic in D than elsewhere, I think I have the best changes to get understood here. So, I'm looking for some library, or technique, that allows me to chain range-evaluating commands like Phobos, but on C# or JavaScript. Either does, because I'm using Bridge.Net to compile C# to JavaScript, but I would prefer C# because of the type system. LinQ is otherwise just what I described, except that it can work only with input ranges that can be reseted to their initial state. That leads me to do a lot of for loops. In D I virtually never need them. I am wondering, does anybody know an alternative which can forward forwarding/bidirectional/random-access capability of source ranges too?
Re: RBTree delegates and types
On 3/19/18 5:16 AM, Viktor wrote: Hi Steve, thanks for replying! I've also noticed that RedBlackTree.opEquals() is like this from the initial pull request and was wondering if noone has been using a delegate and why... typically, you don't need a delegate, but generally, you CAN use a delegate as an alias "less" function. I don't see why it should be restricted here. But this is probably why nobody ever found it -- most people just use the default lambda. On the second topic, I've tried that and it doesn't work. I have a minimal test program that shows the issue. https://run.dlang.io/is/WNF78H Oh! I totally missed that comp is a member function (in your first example). I thought it was passed in. Sorry for not taking a closer look. Yes, you need a `this` pointer for it to work. However, we can do this by encapsulating the return type with an auto function: https://run.dlang.io/is/inSzaU Sorry I didn't get this right away. Interesting chicken-and-egg problem, but as usual, D delivers :) -Steve
dub default settings
I find myself typing over and over again the same things like '-a x86_64'. Is it somehow possible to set those defaults?
Re: RBTree delegates and types
On Sunday, 18 March 2018 at 17:21:58 UTC, Steven Schveighoffer
wrote:
On 3/18/18 8:34 AM, Viktor wrote:
Hey,
I'm trying to convert an old legacy app to D and have a couple
of questions. It has been a very fun weekend!
First, I could not make std.container.rbtree use a delegate
for a comparator. The docs say it should be possible, but I
got a weird error.
I tracked it down to RedBlackTreee.opEquals() using explicit
function when calling equals():
return equal!(function(Elem a, Elem b) => !_less(a,b) &&
!_less(b,a))(thisRange, thatRange);
When I removed the "function" things started compiling (I have
yet to test the code due to question #2 below). I've done a
dub -b unittest without issues so it might be OK.
So, the first...several questions are: do you think this
change is safe and should I raise an issue in the bugzilla or
do a PR for it on github?
Yes, seems like an oversight. RedBlackTree.opEquals was added
almost 6 years ago, and it's possible this wouldn't have worked
back then (https://github.com/dlang/phobos/pull/900)
Should it include a new unittest that makes sure rbtree can be
instantiated with a delegate?
Definitely. Thanks for thinking of this!
The other part I'm still struggling with is about auto types.
Can I store the rbtree type in the following class so it can
be used from another method?
class Indexer(T, alias pred)
{
alias RBType = RedBlackTree!(uint, (a, b) => comp(a, b));
this(T storage)
{
this.storage = storage;
this.index = new RBType();
}
void dumpIndex()
{
// how to get my dirty hands on the index here?
// answer: just use it?
}
bool comp(uint i1, uint i2)
{
auto rec1 = storage[i1];
auto rec2 = storage[i2];
return pred(rec1, rec2);
}
private T storage;
RBType index;
}
-Steve
Hi Steve, thanks for replying!
I've also noticed that RedBlackTree.opEquals() is like this from
the initial pull request and was wondering if noone has been
using a delegate and why...
On the second topic, I've tried that and it doesn't work. I have
a minimal test program that shows the issue.
https://run.dlang.io/is/WNF78H
onlineapp.d(15): Error: need this for less of type bool(int a,
int b)
onlineapp.d(15):instantiated from here: Generic!((a, b)
=> less(a, b))
If I try using an explicit delegate in the alias:
onlineapp.d(15): Error: delegate `onlineapp.Custom.__dgliteral6`
cannot be class members
onlineapp.d(15):instantiated from here: Generic!(delegate
(a, b) => less(a, b))
That seems reasonable to me, since the delegate needs a frame
(for the this pointer) and there is no frame at that point.
I think in the end I'll need to plant an interface that RBTree
will implement and use the interface instead.
The code in question:
class Generic(alias pred)
{
void add(int a, int b)
{
import std.stdio : writeln;
if (pred(a,b))
writeln(a);
else
writeln(b);
}
}
class Custom
{
alias MyGeneric = Generic!( (a,b) => less(a,b) );
private MyGeneric g;
this ()
{
g = new MyGeneric;
}
void test()
{
g.add(5, 6);
}
bool less(int a, int b)
{
import std.stdio : writeln;
writeln("Yup");
return a < b;
}
}
void main()
{
auto t = new Custom;
t.test;
}
Re: Should the "front" range primitive be "const" ?
On Friday, 2 February 2018 at 14:29:34 UTC, H. S. Teoh wrote: On Fri, Feb 02, 2018 at 07:06:56AM +, Simen Kjærås via Digitalmars-d-learn wrote: [...] Its semantics are not broken; it's just harder to use. Due to const transitivity, it's an all-or-nothing deal. .tailConst gives us the middle ground. [...] FWIW there's also head const in phobos since more than one year - known as Final: https://dlang.org/phobos/std_experimental_typecons.html
Re: Logging Function Parameters
On Sunday, 18 March 2018 at 23:17:58 UTC, Dennis wrote: On Sunday, 18 March 2018 at 22:57:15 UTC, aliak wrote: // But you get a: // Error: Using the result of a comma expression is not allowed // writeln(mixin(arguments!f)); You can't mix part of a function call in: "Mixed in text must form complete declarations, statements, or expressions." (https://dlang.org/articles/mixin.html) In this case, it evaluates to a comma expression, which is deprecated. If you put the "writeln();" inside the mixin string it should form a complete statement and compile. Ah! Thanks for the clarification.
Re: how to make private class member private
On Monday, 19 March 2018 at 01:11:43 UTC, psychoticRabbit wrote: The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class. I agree with this. This especially matters with projects where multiple people might work on the same module. You might not want to expose every member to all the people who work on the module. Whereas you might want other members to be exposed to the module and not outside, so the argument for putting the class into a new module doesn't work either, since the members you do want to expose cannot be exposed, unless they're public, in which case it defeats the whole purpose of encapsulation. Yes, it's great that private is module-level by default, but it just doesn't work in practice with modules worked on by multiple people. Tons of bugs can be avoided too, like a few times unittests have passed in phobos with traits because private members were visible in the module. (I can't remember a specific example on top of my head, but it has happened a few times.)
