What could this be?
I'm gotten stuck with this error - "..is not visible from module.."
Re: What could this be?
On Monday, 11 May 2020 at 11:20:51 UTC, Joel wrote: I'm gotten stuck with this error - "..is not visible from module.." Without some code it's hard to say exactly, but this generally means you're referencing a private symbol in a different module: module foo; private struct S {} module bar; import foo; foo.S s; // foo.S is not visible from module bar -- Simen
Bug?
Why doesn't it compile? ``` struct Range(R) { import std.array : empty, front, popFront; R range; bool empty() const { return range.empty; } auto front() const { return range.front; } void popFront() { range.popFront(); } } void main() { auto rng = Range!string("1234"); assert(rng.front == 1); } ``` onlineapp.d(11): Error: void has no value onlineapp.d(11): Error: incompatible types for (rng.front) == (1): void and int try here: https://run.dlang.io/is/Dg8Fpr If you move the import to the global scope, you will get a weird result: ``` import std.stdio; import std.array : empty, front, popFront; struct Range(R) { R range; bool empty() const { return range.empty; } auto front() const { return range.front; } void popFront() { range.popFront(); } } void main() { auto rng = Range!string("1234"); writefln("front: %s", rng.front); assert(rng.front == 1); } ``` front: 1 core.exception.AssertError@onlineapp.d(14): Assertion failure ??:? _d_assertp [0x56107489bc75] onlineapp.d:14 _Dmain [0x561074889902] try here: https://run.dlang.io/is/arieKR WAT???
Re: Bug?
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote: assert(rng.front == 1); Damn! I made a typo. It must be: assert(rng.front == '1') So the second example works fine.
Re: Bug?
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote: If you move the import to the global scope UFCS is only defined to work with global scope functions. A restricted import (module : symbol, symbols) puts things in local scope so ufcs doesn't apply. (interestingly an unrestricted import does NOT do that, it keeps the functions in their original scope, so UFCS works if you locally `import std.range;` but not if you `import std.range : front, popFront, empty;`! lol. but this is... im pretty sure by design, it has been this way for ages.)
Re: Bug?
And the first example still doesn't compile: ``` struct Range(R) { import std.array : empty, front, popFront; R range; bool empty() const { return range.empty; } auto front() const { return range.front; } void popFront() { range.popFront(); } } void main() { auto rng = Range!string("1234"); assert(rng.front == '1'); } ``` onlineapp.d(11): Error: void has no value onlineapp.d(11): Error: incompatible types for (rng.front) == ('1'): void and char ```
Re: Bug?
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote: UFCS is only defined to work with global scope functions. A restricted import (module : symbol, symbols) puts things in local scope so ufcs doesn't apply. But in this case the error should be displayed for lines 4 and 5, not 11. Line 11 contains a call to a member function, not UFCS. In addition, if you add the parentheses, then it works: assert(rng.front() == '1');
Re: Bug?
On 5/11/20 8:44 AM, Jack Applegame wrote: On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote: UFCS is only defined to work with global scope functions. A restricted import (module : symbol, symbols) puts things in local scope so ufcs doesn't apply. But in this case the error should be displayed for lines 4 and 5, not 11. Line 11 contains a call to a member function, not UFCS. In addition, if you add the parentheses, then it works: assert(rng.front() == '1'); Yeah, this is definitely a bug. If I change the return type of front to dchar from auto, it still thinks it's returning void. Calling things like popFront without parentheses has an error "rng.popFront has no effect". Clearly something isn't connecting properly, it's almost like it's resolving to the function itself instead of calling it. -Steve
Re: Bug?
On Monday, 11 May 2020 at 12:44:45 UTC, Jack Applegame wrote: On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote: UFCS is only defined to work with global scope functions. A restricted import (module : symbol, symbols) puts things in local scope so ufcs doesn't apply. But in this case the error should be displayed for lines 4 and 5, not 11. Line 11 contains a call to a member function, not UFCS. In addition, if you add the parentheses, then it works: assert(rng.front() == '1'); You're right, and it absolutely seems the call on lines 4 and 5 work correctly. Instead, the compiler is confused by the presence of two different overloads for front in Range!T, and doesn't attempt to call the one it can call. We get the exact same behavior here: struct S { int gun()(int i) { return 0; } alias fun = gun; int fun() { return 1; } } static assert(S().fun == 1); Filed here: https://issues.dlang.org/show_bug.cgi?id=20821 -- Simen
Re: Bug?
On Monday, 11 May 2020 at 13:12:37 UTC, Simen Kjærås wrote: Filed here: https://issues.dlang.org/show_bug.cgi?id=20821 Thanks.
Re: Bug?
On Monday, 11 May 2020 at 13:06:59 UTC, Steven Schveighoffer wrote: Clearly something isn't connecting properly, it's almost like it's resolving to the function itself instead of calling it. Since the imported front is also a local symbol the compiler probably thinks it is overloaded and not handling that right.
Dub and Unit_Threaded
This seems nonsensical to me. Why is Dub using the correct (0.10.8) version of Unit_Threaded for building the tests, but then using an earlier version (0.10.6) for building and running the test. If I remove 0.10.6 from the .dub/packages directory, then it uses 0.10.8 correctly. Then it complains about DFLAGS for reasons unknown. Yours Confused of Clapham Junciton. |> dub test Running custom 'unittest' configuration. Performing "unittest" build using /usr/bin/ldc2 for x86_64. gtk-d:gtkd 3.9.0: target for configuration "library" is up to date. unit-threaded:from 0.10.8: target for configuration "library" is up to date. unit-threaded:exception 0.10.8: building configuration "library"... unit-threaded:assertions 0.10.8: building configuration "library"... unit-threaded:integration 0.10.8: building configuration "library"... unit-threaded:mocks 0.10.8: building configuration "library"... unit-threaded:property 0.10.8: building configuration "default"... unit-threaded:runner 0.10.8: building configuration "library"... unit-threaded 0.10.8: building configuration "library"... arcamclient ~master: building configuration "unittest"... Running pre-build commands... Building package unit-threaded in /home/users/russel/.dub/packages/unit- threaded-0.10.6/unit-threaded/ Performing "$DFLAGS" build using /usr/bin/ldc2 for x86_64. unit-threaded:from 0.10.6: building configuration "library"... unit-threaded:exception 0.10.6: building configuration "library"... unit-threaded:assertions 0.10.6: building configuration "library"... unit-threaded:integration 0.10.6: building configuration "library"... unit-threaded:mocks 0.10.6: building configuration "library"... unit-threaded:property 0.10.6: building configuration "library"... unit-threaded:runner 0.10.6: building configuration "library"... unit-threaded 0.10.6: building configuration "gen_ut_main"... Linking... Running ../../../../../.dub/packages/unit-threaded-0.10.6/unit- threaded/gen_ut_main -f bin/ut.d -d /usr/bin/dub Building package arcamclient:mock_avr850 in /home/users/russel/Repositories/Git/Masters/Private/ArcamClient_D/ Performing "$DFLAGS" build using /usr/bin/ldc2 for x86_64. arcamclient:mock_avr850 ~master: building configuration "application"... Linking... Linking... To force a rebuild of up-to-date targets, run again with --force. Invalid variable: DFLAGS -- 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
D and Async I/O
OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this is a real server ;-) ). I think the normal response is "Use Vibe.d". However, recently I see Hunt is an alternative. Has anyone any way of choosing between the two? I notice that Hunt uses it's own library eschewing all of Phobos. Is this an indicator that Phobos is not suitable for networking activity? -- 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: GUI library for DMD 2.090 or DMD 2.091
On Mon, 2020-04-27 at 12:12 +, Antonio Corbi via Digitalmars-d-learn wrote: > On Monday, 27 April 2020 at 11:27:57 UTC, Paulo Pinto wrote: > > On Sunday, 26 April 2020 at 09:09:04 UTC, Antonio Corbi wrote: […] > > > I don't know if you are referring to the `clone!` macro > > > described here[1] > > > > > > [1] https://gtk-rs.org/blog/2019/12/15/new-release.html > > > > > > Antonio > > > > Hi, this macro is new to me, it did not exist when I tried to > > have a go at Gtk-rs, so it simplifies not having to write such > > boilerplate ourselves, but like the author mentions it doesn't > > make it go away, it just gets hidden behind the macro. > > Hi, > > Yes, previously this macro lived (in a simplified form, i.e. no > @strong) in the examples provided by the gtk-rs developers. Now > it's part of the gtk-rs bindings. I have not found any real need to use that clone! macro. I have found it straightforward, and easy, to clone the variables required so they can be moved. It also seems self-documenting, making the cloning obvious. -- 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: Integration tests
On Wed, 2020-04-22 at 11:19 +, aliak via Digitalmars-d-learn wrote: > On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: > > Now I discover Python, Rust, and Go have far nicer abstractions > > for writing Internet code than D does. Does D really not have a > > TcpListener abstraction? > > It really doesn't :( :-( Even GTK+ has it's own wrappers around the base socket API to make it sensible for programmers. GtkD offers these for GtkD-based applications, but D has no language support for asynchronous (via Futures/Promises/event loops) which leaves Rust (and Python) far ahead in this race to support asynchronous programming. > And D has so much potential as server tech with the potential > combination of fibers + TLS + shared + static introspection. Potential is necessary but not sufficient. Vibe.d seems to be one solution (in the Rust Async_std and Tokio sense) but Rust has language level support for Futures that make everything a lot easier in Rust than seemingly in D. > The package Vibe-d is quite nice though. I don't know if you've > tried it but it's very simple to get a listener up with it. And now it seems we have Hunt. I am now dithering whether to use Vibe.d or Hunt for my async TCP (but not HTTP(S)) server. […] -- 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: D and Async I/O
On Mon, May 11, 2020 at 4:03 PM Russel Winder via Digitalmars-d-learn wrote: > > ... > I notice that Hunt uses it's own library eschewing all of Phobos. Is this an > indicator that Phobos is not suitable for networking activity? Vibe-d do that too, But https://code.dlang.org/packages/async use phobos socket and works well
Re: D and Async I/O
On Mon, 2020-05-11 at 15:02 +0100, Russel Winder wrote: > OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this > is > a real server ;-) ). > > I think the normal response is "Use Vibe.d". However, recently I see Hunt is > an alternative. Has anyone any way of choosing between the two? > > I notice that Hunt uses it's own library eschewing all of Phobos. Is this an > indicator that Phobos is not suitable for networking activity? Of course the really obvious solution would be to use the GTK+ event loop and GtkD API binding even though the server has no UI since it is a server that is part of the integration tests for a GtkD realised GUI desktop application. -- 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: D and Async I/O
On Mon, 2020-05-11 at 16:36 +0200, Daniel Kozak via Digitalmars-d-learn wrote: > On Mon, May 11, 2020 at 4:03 PM Russel Winder via Digitalmars-d-learn > wrote: > > ... > > I notice that Hunt uses it's own library eschewing all of Phobos. Is this > > an > > indicator that Phobos is not suitable for networking activity? > Vibe-d do that too, But https://code.dlang.org/packages/async use > phobos socket and works well Crickey, a third option. This wil increase my dithering! ;-) -- 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: Integration tests
On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: I ended up creating the following project structure: . ├── dub.sdl ├── dub.selections.json ├── source │ ├── arcam_protocol.d │ └── main.d ├── tests │ └── integration_tests.d └── test_support └── mock_avr850 └── main.d with the following Dub control file: name "arcamclient" description "arcamclient is a Rust/gtk-rs/GTK+ desktop application to control an Arcam amplifier over the Ethernet connection." authors "Russel Winder" copyright "Copyright © 2020 Russel Winder." license "GPL-3.0" targetType "executable" targetPath "bin" configuration "application" { } configuration "unittest" { targetName "arcamclient_test" dependency "unit-threaded" version="*" mainSourceFile "bin/ut.d" excludedSourceFiles "source/main.d" preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f bin/ut.d -d $DUB" preBuildCommands "$DUB build arcamclient:mock_avr850" importPaths "tests" sourcePaths "tests" } subPackage { name "mock_avr850" targetName "mock_avr850" targetType "executable" targetPath "bin" sourcePaths "source" "test_support/mock_avr850" importPaths "source" "test_support/mock_avr850" excludedSourceFiles "source/main.d" } This seems a bit more sensible that what I have been able to achieve with Rust, but is still second rate compared to how easy things are using Python. Have you try Silly? I found far more straightforward to use, that unit-threaded. On my pet game engine, I got it working with this : "configurations": [ ... { "dependencies": { "beep": "~>0.0.2", "silly": "~>1.0.2" }, "name": "unittest", "targetType": "library" } ], Sadly, Silly only is the test runner (and one far prettier that unit-threaded). I need to add separated dub module to make assertion more easy and fluent. Beep go on the correct path with a API like this : @("My test") unittest { myFunc(1, 2, 3).expect!equals(42); auto a = [1, 2 ,3]; a.expect!contains(2); a.lenght.expect!great(0); true.expect!true(); } And the output on case of fail, shows a human friendly message with the expected value and the real value. Another assertion module that not depends on unit-threaded and have better API, is pyjamas . But actually is abandoned. I did a try to get it working again, but depends on another dead dub module... another test runner called "bed" (that I did a PR to fix it to get it working against the actual DMD version). Finally... What I really miss are two things : - A test/integration framework like Spock (Yeah, I professionally work on Java world :( ) - Test runners had a common output format that make IDE/tools work far more easy. See https://github.com/nomad-software/dunit/issues/19#issuecomment-435209223 Offtopic: Should be a way to mark a dub module dead on dub register. This last weeks I don't stop of finding dead/not working stuff and given a really bad image of the state of D.
Re: D and Async I/O
On Monday, 11 May 2020 at 14:02:54 UTC, Russel Winder wrote: OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this is a real server ;-) ). I think the normal response is "Use Vibe.d". However, recently I see Hunt is an alternative. Has anyone any way of choosing between the two? vibe.d is much more mature than Hunt, that would be my take on it. Also Hunt lacks documentation etc. I notice that Hunt uses it's own library eschewing all of Phobos. Is this an indicator that Phobos is not suitable for networking activity? std.socket is terrible, so yes that is an indicator. You can't even wrap something up fast in it either. Basically it's low-level while not being low-level at the same time. You have to handle __everything__ yourself pretty much.
Different visibility in template for class and struct?
Why is local struct visible in this outer template, while local class is not? https://wandbox.org/permlink/MfsDa68qgaMSIr4a https://dlang.org/spec/template.html#instantiation_scope --- enum p(T) = __traits(compiles, new T()); class GlobalC {} struct GlobalS {} void main() { class LocalC {} static assert(p!GlobalC); static assert(!p!LocalC); struct LocalS {} static assert(p!GlobalS); static assert(p!LocalS); // ?? }
Re: Different visibility in template for class and struct?
On 5/11/20 11:11 AM, Shigeki Karita wrote: Why is local struct visible in this outer template, while local class is not? https://wandbox.org/permlink/MfsDa68qgaMSIr4a https://dlang.org/spec/template.html#instantiation_scope --- enum p(T) = __traits(compiles, new T()); class GlobalC {} struct GlobalS {} void main() { class LocalC {} static assert(p!GlobalC); static assert(!p!LocalC); struct LocalS {} static assert(p!GlobalS); static assert(p!LocalS); // ?? } First, it actually does compile, I think because the compiler recognizes that LocalS is POD (plain old data), without methods, so it doesn't need a context pointer. e.g.: auto make(T)() { return new T(); } ... auto x = make!LocalS; // ok If you add a method to LocalS, then make!LocalS fails to compile. However, strangely, p!LocalS still returns true, I think that is an error. -Steve
Re: Different visibility in template for class and struct?
On Monday, 11 May 2020 at 15:29:53 UTC, Steven Schveighoffer wrote: On 5/11/20 11:11 AM, Shigeki Karita wrote: [...] First, it actually does compile, I think because the compiler recognizes that LocalS is POD (plain old data), without methods, so it doesn't need a context pointer. e.g.: auto make(T)() { return new T(); } ... auto x = make!LocalS; // ok If you add a method to LocalS, then make!LocalS fails to compile. However, strangely, p!LocalS still returns true, I think that is an error. -Steve Thanks for your answer. Now I understand that POD matters here. When I add a dtor: `struct LocalS { ~this() {} }`, the `p!LocalS` got false.
Re: Different visibility in template for class and struct?
On 5/11/20 11:40 AM, Shigeki Karita wrote: On Monday, 11 May 2020 at 15:29:53 UTC, Steven Schveighoffer wrote: On 5/11/20 11:11 AM, Shigeki Karita wrote: [...] First, it actually does compile, I think because the compiler recognizes that LocalS is POD (plain old data), without methods, so it doesn't need a context pointer. e.g.: auto make(T)() { return new T(); } ... auto x = make!LocalS; // ok If you add a method to LocalS, then make!LocalS fails to compile. However, strangely, p!LocalS still returns true, I think that is an error. Thanks for your answer. Now I understand that POD matters here. When I add a dtor: `struct LocalS { ~this() {} }`, the `p!LocalS` got false. There is still a bug though. if p!T returns true, but make!T doesn't compile, then something is inconsistent. -Steve
Re: D and Async I/O
On 2020-05-11 16:44, Russel Winder wrote: Crickey, a third option. This wil increase my dithering! ;-) Forth: Mecca [1] :) [1] https://github.com/weka-io/mecca -- /Jacob Carlborg
Re: Error running concurrent process and storing results in array
On 2020-05-07 02:17, data pulverizer wrote: What is the difference between -O2 and -O3 ldc2 compiler optimizations? `--help` says -O2 is "Good optimizations" and -O3 "Aggressive optimizations". Not very specific. -- /Jacob Carlborg
Re: Different visibility in template for class and struct?
On Monday, 11 May 2020 at 16:10:36 UTC, Steven Schveighoffer wrote: On 5/11/20 11:40 AM, Shigeki Karita wrote: On Monday, 11 May 2020 at 15:29:53 UTC, Steven Schveighoffer wrote: [...] Thanks for your answer. Now I understand that POD matters here. When I add a dtor: `struct LocalS { ~this() {} }`, the `p!LocalS` got false. There is still a bug though. if p!T returns true, but make!T doesn't compile, then something is inconsistent. -Steve I agree. This should be a bug https://wandbox.org/permlink/5YoKKt8xjdexzJHp
Re: How to port C++ std::is_reference to D ?
On Saturday, 9 May 2020 at 13:44:27 UTC, Per Nordlöw wrote: On Wednesday, 6 May 2020 at 17:46:28 UTC, Q. Schroll wrote: C++'s decision to make references part of the type has some advantages, but D didn't do it because of many disadvantages. Can you outline or give a link describing the advantages of C++'s vs D's choice in this matter? Whether something is an advantage is subjective at least in some sense. So whether you in particular consider something I'll list here an advantage is basically your choice. 1. You can have variables ("data members") of reference type in structs. (They work like head-const pointers; if D had head-const or at least head-const pointers, those would be practically the same, only that references cannot be null.) 2. Templates can manipulate ref-ness and so on by type building. Notably, I had trouble writing templates that handle non-copyable types correctly at ctfe. The reason was that implicit moving (moving of temporaries) is done entirely by the compiler, but manual moving (std.algorithm.mutation.move) does do stuff (it doesn't just trick the compiler into moving casting stuff to rvalue references). 3. You can have local variables that are references. While not really different from pointers, I think they look less scary than pointers. 4. Especially in casts, you can trick the compiler into doing things without the fear of generating unnecessary code (in C++, std::move and std::forward are mere casts that you could do yourself but look awkward). Potentially, I'm missing something. Personally, I think D did the right thing making references a storage class. You can see very early in learning C++ that references are only half-way type constructors: They are not fully composable. Normally, you can have arrays and pointers to any type, but in C++ you can't have pointers to / arrays of references.
Re: D and Async I/O
On Monday, 11 May 2020 at 17:34:41 UTC, Jacob Carlborg wrote: On 2020-05-11 16:44, Russel Winder wrote: Crickey, a third option. This wil increase my dithering! ;-) Forth: Mecca [1] :) [1] https://github.com/weka-io/mecca And probably more. At least I also have my async library for network IO. It would be nice to have well defined interface for async io. That will allow to choose and test different implementations.
Re: D and Async I/O
On 5/11/20 3:46 PM, ikod wrote: On Monday, 11 May 2020 at 17:34:41 UTC, Jacob Carlborg wrote: On 2020-05-11 16:44, Russel Winder wrote: Crickey, a third option. This wil increase my dithering! ;-) Forth: Mecca [1] :) [1] https://github.com/weka-io/mecca And probably more. At least I also have my async library for network IO. It would be nice to have well defined interface for async io. That will allow to choose and test different implementations. Part of the problem is the different APIs that async libraries use. Some use callbacks, some use fibers, maybe some async/await forms. std.io aims to provide a common interface for async and sync i/o, where you choose the driver at the beginning of your program. If written properly, it could be a nice way to test code with various drivers without having to change code. It would require a Fiber-based approach, however. I have not added an async driver (yet), but it's in my somewhat immediate plans to do so, as I want to start using this more (along with iopipe). Contributions would be welcome. https://github.com/MartinNowak/io -Steve
Re: D and Async I/O
On Monday, 11 May 2020 at 21:15:28 UTC, Steven Schveighoffer wrote: On 5/11/20 3:46 PM, ikod wrote: On Monday, 11 May 2020 at 17:34:41 UTC, Jacob Carlborg wrote: On 2020-05-11 16:44, Russel Winder wrote: Crickey, a third option. This wil increase my dithering! ;-) Forth: Mecca [1] :) [1] https://github.com/weka-io/mecca And probably more. At least I also have my async library for network IO. It would be nice to have well defined interface for async io. That will allow to choose and test different implementations. Part of the problem is the different APIs that async libraries use. Some use callbacks, some use fibers, maybe some async/await forms. callbacks are basic building blocks, which should be supported anyway. std.io aims to provide a common interface for async and sync i/o, where you choose the driver at the beginning of your program. If written properly, it could be a nice way to test My library also can work in this modes. There are low-level "sockets" which can be used only with callbacks, and also high-level sockets which can be used in "sync" mode in fibers or even without fibers as a replacement for std.socket's. Here is simple example where callback-based Timer used to build "sync" sleep: void Sleep(Duration d) { if ( d <= 0.seconds) { return; } auto f = Fiber.getThis(); if (f is null) { // called not from fiber/task, there is no concurrency, // use plain old sleep Thread.sleep(d); return; } // otherwise we yield and return to current fiber // later, when timer expires (using event loop) auto callback = delegate void (AppEvent e) { assert(e == TimeoutExpired); f.call(); }; auto t = new Timer(d, callback); getDefaultLoop().startTimer(t); Fiber.yield(); } code with various drivers without having to change code. It would require a Fiber-based approach, however. I have not added an async driver (yet), but it's in my somewhat immediate plans to do so, as I want to start using this more (along with iopipe). Contributions would be welcome. initially very few interfaces required - like start/stop for Timer, start/stop for SignalHandling, start/stop for file/socket poll. https://github.com/MartinNowak/io -Steve
Probably a trivial question regarding version identifier and unittest
I'm trying to study Adam Ruppe's terminal.d sub-package and I see the following code segment: version(demos) unittest { import arsd.terminal; void main() { // . . . } main; // exclude from docs } Looks like a good baby step to take, so in the command line I use: C:\dub\path\to\arsdpackage\arsd-official>dmd terminal.d -unittest -version=demos OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 134: No Start Address Shouldn't the version identifier demos and the unittest option activate the test block and therefore defines main() which then give the "Start Address"? Also, what is the isolated main; command right after the main function?
Re: Probably a trivial question regarding version identifier and unittest
On 5/11/20 9:54 PM, WhatMeWorry wrote: I'm trying to study Adam Ruppe's terminal.d sub-package and I see the following code segment: version(demos) unittest { import arsd.terminal; void main() { // . . . } main; // exclude from docs } Looks like a good baby step to take, so in the command line I use: C:\dub\path\to\arsdpackage\arsd-official>dmd terminal.d -unittest -version=demos OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 134: No Start Address Shouldn't the version identifier demos and the unittest option activate the test block and therefore defines main() which then give the "Start Address"? That is not a global main, it is inside a unittest block. A unittest block is actually a function. So the main there is a nested function, and not the one that D declares as the entry point. Also, what is the isolated main; command right after the main function? It's calling the inner function. But I'm sure you would realize that if you knew that it's not the true main function. -Steve
Re: Probably a trivial question regarding version identifier and unittest
On Tuesday, 12 May 2020 at 01:54:49 UTC, WhatMeWorry wrote: version(demos) unittest { import arsd.terminal; void main() Shouldn't the version identifier demos and the unittest option activate the test block and therefore defines main() which then give the "Start Address"? The unittest {} block is actually a special syntax for a function. So the main function in here is a *nested* function inside the unittest function and thus doesn't count as a starting point. It is like if you defined void MyTest() { void main() {} } The main there is a nested local helper function and thus wouldn't count as a start point either. Also, what is the isolated main; command right after the main function? That's just calling the defined child function so it actually gets executed. (I didn't put the parens there, but you could: `main();`, to make it clear it is just calling the function. You can compile and run the tests btw with the command line: dmd terminal.d -unittest -version=demos -main the -main option at the end tells the compiler to add an empty main() function at top-level for you to satisfy the linker. The reason I wrote it all this way is for the documentation. Look here for an example of how it looks when it is rendered: http://dpldocs.info/experimental-docs/arsd.terminal.html#color The documentation version there is a complete function my readers can copy/paste in their own files to use as a starting point. (the "// exclude from docs" comment is actually recognized by my doc generator to skip that line, see: http://dpldocs.info/experimental-docs/adrdox.syntax.html#documented-unittests which lets me tweak the user-visible output while still keeping it machine-checked internally too.) Now, why is it in a unittest block? Because then the samples are easier for me to compile and run as a batch to help me make sure they still work. (This isn't exactly perfect - since they are still defined in the module, they can see private members and imports, so it is still possible it will work for me but not for my readers. But it makes it less likely to it that problem.) Lastly, why is it in a demos block? That's just because normal unit tests are not supposed to be interactive and these are (interactive things make better doc samples). So the version block makes sure they are not run accidentally like by a user doing `dub test` at an outer layer. You have to opt into running these blocks by adding the version flag to the build too. You can really see this in simpledisplay.d's docs that have full sample games you can copy/paste and tweak! http://dpldocs.info/experimental-docs/arsd.simpledisplay.html#pong source: http://dpldocs.info/experimental-docs/source/arsd.simpledisplay.d.html#L492 except yikes I forgot to put the version thing there! so someone dub testing simpledisplay will have to play through a round of pong and minesweeper to pass the tests :P lol
Get unknown symbol (struct, method, class) tagged with User Defined Attributes
I've seen a lot of examples of how to get a list of User Defined Attributes from a known symbol but I haven't seen any for how to get a list of symbols when only the UDA is known. The use case is the same as seen in Rust with Serde[1]. Library users annotate a struct to mark it for serialization. In Java and Spring, you can mark a method with @Secured to add authorization to an endpoint[2]. In both of these cases, you have no idea which symbol the UDA will be applied to. So far I've only seen a way to get unknown UDAs from known symbols but not how to get unknown symbols from UDAs. Is there any documentation for how to get a list of symbols annotated with a specific UDA? 1: Serde: https://github.com/serde-rs/json 2: Spring: https://www.baeldung.com/spring-security-method-security
Re: Get unknown symbol (struct, method, class) tagged with User Defined Attributes
On Tuesday, 12 May 2020 at 02:51:39 UTC, Doug wrote: So far I've only seen a way to get unknown UDAs from known symbols but not how to get unknown symbols from UDAs. Is there any documentation for how to get a list of symbols annotated with a specific UDA? see std.traits.getSymbolsByUDA http://dpldocs.info/experimental-docs/std.traits.getSymbolsByUDA.html there's some caveats, like it only searches one particular parent symbol for its children (that's because the way this works is you reflect through children checking each symbol child's uda list to see if it is present) but it basically works for many things at least contained per-module. you can pass each module you care about in though to generate a more full list
Re: What could this be?
On Monday, 11 May 2020 at 11:37:40 UTC, Simen Kjærås wrote: On Monday, 11 May 2020 at 11:20:51 UTC, Joel wrote: I'm gotten stuck with this error - "..is not visible from module.." Without some code it's hard to say exactly, but this generally means you're referencing a private symbol in a different module: module foo; private struct S {} module bar; import foo; foo.S s; // foo.S is not visible from module bar -- Simen Thanks Simen.
Re: Get unknown symbol (struct, method, class) tagged with User Defined Attributes
On Tuesday, 12 May 2020 at 02:53:53 UTC, Adam D. Ruppe wrote: see std.traits.getSymbolsByUDA Thanks for the link. I did see that one. But that function searches within known symbols. My use case if for a library that's used outside of my application. In that case, I wouldn't know which symbol a library applies an annotation to. This is why I asked for how to get a list of unknown symbols from a known UDA. To use a REST frame work as an example, I would supply a @GET annotation and a user would apply that annotation to a handler method. I wouldn't know the method or module in advanced so I wouldn't know which symbol to pass to "getSymbolsByUDA" of any of it's sibling functions. I'm curious to see what I'd be able to do if this is possible.
Re: Probably a trivial question regarding version identifier and unittest
On Tuesday, 12 May 2020 at 02:17:36 UTC, Adam D. Ruppe wrote: On Tuesday, 12 May 2020 at 01:54:49 UTC, WhatMeWorry wrote: [...] The unittest {} block is actually a special syntax for a function. So the main function in here is a *nested* function inside the unittest function and thus doesn't count as a starting point. It is like if you defined [...] This is gold! I've been poking around and reading for days, but you've gotten me further with just a few paragraphs. Cant thank you enough.
Re: Get unknown symbol (struct, method, class) tagged with User Defined Attributes
On 5/11/20 11:30 PM, Doug wrote: On Tuesday, 12 May 2020 at 02:53:53 UTC, Adam D. Ruppe wrote: see std.traits.getSymbolsByUDA Thanks for the link. I did see that one. But that function searches within known symbols. My use case if for a library that's used outside of my application. In that case, I wouldn't know which symbol a library applies an annotation to. This is why I asked for how to get a list of unknown symbols from a known UDA. To use a REST frame work as an example, I would supply a @GET annotation and a user would apply that annotation to a handler method. I wouldn't know the method or module in advanced so I wouldn't know which symbol to pass to "getSymbolsByUDA" of any of it's sibling functions. I'm curious to see what I'd be able to do if this is possible. So the idea is that you know the parent symbol. In the case of serialization/deserialization, you give an instance of a type to serialize or deserialize. Then the library can search the symbols inside that type to see if any has the UDA you are looking for. In the Rust example, there is a line of code: let p: Person = serde_json::from_str(data)?; I'm assuming that this conversion is detected and figured out (i.e. this is how serde "finds" the type desired). For D, it would look something like: auto p = serde_json.from_str!Person(data); If you want a list of ALL symbols that have the UDA in the application, that would require some form of runtime reflection (like Java). D has very limited support for runtime reflection. In D, you would use some form of registration to tell the system about your symbols. -Steve