Re: std.logger issue
On Thursday, 26 January 2023 at 20:08:51 UTC, Krzysztof Jajeśnica wrote: On Thursday, 26 January 2023 at 17:17:28 UTC, o3o wrote: how can I enable `trace` level? Set `sharedLog.logLevel` instead of `globalLogLevel`. ```d // Note: the cast is needed because sharedLog is shared (cast()sharedLog).logLevel = LogLevel.all; ``` Explanation: logging functions (`trace`, `log`, etc.) called without a logger perform the logging using a global logger called `sharedLog`. `sharedLog` uses `LogLevel.info` by default, which is why your trace messages were not showing. Thank you very much Krzysztof, it works.
std.logger issue
``` // rdmd --main -unitest app.d import std.stdio; import std.logger; unittest { globalLogLevel = LogLevel.all; infof("g: %s", globalLogLevel); trace("trace"); // NO output! info("info"); warning("warn"); error("error"); } ``` output is: ``` 2023-01-26T18:16:13.546 [info] log.d:6:main g: all 2023-01-26T18:16:13.546 [info] log.d:8:main info 2023-01-26T18:16:13.546 [warning] log.d:9:main warn 2023-01-26T18:16:13.546 [error] log.d:10:main error ``` how can I enable `trace` level? Thank
Re: vibe.d community/forum/whatever ?
On Monday, 23 January 2023 at 01:51:41 UTC, Rey Valeza wrote: On Monday, 30 August 2021 at 02:39:06 UTC, someone wrote: https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ I've been reading vibe.d tour and some documentation today to get some first impressions. https://vibed.org/community pointed to the link above ... but it seems it is full of crap. Hi, I just uploaded to Github a second edition of the tutorial I wrote last year: https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibed%20second%20edition.pdf Hope this helps. maybe is https://github.com/reyvaleza/vibed/blob/main/BuildWebAppsinVibe.pdf thank you
Looking for MQTT client library
I'm looking a MQTT [0] client library written in D, if it exists. Anyone know of any? I found the great Atila Neves MQTT broker (server) [1], and some C/C++ libraries [2], so, possible solutions are: a. Write a native D library from scratch b. Adapt/copy some parts of [1] to convert from server to client c. Create a binding from [2] Anyone has other idea that I could use to create this myself? Thanks [0]http://mqtt.org/ [1]https://github.com/atilaneves/mqtt [2]http://www.eclipse.org/paho/clients/c/
Re: How to translate C# 'readonly' keyword into D
On Monday, 4 February 2013 at 10:26:55 UTC, simendsjo wrote: [cut] So.. Every method you call through a const instance must also be const, otherwise you have the ability to change something that should be a constant. Thanks simendsjo, now I get it... So, let me continue the example (I remove "const" for simplicity)... I would like check that bar.gun() call fun() function from IFoo unittest { auto foo = new Mock(); //Will not compile.Mock doesn't (yet) exist auto bar = new Bar(foo); bar.gun(); foo.Received().fun(); // pass if 'fun' was called } void main() {} In other words, I need a mock object like nsubstitute (http://nsubstitute.github.com/help/getting-started/) or moq (http://code.google.com/p/moq/) In your old post http://forum.dlang.org/thread/il29hs$2svt$1...@digitalmars.com you were asking for mocking frameworks...do you found any solution? Thanks
How to translate C# 'readonly' keyword into D
I'm a C# programmer, when I apply IoC pattern I use "readonly" keyword (http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.71%29.aspx) in this manner: :// C# code :interface IFoo { : void Fun(); :} : :class Foo: IFoo { : void Fun() {...} :} :class Bar { : private readonly IFoo foo; : // inject IFoo into Bar : Bar(IFoo foo) { :// assert(foo != null); :this.foo = foo; : } : void Gun() { :// foo = new Foo(); ERROR: foo is readonly! :foo.Fun(); : } :} Can someone help me to translate "readonly IFoo foo;" so that the dmd compiler raises an error when I write "foo = new Foo();" ? I try: :// D code :interface IFoo { : void fun(); :} : :class Foo: IFoo { : void fun() { : writeln("fun..."); : } :} : :class Bar { : private const IFoo service; : this(const IFoo service) { : this.service = service; : } : : void gun() { : service.fun(); : } :} :unittest { : const(IFoo) s = new Foo; : auto bar = new Bar(s); : bar.gun(); :} but the compiler complains: Error: function main.IFoo.fun () is not callable using argument types () const
Re: Strategy to link/include library
It's very useful to me ,,,thank you Jacob,
Re: Strategy to link/include library
On Wednesday, 16 January 2013 at 12:00:54 UTC, Jacob Carlborg wrote: Thanks for your prompt response. [cut] You usually place it in a common directory. You then use the -I switch to make the compiler aware of this directory. Let me play with some scenario: I've a library 'acme' release 1.0 and two client C1 and C2. * scenario 1: acme in common directory + acme ... + C1 ... + C2 ... So, in C1 $dms -I../acme *.d and in C2 $dms -I../acme *.d suppose that C2 need a new feature from acme library, so I modify and recompile acme sources and I get the new acme rel. 2.0. But C1 still uses the old release 1.0, and if I recompile C1 it is linked to new new acme rel. 2.0... * scenario 2: acme in subdirectory If I include acme as subdirectory like this: + C1 ... + acme + C2 ... + acme I resolve the problem on scenario 1. (C1 uses rel. 1.0 and C2 rel. 2.0) but if I fix a bug in acme, I should update C1, C2 and all other clients that use acme. What do you think? what is your way of working? Ideally this should be handled by a package manager and a build tool. which package manager do you suggest? (of course orbit :) ), and which build tool (I use rake)? Thank you very much
Strategy to link/include library
Suppose I have the following library structure (from Andrei Alexandrescu 'The D Programming Language' pag. 352) acme ├── algebra.d └── io └── file.d // acme/algebra.d module algebra; import std.stdio; public void gun() { writeln("algebra->gun"); } // acme/io/file.d import std.stdio; public void fun() { writeln("file->fun"); } and suppose I want to use it in this client acmeClient ├── acme.a └── client.d // acmeClient/client.d import std.stdio; import algebra; import io.file; void main(string[] args) { algebra.gun(); gun(); fun(); } I want link acme.a to my client, so Andrei wrote: - The syntax for building a library depends on the implementation; on the reference implementation, you’d do something like this: % cd /path/to/acme_impl % dmd -lib -ofacme algebra.d gui.d io/file.d io/network.d The switch -lib instructs the compiler to build a library, and the switch -of (“output file”) directs the output to a file called acme.lib (Windows) or acme.a (various Unix-derived systems). With that library in tow, all you have to do now to get client code running is something like % dmd client.d acme.lib - So I write (in acme) $ cd acme $ dmd -lib -ofacme algebra.d io/file.d in acmeClient $ cd ../acmeClient $ cp ../acme/acme.a . $ dmd client.d acme.a -ofclient app.d(2): Error: module algebra is in file 'algebra.d' which cannot be read instead if I write $ dmd -I../acme acme.a app.d it works. So, if I want to use acme library in my client project I need to know the entire acme source code. is that correct? Is there an easier way? I am a C# programmer and with Mono dmcs compiler I can do: (in acme) $ dmcs -out:acme.a -target:library *.cs (in acmeClient) $ cp ../acme/acme.a . $ dmcs -out:client -target:exe -reference:acme.a *.cs (..to be honest it easy because mono assembly contains metadata and reference options imports that metadata) So, if I use "Module Summaries" (pag 350 Andrei's book), $ cd acme $ dmd -lib -H doitall.d doitall.di and doitall.d are identical (except for comments). Is there any "pattern" to use "shared" code inside a project? (i.e. manually copy all acme source in a client subdirectory, use git subtree, etc.)