Re: D's Continous Changing
On Thu, Mar 04, 2021 at 06:43:57AM +, user1234 via Digitalmars-d-learn wrote: > On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote: > > For the record, I was able to resolve all of my issues in about 7 > > hours. That included upgrading from DerelictSDL to bindbc and > > converting to use dub instead of make. [...] > > I also should mention that this project was probably last touched in > > 2017. I thought I pulled it out a year ago, but that was a different > > project. > > otherwise another solution is to check every two monthes the sanity of > your projects. E.g a montly cronjob on a CI service and that uses > latest DMD Docker image. If it fails you got an email... It certainly > cooler to take 5 mins every two monthes than 7 hours 4 years. Y'know what'd be cool: if people could add their D projects to some kind of master CI (don't know if the existing dmd/druntime/phobos CI config allows this) so that whenever a change in the language causes breakage, the relevant PR will get flagged for review. I wouldn't say block the PR altogether -- we don't want some obscure no-longer-maintained project to hold back everyone else -- but at least flag it as a breaking change so that the owner can be contacted to see if something could be worked out. I know we already do this for some key projects, but a large-scale CI test would be nice, if we had the resources for it. T -- A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."
Re: D's Continous Changing
On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote: For the record, I was able to resolve all of my issues in about 7 hours. That included upgrading from DerelictSDL to bindbc and converting to use dub instead of make. I hope my above post does not lead people to believe that I don't like D, because I otherwise wouldn't have lost track of time until midnight working on this project! I also should mention that this project was probably last touched in 2017. I thought I pulled it out a year ago, but that was a different project. otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years.
Re: D's Continous Changing
On Thursday, 4 March 2021 at 05:44:53 UTC, harakim wrote: ... Yes it's a problem indeed. I had the same problem and that's worse when you don't upgrade very often. But let me tell something, where I work we have software in C#, do you think that upgrading was smoothly with all the tools that Microsoft provides? No it wasn't, and it gets worse with third party components. So this guy was hired just for that, port a very old code to the new framework, and after a month he did, yes it compiled alright... but the software didn't work as expected is some cases, some controls wasn't acting right and was very unreliable. Guess what? They are still developing with old framework until everything works correctly on the new framework. Matheus.
Re: D's Continous Changing
For the record, I was able to resolve all of my issues in about 7 hours. That included upgrading from DerelictSDL to bindbc and converting to use dub instead of make. I hope my above post does not lead people to believe that I don't like D, because I otherwise wouldn't have lost track of time until midnight working on this project! I also should mention that this project was probably last touched in 2017. I thought I pulled it out a year ago, but that was a different project.
D's Continous Changing
Every time I come back to a D program I wrote over a year ago, it
seems like there are numerous breaking changes and it takes me a
while to get it to compile again. And the documentation is
difficult to figure out. I wish I could remember every time I've
had to change this line of code, but I know most times I have
come back to this project over the last 14 years, I have had to
change it.
This is more or less what I had the last time:
auto sekunden = to!("seconds", long)(dauer);
return cast(long)floor(sekunden * 18);
The compiler complained about double. I found a post in dlang
from 2019 saying the library doesn't allow double conversion. It
sure doesn't! However, it used to.
I downloaded bindbc and got an error building with dmd version
2.087. The error was 'atomicFence is not a template declaration'.
Mike suggested I upgrade to 2.095 and lo and behold, that
compilation issue went away.
Now, I hate Java as much as the next guy (maybe more than most
next guys), but the things that led to me being a Java Developer
today are:
1. The Java Trails tutorials and JDK documentation
2. Backwards compatibility and easy-to-understand versioning
3. Lack of self-respect and willingness to stand up for what's
right
#3 is not in the purview of a language developer, but #1 and #2
are. I always feel like I want to be an evangelist for D, but
then I come back and things have changed and by the time I figure
out what's going on and do something cool, I need to take a
break. That is because I run into compilation errors with a few
minor version updates, I spend a lot of time retooling and fixing
my project to work on a new version of the compiler (or, I
assume, standard library) and libraries. I don't have that
problem in other languages.
If I write code in Java (barring a few major changes like the
generics update), it will continue to work just fine in newer
versions of Java. I can dig out the Java version of the program
which I wrote - just before the D program I am referring to - in
2006/2007 and it still compiles and runs horribly just like the
day I wrote it.
When Java 6 came out, I bought a book called Java 6 SE
Development. I read it and since I knew Java 5 now I knew what
was in Java 6.
As to the Java Trails and JDK documentation, I could figure out
how to do anything in the standard library that I needed to. I
didn't have to look anywhere else. As a new developer I wrote an
entire multi-threaded application that connected to a server
written in C and made thousands of draws per frame at 8-10 frames
per second, and I didn't have to use any resources outside of one
book and the standard Java library documentation. That's pretty
good.
Contrast to me trying to figure out how to format a number in
binary. format!"%b"(number) does not work but is very similar to
what is suggested in the documentation. I was able to figure out
it's format("%b", number) but it took a few minutes.
I also have to figure out how to determine how many 18ths of a
second have elapsed since the application started up. Don't ask
me why 18ths, that is just the number that the server uses. Does
total give me the total number of nanoseconds or the number of
nanoseconds after the large time units are factored out? The
documentation appears to say one thing but the tests appear to
show the opposite. I just have to write a test program to figure
it out.
I've been using D for close to half my life and I have no
intention to stop using it, but it will never be my go-to tool
for things like web development with C# around. I'd love for it
to be the language and tooling that I reach for all the time. It
has the potential to be that, but just the thought of having to
upgrade to the new compiler, new standard library, new build
tools and new library makes me hesitate every time. Even now, on
this project, I am going to spend ~10 hours to work through these
issues just to get back to where I was.
I think the first thing to do is lock down D to major version
changes. Any DMD 2 program should continue to compile with any
future 2.x version of DMD. If it is not longer backwards
compatible, make that version 3. Then for each version upgrade,
write some kind of upgrade guide. Crowd source it even as people
experience issues.
Maybe it's just me, but if I had confidence that the versions
would be around a little while and an example I write today would
work for others in a year or two, I would be more willing to
contribute examples, documentation and so forth. As it is, I will
probably do that in some fashion, but very limited and possibly
not in as community-wide of a venture.
PS I have a copy of The D Programming Language I refer to when I
start programming but it's in a storage unit. That is at least as
good as the Java Trails, although I'm not sure the examples would
even compile today.
Re: Vibe.d tutorial
On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote: Hi, I wrote a tutorial on Vibe.d while trying to re-learn Vibe.d. I find that most of Kai Nacke's book need updating, so I wrote a tutorial while trying to re-learn it. Here it is. https://github.com/reyvaleza/vibed/commit/27ec3678f25d1dd414fae1390677397a7bc57721 I would be glad if you can give me some feedback so I can improve it. Thanks! Wow, that's a lot of hard work! Nice!
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 14:17:02 UTC, Siemargl wrote: On Wednesday, 3 March 2021 at 14:12:54 UTC, Siemargl wrote: I test full rebuild of dlang-IDE (20k loc) now for dmd under Update, 20k loc without counting libraries. Thanks for the info. Yeah the times I'm trying to reach are around 0.5secs so as to have the same feel as a scripting language. I'm having some success pulling out small bits of code from other libraries and keeping things minimal and c-style-ish.
Re: How to get output of piped process?
On Monday, 22 February 2021 at 14:52:22 UTC, frame wrote: On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote: https://github.com/DannyArends/DaNode/blob/master/danode/process.d Danny This example shows how easy it is to implement a non-blocking stream. Phobos knows this for sockets but not for pipes? Sockets seem to be more OS independent and are way more mature in Phobos. Pipes seem to have been added as an afterthought in std.process and std.stdio I had to add code for windows to deal with non-blocking/buffering pipes, Linux uses fcntl/fileno to enable non-blocking No idea why non-blocking pipes aren't in Phobos, but pipes should not be an afterthought but a first class citizen imho
Re: How to get output of piped process?
On Tuesday, 23 February 2021 at 10:07:03 UTC, Imperatorn wrote: On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote: On Friday, 19 February 2021 at 15:39:25 UTC, kdevel wrote: [...] Perhaps a bit late, but this is how I deal with pipes and spawnShell. Read one byte at a time from stdout and stderr: https://github.com/DannyArends/DaNode/blob/master/danode/process.d Danny Interesting, do you have any benchmarks for DaNode? I used to run Apache bench on the code to make sure it was as fast as possible, for static files it is pretty performant since it buffers the files, and serves them directly from memory. The main overhead comes from the external process booting up, rdmd is nice since it only does the compile once then reuses the compiled binary for external scripts. PHP and such are always hit with the additional overhead. Feel free to run your own tests, the development branch has the latest version with some additional bug fixes not yet available in the master branch, and feedback is welcome and can be posted as an issue in Github
Re: How to get output of piped process?
On Thursday, 25 February 2021 at 15:28:25 UTC, kdevel wrote: On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote: On Friday, 19 February 2021 at 15:39:25 UTC, kdevel wrote: [...] Fortunately the D runtime /does/ take care and it throws---if the signal is ignored beforehand. I filed issue 21649. [...] Perhaps a bit late, It's never too late.™ :-) but this is how I deal with pipes and spawnShell. Read one byte at a time from stdout and stderr: https://github.com/DannyArends/DaNode/blob/master/danode/process.d Is this immune to SIGPIPE and is this design able to serve infinite streams? No I have linked up a signal handler to just ignore sigpipe, the web server closes connections after not seeing a valid output from the script for 5min (e.g. no header) BTW: Why does run use spawnShell and not spawnProcess (would save one File object). I tried different approaches, this one worked for me™ and I just went with it. I need the stdin (for the get/post/cookies) stdout (php/d/brainf*ck script output) and stderr for the error stream from he external script If the design is not intended to serve infinite streams I would suggest to open two temporary files "out" and "err", delete them, and let the child process write stdout/stderr into those files. I used to do that, but it generated a lot of temporary files, and I would need to parse in the files after the process is done to serve the output to the client. Using pipes is cleaner code wise, since I can just stream back the output to the client (e.g. in keepalive connections) IFAICS this avoid threads, sleep, pipe and reading with fgetc.
Re: What's the default implementation of opCmp/opEquals for structs?
On 3/3/21 1:37 PM, Jack wrote: the one that the compiler defaults to when you don't provide one? There's no default opCmp. For opEquals, it's a memberwise comparison. -Steve
What's the default implementation of opCmp/opEquals for structs?
the one that the compiler defaults to when you don't provide one?
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 14:12:54 UTC, Siemargl wrote: I test full rebuild of dlang-IDE (20k loc) now for dmd under Update, 20k loc without counting libraries.
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 09:02:54 UTC, Anthony wrote: Strange, usual D programs builds fast. What build times do you get? Seems like some other people have similar issues: https://forum.dlang.org/post/pvseqkfkgaopsnhqe...@forum.dlang.org https://forum.dlang.org/thread/mailman.4286.1499286065.31550.digitalmar...@puremagic.com All you mentioned are template issues. Some was fixed. I test full rebuild of dlang-IDE (20k loc) now for dmd under Windows: (Result is 5.5Mb .exe file) -full rebuild with all libs take ~21s >dub build --build=debug --arch=x86_mscoff --force -change one file and rebuild <7s >dub build --build=debug --arch=x86_mscoff
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 07:23:58 UTC, Siemargl wrote: On Wednesday, 3 March 2021 at 03:52:13 UTC, Anthony Quizon wrote: On Monday, 1 March 2021 at 08:52:35 UTC, Imperatorn wrote: Having a library with bare minimum meta programming would help with this I think. I'm willing to pay the cost of safety. Strange, usual D programs builds fast. As a alternative to Phobos, you can see to D1 standard library - Tango, ported to D2. https://github.com/SiegeLord/Tango-D2 Without mass template magic, its easier. There is also print book "Learn to Tango with D". Thanks! I'll take a look. Strange, usual D programs builds fast. What build times do you get? Seems like some other people have similar issues: https://forum.dlang.org/post/pvseqkfkgaopsnhqe...@forum.dlang.org https://forum.dlang.org/thread/mailman.4286.1499286065.31550.digitalmar...@puremagic.com
