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: 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: 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: 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: 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
On Fri, 2019-08-02 at 16:49 +, Alexandre via Digitalmars-d-learn wrote: […] > > Do you thing D would be the right tool for the job at this point > for me? Assuming I have 2 goals in mind: 1) become a better > programmer and 2) want to make fun writing software for myself > and if possible show something I might be proud of. > I thought C would be a better choice for the 1), because everyone > says it's great to see whats behind the hood and things like > that. My experience with C btw is CS50 course, plus around > 200/300 pages of some books, still reading and a few toy > projects. So, basically 0 knowledge. haha. But after reading your > opinion, I guess C might not be the right tool for me, since I > wont be doing any kind of thing related to hardware (I think). Seeing what is behind the hood was important in the 1970s and 1980s because the hardware was constrained and programming languages (other than perhaps Lisp) were still trying to provide abstractions over the extant hardware. In the 2000s and 2010s "seeing what is under the hood" is more or less irrelevant for most applications programmers – this does not include people for whom hard real time factors are critical to their software. Most application programmers should be focusing on using the right algorithms and data structures for the task and letting the compilers and their code generators worry about what is "under the hood". Programming for microcontrollers is a different game and C dominates there still (I assume, it is over a decade since I was doing that stuff), and for good reason, the algorithms and data structures are hardware oriented rather than being abstract. And when your hardware has bit data structures, so does your programming language: C compilers for 8051 and AVR chips have special extensions to allow bit access. As for your 2, what do you find fun to create software for? It is then a question of choosing the language that best enables you to simply and easily create the data structures and thence the algorithms for those problems. Being able to show off software and be proud of it revolves around having the simplest and most understandable expressions of the best data structures and algorithms for the problem addressed. C can be used for this but you end up hacking this very badly, and opening yourself up to horrors such as buffer overrun. My pet project of the moment is a DVB player (Me TV). It was originally a C program authored by someone else who then began transforming it to a mixed C/C++ system. It's original goal was to compete with MythTV and Kodi, but it lost. When I picked it up I decided to strip it all back so as to be a lightweight player to complement rather than compete with MythTV and Kodi. It became very clear, very quickly that C++11 and indeed C++14 were not the right tools for the job (poor support for messaging between threads being the single biggest problem). I decided to do a re-write from scratch in D using GtkD and GStreamerD. It all went well, D provided all the tools for creating the right abstractions; the right data structures and algorithms were easy to express and the libraries gave really good access to the underlying C libraries. But… the GStreamer folk had rejected D as an officially supported language for plugins and official API wrapper/binding support. Does this matter given Mike's efforts keeping GtkD and GStreamerD up to date? In my case yes. I had to get involved in amendments to GStreamer itself and developing new API wrapper. I guess I could have kept going with D as the implementation language for Me TV, but it seemed right to switch to Rust, which is officially supported by the GStreamer folk, so lots of extra support for GStreamer changes and wrapper writing (I guess I will end up doing a D version for Mike to add to GStreamerD). It turns out that Rust is actually the wrong tool for the job of working with GObject systems and yet the GStreamer folk chose Rust because they abhorred C++ and assumed D always came with a garbage collector (which is true in this case) and they have a morbid hatred of garbage collection (true for some bits of GStreamer which are hard real time). What the gtk-rs people have done though is to provide an excellent (albeit not totally complete as yet) Rust inheritance system for GObject-based code. Of course D has inheritance and so no problem, D is better than Rust for this. Objectively D is the better language for GObject-based software, and yet Rust is in the driving seat. Is this another "everyone used C for applications programming but shouldn't have done" moment? Almost. Rust is fine for those cases where composition is the right abstraction approach. D can also do this, ditto Go, and indeed Java, Kotlin, etc. Where a core abstraction requirement is inheritance, as in GObject-based systems, D beats Rust. And yet the gtk-rs folk have used Rust anyway and created the abstractions. What is the moral behind this story of mixed
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: 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
Re: Using python in D
On Sat, 2019-06-08 at 16:53 +, rnd via Digitalmars-d-learn wrote: > […] > I did not delete Python2.7 since I thought there could be some > part of Debian/installed package that may depend on it. But I > will try to do it now. I overstated the case a bit. I do not use Python 2.7 but there are a few packages that are LaTeX, Samba, etc. related that still require Python 2. This is clearly an insane position but the Debian packages and/or the upstream applications have not been properly managed. There are one or two situations where Python 2 should still be used, but for 99.99% of situations Python 3 is the only choice. > I am not well versed with the procedure of submitting bug report > and will appreciate if you/some other expert on this forum does > it. PyD is hosted on GitHub so it is a question of putting in an issue there: https://github.com/ariovistus/pyd/issues The best bet is to write up what you have presented on email here, and then let the PyD developers guide you into providing the data they need to decide what the actual problem is and how it might be fixed. -- 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 Fri, 2019-06-07 at 14:02 +, rnd via Digitalmars-d-learn wrote:
This being D meets Python, I thought I'd take a look at this one.
> I tried following in dub.selections.json file:
>
> {
> "fileVersion": 1,
> "versions": {
> "pyd": "0.10.5"
> },
> "subConfigurations": {
> "pyd": "python35"
> }
> }
I do not use JSON for human constructed files, and whilst I think SDL
is inferior to TOML for these sorts of files, I am using the Dub
specification:
name "pyd_test"
description "A PyD project from rnd on the email list."
dependency "pyd" version="*"
subConfiguration "pyd" "python37"
which seems to do the job.
> I also tried python3.5 and python3 in place of python35, but
> everytime python27 is being used (where pandas is not installed).
> The error is:
I only have Python 3.7, I deleted Python 2.7 long ago, and always use
the latest Python on Debian (which may get a bit old during the stupid
process called Debian release freeze.
> $ dub run
> Performing "debug" build using /usr/bin/dmd for x86_64.
> pyd 0.10.5: target for configuration "python27" is up to date.
> <<< NOTE VERSON HERE;
> rntestpy ~master: building configuration "application"...
> Linking...
> To force a rebuild of up-to-date targets, run again with --force.
> Running ./rntestpy
> pyd.exception.PythonException@/home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/pydobject.d(59):
> exceptions.ImportError: No module named pandas
>
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/exception.d:46 void
> pyd.exception.handle_exception(immutable(char)[], ulong)
> [0x56438721e9e8]
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/pydobject.d:59 pyd.pydobject.PydObject
> pyd.pydobject.PydObject.__ctor(deimos.python.object.PyObject*)
> [0x56438721f2e8]
> /home/cardio/.dub/packages/pyd-
> 0.10.5/pyd/infrastructure/pyd/embedded.d:54 pyd.pydobject.PydObject
> pyd.embedded.py_import(immutable(char)[]) [0x56438721e501]
> source/main.d:6 _Dmain [0x56438721ded0]
> Program exited with code 1
>
> I also tried command "dub run --force" but still the error
> persists.
I am getting what appears to be the exact same problem:
|> dub
Performing "debug" build using /usr/bin/ldc2 for x86_64.
pyd 0.10.5: target for configuration "python37" is up to date.
pyd_test ~master: building configuration "application"...
To force a rebuild of up-to-date targets, run again with --force.
Running ./pyd_test
pyd.exception.PythonException@source/main.d(10):
NameError: name 'pandas' is not defined
exception.d:46 [0x564147a72be6]
embedded.d:283 [0x564147a72a23]
main.d:10 [0x564147a6fce1]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x7f8116bff12f]
??:? _d_run_main [0x7f8116bfef45]
__entrypoint.d:8 [0x564147a70314]
??:? __libc_start_main [0x7f81167d909a]
??:? [0x564147a6fb99]
Program exited with code 1
But I am quietly confident that pandas is installed into the standard
place:
|> aptitude search python3-pandas
i python3-pandas
- data structures for "relational" or "labeled" data -
Python 3
i A python3-pandas-lib
- low-level implementations and bindings for pandas - Python
3
So, a priori, this would seem to be a fault within PyD for not looking
up the right place for Python packages.
Having looked at the dub.json ( :-( ) file for PyD it seems that it is
looking in /usr/lib/python3.7m whereas on Debian the directory should
be /usr/lib/python3.7. I have no idea how to control this from a user
dub.sdl.
Of course the installed Python packages are in /usr/lib/python3/dist-
packages, at least on Debian, so the above shouldn't apply!
> I also tried to give command "source pyd_set_env_vars.sh
> /usr/bin/python3" but still it is not working.
>
> Another command which I tried produced following output but still
> the problem persisted:
>
> $ python3 pyd_get_env_set_text.py
> export PYD_D_VERSION_1=Python_2_4_Or_Later
> export PYD_D_VERSION_2=Python_2_5_Or_Later
> export PYD_D_VERSION_3=Python_2_6_Or_Later
> export PYD_D_VERSION_4=Python_2_7_Or_Later
> export PYD_D_VERSION_5=Python_3_0_Or_Later
> export PYD_D_VERSION_6=Python_3_1_Or_Later
> export PYD_D_VERSION_7=Python_3_2_Or_Later
> export PYD_D_VERSION_8=Python_3_3_Or_Later
> export PYD_D_VERSION_9=Python_3_4_Or_Later
> export PYD_D_VERSION_10=Python_3_5_Or_Later
> export PYD_D_VERSION_11=__PYD__DUMMY__
> export PYD_D_VERSION_12=__PYD__DUMMY__
> export PYD_D_VERSION_13=__PYD__DUMMY__
> export PYD_LIBPYTHON_DIR=/usr/lib
> export PYD_LIBPYTHON=python3.5m
This last one may well be the problem. Try manually adjusting it to
Re: How to create GTK+ apps with Glade and D on windows
On Fri, 2019-05-31 at 18:47 +, Obsidian Jackal via Digitalmars-d- learn wrote: > I'm new to D and want to create GTK+ apps. I have Visual Studio, > Glade, the Gtk+ runtime, DMD, and DUB installed. What steps, > guides, or advice should I follow to be able to be able to use > these tools together to make a sane app?. Many people ignore Glade and hand code the widget structure of their applications. For small and simple applications this is fine. I have done this for Me TV – though I have now switched from D to Rust for this application so no public D repository, long story. I did though use XML files (hand written, embedded in the compiled executable using D's string import) for the menus. For GFontBrowser (https://github.com/russel/GFontBrowser for now, I may well move the mainline repository to GitLab due to better integrated CI/CD) I use Glade and a gtk.Builder instance to read the Glade file – which is embedded into the compiled executable using string import rather than being a file on the filestore. This works very well, and allows all the layout to be done using a layout system rather than fiddling with lines of code. Deciding how much of the call-backs etc. to specify in the Glad file and how much to do in the code is something there seems to be no de facto standard on, so it is down to personal taste. I choose only to build the widget tree with Glade and do all the call-backs in code. I generally start small to get the hang of things and then progress towards the final application. If the UI has any complications I use Glade for layout. Reading Ron Tarrant's http://gtkdcoding.com/ will almost certainly be worth it, even if you disagree with some of his codes. GtkD and GStreamerD (Mike Wey's work) rock – though gtk-rs and gstreamer-rs are also excellent. -- 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: Meson build system user learning D.
On Mon, 2019-05-27 at 16:13 +, Mike Brockus via Digitalmars-d-learn wrote: > […] > > I tried that custom command voodoo then I tried to use 'dub' as a > method for hunting down dependencies. Basically got something > like this. Apologies but I am not sure what you have tried. Installing unit- threaded as a shared library is so as to build a D project without dub at all. What I didn't say in the previous email is that if you are installing libraries not to the standard place you have to set some environment variables. In my case, consistent with the build instructions I gave for my case: PKG_CONFIG_PATH=.:/home/users/russel/Built/share/pkgconfig:/home/users/russel/Built/lib/pkgconfig LD_LIBRARY_PATH=.:/home/users/russel/Built/lib Having . in the paths is not something everyone does though. > ''' > Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on > May 4 2019) > Dependency unit-threaded found: NO > > meson.build:71:0: ERROR: Dependency "unit-threaded" not found > ''' This seems like you are using Dub from within the Meson/Ninja build, this is not something I do. I know you can use Dub from Meson to deal with dependencies, but this is not something I do. I build all the dependencies and then build the application without Dub. If using Dub from Meson to handle dependencies becomes the de facto standard I'll give it a whirl. -- 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: Meson build system user learning D.
On Thu, 2019-05-23 at 04:21 +, Mike Brockus via Digitalmars-d-learn wrote: > […] > > That is cool that Atila was kind enough to accept the meson.build > file. But how do I use the written meson.build that is > apparently in the subdirectory directory "build"? Just asking > because normally I see a meson.build in the root of the project. Having the meson.build in the project root directory is the norm, and that was where I put it originally. However, Atila chose to leave only the Dub build in the root directory and place all other build-related files in the build directory. This is not a problem since Meson is entirely happy with that structure. I have my clone of unit-threaded in ~/Repositories/Git/Fork/Unit_Threaded and I build in ~/BuildArea/Unit_Threaded. My meson command in the build directory is: meson --prefix=$HOME/Built ~/Repositories/Git/Fork/Unit_Threaded/built and this works fine. I then build and install using Ninja. To date it all works for me. If you try this and something goes wrong put an issue on the unit-threaded GitHub project area and email me in case I don't get a notification from the issue system. -- 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: Bitfields
On Tue, 2019-05-21 at 19:14 +, Era Scarecrow via Digitalmars-d-learn wrote: > […] > I worked on/with bitfields in the past, the limit sizes is more > or less for natural int types that D supports. Rust bitfield crate and it's macros are the same, the underlying type for a bitfield must be a primitive integer type. Fortunately, Rust has i128 and u128 which is enough for my 112 bit EIT header. Boris Barboris suggested using BitArray and I willinvestigate but the size_t/byte problem would need to go away. > However this limitation is kinda arbitrary, as for simplicity it > relies on shifting bits, going larger or any byte size is > possible depending on what needs to be stored, but ti's the speed > that really takes a penalty when you aren't using native types or > you have to do a lot of shifting to get the job done. > > What's the layout of what you need? I'll see if i can't make > something that would work for you. > > Would be better if you can use a object that breaks the parts > down and you can actually fully access those parts, then just > re-store it into the limited space you want for storage, which > then would be faster than bitfields (although not by much) I found an interesting way forward in the source code of dvbsnoop. It basically uses the byte sequence as a backing store and then has a function to do the necessary accesses to treat it as a bit array. If D's Bit Array can work with bytes instead of size_t then it is exactly what dvbsnoop does (in C) but adds writing as well as reading. The Rust solution using bitfield with a u128 backing it seems to work, but it is all very clumsy even if it is efficacious. -- 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: Bitfields
On Tue, 2019-05-21 at 18:22 +, Boris-Barboris via Digitalmars-d-learn wrote: […] > > Never used it myself, but BitArray with careful handling of > endianess might fit your task. > > https://dlang.org/phobos/std_bitmanip.html#.BitArray.this.2 > https://dlang.org/phobos/std_bitmanip.html#.peek I'll have to mull that one over. The incoming data is a sequence of bytes that is treated as a bitfield. Although the standard says "big-endian" it is isn't entirely clear how this relates to the bitfields, I guess I need to read the standard more. :-( I guess the question is whether BitArray can work with bytes rather than size_t as elements of the backing array. -- 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
Bitfields
Hi, Has anyone used D to work with arbitrary length bitfields with multiple occurences of a sub-bitfield. I am working with DVB Sections and EIT packets are defined as bitfields with loops in them and the header is 112 bits. The loops are handleable with subfields obviously, assuming you can work out how the bigendian works on the byte sequence. As far as I can see std.bitmanip only caters for 8, 16, 32, and 64 bit long bitfields. -- 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: Meson build system user learning D.
On Tue, 2019-05-21 at 05:21 +, Mike Brockus via Digitalmars-d-learn wrote: > […] > The solution from Reddit solves the problem for 'dub' but as part > of my project C to D I wanted to use Meson and run test with > whatever is available, coming next week I will try to incorporate > 'unit-threaded' and if it works then I can tell Meson to include > it as my decency and to use 'dub' to get it for me so I can focus > on writing test for my code. I am currently working on becoming > an Android app developer leaning Kotlin and on the weekends it's > D. I use unit-threaded for my D code tests. Atila was kind enough to allow me to add a Meson build to unit-threaded. I therefore build and install a shared library of unit-threaded so as to avoid use of Dub in the Meson build of my D projects. > […] > > However it is good to know that there is currently no compiler > for D on a AVR chip. I thought GCC had an AVR backend so that GDC provides D on AVR. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: is there a way to embed python 3.7 code in D program?
On Sun, 2019-05-12 at 20:06 +, torea via Digitalmars-d-learn wrote: > Hi, > > I'd like to use D for the "brain" of a small robot (Anki vector) > whose API is coded in Python 3.6+. > I had a look at Pyd but it's limited to python 2.7... PyD works entirely fine for me using Python 3.7. I am using PyD 0.10.5 from PyPI > Would there be other ways to call python functions and retrieve > the python objects (including camera image) inside a D program? > > Best regards -- 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 fetch
Hi, Is there a way of asking which version of package XXX "dub fetch XXX" will actually fetch. I would like to avoid checking the contents of ~/.dub/packages before and after. -- 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/Phobos/Types problem — panic level due to timing.
On Thu, 2019-05-09 at 08:33 +, John Colvin via Digitalmars-d-learn wrote: > […] > > Not big benefit in this case, very big benefit with longer chains. > > It reads in the order of operations, as opposed to inside out. John, Coming from a Haskell/Lisp background to declarative expression, I do not have a problem with the function application approach. However if the audience are more likely to understand the method application approach (and this is fundamentally a Java audience) then that is the way of should be shown. I showed the variant you suggested. :-) -- 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/Phobos/Types problem — panic level due to timing.
On Wed, 2019-05-08 at 11:56 +, Alex via Digitalmars-d-learn wrote: > On Wednesday, 8 May 2019 at 11:53:34 UTC, Russel Winder wrote: > > On Mon, 2019-05-06 at 15:53 +, John Colvin via > > Digitalmars-d-learn wrote: > > > […] > > > > > > pretty please show people it with UFCS: > > > > > > recurrence!((a, n) => a[n-1] + a[n-2])(zero, one) > > > .dropExactly(n) > > > .front > > > > Any particular reason for preferring this form over the > > original? > > For example, It is more readable, as the order of execution is > unwinded. I think there is an individual element to this, and what people are used to. However I have taken John's request and changed the line he wanted changed. -- 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/Phobos/Types problem — panic level due to timing.
On Mon, 2019-05-06 at 15:53 +, John Colvin via Digitalmars-d-learn wrote: > […] > > pretty please show people it with UFCS: > > recurrence!((a, n) => a[n-1] + a[n-2])(zero, one) > .dropExactly(n) > .front Any particular reason for preferring this form over the original? -- 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/Phobos/Types problem — panic level due to timing.
On Sunday, 5 May 2019 at 19:34:05 UTC, Nicholas Wilson wrote: On Sunday, 5 May 2019 at 19:18:47 UTC, lithium iodate wrote: [...] Yep https://run.dlang.io/is/XsLrRz works for me, https://run.dlang.io/is/KxY0e9 doesn't. Thanks people. I now have a working code. :-)
Re: Any full feature xml library available?
On Fri, 2019-05-03 at 14:07 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > The problem is that while there is no shortage of complaints about XML > support in D, there is a great dearth of people actually willing to *do* > something about it. In my case it is because I have no need to deal with XML using D, and I am not in the market for paid work. Those actually doing stuff with XML and D have far fewer excuses. > At least Jonathan wrote dxml, which arguably would meet the need in most > cases. So there's that. But if somebody wants entity references and > other similar things, the only recourse would appear to be to wrap > libxml2. Given D's aptitude at interfacing with C, this should be much > simpler than writing dxml. It just needs someone to sit down and *do* > it. That people who have the problem can write many lengthy emails on the D lists rather than doing something about creating a D binding to libxml2 is clearly the bulk of the problem. -- 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
Compiler/Phobos/Types problem — panic level due to timing.
Hi, I had merrily asumed I could implement nth Fibonacci number with: takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying: /usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) /usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) fibonacci.d(25): Error: template instance `fibonacci.declarative.recurrence!((a, n) => a[n - 1] + a[n - 2], immutable(BigInt), immutable(BigInt))` error instantiating /usr/include/dmd/phobos/std/range/package.d(5720): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are: /usr/include/dmd/phobos/std/bigint.d(178): std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T) /usr/include/dmd/phobos/std/bigint.d(194):std.bigint.BigInt.opAssign(T : BigInt)(T x) /usr/include/dmd/phobos/std/range/package.d(3177): Error: template instance `std.range.primitives.isInputRange!(Recurrence!(__lambda2, immutable(BigInt), 2LU))` error instantiating fibonacci.d(25): Error: template std.range.drop cannot deduce function from argument types !()(Recurrence!(__lambda2, immutable(BigInt), 2LU), immutable(ulong)), candidates are: /usr/include/dmd/phobos/std/range/package.d(3176):std.range.drop(R)(R range, size_t n) if (isInputRange!R) I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation? I am close to giving up and imbibing of too much Pernod. -- 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: Any full feature xml library available?
On Thu, 2019-05-02 at 09:28 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > On Thu, May 02, 2019 at 05:23:29PM +0100, Russel Winder via > Digitalmars-d-learn wrote: > [...] > > There are situations where you create a binding in preference to > > writing something from scratch. cf. gtk, gstreamer, etc. so why not > > libxml2? > [...] > > No particular reason, except nobody has taken up the task yet. Would > you? If I were interested in XML processing yes I would. However, just at the moment I am doing things with MPEG-TS and gstreamer-rs. I may investigate the analogue for GstreamerD. On the other hand there are enough people moaning about std.xml and the general lack of quality, high performance D support for XML that there is clearly a lot of people who should be interested in creating a D binding to libxml2. -- 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 - Git training Lon/HK and book recommendation on taste in programming
On Wed, 2019-05-01 at 09:51 +, Laeeth Isharc via Digitalmars-d- learn wrote: > Hi. > > First question - can anyone recommend git / Gitlab training > providers in HK and London? Two distinct audiences - highly > intelligent people that may or may not really program, and > experienced developers with a finance background that could > benefit from knowing how to use git properly (finance is often in > the dark ages). There were some sessions on Git at ACCU 2019 they might prove useful to the programmer audience, but definitely not the non-programmer audience! The presenters of the sessions are, I believe full time employees and so not available for training workshops. Some of them would be fine with programmers and totally useless with non-programmers. Some of them though have the empathy to work with either. It might be worth approaching them to see if they are interested in "on the side" work. Otherwise there are some UK-based trainers who know Git well enough, and have the empathy to deal with the non-programmers, but whether they could stay ahead of the programmers with Git is an open question. But then co-learning is a standard approach if they know that way of working. -- 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: Any full feature xml library available?
On Fri, 2019-05-03 at 03:50 +1200, rikki cattermole via Digitalmars-d- learn wrote: > On 03/05/2019 3:36 AM, Russel Winder wrote: > > […] > > libxml2 is definitely usable from Python, it must be usable from D. > > Of > > course, I am assuming libxml2 has the facilities required. > > libxml2 is precisely what I meant. > > We just don't have the libraries written in D at this point. There are situations where you create a binding in preference to writing something from scratch. cf. gtk, gstreamer, etc. so why not libxml2? -- 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: Any full feature xml library available?
On Thu, 2019-05-02 at 02:11 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] > > It does not. Those features come under the big bad guys feature list. > > Gonna have to go to C for it. Surely that means you can use Python, Rust, C++, or D rather than having to descend to using C? libxml2 is definitely usable from Python, it must be usable from D. Of course, I am assuming libxml2 has the facilities 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
Re: GTK Scale/Volume Buttons Show Muted Icon on Startup
On Thu, 2019-04-25 at 11:36 +, Ron Tarrant via Digitalmars-d-learn wrote: > I've scoured the docs, the wrapper code, the Internet, but can't > come up with an explanation... > > When running this example of a VolumeButton, no matter what the > initial value of the slider, the icon showing is > audio-volume-muted. Experience with Me TV in D/GtkD/GStreamerD and Rust/gtk-rs/gstreamer-rs indicates that volume buttons and adjustments in GTK+ have issues, this is not a GtkD or gtk-rs thing it seems to be a GTK+ thing. If I remember correctly, you have to set up the volume button, set the initial volume, then set up and add the adjustment, and then reset the initial value via the adjustment to get the icon correct. Memory on this is hazy as it was a while ago, I got it working and then left it alone, untouched. -- 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
