Re: DDoc generation
On Fri, 2020-09-18 at 20:22 -0400, James Blachly via Digitalmars-d-learn wrote: > On 9/18/20 9:35 AM, Russel Winder wrote: > > On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via Digitalmars-d- > > learn wrote: > > > > […] > > > it ddoc files, and compile those along with your > > > application. > > > > > > https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation > > > > > > > Any small project examples anywhere? > > > > I am also learning about ddoc generation (something that IMO could stand > to be much better , ahem, documented). A nice example I've found is the > libmir site: > > https://www.libmir.org/ > http://mir-algorithm.libmir.org/ (mir-core., mir-random., etc.) > > and its documentation generation infrastructure: > > https://github.com/libmir/circle-dlang Yikes. Maybe it is just a first sight thing, but if that is what is needed to handle Mir, maybe I should try and make Doxygen work for my D projects – though doxygen only works "to some extent D". -- 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: DDoc generation
On Sat, 2020-09-19 at 08:12 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-09-18 13:41, Russel Winder wrote: > > Hi, > > > > I am trying to get to grips with DDoc for documenting an application. > > Getting > > the individual module HTML files seems to be the easy bit. The question is > > how > > to get an index.html (or equivalent) so as to have an application level > > entry > > point to the generated documentation. > > There's no built-in support for that. You might want to look at some > other doc generating tool if those support that. Doesn't that then make the whole DDoc system fairly useless, despite it's use in Phobos? -- 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: DDoc generation
On Fri, 2020-09-18 at 09:02 -0400, Steven Schveighoffer via Digitalmars-d- learn wrote: […] > > it ddoc files, and compile those along with your > application. > > https://dlang.org/spec/ddoc.html#using_ddoc_for_other_documentation > Any small project examples anywhere? -- 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
DDoc generation
Hi, I am trying to get to grips with DDoc for documenting an application. Getting the individual module HTML files seems to be the easy bit. The question is how to get an index.html (or equivalent) so as to have an application level entry point to the generated documentation. -- 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
DDoc Web page
I see that: https://dlang.org/spec/ddoc.html refers to: https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/index.html which is really rather ancient and definitely out of date. Should change this to: https://docs.oracle.com/en/java/javase/15/javadoc/index.html -- 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: Dlang: The Complete D programming Language Course
On Thu, 2020-07-23 at 14:39 +, Greatsam4sure via Digitalmars-d-announce wrote: > On Thursday, 23 July 2020 at 01:13:25 UTC, aberba wrote: > > Found this introductory course from Udemy on D > > > > > > Complete introduction to programming in D. Learn by doing > > assignments and projects. > > https://www.udemy.com/course/d-programming-language/ > > > This is lovely. How, wish this training is free. Wouldn't it be nice if all programmers wrote all programs for free. -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Thu, 2020-07-02 at 13:28 +, Abdulhaq via Digitalmars-d-announce wrote: > […] > Herb Sutter is a national treasure, C++ has become bearable, nay > even useful, under his stewardship and that is really saying > something s/national/international/ Herb's closing keynote at ACCU 2017 was a joy to be in, even as a C++ disliker. The energy he generated in the mostly pro-C++ audience was astounding. https://www.youtube.com/watch?v=6nsyX37nsRs=PL9hrFapz4dsMQuBQTnHXogJpMj6L_EQ10 I should add the questions went on for over an hour after the talk. I only brought it to an end so that people could go home – and the hotel and A/V staff could clear up. Even then Herb was another 20 or 30 minutes answering further questions as the room around them was disassembled. -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Thu, 2020-07-02 at 18:22 +, Dibyendu Majumdar via Digitalmars-d- announce wrote: […] > So why was Java successful? It was not compatible with an > existing language. Java has a weird history compared to other languages. It switched from white goods programming language to browser programming language just at the moment a large number of academics world wide were getting dissatisfied with Pascal/C/C++/Scheme/Miranda/OCaml as the set of languages to choose from to teach first year programming. It very rapidly failed as a browser language, but switched wonderfully quickly to be a virtual machine based general programming language. Timing is everything here… a large number of academic jumped on the Java bandwagon, so a large number of undergraduates were forced to learn it. There was a period in late 1990s and early 2000s when every CS graduate knew Java, and, to the eternal shame of academics, no other programming language. The second part of the success, at least in London, was the dissatisfaction of many in the finance industry with Smalltalk. They saw Java, and the number of Java programmers being produced by academic and switched to Java. The rest, as they say, is history. > Neither Rust nor Go are compatible with C++. > Rust, D and Go are all compatible with C in some sense. C is the portable assembly language of computing, any high level programming language that cannot use C APIs is a dead language. > Basically Herb is claiming to succeed a language must be able to > be a drop in replacement for C++ in a mix-match way. I think it > is a fallacy. Herb does have a (not exactly) hidden agenda that C++ is the one true programming language. > There is no single recipe that will make a language successful. Very true. -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Mon, 2020-06-29 at 15:45 +, Dagmar via Digitalmars-d-announce wrote: > On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote: > > Of course C++ is now really a niche language used by those who > > still use it and do not move on to more modern languages! > > I am a C++ developer. I do want to move to a modern language, but > there is no one that fits my needs. So stick with C++? Changing language is not always the right choice. But it is a very context dependent decision. > Rust has a very promising ownership-borrowing concept but the > lack of OOP and its awful syntax (mostly because of lifetimes) > make it a no go for me. In the classic terminology, Rust is object based not object oriented. The question is whether inheritance is crucial for the application. Clearly inheritance is crucial to GTK, so the gtk-rs folk have created an inheritance system in Rust. In my experience, unless you are writing a library type, if your code has lifetime variables then "you are doing it wrong". As soon as I stopped trying to use any lifetime variables in my Rust applications it all got a lot easier. Of course for library code that has to worry about lifetimes, they are needed. > Go is just an oversimplified language. No generics/teplates in > 2020, seriously? Actually the Go core team are very serious about not having generics in Go. Despite the plethora of proposals, none have really made it. I do wonder if often the objections to a proposal are more along the lines of "we didn't think of that so it is not going in". I think there will eventually be generics in Go, but I have no idea when. To be open, I have stopped using Go. Not so much because of the language, but because the GTK and GStreamer bindings are somewhat second rate. > D has a GC. If you turn it off you lose dynamic/associative > arrays, classes, probably something else. Why would I even want > to use such language at all? It's much easier to stay with C++ > this way, since it has lots of C/C++ libraries, IDEs, tools, > broad community, support of big companies. Or use Rust. ;-) […] > C++20 is a big improvement at least because of concepts, > coroutines, and ranges. I can't say I will be tempted back to C++, the GTK and GStreamer bindings are a bit second rate. Having got into D and Rust for doing my desktop applications, I am not going back. […] -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Mon, 2020-06-29 at 15:44 +, Patrick Schluter via Digitalmars-d-announce wrote: > […] > And that is completely wrong headed. Internet is not always > directly accessible. There are a lot of companies that restrict > access to the Internet for their security sensible servers, > […] > No, Internet is not always as easy peasy and having a language > that can live alone and provide quite a lot of features without > always calling home is a good thing. > […] So that is Java out then as a language to use for corporate software development activity. Way back when I was running a company or two, I put in place "you can't access the internet directly for dependencies" system, more to lower bandwidth use than security it has to be said. So we bought another disc and mirrored the repository – but not slavishly, just the bits we needed and with various scans and tests to try and stop any rogue software. This seemed to be the standard sort of behaviour back then. Perhaps this is not what happens now? -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Mon, 2020-06-29 at 20:41 +, Paulo Pinto via Digitalmars-d-announce wrote: […] > > Rust has only standardized part of the async/await story, the > asynchronous > runtime is not part of the standard library, so currently it is > impossible to write code that works flawlessly across the > existing runtimes. […] Actually this is a good thing in that I can write Rust async/await code and have it run on the GTK event loop. Here we have a case of multiple vendor implementations of a single standard interface. The problems tend to be in the implementations of the event loops not the bit that is effectively (de facto rather than de jure) standardised. […] > The typical scenarios where we would use GPGPU shaders, iDevices, > Android and Windows drivers, Arduino, SYCL, DPC++, Unreal, > XBox/PS/Switch SDKs, ... Not my area, but my guess is that there is sufficient pre-existing code base that it is not feasible to switch languages, staying with the languages of the pre-existing codebase is the sensible thing to do unless someone comes along with a big pot of money. […] > Java has a standard to guide for, updated for each language > release. > > So it doesn't need to be ISO, can be ECMA, or some other formal > writen specification, with multiple vendor implementations. Java is really standardised by the implementaion of OpenJDK. There is no standard agreed by any formal body other than the JCP executive committee. There are three maybe four implementations, the one everyone uses, and the other you have to pay for. -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Mon, 2020-06-29 at 12:41 +, Paulo Pinto via Digitalmars-d-announce wrote: […] > > Concepts, coroutines, and modules are already in ISO C++20. Only once the standard is voted in. :-) Also ranges are in I believe. > And co-routines are in a much better story than the incompatible > runtimes currently existing for Rust async/await story. I have not used C++ co-routines, but having used Rust co-routines, they seem fine. You need to make good on your negative criticism – which I would like to hear. > Rust still needs to improve a lot on its tooling and ecosystem to > cover many of the scenarios we use C++ for, even if is safer. I can believe that may be true for others, but for me JetBrains CLion, Rustup, and Cargo make for an excellent environment. crates.io works very well – better than CLion, CMake, and lots of manual hacking around to get libraries for C++. > Already the fact that it lacks an ISO standard is a no go in many > domains. That is a choice for those organisations. I am guessing those organisations do not use Java, D, Python, etc. > I guess you mean using Python as glue for GPGU libraries written > in C++. In C, but yes. Though I haven't done it in a while now. -- 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: Talk by Herb Sutter: Bridge to NewThingia
On Mon, 2020-06-29 at 10:31 +, IGotD- via Digitalmars-d-announce wrote: > […] > Back to C++20 and beyond which Herb Sutter refers to a lot. Is > C++20 a success, or even C++17? Does anyone know this? Modern C++ > isn't a programming standard so what I've seen is just a mix of > everything. I guess the question is whether concepts, coroutines, and modules finally make it in. The really interesting question is whether metaclasses make C++23. Of course C++ is now really a niche language used by those who still use it and do not move on to more modern languages! > I have lost track of all new C++ features and now he even refers > it as "NewLang" what that is. Is that Bjarnes famous quote > "Within C++, there is a much smaller and clearer language > struggling to get out."? I believe it when I see it. The problem is backward compatibility. Every new feature in C++ requires backward compatibility with all previous C++, leading to a more and more complex language. Fortran has the same problem but easier to cope with as it is a simpler language. Languages without standards do not have this problem. Except when language developers introduce breaking changes and a section of the user population screams "we must have backward compatibility". What they mean really is that they do not want to maintain their code. The Java folk showed how this pans out: eventually companies that will not deal with breaking changes go bust and are no longer a problem. I am sure this will be seen as a rant and a troll, but that doesn't stop it also being true. > One thing that isn't mention that is very important for a > language to succeed is libraries. C++ has a lack of standard > libraries which forces the programmer to look for third party > alternatives, which are of varying standard. This leads to that > the there is no particular programming API standard it must > gravitate to the lowest common denominator. This in contrast to > Phobos which is more complete. Another rant… …batteries included standard libraries are a thing of the 1990s and earlier. They are a reflection of pre-Internet thinking. You got a language distribution, and everything else was home grown. Now we have the Internet you can get libraries via download. Languages come with the minimal library needed to function and all else is gettable. Go, Rust, Python, and other languages have this (even though Python still has a batteries included standard library). C++ has moved on to this idea; Conan (or other system) hasn't really caught on in C++ circles. Ditto Fortran, still using pre-2000 thinking. D is in a similar position to Python, a huge batteries included standard library much of which should be culled, or at lease marked as deprecated, and has an central package repository for people to use. Rust, Go, and Python, show the way here. Libraries can spring up, evolve, die off, all controlled by usefulness to the user population. C++ people's focus on "the standard" seems to be stopping them doing good things. > Does C++ need more language features or does C++ need better > standard libraries? I would say the latter. If it weren't for Qt, > C++ would just be a skeleton language. Qt is a great library and > was that even before C++11 which proves that the new language > features weren't that important. > > What do you think, did "modern C++" really succeed? Clearly Modern C++, aka C++11, was a great innovation and step forward. C++14, C++17, and I guess C++20 move the language forward. On the other hand people are stopping using C++ in favour of Go, Rust, Python, but it seems not D. -- 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: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 13:21 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-06-07 11:24, Russel Winder wrote: > > Hi, > > > > Why on earth is Dub sending out this error message (Invalid variable: DUB) > > on > > GitLab but not on Travis-CI or locally? > > > > OK, that was slightly rhetorical, more reasonably, why is dub sending out > > this > > message at all? > > Dub is supposed to make an environment variable named "DUB" available to > the build script. It should contain the path to the Dub executable. I > guess that somehow fails. Might be some unexpected character in the path? I guess dub 1.19 is just too old. I have to manually set "export DUB=/usr/bin/dub". -- 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: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 10:30 +, Basile B. via Digitalmars-d-learn wrote: […] > What is the docker image that you use ? If it is an older > version maybe that the $DUB env variable is not yet supported by > the dub version that's installed (it exists since 2.084.0 > according to [1]). I am using ubuntu:focal. ubuntu:bionic has ldc 1.8 which is far too old. Focal has ldc 1.20. I think the dub version is 1.19. I am having to manually symbolically link /usr/bin/gcc and /usr/bin/cc so I suspect the installation of focal is not going quite right. Especially as I have to manually set a TZ variable to avoid a lock up. > In my .gitalab-ci.yml I use 'dlang2/ldc-ubuntu' [2] or > 'dlang2/dmd-ubuntu' [3] which give always recent versions of D. > > [1] https://dlang.org/changelog/2.084.0.html > [2] https://hub.docker.com/r/dlang2/ldc-ubuntu > [3] https://hub.docker.com/r/dlang2/dmd-ubuntu I shall have to investigate these docker images in favour of working with a bare Ubuntu. -- 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
Travis-CI and testing D builds
Hi, The Travis-CI D language image for dist bionic still seems to be build on Xenial. Is this as it should be? -- 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: Dub Error Message "Invalid variable: DUB"
On Sun, 2020-06-07 at 10:24 +0100, Russel Winder wrote: > Hi, > > Why on earth is Dub sending out this error message (Invalid variable: DUB) > on > GitLab but not on Travis-CI or locally? > > OK, that was slightly rhetorical, more reasonably, why is dub sending out > this > message at all? I am assuming that the error comes from the line: preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f generated/ut_dub_main.d -d $DUB" in the unittest configuration as suggested for using unit-threaded. The question is why does the symbol DUB not need to be defined locally or on Travis-CI, but only on GitLab? |> printenv | grep -i dub |> On Travis-CI and locally Dub find where it is, why does it not do this on GitLab? It is at /usr/bin/dub in all cases. -- 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 Error Message "Invalid variable: DUB"
Hi, Why on earth is Dub sending out this error message (Invalid variable: DUB) on GitLab but not on Travis-CI or locally? OK, that was slightly rhetorical, more reasonably, why is dub sending out this message at all? -- 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: unit-threaded v1.0.0
On Mon, 2020-06-01 at 08:41 +, Atila Neves via Digitalmars-d-announce
wrote:
[…]
> Out of curiosity, what is the difference for you between:
>
> testFoo() { /* ... */ }
>
> and:
>
> @("foo")
> unittest { /* ... */ }
Primarily consistency with the way all other unit test frameworks which are
based on test functions – I am not a fan of class-based unit tests hence using
pytest in favour of unittest in Python. Using functions just feels more
normal.
Secondarily lack of understanding of the scope rules of multiple unittest
blocks.
In the end though I use whatever is provided. So if functions are for the
chop, I will switch to using labelled unittest blocks.
--
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: unit-threaded v1.0.0
On Thu, 2020-05-28 at 15:35 +, Atila Neves via Digitalmars-d-announce wrote: > I decided to stop being like Google and finally tag version 1 of > unit-threaded: > > https://code.dlang.org/packages/unit-threaded > > From now on I'm going to focus on compilation speed (no matter > how ugly that might make the implementation), and also dropping > support in v2.x.x for anything other than unittest blocks (bye > bye test classes and functions). This last is sad, for me. I like using test functions rather than named unittest blocks. -- 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: Using Vibe.d for not HTTP
On Mon, 2020-05-25 at 12:29 +, Panke via Digitalmars-d-learn wrote: > […] > https://vibed.org/api/vibe.core.core/runTask ? > Possibly, it is just that the documentation is sadly lacking in examples of use. -- 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: Using Vibe.d for not HTTP
On Mon, 2020-05-25 at 11:55 +0200, Daniel Kozak via Digitalmars-d-learn wrote: […] > > https://run.dlang.io/is/SMLuA2 Thanks for this pointer. It was very helpful to read it as it confirmed that I was going doing the right thing in my code. That you have two sources adding some interleaving is most interesting and very informative, useful to read. Now I need to find out how to spawn a task that can send out data even when the connection handler is blocked awaiting something to read. I also need to find out why I am now getting a SIGSEGV I wasn't getting before when no changes seem to have occured in the code. lldb is not really that useful, just as gdb wasn'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: Using Vibe.d for not HTTP
On Sun, 2020-05-24 at 17:01 +0100, Russel Winder wrote: > […] > connection.read(buffer, IOMode.once); > What an idiot I am, this call returns the read count, which makes it fine. Progress now being made. -- 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: Using Vibe.d for not HTTP
On Sun, 2020-05-24 at 12:26 +, bauss via Digitalmars-d-learn wrote:
[…]
Thanks for responding, much appreciated.
> void handleConnections(TCPConnection connection) {
> ...
> }
I guess I was looking for an example of what to put in this function!
> auto buf = new ubyte[amount];
>
> connection.read(temp);
The documentation on read is sadly lacking :-(
https://vibed.org/api/vibe.core.net/TCPConnection.read
It seems to block pending filling all the spaces in the buffer. Not really
very useful.
I tried:
connection.read(buffer, IOMode.once);
but there seems no report on how many bytes were read, you have to guess by
parsing the buffer and making assumptions. Unless I am missing something,
which I really hope I am.
> connection.write(buf);
Not quite at that stage yet!
[…]
--
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
Using Vibe.d for not HTTP
Hi, Clearly Vibe.d is mostly for people doing HTTP and HTTPS stuff. Yet it claims to be able to support TCP and UDP working with other protocols. However, all the serious examples are HTTP/HTTPS related. All the TCP and UDP examples are basically trivial and thus useless to me for learning. I am hoping I have just missed the page/example that does something more than just echo for a TCP server. If I haven't, is ther an example somewhere people know of that I can look at? My problem is that I am not sure how to do a read/write system that is not just echo using the "connection.write(connection)" trick. -- 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: Learning Vibe.d
On Sat, 2020-05-23 at 20:52 +, Steven Schveighoffer via Digitalmars-d- learn wrote: […] > > It’s a recent problem with vibe-core. I’ve had to switch back to > version 1.8.1. > > https://github.com/vibe-d/vibe-core/issues/205 Really good to know this is a genuine problem and not just me doing something wrong! :-) For my purposes switching to using SIGKILL rather than SIGTERM in my tests seems to work with 1.9.1, so I'll go with that till 1.9.2 or 1.10.0 produces a fix rather than revert to 1.8.1. -- 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: Learning Vibe.d
On Sat, 2020-05-23 at 16:56 +, bauss via Digitalmars-d-learn wrote: […] > > Had similar experiences on non-windows platforms. I forgot to mention I was on Linux (Debian Sid). I am (sort of) pleased it isn't just me – definitely unhappy it has happened to others as well. > I think the solution is just to kill the pid. Killing from the command line is not really an option as the process is used in integration tests. I guess I'll have to send the process SIGKILL rather than SIGTERM, which is a bit annoying. -- 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
Learning Vibe.d
Hi, I thought I would try and do the async version of my mock AVR850 using the vibe.d TCP stuff. This is not HTTP, it is proper networking! ;-) Problem one is that vibe.d sever processes never seem to terminate. I am using runApplication or more likely runEventLoop in my main but it never returns. Starting the server from the command line, I Ctrl+C the process and get the message: [main() INF] Received signal 2. Shutting down. but whilst I get a command line prompt, the process is not terminated. This is a bit of a blocker so help very much required. -- 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
Assignment of tuples
So I have an enum:
enum RC5Command: Tuple!(ubyte, ubyte) {
Standby = tuple(to!ubyte(0x10), to!ubyte(0x0c)),
…
I can do:
RC5Command rc5command = RC5Command.CD;
However, if I do:
rc5command = RC5Command.BD;
I get:
source/functionality.d(80,16): Error: template std.typecons.Tuple!(ubyte,
ubyte).Tuple.opAssign cannot deduce function from argument types
!()(RC5Command), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/typecons.d(900,19):
opAssign(R)(auto ref R rhs)
with R = RC5Command
must satisfy the following constraint:
areCompatibleTuples!(typeof(this), R, "=")
which is totally unreasonable. And yet D insists. I guess there is an
explanation, but mostly this seems like a bug.
--
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-18 at 11:56 +, Sebastiaan Koppe via Digitalmars-d-learn wrote: > On Thursday, 14 May 2020 at 09:36:33 UTC, Russel Winder wrote: > > Whilst C frameworks use callbacks and trampolines, high level > > languages seem to be basing things on futures – or things that > > are effectively isomorphic to futures. > > What I find most lacking is proper cancellation. Also, futures > are eager. Whilst GIO has an explicit cancellation stack parameter for all its async operations, I am not sure it is really necessary for the sort of applications I would write – I use null in all cases. Futures are neither eager nor lazy in and of themselves. I am not sure why this is an issue, futures are futures and promises are promises; they are what they are. > > Concurrency and parallelism will never be solved problems I > > suspect, but I think there is a fairly good consensus now on > > what is state of the art. > > I haven't found a language that ticks all the boxes. Kotlin comes > close. We have different needs. I am finding Python's asyncio/async/await and Rust's async/.await with futures perfectly reasonable for creating asynchronous (aka reactive in the hipster jargon) code. The Gio networking stuff is all very C. The Python PyGobject API to it doesn't seem to work, and the Rust API is still a work in progress (the client side works fine, the server-side needs work, and it all needs adding to gtk-rs. > > > I think there are a lot of lessons to be learned from all the > > > efforts in the programming community. > > > > > > We should: > > > > > > - get stackless coroutines > > > - get structured concurrency > > > - steal as many idea from the C++'s executors proposal > > > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r13.html) > > > > I am not convinced C++ has the best "state of the art" in this > > respect – after all it is just copying what JVM languages have > > had for ages, and Rust updated for modern native code languages. > > I am not sure you have read the proposal. Initially I brushed it > off, but upon closer inspection I realised there are some gems in > there. You are right. I will read it fully rather than just the abstract. Perhaps the C++ folk have learned lessons from the Kotlin, Python, and Rust stuff to have something better. I'm still not going to use C++, but it doesn't hurt to learn good lessons. The crucial need from my perspective is having channels, aka queues that create events on the event loop. gtk-rs has shown how to integrate futures and channels really quite well. -- 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, Unit_Threaded, and GtkD
On Sun, 2020-05-17 at 20:32 +, Luis via Digitalmars-d-learn wrote: > On Sunday, 17 May 2020 at 10:19:38 UTC, Russel Winder wrote: > > I am experimenting with using manual control of the Glib event > > loop using the pending and iteration methods on the default > > MainContext within each unit- threaded test. The alternative of > > running a GTK application and then putting the tests in as an > > asynchronous sequence only works with Rust and Python since D > > has no coroutines of any sort. > > > > A Fiber can't be used for this ? D Fibers don't have a scheduler. > Yielding returns to the caller context. > https://dlang.org/phobos/core_thread_fiber.html Futures based co-routines with an executor could do it, but without some form of scheduling, manual control is needed. In fact I think spawning an OS thread is probably a better route, the Glib event loop can then run as it wants being controlled via events being placed on it's queue from another thread. -- 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: Droutines [was D, Unit_Threaded, and GtkD]
On Sun, 2020-05-17 at 11:19 +0100, Russel Winder wrote: […] > > Of course now there is jin.go which is a synchronous multi-tasking approach > with channels rather than an asynchronous approach available in D. Had I checked I would have seen this was a four years ago package that has been left fallow since. It seems like something that should be resurrected and made a core package for concurrency and parallelism for D. I suspect there is significant overlap of some task, thread, fibre, and scheduling code with std.parallelism, but is it worth trying to share code ir just go with separate code? It might be worth extracting the futures code out of vibe.d so that D has a futures package in the Dub repository so that people can create asynchronous coroutines on top of it. -- 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, Unit_Threaded, and GtkD
On Sat, 2020-05-16 at 11:37 +, Cogitri via Digitalmars-d-learn wrote: > On Saturday, 16 May 2020 at 10:51:07 UTC, Russel Winder wrote: > > Has anyone got any D code using the Glib event loop, usually > > GtkD code I'd guess, that is well tested using Unit_Threaded? > > I always had a hard time doing unittests for things with as many > moving parts as glib based software, so I usually just do > integration tests like so: > https://gitlab.alpinelinux.org/Cogitri/apk-polkit/-/blob/1dfbe2b3d959e3c083fcb82419a0a0401c485937/tests/apkd_dbus_server/addAndDelete.d > > Maybe I should look into Unit_Threaded for more fine grained > tests, but I think the effort for all the mocking stuff that I'd > have to implement even for a (relatively) simple GDBus > application would be quite substantial. I am experimenting with using manual control of the Glib event loop using the pending and iteration methods on the default MainContext within each unit- threaded test. The alternative of running a GTK application and then putting the tests in as an asynchronous sequence only works with Rust and Python since D has no coroutines of any sort. Of course now there is jin.go which is a synchronous multi-tasking approach with channels rather than an asynchronous approach available in D. -- 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, Unit_Threaded, and GtkD
Has anyone got any D code using the Glib event loop, usually GtkD code I'd guess, that is well tested using Unit_Threaded? -- 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 Tue, 2020-05-12 at 20:05 +0200, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2020-05-12 11:23, Russel Winder wrote: > > > As far as I can tell D has no futures… > > Future and async in vibe.d [1]. Future in Mecca [2]. > > [1] https://vibed.org/api/vibe.core.concurrency/async > [2] > https://github.com/weka-io/mecca/blob/0593a35dd1a9978855d7db349fc1172f04cf8013/src/mecca/reactor/sync/future.d#L23 D needs something at the language level on which Vibe.d and Mecca build. This is a lesson from Rust, Kotlin, Python, etc. worth taking up. Unfortunately, I can't see D changing because it seems not enough people with interest in developing the language have the resource/interest in this. :-( -- 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 Tue, 2020-05-12 at 09:57 +, Sebastiaan Koppe via Digitalmars-d-learn wrote: […] > > Yeah it is a shame, but you see it in almost every language. > Probably means concurrency and io isn't a fully solved problem > yet. Whilst C frameworks use callbacks and trampolines, high level languages seem to be basing things on futures – or things that are effectively isomorphic to futures. Concurrency and parallelism will never be solved problems I suspect, but I think there is a fairly good consensus now on what is state of the art. D as a language is lagging, and this is sad. […] > > I think there are a lot of lessons to be learned from all the > efforts in the programming community. > > We should: > > - get stackless coroutines > - get structured concurrency > - steal as many idea from the C++'s executors proposal > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r13.html) I am not convinced C++ has the best "state of the art" in this respect – after all it is just copying what JVM languages have had for ages, and Rust updated for modern native code languages. But yes, if D doesn't get something in the async/await style then its future (!) is non-existent. :-( -- 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 19:34 +0200, Jacob Carlborg via Digitalmars-d-learn 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 Hummm… it seems everyone who needed async activity and particularly I/O in D has written their own. Mostly along with all their own data structures and algorithms library. The Rust experience is that there were also many attempts (cf. Tokio and Async_std) but that development and maintenance now seems focused on providing the minimal support for futures in the language (as an API to work with) and the crate futures to provide all the serious stuff, and that all the different event loops are converging on using this – Tokio and Async_std are moving to provide functionality over the std::futures and futures stuff as far as I can tell, indeed Async_std's name tells their story. It isn't pretty in many ways, but it works, and provides a one true Rust-y way of being asynchronous. gtk-rs is working to use the GTK+ async stuff (which is callback based) but provide it in a Tokio/Async_std kind of API based on std::futures and futures crate. This is a huge, huge plus over what D has. GtkD is missing all the added extras that gtk-rs is in the process of providing. As far as I can tell D has no futures… on which to base an equivalent system. I guess the async/.await language syntax will almost certainly never get into D even though it is the choice for Rust and Python – and indeed Kotlin but with a different syntax structure. But is there an alternative, a pure library based way. Clearly yes at the expense of some irritating verbosity that Rust, Python and Kotlin chose not to cope with, but to make language syntax changes instead. Of course this requires effort. Clearly, Rust, Python, and Kotlin have paid people to do all the futures stuff. Firther there is some effort to do this in gtk-rs and I am providing some input with this. If there was effort to add futures to D and extend GtkD in the way gtk-rs is being extended, it would be good for D. D is far, far better than Rust for writing GTK+ code, and could easily replace Vala. However, with the way gtk-rs is developing and GtkD is not, Rust will win out. Well at least people like me will use Rust and gtk-rs instead of D and GtkD because of the language and library evolution in the right direction. Sadly I think that whilst there may or may not be a flurry of activity on this thread, there will not be enough volunteers committed to do the work on futures in D and GtkD to make anything happen. I keep trying to come back to D for GTK+ working, but in the end I keep going back to Python and Rust because D has no futures, and no added extras over GtkD auto translation of the GTK+ API to make it D-y in the way gtk-rs make GTK+ Rust-y. Sorry for the apparent gloom, I just felt the need to tell it how I feel. -- 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: 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: 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: Dub failing with message about DFLAGS
On Tue, 2020-04-28 at 15:09 +, WebFreak001 via Digitalmars-d-learn wrote: > […] > > well it was some problem that you tried to use the $DFLAGS > environment variable somewhere but it wasn't defined The problem is something to do with Dub and Unit-Threaded. My build never uses the "$DFLAGS" explicitly. The Unit-Threaded stuff does however do: Performing "$DFLAGS" build using /usr/bin/ldc2 for x86_64. which is just weird. -- 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: Dub failing with message about DFLAGS
On Tue, 2020-04-28 at 14:03 +, WebFreak001 via Digitalmars-d-learn wrote: > […] > > in this case, try dub upgrade --vverbose and the full exception > message should hopefully show I have no idea what has changed, but things are now working again. Strange. Thanks for chipping in with support. -- 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: Dub failing with message about DFLAGS
On Tue, 2020-04-28 at 12:04 +, WebFreak001 via Digitalmars-d-learn wrote: > On Tuesday, 28 April 2020 at 11:56:26 UTC, Russel Winder wrote: > > Hi, > > > > Has anyone seen this before, it has just started happening to > > me and is stopping me doing any work on this D project. > > > > > > > > dub build > > Invalid variable: DFLAGS > > try running with `dub build -v` I am not sure this gives any further information. :-( |> dub build -v Using dub registry url 'https://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/users/russel/.dub/packages/local-packages.json Looking for local package map at /home/users/russel/Repositories/Git/Masters/Public/ArcamClient_D/.dub/packages/local-packages.json Determined package version using GIT: arcamclient ~master Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/users/russel/.dub/packages/local-packages.json Looking for local package map at /home/users/russel/Repositories/Git/Masters/Public/ArcamClient_D/.dub/packages/local-packages.json Found dependency gtk-d:gtkd 3.9.0 Found dependency unit-threaded 0.10.8 Found dependency unit-threaded:mocks 0.10.8 Found dependency unit-threaded:assertions 0.10.8 Found dependency unit-threaded:exception 0.10.8 Found dependency unit-threaded:from 0.10.8 Found dependency unit-threaded:property 0.10.8 Found dependency unit-threaded:runner 0.10.8 Found dependency unit-threaded:integration 0.10.8 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/users/russel/.dub/packages/local-packages.json Looking for local package map at /home/users/russel/Repositories/Git/Masters/Public/ArcamClient_D/.dub/packages/local-packages.json Found dependency gtk-d:gtkd 3.9.0 Found dependency unit-threaded 0.10.8 Found dependency unit-threaded:mocks 0.10.8 Found dependency unit-threaded:assertions 0.10.8 Found dependency unit-threaded:exception 0.10.8 Found dependency unit-threaded:from 0.10.8 Found dependency unit-threaded:property 0.10.8 Found dependency unit-threaded:runner 0.10.8 Found dependency unit-threaded:integration 0.10.8 Generating using build 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
Dub failing with message about DFLAGS
Hi, Has anyone seen this before, it has just started happening to me and is stopping me doing any work on this D project. |> dub build 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
Rust, D, GTK+, and asynchronous working
Hi, Background: I chose to rewrite a Python/PySide2/Qt application in X/GTK+. After much dithering I was pushed to Rust/gtk-rs/GTK+ and set to it. Then I decided to do D/GtkD/GTK+ as well. Totally unscientific, biased, and indeed prejudiced result is that D is a nicer programming language to work with than Rust for doing GTK+ related UIs. BUT… Now I have to add the networking. GTK+ (and therefore both gtk-rs and GtkD) has APIs for all the socket stuff so as to be harmonious with the Glib/GIO/GTK way of the world. The Big Question™ is how to add monitoring a read socket stream in the event loop. Qt just does it automatically as far as I can tell, but GTK+ appears not to. Which is totally bizarre. Rust now has async/await and futures such that you can create something to put on the GTK+ event loop very easily. It also has very nice tools for doing "reactive programming" using classic programming constructs that turn into event loop manangement with futures. Does D have anything similar or has it missed the "programming with event loops" boat. Currently I am having a hard time finding ways of doing what is easy with Rust/gtk-rs/GTK+ using D/GtkD/GTK+ and this is rather frustrating given how much nicer D is for working with GTK+ than Rust is. -- 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 Sat, 2020-04-25 at 09:30 +, Paulo Pinto via Digitalmars-d-learn wrote: […] > > Just curious, how do you handle the whole RC> story in > Gtk-rs? > > For me it made the point that languages with tracing GC or > implicit reference counting are much better solution for doing > GUI programming. > I am still not sure I have truly come to terms with the whole Rc/Arc and RefCell stuff. It isn't so much the using them, it is trying to decide what is the right combination for a given situation. Big D win here due to garbage collection. -- 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: LDC 1.21.0
On Fri, 2020-04-24 at 11:19 -0700, H. S. Teoh via Digitalmars-d- announce wrote: […] > > Awesome! > > Many thanks to the LDC team for the hard work to bring this awesome > compiler to us! Agreed. Very much agreed. Hopefully the Debian D packaging folks can be speedy getting this new version of LDC into Debian Sid. -- 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 Fri, 2020-04-24 at 15:50 +, Phrozen via Digitalmars-d-learn wrote: > […] > @Basile B., thanks for the suggestion. I'll try this library too. > Just a bit of confirmation: I am a fan of D and GtkD for desktop UI work. GTK+ is just a UI framework unlike Qt (which is UI and networking, database, etc.) and is fairly straightforward to work with after the initial learning hump – which is the same between GTK+ and Qt. Qt is really C++ and Python only though many languages have bindings to QML. GTK+ has many bindings, C++, Go, Rust, and D to name just the obvious native code languages. C++ (gtkmm) and Go (gotk3) bindings are manuals ones, Rust (gtk-rs) and D (GtkD) bindings are generated from the API specification (GIR files). I believe this makes gtk-rs and GtkD far superior to gtkmm and gotk3. I have done a number of projects in Rust/gtk-rs and D/GtkD. Overall I prefer the code of D/GtkD over Rust/gtk-rs *but* there is much more IDE and editor support for Rust compared to D. This makes Rust code easier to write than the equivalent D code, even if that Rust code is more ugly than the equivalent D code. So whilst I keep wanting to do D/GtkD, I keep getting pulled to Rust/gtk-rs simply because CLion (and Emacs) support for Rust is so much nicer than the D support. I must laud Samael's efforts on the IntelliJ IDEA/CLion D support, it is magnificent, but the project needs more resource to get the CLion D plugin somewhere near as good as the Rust CLion plugin. I am sure VisualStudio fans, indeed any other IDE users, will say the same about their IDE, I am a CLion user so try to push CLion support. -- 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 testing, unit-threaded, and threads
On Thu, 2020-04-23 at 14:41 +0300, drug via Digitalmars-d-learn wrote: > […] > Did you try `dub test -- -s`? Oh f###, that is about the only combination I didn't try. :-( Thanks. Problem solved. :-) Not sure about the Fixture proposal, I will research and cogitate further. -- 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: Option and Result [was Integration tests]
On Tue, 2020-04-21 at 21:29 +, aliak via Digitalmars-d-learn wrote: > On Tuesday, 21 April 2020 at 16:30:15 UTC, Russel Winder wrote: […] > > There've been a few attempts at building a Result type: > > https://code.dlang.org/search?q=expect > And here: > https://github.com/aliak00/ddash/blob/master/utils/source/ddash/utils/expect.d > > > Is Option intended for adding to Phobos? > > Not that I am aware of. There was an attempt to PR an Option type > way back when which never made it: > https://github.com/dlang/phobos/pull/3915 > > There was a post here: > https://forum.dlang.org/thread/hqtdekjtdgbhhbjgy...@forum.dlang.org Perhaps there can be one implementation package of Nullable, Option, and Result that is in the Dub repository that everyone can use even though they really ought to be part of Phobos. -- 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
Integration testing, unit-threaded, and threads
Hi, I need to start a process before the tests run, and terminate it after the tests run. A module with a shared static constructor and shared static destructor sounds like the way of doing this since the constructor is run before main and the destructor after main. However I am using unit-threaded, not for the threads but because it is great for a whole load of other reasons. In fact the threads are becoming a problem. As far as I can tell main is terminating before all the tests are complete which means the shared static destructor is executing before all the tests are complete. To test this hypothesis I want to run single threaded. unit-threaded says this is possible using a command line option -s. The question is which command line? dub test doesn't accept it and neither does the dub command creating ut_main.d -- 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: Enum conversion
On Tue, 2020-04-21 at 15:48 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[…]
>
> 1. it's shorter and prettier.
> 2. No cast (I avoid using cast whenever I can).
> 3. No gotcha type conversions.
Works for me, you have me convinced. :-)
> e.g. for point 3:
>
> enum ZoneMember { // : int
>One = 1,
>Two = 2,
>ReallyBig = 4567,
> }
>
> auto b1 = ubyte(ZoneNumber.One); // 1 (compiler uses VRP to make this
> work)
> auto b2 = ubyte(ZoneNumber.ReallyBig); // Compiler error
>
> vs.
>
> auto b1 = cast(ubyte)ZoneNumber.One; // 1
> auto b2 = cast(ubyte)ZoneNumber.ReallyBig; // b2 == 215 (truncated)
>
> vs.
>
> auto b1 = to!ubyte(ZoneNumber.One); // 1
> auto b2 = to!ubyte(ZoneNumber.ReallyBig); // runtime error
QED.
Though for converting a ulong to a ubyte, I am assuming to!ubyte(x) is
the right tool for the job.
[…]
> pragma(msg, typeof(ZoneNumber.One).stringof); // ZoneNumber
Which is as it should be really. I was clearly having a mental
aberration. Anyway, the probem is now solved! :-) Thanks for your
input, much appreciated.
--
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
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.
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?
To date all I can get is:
std.socket.SocketOSException@std/socket.d(2792): Unable to bind socket: Bad
file descriptor
when trying to open a TCP server on 127.0.0.1:5, with Python, Rust,
or Go it all worked first time. This is really sad given D has so many
advantages over Rust. :-(
--
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: Enum conversion
On Tue, 2020-04-21 at 18:09 +, tsbockman via Digitalmars-d-learn wrote: > On Tuesday, 21 April 2020 at 16:03:20 UTC, Russel Winder wrote: > > then which of these is the right way of accessing the value? > > > > cast(ubyte)ZoneNumber.One > > to!ubyte(ZoneNumber.One) > > Either is acceptable because there is no way that this operation > can fail. Using a naked `cast` makes less work for the compiler > and performs optimally with or without inlining, though. Seems like in this case cast is better than to! use. > > conversely what is the right way of going the other way: > > > > cast(ZoneNumber)1 > > to!ZoneNumber(1) > > Use `to` except where you can gaurantee that the input value maps > to a valid enum member, because `cast` does not check your work: > > writeln(cast(ZoneNumber)17); // breaks the type system > writeln(to!ZoneNumber(17)); // throws a ConvException: Value > (17) does not match any member value of enum 'ZoneNumber' > > So, `cast` is faster, but unsafe. `to` is slower, but protects > the enum's invariant. Thanks. It seems to! is de rigueur in this case. -- 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: Enum conversion
On Tue, 2020-04-21 at 12:59 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 4/21/20 12:03 PM, Russel Winder wrote:
> > Hi,
> >
> > Given an enum:
> >
> > enum ZoneNumber {
> > One = 1,
> > Two = 2,
> > }
> >
> > then which of these is the right way of accessing the value?
> >
> > cast(ubyte)ZoneNumber.One
> > to!ubyte(ZoneNumber.One)
>
> I generally do this:
>
> ubyte(ZoneNumber.One)
Hummm… I hadn't got to that one. :-)
Why choose that rather than one of the other two?
>
> > conversely what is the right way of going the other way:
> >
> > cast(ZoneNumber)1
>
> This will incur zero runtime cost, so I would recommend that.
>
> > to!ZoneNumber(1)
>
> This works too, I think it just does the equivalent of the first, but
> if
> not inlined, you will incur some runtime cost.
>
> > I tried:
> >
> > enum ZoneNumber : ubyte {
> > One = 1,
> > Two = 2,
> > }
> >
> > but the members One and Two still seem to be types as int. :-(
> They are typed as ZoneNumber, which is a derivative of ubyte. What
> measurement are you doing to determine that they are int?
typeof(ZoneNumber.One).stringof seemed to return uint.
>
> auto x = ZoneNumber.One;
> ubyte y = x; // fine
>
> If you leave off the :ubyte part, the declaration of y would fail.
>
> Similarly, this would fail:
>
> enum ZoneMember : ubyte {
> One = 1,
> Two = 2,
> ThreeThousand = 3000, // Error: cannot implicitly convert
> expression 3000 of type int to ubyte
> }
Oooo… I like this, adding ":ubyte" immediately.
--
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: Option and Result [was Integration tests]
On Mon, 2020-04-20 at 20:19 +, aliak via Digitalmars-d-learn wrote: > > […] > [0]: https://github.com/aliak00/optional Rust has Option and Result, and most languages are rapidly introducing at least Option if not Result – and yes it is almost certain all this comes from Haskell. Is Option intended for adding to Phobos? -- 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
Enum conversion
Hi,
Given an enum:
enum ZoneNumber {
One = 1,
Two = 2,
}
then which of these is the right way of accessing the value?
cast(ubyte)ZoneNumber.One
to!ubyte(ZoneNumber.One)
conversely what is the right way of going the other way:
cast(ZoneNumber)1
to!ZoneNumber(1)
I tried:
enum ZoneNumber : ubyte {
One = 1,
Two = 2,
}
but the members One and Two still seem to be types as int. :-(
--
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 Fri, 2020-04-17 at 17:51 +, Jon Degenhardt via Digitalmars-d- learn wrote: > On Friday, 17 April 2020 at 16:56:57 UTC, Russel Winder wrote: > > Hi, > > > > Thinking of trying to do the next project in D rather than > > Rust, but… > > > > Rust has built in unit testing on a module basis. D has this so > > no problem. > > > > Rust allows for integration tests in the tests directory of a > > project. These are automatically build and run along with all > > unit tests as part of "cargo test". > > > > Does D have any integrated support for integration tests in the > > way > > Rust does? > > Automated testing is important, perhaps you describe further > what's needed? I haven't worked with Rust test frameworks, but I > took a look at the description of the integration tests and unit > tests. It wasn't immediately obvious what can be done with the > Rust integration test framework that cannot be done with D's > unittest framework. I should point out that Rust is far behind Python's PyTest in terms of testing sophistication, and I fear D lags behind Rust. I think the following is just saying what everyone knows, but it seems making it explicit for this thread. Let us distinguish unit testing, integration testing, and system testing using the definitions: unit testing is self standing testing the code with no extra dependencies; integration testing is testing some functionality of the system with all external resources mocked out (possibly by using a process to simulate the external resource, which is what I want for this project); system testing is testing some functionality with real external resources. D, like Rust, supports unit testing very nicely, well unit_threading seems essential, on a per module basis. Python unit testing with PyTest is very straightforward. Rust supports integration testing explicitly, D does not. Python PyTest does but only because with Python you need no extra infrastructure. Integration testing must not have access to the internals of a module or group of modules, but should appear as a using application. Rust/Cargo integrates this using the tests directory as a peer to the src directory: each file in the tests directory represents a crate that uses the code under test as a crate. Integration and automated system testing in Rust is really a question of whether external resources are mocked or used for real. Python PyTest integration and system testing is very much the same. As far as I know, D/Dub, D/Meson, D/SCons, D/CMake, and D/Make do not provide an out of the box way of building integration tests. Hidden agenda item: system testing really needs to be in a sandbox of some sort. > An important concept described was testing a module as an > external caller. That would seem very be doable using D's > unittest framework. For example, one could create a set of tests > against Phobos, put them in a separate location (e.g. a separate > file), and arrange to have the unittests run as part of a CI > process run along with a build. > > My look was very superficial, perhaps you could explain more. The important difference between using a unit test infrastructure and an integration/system test infrastructure is that: – unit tests are inside the system testing functions and other code features; – integration tests are outside the system testing functionality with mocked external resources. So the build system needs to build all the codes that realise the mocks of the external resources. So for a vestigial Rust project: . ├── Cargo.lock ├── Cargo.toml ├── README.md ├── src │ ├── arcam_protocol.rs │ ├── lib.rs │ └── main.rs └── tests ├── integration_tests.rs └── mock_avr850.rs src/arcam_protocol/rs has all the unit tests in it. D can do the equivalent. tests/mock_avr850.rs is an application that mocks a real amplifier; tests/integration_tests is an application that uses the project as an external crate and starts the mock amplifier for each of the tests. As far as I can tell there is no Dub, Meson, Scons, CMake, Make infrastructure for building D code that supports this sort of thing. Python using PyTest can do all the above really very trivially, D/Cargo has yet to catch up! -- 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
Integration tests
Hi, Thinking of trying to do the next project in D rather than Rust, but… Rust has built in unit testing on a module basis. D has this so no problem. Rust allows for integration tests in the tests directory of a project. These are automatically build and run along with all unit tests as part of "cargo test". Does D have any integrated support for integration tests in the way Rust does? -- 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: Introduction and request for help
On Tue, 2020-03-10 at 14:18 +, Ron Tarrant via Digitalmars-d-learn wrote: > On Monday, 9 March 2020 at 22:48:35 UTC, Kendell wrote: > > > Hey Everyone, > > > > I'm a new D developer and therefore new to Gtkd. > > So far I've had no problems building this project with DUB. > > However I want to move over to meson so that I can build it for > > flatpak. I am finding that I am unable to build with meson. > > […] > > Here's hoping someone will notice your plea. I have got stuck in to this on the GtkD forum. -- 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: weekly news?
On Thu, 2020-01-23 at 23:47 -0500, James Blachly via Digitalmars-d- learn wrote: > On 1/23/20 8:13 PM, Mike Parker wrote: > > On Thursday, 23 January 2020 at 15:44:10 UTC, Adam D. Ruppe wrote: > > > > > Or delete all that wordpress junk and make something in D :P > > > > I intend to delete all that Wordpress junk and go completely > > static > > eventually. > > Mike, I know we're not a golang shop, but I highly recommend > switching > to HUGO for the blog. I currently use Nikola for the ACCU Conference website, but the intention is to switch to HUGO as soon as we can – the ACCU website is switching from an ancient CMS to HUGO and the conference website switches with it.. > -- 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: Blog Post #0099: A Special Request
On Thu, 2020-01-23 at 15:12 +, Ron Tarrant via Digitalmars-d-learn wrote: > On Thursday, 23 January 2020 at 12:43:24 UTC, Antonio Corbi wrote: > > > Yes, it uses 'sed' to get 'constants.d' from 'constants.d.in' > > at configuration time. > > So you can write your own 'constants.d' with the appropiate > > values for UIDIR and DATADIR and delete/comment the the > > preBuildCommands in dub.sdl. > > This is beginning to sound like it's beyond the scope of the blog. Someone does a side tutorial referenced from your blog? With reverse links obviously. -- 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: weekly news?
On Wed, 2020-01-22 at 23:08 +, Russel Winder wrote: > On Wed, 2020-01-22 at 22:48 +, Mike Parker via Digitalmars-d- > learn > wrote: > […] > > To D Blog has an RSS feed: > > > > http://dlang.org/blog/index.php/feed/ > > > […] > > This URL doesn't seem to work for me. > > It redirects to: > > https://dlang.org/blog/feed/ > > which gives "file not found" And yet it works fine as an RSS feed! > -- 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: weekly news?
On Wed, 2020-01-22 at 22:48 +, Mike Parker via Digitalmars-d-learn wrote: […] > > To D Blog has an RSS feed: > > http://dlang.org/blog/index.php/feed/ > […] This URL doesn't seem to work for me. It redirects to: https://dlang.org/blog/feed/ which gives "file not found" -- 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: What kind of Editor, IDE you are using and which one do you like for D language?
On Sat, 2019-12-28 at 22:01 +, p.shkadzko via Digitalmars-d-learn wrote: […] > p.s. I found it quite satisfying that D does not really need an > IDE, you will be fine even with nano. Java people said this and we got Eclipse, Netbeans, and IntelliJ IDEA, and many people were better Java (and Kotlin, Groovy, Clojure, Scala, etc.) programmers because they used them. C and C++ people said this and we got CLion, and many programmers were better C or C++ programmers because they used it. Go people said this and we got Goland, and many people were better programmers because they used it. Whilst many programmers are happy using 1970s approaches to programming using ed, ex, vi, vim, emacs, sublime text, atom, etc. Many programmers prefer using IDEs, and are better programmers for it. D programmers can use text editors if they want, but many D programmers would be much better D programmers for having a full IDE – which is, for me, why getting the D language plugin to CLion (and IntelliJ IDEA) is important for D traction. The more the D community advertise that IDEs are for wimps, the less likelihood that people will come to D usage. -- 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: [OT] What kind of Editor, IDE you are using and which one do you like for D language?
On Tue, 2019-12-24 at 09:52 -0800, H. S. Teoh via Digitalmars-d-learn wrote: > On Tue, Dec 24, 2019 at 10:18:49AM +0000, Russel Winder via > Digitalmars-d-learn wrote: […] > Haha, well, a *real* hardcore retro guy would be using a magnet, a > pin, > and a *really* steady hand, to flip individual bits on an exposed > harddisk platter to create the executable in the filesystem directly, > one bit at a time. > > Of course, one could also just use emacs: > > https://xkcd.com/378/ > > :-D One always returns to using Emacs for text editing – it is the One True Editor™ (and kitchen sink). […] > It wasn't so much wrong highlighting for me, it was the fact that it > was > highlighted at all. I find the kaleidoscopic colors extremely > distracting and disruptive to my focusing on the textual content of > the > code. Not to mention that the colors usually clash horribly with my > chosen foreground/background color scheme in my terminal, which only > adds unreadable bits of text to the problem. Emacs and JetBrains CLion seem to work fine for me in both light-on- dark and dark-on-light mode, so syntax highlighting works for me for the editors I use. I keep trying VIM, Atom, VSCode, SublimeText, Geany, etc. from time to time, but I get bored trying to get them set up to be even remotely sensible and just go back to Emacs. […] > > Actually, I wouldn't mind a syntax-oriented editor, if one could be > made > that wasn't artificially restrictive in terms of editing various > different languages and various different flavors of different > languages, such that it could be used as a general tool. There is a movement to try and bring back what could be described as SOEs, but I am not seeing that much traction as yet. The incumbent editors that use vast quantities of CPU to reconstruct ASTs on the fly seem to dominate mindset. […] > > This madness is nothing compared to the utter, gibbering insanity of > modern web design, in which modern 8-core CPUs with GHz speeds and > GBs > of memory run dead-simple applications like word processors at the > *same* speeds (if not worse!) as WordStar would run back in 1980 on > an 8 > *Hz* CPU with 64KB of RAM. With exactly the same lag between > keystrokes, and the same (lack of) reliability requiring frequent > backups and incessant restarting. > > Now *that* I call a mad, mad world. The madness of IDEs parsing and > reparsing the same AST over and over again umpteen times per second > doesn't even begin to scratch the surface of *this* madness. I just > can't wait to see some poor sod attempt to reimplement a modern IDE > in > Javascript and succeed at reproducing 1980's IDE speeds and (lack of) > quality. And of course the masses would slobber all over it and hail > it > as "progress". The browser king has no clothes, and everybody sees > invisible. I can only agree with this rant. The modern world of software has increasingly become about doing less and less useful to the end user with more and more hardware resources. -- 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: Blog Post #0095: Hardware II - Full Monitor Report
On Tue, 2019-12-24 at 09:49 +, Ron Tarrant via Digitalmars-d-learn wrote: > If you liked last week's post, this one will knock your socks > off. Wanna know (programmatically) which monitor your application > window is on? Here's how to find out: > https://gtkdcoding.com/2019/12/24/0095-hardware-ii-full-monitor-report.html You have to love GTK+, GtkD, and D. :-) Happy Winter Solstice (*). (*) Or whatever winter solstice related holiday works for you. :-) -- 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: [OT] What kind of Editor, IDE you are using and which one do you like for D language?
On Mon, 2019-12-23 at 08:09 -0800, H. S. Teoh via Digitalmars-d-learn wrote: […] > > No idea, I use vanilla vim (not even with syntax highlighting -- I'm > a > hardcore retro guy). Surely a hardcore retro guy would be using vi not vim? Indeed wouldn't a real hardcore retro guy be using ed? :-) I used to be anti syntax highlighting in editors, but it was because the highlighting was usually crap or worse wrong. Once I started using syntax highlighting where the highlighting was correct with respect to the language definition, I found it indispensable. Of course the real problem is that we store text of code rather than AST of the code, but that war got lost in the 1980s when syntax oriented editors were rejected in favour of text editors. Now editors and IDE spend all their CPU cycles reconstructing and maintaining the AST of the code from the text representation. It's a mad, mad, mad world. -- 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: What kind of Editor, IDE you are using and which one do you like for D language?
On Sun, 2019-12-22 at 17:20 +, BoQsc via Digitalmars-d-learn wrote: > There are lots of editors/IDE's that support D language: > https://wiki.dlang.org/Editors > > What kind of editor/IDE are you using and which one do you like > the most? CLion with the DLanguage plugin. Very much a work in progress, very much a nice IDE despite the lack of many features one might expect. For editor, Emacs with the d-mode plugin. -- 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: dud: A dub replacement
On Tue, 2019-11-19 at 10:32 +, Joseph Rushton Wakeling via Digitalmars-d- announce wrote: > […] > > I'm simply concerned that if we don't put enough scrutiny on the > app features and behaviour, we run the risk of simply reproducing > some of the problematic design decisions of the existing tool. > > As an example -- try running `dub test --build=release`. > Intuition suggests that this is testing a release build. But > actually it strips out your unittests, because `--build=release` > determines not only the optimization flags, but the complete set > of DFLAGS used -- and `-unittest` isn't among them. > > I ran `dub test && dub test --build=release` as a matter of habit > for some time before discovering the latter wasn't actually > testing anything. And while I now know that I _can_ define a > custom build to get what I want, that's clumsy and hard(er) to > discover, and annoying to have to repeat for every project I > create. > > That's the kind of usability and design concern we really ought > to be revisiting in any rewrite. How can I not agree with this being a critical bug in Dub! :-) -- 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: dud: A dub replacement
On Tue, 2019-11-19 at 10:38 +, Joseph Rushton Wakeling via Digitalmars-d- announce wrote: > On Monday, 18 November 2019 at 20:48:53 UTC, bachmeier wrote: > > IMO this is one of the most important parts of the first five > > minutes with the language. Someone has installed the compiler, > > and now they want to test it out. If they have a bad experience > > with Dub, they will not continue with the language. A package > > manager, including the choice of format, is something you have > > to get right. Rust understands this. > > Fair point. But that isn't something that has to be decided at > the _start_ of a rewrite: better to focus on wanted behaviour, > and then derive the ideal config format from that. I'd argue that from a socio-technical perspective it is an important factor that should be an integral part of developing any user facing tool. The functionality of the tool is important, but how that functionality is presented to a user new to the tool and a user proficient with the tool should be equally important. As an example of how not to do things, perhaps I can suggest earlier forms of Git. It took nigh on a decade to simplify things to get to the overcomplicated CLI we have today with Git. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 20:19 +, Tobias Pankrath via Digitalmars-d-announce wrote: > On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote: > > > Probably yes. Though Cargo has taken many different decisions > > to Dub and mostly I think Cargo took better decisions. > > Could you elaborate a bit, please? I am not familiar with Cargo > though. The single biggest difference for me just now is management of compilation products. In an attempt to share compiled products between projects, Dub keeps all downloaded package source and compilations products of that source in a central location. This ends up with a very complicated, and more or less unusable except by Dub, store of compilation products – especially as the easy to get to compilation product has unknown compilation details. Also it assumes you have infinite amounts of disc space. Cargo keeps the downloaded package sources centrally, but leaves all compilation products in the project build area. This makes it easy to manage and the compilation details of the compilation products are easy to understand. OK you still have to manually manage the central repository but as it is source only, you get a much smaller growth to infinite disc space requirement. As for smaller issues: I prefer TOML over SDL as project specification notation (JSON is not an option for me). The convention over configuration rules for projects with multiple compilation products is nicer in Cargo compared to Dub. Cargo is far more accepted in Rust circles than Dub is in D circles. The issue is not that this is true, but why is it true: is it just that D folk are still obsessed with Make, SCons, CMake, Meson, etc. where Rust folk have never even considered them. D is still working with the ancient philosophy of the distributed standard library provides everything, cf. Python and "batteries included". Python has long ago had to give up on this and open its arms to PyPI based package distribution. Go and Rust never went with the "batteries included" but put the infrastructure in place at the outset for supporting libraries from repositories – Rust/Cargo handles this far better than Go. The upshot is that the D package repository is still not really central to D code development. And using Git, Breezy, Mercurial, etc. repositories is just not as simple and straightforward as it is with Go and Rust/Cargo. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 16:54 +, JN via Digitalmars-d-announce wrote: > […] > > I only use the JSON format. JSON is widespread together with XML. > SDL I heard first time of in the context of Dub and never seen it > used elsewhere. TOML also I know only from Cargo. YAML at least I > know from several different projects. It is so easy to make spelling errors in keys using hand-written JSON. SDL I have only ever used with Dub, but it works better for me than JSON. TOML is really an INI evolution so known to many. YAML is used by many but doesn't really allow for the ease of specifying lists as TOML and SDL have. > I guess the tool must be working very well though if the main > argument is what kind of data format to use :) Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 15:35 +, Joseph Rushton Wakeling via Digitalmars-d- announce wrote: > […] > It is quite extraordinary how readily folks fall to arguing over > what the config format should be, rather than what the app should > actually be able to do. :-\ Perhaps because writing the configuration files is a critical part of the usability of the tool. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 09:53 +, Paolo Invernizzi via Digitalmars-d-announce wrote: […] > A win-win move would be to have dud emit the other formats > automatically as part of the compilation procedure, so to have > always all of them present and synced on the content. Why? In fact, why even think of doing this at all? There should be one and only one human written configuration file for a build and it should be in a notation suitable for being written by humans. > It shouldn't be too much difficult, and maybe it's a cleaver way > to move on from discussions about different formats. Again why? It seems like a pointless overhead that achieves nothing constructive. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 10:26 +, Sebastiaan Koppe via Digitalmars-d-announce wrote: > On Monday, 18 November 2019 at 09:53:56 UTC, Paolo Invernizzi > wrote: > > A win-win move would be to have dud emit the other formats > > automatically as part of the compilation procedure, so to have > > always all of them present and synced on the content. > > I already regret starting about this. Instead of rooting for the > SDL format, I should have just recommended to deprecate the json > one. I do not think you should regret starting a discussion on this. Personally I only ever use SDL with Dub. Even contemplating using JSON for human written configuration files is, for me, totally the wrong thing to do. -- 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: dud: A dub replacement
On Mon, 2019-11-18 at 09:31 +, Sebastiaan Koppe via Digitalmars-d-announce wrote: > On Monday, 18 November 2019 at 08:57:58 UTC, Russel Winder wrote: > > Is SDL the right format? Cargo uses TOML to great effect. > > > > And TOML has, I suspect greater traction more widely than SDL. > > I personally prefer SDL when it comes to nested data, but yeah, > that would work as well. > > The point I was making is to just have 1 format. With dud that > should be possible. For me the argument is that SDL and TOML are intended for human's to write configuration scripts, whilst XML and JSON are intended for computers to send data to other computers. -- 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: dud: A dub replacement
On Sun, 2019-11-17 at 19:10 +, Sebastiaan Koppe via Digitalmars-d-announce wrote: > On Sunday, 17 November 2019 at 16:26:45 UTC, Denis Feklushkin > wrote: > > On Thursday, 14 November 2019 at 23:33:06 UTC, Nick Sabalausky > > (Abscissa) wrote: > > Also, this, apparently, should lead to the fact that dud will > > have their own package description format. Almost inevitable. > > (This has already been discussed, perhaps.) > > SDL all the way please. Is SDL the right format? Cargo uses TOML to great effect. And TOML has, I suspect greater traction more widely than SDL. -- 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: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Mon, 2019-10-21 at 12:25 +, Per Nordlöw via Digitalmars-d-announce wrote: > On Monday, 21 October 2019 at 12:12:56 UTC, Per Nordlöw wrote: > > Is it prepackaged on Ubuntu? > > Do you mean the package golang-go? I am not sure what Ubuntu package version is, with it's 6 month or 3 year update cycle it is almost certainly well out of date, but Debian Sid tries to stay up to date. golang-go is currently golang-1.13-go but you can use the meta-package golang-1.13 to enforce that version. -- 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: Permission to Use Comments?
On Mon, 2019-10-14 at 15:36 +, Jesse Phillips via Digitalmars-d-learn wrote: […] > Pretty sure since this is a public forum, legally you just need > to reference your sources (if even that). Asking permission is > just polite. […] But the forum/email list does not have terms of use that transfer copyright from the writer to the owner of the server hosting the forum/email list. Literary works are copyright the writer unless they give up that copyright. But IANAL. Quoting short parts of a literary work with attribution is clearly fair use – at least in the jurisdictions I know about, there may be some jurisdictions in which this doesn't apply. Asking permission guarantees no future copyright case brought against you. -- 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: Permission to Use Comments?
On Mon, 2019-10-14 at 11:14 +, Ron Tarrant via Digitalmars-d-learn wrote: […] > 1) Does anyone know how copyright laws stand regarding reuse of > comments on a forum? IANAL, but… I believe emails, and I suspect forum posts, are copyright since they are literary works. Quoting them with reference to the original source is, I believe, fair use. But that depends on the jurisdiction. For forums I would guess that the jurisdiction of the server handling the UI (and possibly the one holding the storage if different) is the jurisdiction for copyright law. For emails it is likely weird, and not at all obvious. > 2) Does anyone object to me quoting them for promotional purposes? Not I. I am happy for comments I make regarding GtkDCoding on this email list to be used above my name on the GtkDCoding website. -- 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: How can I make a program which uses all cores and 100% of cpu power?
On Fri, 2019-10-11 at 00:41 +, Murilo via Digitalmars-d-learn wrote: > I have started working with neural networks and for that I need a > lot of computing power but the programs I make only use around > 30% of the cpu, or at least that is what Task Manager tells me. > How can I make it use all 4 cores of my AMD FX-4300 and how can I > make it use 100% of it? Why do you want to get CPU utilisation to 100%? I would have thought you'd want to get the neural net to be as fast as possible, this does not necessarily imply that all CPU cycles must be used. A neural net is, at it's heart, a set of communicating nodes. This is as much an I/O bound model as it is compute bound one – nodes are generally waiting for input as much as they are computing a value. The obvious solution architecture for a small computer is to create a task per node on a thread pool, with a few more threads in the pool than you have processors, and hope that you can organise the communication between tasks so as to avoid cache misses. This can be tricky when using multi-core processors. It gets even worse when you have hyperthreads – many organisations doing CPU bound computations switch off hyperthreads as they cause more problems than theysolve. -- 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: Functional Programming in D
On Thu, 2019-10-10 at 03:08 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […] > Note this is why I wrote "functional-style programming" w.r.t. D, rather > than "functional programming". Clearly, what D has isn't "real" > functional programming in the strict sense, but it does share similar > characteristics when written in that style. Indeed, I was trying to support that view. I think declarative rather than functional-style is a better label for this since it avoids the functional vs imperative paradigm conflict left over from the late 1980s and 1990s. -- 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: Functional Programming in D
On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […] > Actually, std.functional is somewhat of a misnomer. It mostly deals with > higher-order functions, i.e., functions that return functions, currying, > that sort of thing. These are part of functional programming, but > there's more to functional programming than that. I'd say std.range and > std.algorithm are another major part of functional-style programming > support in D, along with the purity system. […] I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D. The reason is things like lazy evaluation and the consistency of everything being a function, etc. The underlying computational models of functional programming languages and imperative programming languages need different mindsets to use well. Witness the issues in using Scala. Having said this, declarative programming can be pursued in functional languages, logic languages (e.g. Prolog), and imperative languages. Tools such as higher order functions are crucial to this, but currying is not, unless it is core to partial evaluation as it is in Haskell. Modern C++, D, Rust – but not Go – all admit programming using a declarative way of working just as Haskell and Scheme do. My experience of emphasising declarative programming in imperative languages is that people build smaller, more comprehensible, and maintainable code that achives the goal compared with using tradition imperative programming. -- 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: Pro programmer
On Wed, 2019-08-28 at 04:46 +, Jani Hur via Digitalmars-d-learn wrote: > […] > For Lisp, Clojure (https://clojure.org/) is a strong candidate: > > https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html Common Lisp implementations may still have car, cdr, etc. for backward compatibility, but I haven't seen any human written/read Lisp code using them for ages. So that is a bit of a false argument by Bob on that one. Clojure is fun, but only if you already have to have the JVM and The Java Platform. Common Lisp implementations have all the needful and do not have the resource requirements of the JVM, and they have JITs. -- 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 it possible to target all platforms that Qt Quick can target?
On Mon, 2019-08-12 at 17:45 +, Enjoys Math via Digitalmars-d-learn wrote: > Hi, > > I'm writing my GUI in C++ & Qt Quick. I know that I could > connect to D from the GUI code using a DLL, but can something > similar be done on the other PC OS's and the mobile OS's? > > Thanks. > Looking at https://wiki.dlang.org/GUI_Libraries there are some wrappers to Qt for D, including dqml. I think some may not be as maintained as it would be nice to have. Actually it would be nice if there was one standard D wrapper for Qt and QML as there is GtkD the one true D wrapper to GTK+. -- 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: Desktop app with vibe.d
On Mon, 2019-08-12 at 20:01 +, DanielG via Digitalmars-d-learn wrote: > On Monday, 12 August 2019 at 10:41:57 UTC, GreatSam4sure wrote: > > I will be happy if I can build an app in D with fanciful ui. I > > will also be happy if you know any other way to build a > > fanciful ui in D like adobe flex, javafx, etc. > > I haven't seen anybody doing it yet, but in theory you could > launch a browser / Electron instance / etc, and have it connect > via gRPC to code written in D. > > Then you could have a fancy React UI and use D to do the heavy > lifting. GtkD allows for "reactive" UI. https://www.reactivemanifesto.org/ There is also Qt, I haven't tried any of the D bindings to Qt, but given Qt is event loop based I am sure it allows for "reactive" UI as well – it definitely does using Python/PySIDE2. GTK+ doesn't have the equivalent of the stage/engine of QML. QML is Qt's version of JavaFX, so you do not need a browser to get a dynamic reactive UI. -- 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: Help me decide D or C
On Fri, 2019-08-02 at 20:24 +, Jon Degenhardt via Digitalmars-d-learn wrote: […] > In my view, the most important thing is the decision you've > already made - to pick a programming language and learn it in a > reasonable bit of depth. Which programming language you choose is > less important. No matter which choice you make you'll have the > opportunity to learn skills that will transfer to other > programming languages. > […] Knowing what a given programming language is best for is core here: so no using Prolog to try and write an operating system on real hardware. Knowing many paradigms well is proven experimentally (see the work by Petre, Green, Gilmore, and others) to improve capability in any given language. So knowing Java, Prolog, Lisp, Python, SQL, C, Go, Rust, D, Kotlin, Groovy, Ruby to a goodly level of competence makes you a better programmer in any one of them. So no matter which language you learn always plan to learn others. In this sense C and D are equal, but for applications I'd choose D over C. -- 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: [OT] Re: Using Haskell for teaching [was: Help me decide D or C]
On Fri, 2019-08-02 at 23:24 -0600, Jonathan M Davis via Digitalmars-d-learn wrote: […] > The university I went to had an undergrad class on programming paradigms > that I _think_ was required (maybe two even), but it was definitely just the > focus of a small number of classes, whereas my experience is that you get a > lot more out of it when you actually use a language with a different > paradigm for a while rather than just doing one group of assignments in it - > and when the class covers multiple programming paradigms, that also dilutes > how much you get out of each. On some level, as with many things, a lot of > it depends on how much the students decide to put into it on their own. […] UCL used to have a 10 week module that tried to do three language to show that different programming languages were best for different problems. Prolog, Snobol, and ??? were the trio when we terminated the module as not being effective. This reinforced having a third programming language module in the compulsory programming sequence so as to have 10 weeks per language rather than three. Still not really long enough but it worked a lot better. I think universities will be far better able to teach programming now that entrants already know Python (to a greater or lesser extent). The single biggest problem will be (has always been) having academics on the staff competent and willing to put on programming courses. Far too many academics in universities are truly crap programmers and are the last people you want to show their crapness to students. -- 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: Help me decide D or C
ed the abstractions. What is the moral behind this story of mixed messages? There are many, some are: prejudices can make people make the wrong choices and then patch things up; using the right libraries is always a good idea; sometime you make a choice based on accepting some negative aspects just trying to maximise the positive ones. What I haven't mentioned as yet is editor/IDE support, this must not be underestimated. Support for writing Go, Rust, C, C++, Java, Kotlin, etc. code is very strong. Originally a vi person I switched to Emacs and have been an Emacs addict since the mid 1980s. The came the IDE, and I have become a bit of a JetBrains fan. CLion, Goland, IntelliJIDEA, and PyCharm are sponditious. They make Emacs seem a bit pathetic for developing Go, Rust, C, C++, Java, Kotlin, Groovy, etc. code. CLion support for Rust makes writing Rust code easier. There is a the beginnings of a D plugin (indeed I ought to be helping work on it but am failing to do that), but the Rust plugin is already wonderful. This is mostly because JetBrains see an income stream form supporting Rust, but see no such income stream from supporting D. This is arguably D biggest problem, the editor and IDE supprt for D is second, even third, rate compared to the support available for Go, Rust, Java, Kotlin, Groovy, C, and C++. No matter how good a language is, it is only as good as the editor and IDE support. So despite D being better than Rust for Me TV, I use Rust because the inheritance issue is patched up in the gtk-rs library, and I can develp the Me TV software, and especially debug SIGSEGV, far better in CLion using Rust than trying to use D. Sadly there seems to be a inherent belief in the D community at large that VIM (or Emacs) is all you need. For those individuals that may be true. However Visual Studio and CLion is where the native code development action is for programmers who want an easier life. > I have receive so many good opinions so far. I realize there is > no consensus what so ever. As I was suggested Haskell, Python, D, > C etc. It's a good thing, but hard to make a decision. Lots of people means lots of opinions! But the arguments were sensible and presented in good faith: they just reflected the variables: what programming do you already know; what is the software being written for; and what is the execution platform of the software once written. This must lead to many variations, and so in the end an individual in a given situation has to "plump" for a choice, and then follow through. Without knowing the problem that are fun for you it is difficult to pin things down further than D, Go, Rust, Java, and Kotlin are all good languages for writing applications. -- 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: Help me decide D or C
On Fri, 2019-08-02 at 17:25 +, berni via Digitalmars-d-learn wrote: > […] > > Yes, that was intentional. What I wanted to say is, that I think, > that it would have been better, if C was never invented at all... > In that case, there would have been space for an other language > for writing operating systems, without that much bugs in its > design. (But one never knows afterwards...) If C had not been invented by Ritchie, Thompson, et al., something very like it would have been invented by someone else. BCPL and B were not really gaining the traction they perhaps should have had, and Algol, Algol68, FORTRAN, PL/1, COBOL, etc. were not really designed for writing operating systems. https://en.wikipedia.org/wiki/Timeline_of_programming_languages The problem was not the invention of C, the problem was all those programmers who stopped thinking about using the right tool for a given task in a given context, and started using C for all programming situations. But it happened, it is read-only history. Rust, D, and Go are the current ways out of the tragedy that was using C for applications programming. C++ is finally catching up. -- 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
[OT] Re: Using Haskell for teaching [was: Help me decide D or C]
On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > […] > My feeling is that functional languages are likely to be a very poor place > for most folks to start learning, much as I think that they're great for > someone to learn and work with at some point. I have heard of beginning > programming classes using functional languages and having it go very well, > but it seems hard to believe to me. Imperative programming can already be a > lot for beginners, but most people really don't think even vaguely in a > functional manner. Even simple recursion tends to be a bit of a mind-bender > for people at first. […] At UCL in the late 1980s and early 1990s, we used a functional programming language in the first term and C++ in the second term for teaching programming. Initially Scheme was the functional programming language but we then switched to Miranda (which was a pre-cursor to Haskell). This deep immersion in two totally different programming paradigms worked very well. The mid/late 1990s mad rush to Java everywhere in teaching (of which I was a part) was in hindsight madness (of a global sort). The move by many institutions to using Python first and then Java rebalances somewhat but is missing the point – it's about the paradigms. I have retrenched as a believer in the Haskell/C++, or Prolog/Java, or some such. In the new era with new undergraduates already knowing Scratch and Python, universities should really go the whole hog in getting programming paradigms and programming as a skill as well as knowledge, with all the tools,fair and square into the first year curriculum. Of course I have been out of academia for 20 years, and am now out of employment, so my views have no impact. :-) -- 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: Help me decide D or C
On Fri, 2019-08-02 at 13:45 +, Alexandre via Digitalmars-d-learn wrote: > […] > Could you elaborate more about C being a burden? I have read so > many people saying C gives a great foundation and should be > everyone's first language. Now I am confused. C is a programming language created in the early 1970s to make writing UNIX easier. Early versions of UNIX (and Multics before it) were written in assembly language. Dennis Ritchie et al. wanted to use a programming language that had a higher level of abstraction than assembly language so as to make writing UNIX easier. BCPL gave many of the ideas for B which led to C, effectively a portable assembly language but with special eyes on the PDP-8, PDP-11, and later VAX-11 machine codes. C was hugely successful for writing operating systems because it was "close to the metal" and yet with better abstractions than assembly language. I spent many happy (and many unhappy) hours in the early 1980s writing device drivers for UNIX 6, UNIX 7, and BSD 4.0. C was the right tool for the job at hand at that time. Many tools associated with UNIX were written in C, including the C compiler, since the only other option at the time in the UNIX context was assembly language. Already though there was the question: was C the right tool for the job of writing applications – as opposed to hardware controlling software. One could argue that "buffer overruns" was clear evidence that C was the wrong tool for the job. Unfortunately the obsession with C, even if it was not the right tool for the job at hand, had taken hold: if you didn't write your application in C you were somehow a second or third rate human being, let alone programmer. Then came C++ (or then C with Classes) and the beginning of the rift between the C camp and the "we need a programming language with higher levels of abstraction" camp. I am sure many can write lots on the 1990s and 2000s and the various language wars, but here we are in 2010s entering the 2020s and we have D, Rust, Go, Java, Kotlin, Python, Ruby, C++, Lisp, Prolog, Erlang, etc. all of which have their problems, but all of which have their "sweet spots" for being the right tool for the job at hand. C is no longer the de facto standard language for writing all software. People are increasingly recognising that it is as if C were specifically created for writing software that controls hardware. C still has a role in the world of programming, and it definitely has a status as one of the most important programming languages ever. Moral of this story is that, for me, in 2019, if you are writing applications software or software tools, C is not the right tool for the job. -- 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: Help me decide D or C
On Thu, 2019-08-01 at 14:49 +, bachmeier via Digitalmars-d-learn wrote: […] > There's nothing wrong with Haskell if you want to take a deep > dive into pure functional programming. I personally find Haskell > to be more of a religion than a programming language. You can > learn the same perspective from functional-first languages like > Clojure, Scala, Ocaml, and F#. […] Whilst I agree that most "this is the one true programming language" people are quasi-religious, programming languages are not: Haskell is a just a lazy, pure functional programming language, some adherents show quasi-religious fervour, just as some adherents of C++, Java, C, Go, Rust, D, etc. do. I am not sure about F# (I do not know anything of it), but Clojure, Scala, and OCaml are very different from Haskell for various reasons, cf. lazy vs. eager, pure vs. impure. Haskell is a programming language worth learning for all programmers,along with Lisp, Prolog, and Erlang. I'll bet (but I have no experimental data, just a hypothesis) that any D programmer that knows Haskell writes better D than a D programmer who doesn't know Haskell. -- 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: gtkDcoding Facelift Launch
[…] > > And instead of linking directly to the article, here's a link to > the main page so you can see the entire facelift: > https://gtkdcoding.com. Excellent stuff. Thanks for putting in the effort on this, it is well worth it. -- 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: How to walk over two arrays by ref in beautyfull way?
On Mon, 2019-06-10 at 08:02 +, vitalfadeev via Digitalmars-d-learn
wrote:
[…]
Perhaps I am missing something that is critical to the example, but I
rewrote the code as:
import std.algorithm: map;
import std.stdio: writeln;
bool false_cb() { return false; }
bool true_cb() { return true; }
void main() {
auto checkers = [_cb, _cb, _cb];
auto result = map!(a => a())(checkers);
writeln(result);
}
This avoids the assumption that 0 is false and 1 is true. Also it makes
use of D map which seems to me what is happening at the core of the
code – using foreach and zip or lockstep just seems to be implementing
map. But as I say, I may be missing something.
--
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: Using python in D
On Sun, 2019-06-09 at 03:42 +, rnd via Digitalmars-d-learn wrote: > […] > I also wanted to know: Once executable is successfully created, > will it work on systems where Python and pandas are not installed? I suspect not, but then I do not use Windows. I would be surprised if the executable was self contained since that would imply loading the Python VM, it's standard library, and the used extenal packages. py2exe does though do this sort of thing so maybe PyD can. I do not know, sorry. -- 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
