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
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 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: 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: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
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: 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
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
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: 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
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 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: 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: 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: 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: 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: 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: 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: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
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: 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.
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 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: 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, 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: 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: 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
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
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
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.
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 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 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: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 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: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.
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: 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
What could this be?
I'm gotten stuck with this error - "..is not visible from module.."
