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: 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
[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 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
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 messa
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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: 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 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: 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: 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: 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: 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 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: 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
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: 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
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: 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
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: 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: 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 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
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: 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
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: 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: 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
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
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
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
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 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
Dub and Unit_Threaded
This seems nonsensical to me. Why is Dub using the correct (0.10.8) version of Unit_Threaded for building the tests, but then using an earlier version (0.10.6) for building and running the test. If I remove 0.10.6 from the .dub/packages directory, then it uses 0.10.8 correctly. Then it complains about DFLAGS for reasons unknown. Yours Confused of Clapham Junciton. |> dub test Running custom 'unittest' configuration. Performing "unittest" build using /usr/bin/ldc2 for x86_64. gtk-d:gtkd 3.9.0: target for configuration "library" is up to date. unit-threaded:from 0.10.8: target for configuration "library" is up to date. unit-threaded:exception 0.10.8: building configuration "library"... unit-threaded:assertions 0.10.8: building configuration "library"... unit-threaded:integration 0.10.8: building configuration "library"... unit-threaded:mocks 0.10.8: building configuration "library"... unit-threaded:property 0.10.8: building configuration "default"... unit-threaded:runner 0.10.8: building configuration "library"... unit-threaded 0.10.8: building configuration "library"... arcamclient ~master: building configuration "unittest"... Running pre-build commands... Building package unit-threaded in /home/users/russel/.dub/packages/unit- threaded-0.10.6/unit-threaded/ Performing "$DFLAGS" build using /usr/bin/ldc2 for x86_64. unit-threaded:from 0.10.6: building configuration "library"... unit-threaded:exception 0.10.6: building configuration "library"... unit-threaded:assertions 0.10.6: building configuration "library"... unit-threaded:integration 0.10.6: building configuration "library"... unit-threaded:mocks 0.10.6: building configuration "library"... unit-threaded:property 0.10.6: building configuration "library"... unit-threaded:runner 0.10.6: building configuration "library"... unit-threaded 0.10.6: building configuration "gen_ut_main"... Linking... Running ../../../../../.dub/packages/unit-threaded-0.10.6/unit- threaded/gen_ut_main -f bin/ut.d -d /usr/bin/dub Building package arcamclient:mock_avr850 in /home/users/russel/Repositories/Git/Masters/Private/ArcamClient_D/ Performing "$DFLAGS" build using /usr/bin/ldc2 for x86_64. arcamclient:mock_avr850 ~master: building configuration "application"... Linking... Linking... To force a rebuild of up-to-date targets, run again with --force. Invalid variable: DFLAGS -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
D and Async I/O
OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this is a real server ;-) ). I think the normal response is "Use Vibe.d". However, recently I see Hunt is an alternative. Has anyone any way of choosing between the two? I notice that Hunt uses it's own library eschewing all of Phobos. Is this an indicator that Phobos is not suitable for networking activity? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GUI library for DMD 2.090 or DMD 2.091
On Mon, 2020-04-27 at 12:12 +, Antonio Corbi via Digitalmars-d-learn wrote: > On Monday, 27 April 2020 at 11:27:57 UTC, Paulo Pinto wrote: > > On Sunday, 26 April 2020 at 09:09:04 UTC, Antonio Corbi wrote: […] > > > I don't know if you are referring to the `clone!` macro > > > described here[1] > > > > > > [1] https://gtk-rs.org/blog/2019/12/15/new-release.html > > > > > > Antonio > > > > Hi, this macro is new to me, it did not exist when I tried to > > have a go at Gtk-rs, so it simplifies not having to write such > > boilerplate ourselves, but like the author mentions it doesn't > > make it go away, it just gets hidden behind the macro. > > Hi, > > Yes, previously this macro lived (in a simplified form, i.e. no > @strong) in the examples provided by the gtk-rs developers. Now > it's part of the gtk-rs bindings. I have not found any real need to use that clone! macro. I have found it straightforward, and easy, to clone the variables required so they can be moved. It also seems self-documenting, making the cloning obvious. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Integration tests
On Wed, 2020-04-22 at 11:19 +, aliak via Digitalmars-d-learn wrote: > On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: > > Now I discover Python, Rust, and Go have far nicer abstractions > > for writing Internet code than D does. Does D really not have a > > TcpListener abstraction? > > It really doesn't :( :-( Even GTK+ has it's own wrappers around the base socket API to make it sensible for programmers. GtkD offers these for GtkD-based applications, but D has no language support for asynchronous (via Futures/Promises/event loops) which leaves Rust (and Python) far ahead in this race to support asynchronous programming. > And D has so much potential as server tech with the potential > combination of fibers + TLS + shared + static introspection. Potential is necessary but not sufficient. Vibe.d seems to be one solution (in the Rust Async_std and Tokio sense) but Rust has language level support for Futures that make everything a lot easier in Rust than seemingly in D. > The package Vibe-d is quite nice though. I don't know if you've > tried it but it's very simple to get a listener up with it. And now it seems we have Hunt. I am now dithering whether to use Vibe.d or Hunt for my async TCP (but not HTTP(S)) server. […] -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D and Async I/O
On Mon, 2020-05-11 at 15:02 +0100, Russel Winder wrote: > OK, so I need to create an asynchronous TCP server (not HTTP or HTTPS, this > is > a real server ;-) ). > > I think the normal response is "Use Vibe.d". However, recently I see Hunt is > an alternative. Has anyone any way of choosing between the two? > > I notice that Hunt uses it's own library eschewing all of Phobos. Is this an > indicator that Phobos is not suitable for networking activity? Of course the really obvious solution would be to use the GTK+ event loop and GtkD API binding even though the server has no UI since it is a server that is part of the integration tests for a GtkD realised GUI desktop application. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D and Async I/O
On Mon, 2020-05-11 at 16:36 +0200, Daniel Kozak via Digitalmars-d-learn wrote: > On Mon, May 11, 2020 at 4:03 PM Russel Winder via Digitalmars-d-learn > wrote: > > ... > > I notice that Hunt uses it's own library eschewing all of Phobos. Is this > > an > > indicator that Phobos is not suitable for networking activity? > Vibe-d do that too, But https://code.dlang.org/packages/async use > phobos socket and works well Crickey, a third option. This wil increase my dithering! ;-) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: 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 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 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
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, 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
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 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: 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
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
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
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
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
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: 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
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 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 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
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: 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
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: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
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
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
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
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
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 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: Windows to Linux Porting
On Fri, 2018-05-04 at 03:30 +, Vino via Digitalmars-d-learn wrote:
> Hi All,
>
>Request you help on the below code, the below code always state
> the file does not exist even if the file do exist.
>
> Code:
>
> import core.stdc.stdlib: exit;
> import std.stdio;
> import std.file;
> import std.path;
>
> auto osSwitch () {
> string ConfigFile;
> version (Windows) { ConfigFile = absolutePath(`.\nasconfig.txt`);
`./nasconfig.txt`
perhaps: Linux uses / (as does Windows in fact) for directory separator.
> } else version (Linux) { ConfigFile =
> absolutePath(`nasconfig.txt`); }
> return ConfigFile;
> }
> void main () {
> auto ConfigFile = osSwitch;
> if (!ConfigFile.exists) { writeln("The Configuration File ",
> buildNormalizedPath(ConfigFile), " do to exist, Terminating the
> execution.."); exit(-1);}
> else { writeln(ConfigFile); }
> }
>
> From,
> Vino.B
>
--
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: Windows to Linux Porting
On Fri, 2018-05-04 at 08:47 +, Vino via Digitalmars-d-learn wrote: > […] > Was able to resolve the issue, the issue was the letter "L" in > version (Linux) where is should be version (linux). It would have helped if I had read the code first rather than jumped to a conclusion. :-) -- 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: Windows to Linux Porting - timeCreated and timeLastAccessed
On Fri, 2018-05-04 at 08:02 -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > […] > Linux does not keep track of the creation time of a file. So, it will not > work to have a program on Linux ask a file how long it's been since the file > was created. If you want that information, you'll have to store it elsewhere […] Linux itself doesn't but most filesystems certainly do. Ext4 definitely does. https://unix.stackexchange.com/questions/7562/what-file-systems-on-linux-store -the-creation-time -- 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
Temporary file creation for unittests
Hi, What's the current official position on how to create temporary files for use during a unittest. I found https://github.com/dlang/phobos/pull/5788 but it seems to be languishing in the "we have discussed all the issues that no-one will ever have a problem with" phase. What to do between now and when there is an LDC release that has the result of the merge? -- 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: Temporary file creation for unittests
On Mon, 2018-05-21 at 15:16 +, Atila Neves via Digitalmars-d-learn wrote:
> On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote:
> > Hi,
> >
> > What's the current official position on how to create temporary
> > files for use during a unittest. I found
>
> Not official, but...
>
> import unit_threaded;
>
> with(const Sandbox()) {
> writeFile("myfile.txt", "contents");
> shouldExist("myfile.txt");
> shouldEqualContent("myfile.txt", "contents");
> fileShouldContain("myfile.txt", "cont");
> }
>
> Atila
OK, we like this. A lot.
Given I use Unit-Threaded, why did I not know this. Ah, OK, RTFM. :-)
Did I mention how much I like this RAII approach?
--
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
ldc2 and dmd
Hi, I have a shared object (of DInotify) compiled with ldc2. I have a program (me-tv) which seems to work when compiled with ldc2. If I compile the program (me-tv) with dmd then it throws a SIGSEGV seemingly in _D3std4file15DirIteratorImpl5frontMFNdNfZSQBoQBn8DirEntry in DInotify. Is this what I should expect? -- 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
Stopping compile time execution
I have a bit of code which is the definition of a class Preferences,
which has:
this() {
filePath = expandTilde(chainPath("~", ".config", "me-tv",
"preferences.yml").array);
filePath is a member of the class. Now if I have a module level
instance (clearly not a good move but OK for now):
public auto preferences = new Preferences;
then Dub using DMD on Debian Sid gives me:
/usr/include/dmd/phobos/std/path.d(3970,31): Error: getenv cannot be
interpreted at compile time, because it has no available source code
/usr/include/dmd/phobos/std/path.d(4064,41):called from here:
expandFromEnvironment(inputPath)
source/preferences.d(36,25):called from here:
expandTilde(array(chainPath("~", ".config", "me-tv", "preferences.yml")))
What is the official way of getting preferences initialised at run time
and not compile time.
--
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: Stopping compile time execution
On Sat, 2018-05-26 at 04:00 +1200, rikki cattermole via Digitalmars-d- learn wrote: > […] > > Use a module constructor to initialize your global. Splendid idea! :-) I know, I should have thought of that. I note that if you click "Constructor" on https://dlang.org/spec/module .html you get taken to https://dlang.org/spec/class.html#Constructor which really does help describe the concept of a module constructor. -- 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's the purpose of the 'in' keyword ?
On Sun, 2018-05-27 at 13:10 +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Sunday, 27 May 2018 at 13:02:23 UTC, loloof64 wrote: > > What's the purpose of this 'in' keyword ? I could not process a > > good Google request to get an answer. > > It means you are taking the parameter in to look at, but not > modify or store. > > Basically "const". (well, for now, literally "const" but that can > change with other details) Is there an easy set of "rules" as to when to use 'const' and when to use 'in'? In a situation where there are multiple ways of expressing the same concept there needs to be idioms to guide people to do the right thing in a given context. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+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 do I break from loop when using parallel()?
On Mon, 2018-05-28 at 21:04 +, Dr.No via Digitalmars-d-learn wrote:
> import std.parallelism : parallel;
> foreach(t; parallel(arr))
> {
> if(!doSomething(t)) {
> return false;
> }
> }
>
> It reuturns the run time error:
>
> > std.parallelism.ParallelForeachError@(0): Cannot break from a
> > parallel foreach loop using break, return, labeled
> > break/continue or goto statements.
>
> What's the proper way to break from loop?
It isn't a loop, it is a task scatter/gather, with each task running to
completion independent of all other tasks. Thus the concept of
break/return doesn't exist.
It could be argued that this is a bad use of foreach, but it is what it
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
spawn, send, and receive
I am fiddling again with writing a D version of Me TV to compare with the C++ (already declared dead), and the Rust version (currently the 'real' version). From the main thread (which eventually becomes the GTK+3 event loop thread) I spawn three threads to create "actors" that pass messages. Actually it is a pipeline. 1 → 2 → 3 The intention will then be that Actor 3 communicates with the GTK+3 event loop in whatever way is allowed. All three threads seem to start. 3 always goes straight into receive. In some circumstances 2 sends messages to 3 before it enters it's receive, in other circumstances it goes straight into receive. 1 alternates between a listening activity not to do with the threads and a receive (for termination). 1 and 2 are seen to execute sends to the correct Tid, but no receive ever executes. I tried putting Variant as the last option to see if there were message but just of the wrong type, and… no message received. It seems that receive is blocking and never being triggered even though provably there are sends that should trigger a receive. So I assume I am doing something very silly that causes this, or my code is wrong in some other way. The code is at: https://github.com/russel/Me-TV_D src/inotify_daemon.d contains Actor 1 code. src/frontend_manager.d contains Actor 2 code. src/control_window.d contains Actor 3 code. src/main.d has the startup code. -- 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: spawn, send, and receive
It seems that the receive function, immediately on processing a message, is terminating it's thread silently. So the question now is under what circumstances does std.concurrency.receive exit its thread without notice? On Thu, 2018-05-31 at 17:29 +0100, Russel Winder wrote: > I am fiddling again with writing a D version of Me TV to compare with > the C++ (already declared dead), and the Rust version (currently the > 'real' version). > > From the main thread (which eventually becomes the GTK+3 event loop > thread) I spawn three threads to create "actors" that pass messages. > Actually it is a pipeline. > > 1 → 2 → 3 > > The intention will then be that Actor 3 communicates with the GTK+3 > event loop in whatever way is allowed. > > All three threads seem to start. 3 always goes straight into receive. > In some circumstances 2 sends messages to 3 before it enters it's > receive, in other circumstances it goes straight into receive. 1 > alternates between a listening activity not to do with the threads > and > a receive (for termination). 1 and 2 are seen to execute sends to the > correct Tid, but no receive ever executes. I tried putting Variant as > the last option to see if there were message but just of the wrong > type, and… no message received. It seems that receive is blocking and > never being triggered even though provably there are sends that > should > trigger a receive. > > So I assume I am doing something very silly that causes this, or my > code is wrong in some other way. > > The code is at: > > https://github.com/russel/Me-TV_D > > src/inotify_daemon.d contains Actor 1 code. > src/frontend_manager.d contains Actor 2 code. > src/control_window.d contains Actor 3 code. > > src/main.d has the startup code. > -- 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
Debugging silent exit of threads in Phobos calls
So I had a play and gdb seems to be useless for trying to find out why calls to std.concurrency.receive exit silently. Obviously std.concurrency.receive should never terminate a thread, and it should never terminate a thread silently, but given that it clearly does (using dmd 2.080 from d-apt on Debian Sid) how is one to find out useful information as to why it is exiting silently. -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 09:31 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > On 6/1/18 7:12 AM, Russel Winder wrote: > > So I had a play and gdb seems to be useless for trying to find out > > why > > calls to std.concurrency.receive exit silently. > > > > Obviously std.concurrency.receive should never terminate a thread, > > and > > it should never terminate a thread silently, but given that it > > clearly > > does (using dmd 2.080 from d-apt on Debian Sid) how is one to find > > out > > useful information as to why it is exiting silently. > > I remember something like a receive thread that throws terminates > silently. Do a try/catch to see if it's that. Tried to catch Exception but that failed to work, fortunately remembered to catch Throwable and it turned out to be a receive threw an exception core.exception.AssertError@/usr/include/dmd/phobos/std/variant.d(323): It seems that the type frontend_manager.FrontendAppeared is not the same as frontend_manager.FrontendAppeared. :-( Who knew. -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 16:37 +0300, ketmar via Digitalmars-d-learn wrote: > […] > yeah. if it receives something it doesn't expect (and there is no > `Variant` > clause to catch it), it throws. and exceptions from threads are > silently > dropped on the floor -- along with the dead threads. so it is better > to > always wrap your threads in `try/catch`, and at least log an > exception. It seems that in the case he presence of the Variant doesn't matter. The message sent is of type frontend_manager.FrontendAppeared and one of the receive types is frontend_manager.FrontendAppreared yet this fails to match but it is not treated as a Variant. The stack trace is: ControlWindowDaemon: receive threw an exception core.exception.AssertError@/usr/include/dmd/phobos/std/variant.d(323): FrontendAppeared ??:? _d_assert_msg [0x55e72826] ??:? bool std.variant.VariantN!(32uL).VariantN.handler!(frontend_manager.FrontendAppeared).handler(std.variant.VariantN!(32uL).VariantN.OpID, ubyte[32]*, void*).tryPutting(frontend_manager.FrontendAppeared*, TypeInfo, void*) [0x55ba1dc1] ??:? long std.variant.VariantN!(32uL).VariantN.handler!(frontend_manager.FrontendAppeared).handler(std.variant.VariantN!(32uL).VariantN.OpID, ubyte[32]*, void*) [0x55ba1949] ??:? inout @property inout(frontend_manager.FrontendAppeared) std.variant.VariantN!(32uL).VariantN.get!(frontend_manager.FrontendAppeared).get() [0x55b9fadf] ??:? void std.concurrency.Message.map!(void function(frontend_manager.FrontendAppeared) @safe*).map(void function(frontend_manager.FrontendAppeared) @safe*) [0x55b9fa9c] ??:? bool std.concurrency.MessageBox.get!(void function(frontend_manager.FrontendAppeared) @safe*, void function(frontend_manager.FrontendDisappeared) @safe*, void delegate(std.concurrency.OwnerTerminated) @safe).get(scope void function(frontend_manager.FrontendAppeared) @safe*, scope void function(frontend_manager.FrontendDisappeared) @safe*, scope void delegate(std.concurrency.OwnerTerminated) @safe).onStandardMsg(ref std.concurrency.Message) [0x55b9f3b4] ??:? bool std.concurrency.MessageBox.get!(void function(frontend_manager.FrontendAppeared) @safe*, void function(frontend_manager.FrontendDisappeared) @safe*, void delegate(std.concurrency.OwnerTerminated) @safe).get(scope void function(frontend_manager.FrontendAppeared) @safe*, scope void function(frontend_manager.FrontendDisappeared) @safe*, scope void delegate(std.concurrency.OwnerTerminated) @safe).scan(ref std.concurrency.List!(std.concurrency.Message).List) [0x55b9f834] ??:? bool std.concurrency.MessageBox.get!(void function(frontend_manager.FrontendAppeared) @safe*, void function(frontend_manager.FrontendDisappeared) @safe*, void delegate(std.concurrency.OwnerTerminated) @safe).get(scope void function(frontend_manager.FrontendAppeared) @safe*, scope void function(frontend_manager.FrontendDisappeared) @safe*, scope void delegate(std.concurrency.OwnerTerminated) @safe) [0x55b9f2c8] ??:? void std.concurrency.receive!(void function(frontend_manager.FrontendAppeared) @safe*, void function(frontend_manager.FrontendDisappeared) @safe*, void delegate(std.concurrency.OwnerTerminated) @safe).receive(void function(frontend_manager.FrontendAppeared) @safe*, void function(frontend_manager.FrontendDisappeared) @safe*, void delegate(std.concurrency.OwnerTerminated) @safe) [0x55b9f0ec] ??:? void control_window.runControlWindowDaemon() [0x55b9edb3] ??:? void std.concurrency._spawn!(void function()*)._spawn(bool, void function()*).exec() [0x55ba3f4f] ??:? void core.thread.Thread.run() [0x55e739a7] ??:? thread_entryPoint [0x55ea5267] ??:? [0xf79bd5a9] -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 07:59 -0700, Ali Çehreli via Digitalmars-d-learn wrote: > On 06/01/2018 04:12 AM, Russel Winder wrote: > > > Obviously std.concurrency.receive should never terminate a thread, > > and > > it should never terminate a thread silently, but given that it > > clearly > > does (using dmd 2.080 from d-apt on Debian Sid) how is one to find > > out > > useful information as to why it is exiting silently. > > It sounds like one of the message handlers is throwing. In that case, > it > sounds like a good idea to wrap each handler with try-catch. The try/catch allows one to see that there appears to be a problem inside Phobos, i.e. it determines that x.X is not the same type as x.X and throws an assertion error. To handle this in the application is to accept that Phobos is broken and not fixable. :-( Unless this is actually just that x.X is not x.X even though it is x.X. In this case it would be a module naming error in D and Phobos is not wrong. > […] -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 17:53 +0300, ketmar via Digitalmars-d-learn wrote: > […] > it looks like "// type T is not constructible from A" phobos > assertion > triggered. that is, std.variant cannot wrap the struct, and all hell > breaks > loose. An instance of FrontendAppeared is created in frontend_manager module and sent to the actor defined in control_window module which has: import frontend_manager: FrontendAppeared It seems the symbol FrontendAppeared in control_window is matching the FrontendAppeared type of the message sent, and yet the assertion fails. -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 18:21 +0300, ketmar via Digitalmars-d-learn wrote: > […] > it may be something with struct copying. variant wants to copy a > struct > into itself, and somehow failed. either there is no room, or > something > prevented it to do that. it is hard to say more without full source > code. Full source is at: https://github.com/russel/Me-TV_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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 11:20 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > That assertion is something that should never happen. Something is > wrong > with the type checking here. > > If you look up earlier, clearly the type id matches. There is > something > weird about that static if that is not working. > > Can you put in some more debug messages and see what the exact types > of > A and T are? Just put it right before the assert. > The assert is in Phobos, so I am not sure I can. (Sorry to sound like a beginner at this, it is probably because I feel like one just at the moment!) -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 09:56 -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 06/01/2018 09:40 AM, Russel Winder wrote:
>
> > The assert is in Phobos, so I am not sure I can.
>
> Not the cleanest solution but one can always "carefully" :) edit the
> installed Phobos files. Mine are under /usr/include/dmd/phobos/std/
> It
> will most likely work as they are almost always templates, meaning,
> compiled with your code.
>
> Ali
I may have avoided needing to do this. If I change my stripped down
trial code from using:
struct Message {
int counter
}
to using the equivalent of what happens in Me TV:
struct Datum {
public const int a;
public const int b;
}
struct Message {
Datum datum;
}
Then my stripped down trial code fails in a not dissimilar way. I think
therefore this is a bug in Phobos.
I'll trim this sample code down to the minimum so it can be used in the
test suite of Phobos creating a red.
--
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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 18:30 +0100, Russel Winder wrote:
> […]
>
> I'll trim this sample code down to the minimum so it can be used in
> the
> test suite of Phobos creating a red.
>
Here it is, a small bit of code that breaks Phobos'
std.concurrency.receive.
import core.thread: Thread;
import core.time: seconds;
import std.concurrency: Tid, OwnerTerminated, receive, receiveTimeout, send,
spawn;
import std.conv: to;
import std.stdio: writeln;
struct Datum {
public const int a;
public const int b;
}
struct Message {
Datum datum;
}
void sender(Tid receiver) {
writeln("Sender sending.");
receiver.send(Message(Datum(0, 0)));
writeln("Sender finished.");
}
void receiver() {
writeln("Receiver going into receive.");
try {
receive(
(Message message) {
writeln("Receiver received ",
to!string(message));
},
);
} catch (Throwable t) {
writeln("Receiver receive threw " ~ to!string(t));
}
writeln("Receiver finished.");
}
void mainloop() {
Thread.sleep(2.seconds);
}
int main() {
auto receiver = spawn(&receiver);
spawn(&sender, receiver);
mainloop();
return 0;
}
--
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: Debugging silent exit of threads in Phobos calls (bugzilla issue submitted)
On Fri, 2018-06-01 at 14:02 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > Perfect, put this into a bugzilla entry. Most definitely it's a bug > in > phobos, it's clear from the assert(false, ...) which is NEVER meant > to > happen. Bug report submitted. https://issues.dlang.org/show_bug.cgi?id=18934 Hopefully it is easy to fix and 2.081 can be released quickly as my only way forward is to hack the code to avoid the problem which then essentially destroys the abstractions. OK so it would be a retrievable hack, but one has to draw the line somewhere. Also I have to stop having fun with Me-TV_D and get back on to organising ACCU 2019. It is time D people submitted sessions to ACCU: ACCU 2018 had lots of Rust sessions to counterbalance the C++ stuff and it went down well. > BTW, yes I was saying edit the global phobos sources :) I do this > all > the time to try and debug something. You just have to remember to put > it > back the way it was. In this case, you would just be printing > something > before crashing, so it actually could stay there. > > One "nice" aspect of pretty much everything being a template. I get ldc2 from the Debian/Fedora repositories and dmd from d-apt (no Fedora equivalent) I really want to avoid fiddling with files that are installed via packaging. Though I guess any changes can be fixed by a reinstallation of the package. -- 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: Debugging silent exit of threads in Phobos calls
On Fri, 2018-06-01 at 16:19 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 6/1/18 1:41 PM, Russel Winder wrote:
> > struct Datum {
> > public const int a;
> > public const int b;
> > }
> >
> > struct Message {
> > Datum datum;
> > }
>
> I found the bug. Basically, the Variant static if is failing because
> the
> assignment it is checking (assigning a Message to a Message) would
> overwrite const data. But it's not really overwriting existing data,
> it's emplacing into new data (always). So this check is not correct.
I think then my bug report 18934 is slightly wrong and it isn't the
struct within struct that is the problem, it is the const fields in a
struct that is?
> Much simpler test case:
>
> struct S
> {
> const int x;
> }
>
> void main()
> {
> import std.variant;
> import std.stdio;
> Variant v = S(1);
> writeln(v.get!S); // same failure
> }
>
Aha, much nicer since it is far more localised to the issue. I was
still focused on the receive and the struct within struct, which seems
to be the wrong issue: it is the const fields that are the problem.
Feel free to ignore my example and stack trace on
https://issues.dlang.org/show_bug.cgi?id=18934
and replace it with the above!
> If I replace the check in std.variant:
>
> static if (is(typeof(*cast(T*) target = *src)) ||
>
> with:
>
> static if (is(typeof(delegate T() {return *src;}))
> ||
>
> Then it works (both your code, and the simple example).
>
> Note that in all cases, variant is returning a COPY of the data, not
> a
> reference, so it shouldn't be possible to violate const.
Excellently done. Thanks for attacking this problem and finding a
solution. I will not now even contemplate hacking up my code. Actually
I would have put const in and still got a problem it seems, as I had
the wrong reason for the problem.
> Please, file a bug. I will see if I can submit a PR to fix.
>
Bug report is 18934.
If there can be a fast release of this via 2.080.1 with subsequence
fast releases via d-apt and Debian and Fedora packaging, I would be a
very happy bunny.
In the meantime onward with ACCU 2019 organisation.
ACCU needs more D content. Yes it is 50% C++, but that is exactly why
it needs D content. It also needs Go content. in 2018 we had Rust
content and it went down 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: Debugging silent exit of threads in Phobos calls
For anyone still interested in this problem: Steve's pull request fixing the problem is included in D 2.081.0. I can experiment as soon as DMD 2.081.0 is released but will have to wait till the fixes get into LDC to create production code. Moral of the story: silent, except during gdb debugging, assertion fails in Phobos are a pain in the arse. -- 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
