Re: Solution to problems:
On Wednesday, 25 March 2015 at 03:30:19 UTC, Jake The Baker wrote: On Tuesday, 24 March 2015 at 17:49:56 UTC, CraigDillabaugh wrote: On Tuesday, 24 March 2015 at 17:13:07 UTC, Jake The Baker wrote: You guys are complete ignoring 90% of the post. It is not just about configuration. Regardless, I'll be back in another year to see what progress has been made. Good luck. I really do hope you guys can get your shit together and make D the top language! I'd like to actually use it for serious stuff one of these days(hopefully before my hair turns gray) Did you even look at Digger and DVM as was suggested above? They don't seem to fulfil your vision, but they do provide some of what you are asking for. Again, the point is that one can't do it. We know it can be done. It's about efficiency. You are not accumulating the man hours it takes over the total work time(the unexpected stuff that can take days to fix. Days most people are not willing to even risk wasting if it is possible). If all this stuff was properly integrated into an ide like work space specifically tailored to D development, then I'm sure D would get more bites than it is. Obviously it isn't a simple undertaking. Lets suppose if 30 coders that come to this forum were on board. Suppose one year was spend developing such an app that make it very effective to not only develop in D but also help develop D. Suppose it was just a super awesome and efficient IDE that solved all the programmers problems. Ok, Would that year be worth the wasted time on the IDE considering what it can accomplish in the next 10+ years? Is the investment worth it? This is an invest 10k$ and get 1M$ back type of scheme. But in this case if done right it will actually happen. (e.g., invest in the stock market on logical investments vs giving your money to Burt Bernie's Investment Firm. I just see a bunch of wasted arguments about things on this forum. If all that energy was captured and harnessed into creating something that would increase productivity then it will do so exponentially. (30 people spend 1 year to create something that potentially millions will use every day for the next 10+ years. That's a 33,000 ROI... who would pass that up?) Of course, maybe we can just use 10 people and about 3 months to get a good approximation? Maybe eclipse could be developed to do the job? Maybe Visual D could be extended to include built in bug tracking, repository and versioning issues, collaboration, etc? These questions can't be answered until people think there is a problem. Maybe the real solution is just to scrap D and get behind Go. Who knows until people honestly look at the underlying problems that are preventing D from becoming mainstream(time is and obvious one, but the more reason to get it done ASAP before we all end up in the old folks home). But I guess I digress! Some people just like to dig. Here's a shovel to help you on your way... Does an IDE exist for contributing to Go? https://golang.org/doc/install/source Hmm, looks like CLI might be the IDE of go developers. And if you just want to contribute to its ecosystem with Go progs? https://golang.org/doc/code.html Well this looks very similar to D + DUB. In fact D is better because it doesn't dictate any one way. You can choose whatever works for you. I'm using Make, CMake and dub...I'm becoming addicted to DUB for rapid prototyping. If you really want this, you could champion it yourself. I'm sure the D IDE development projects could use as many hands as possible. bye, lobo
Re: The D Language: A sweet-spot between Python and C
On Monday, 30 March 2015 at 00:57:06 UTC, Walter Bright wrote: http://blog.experimentalworks.net/2015/01/the-d-language-a-sweet-spot-between-python-and-c/ Reddit: https://www.reddit.com/r/programming/comments/30qqck/the_d_language_a_sweetspot_between_python_and_c/ The syntax was a big part of D that got me hooked. It just feels right, as Python syntax often does, but with D there's raw power behind it. Coming from C++ I'd always end up prototyping in Python because it's such a productive language. Unfortunately Python doesn't have the grunt when I need it so it turns into a Python/C++ combo. I tried Go and Rust but found both languages put up roadblocks too often and got in my way. Cheers, lobo
Re: DMD compilation speed
On Monday, 30 March 2015 at 22:39:51 UTC, lobo wrote: On Sunday, 29 March 2015 at 23:14:31 UTC, Martin Krejcirik wrote: It seems like every DMD release makes compilation slower. This time I see 10.8s vs 7.8s on my little project. I know this is generally least of concern, and D1's lighting-fast times are long gone, but since Walter often claims D's superior compilation speeds, maybe some profiling is in order ? I'm finding memory usage the biggest problem for me. 3s speed increase is not nice but an increase of 500MB RAM usage with DMD 2.067 over 2.066 means I can no longer build one of my projects. bye, lobo I should add that I am on a 32-bit machine with 4GB RAM. I just ran some tests measuring RAM usage: DMD 2.067 ~4.2GB (fails here so not sure of the full amount required) DMD 2.066 ~3.7GB (maximum) DMD 2.065 ~3.1GB (maximum) It was right on the edge with 2.066 anyway but this trend of more RAM usage seems to also be occurring with each DMD release. bye, lobo
Re: They wrote the fastest parallelized BAM parser in D
On Monday, 30 March 2015 at 20:25:33 UTC, CraigDillabaugh wrote: On Monday, 30 March 2015 at 20:09:35 UTC, Laeeth Isharc wrote: clip You're right about the lack of visualization being a shame. I have been thinking about porting Bokeh bindings to D. There isn't much too it on the server side - all you need to do is build up the object model and translate it to JSON - but I have not time right now to do it all myself. clip A comment on the visualization thing. Is this really a big issue? [snip] Yes of course, why do you think Pyhton + sciPy/Numpy has such a foothold in the scientific community. Visualisation is an important part of data processing pipeline. It's also why Matlab is so useful for those lucky enough to work for a company that can afford it. bye, lobo
Re: DMD compilation speed
On Sunday, 29 March 2015 at 23:14:31 UTC, Martin Krejcirik wrote: It seems like every DMD release makes compilation slower. This time I see 10.8s vs 7.8s on my little project. I know this is generally least of concern, and D1's lighting-fast times are long gone, but since Walter often claims D's superior compilation speeds, maybe some profiling is in order ? I'm finding memory usage the biggest problem for me. 3s speed increase is not nice but an increase of 500MB RAM usage with DMD 2.067 over 2.066 means I can no longer build one of my projects. bye, lobo
Re: Benchmark block
On Monday, 30 March 2015 at 23:29:40 UTC, Jonathan wrote:
I have no idea if this has been discussed yet, but I was
thinking it would be neat to have benchmark blocks that only
run when specified, like how unittest works.
Code:
benchmarks
{
import std.conv : to;
int a;
void f() {auto b = to!string(a);}
auto r = benchmark!(f)(10_000);
auto f0Result = to!Duration(r[0]);
writeln(f0Result)
}
Example:
rdmd -benchmarks -main myapp.d
Alternatively, the writeln could be replaced with some kind of
standard benchmark output utility (similar to the idea of
assert when used for unit tests).
Thoughts?
Would this do what you're after?
version(benchmark) {
unittest {
import std.conv : to;
int a;
void f() {auto b = to!string(a);}
auto r = benchmark!(f)(10_000);
auto f0Result = to!Duration(r[0]);
writeln(f0Result)
}
}
rdmd -main -- -version=benchmark -unittest myapp.d
Or something along those lines.
This will run all the normal unit tests as well as the benchmark
tests, which I'd argue is a good thing anyway.
bye,
lobo
Re: D as System Language
On Monday, 30 March 2015 at 15:39:07 UTC, Adam D. Ruppe wrote: On Monday, 30 March 2015 at 15:32:25 UTC, Columbus wrote: Is there usefull documentation about using D as OS language? I wrote briefly in my book some stuff that might help get you started https://www.packtpub.com/application-development/d-cookbook Basically you can start with an empty runtime and then add back missing functions as needed to get it to compile. For your interest: At first, the OS should run on x86_64. Though I did 32 bit, I haven't worked with 64 bit. Probably not that much different though. I wrote a small 64-bit OS kernel that basically echos keystrokes back at you. I got bored with mine. I'd done what I was interested in, which was a x86_64 bootloader in ASM + D using grub2. The osedv.org site was useful but a lot of the information is incorrect or outdated, especially the 64-bit bootloader and grub2 stuff. The D Cookbook is a great read by the way, nice work ! bye, lobo
Re: DMD compilation speed
On Wednesday, 1 April 2015 at 02:54:48 UTC, Jake The Baker wrote: On Tuesday, 31 March 2015 at 19:27:35 UTC, Adam D. Ruppe wrote: On Tuesday, 31 March 2015 at 19:20:20 UTC, Jake The Baker wrote: As far as memory is concerned. How hard would it be to simply have DMD use a swap file? That'd hit the same walls as the operating system trying to use a swap file at least - running out of address space, and being brutally slow even if it does keep running. I doubt it. If most modules are sparsely used it would improve memory usage in proportion to that. Basically if D would monitor file/module usage and compile areas that are relatively independent it should minimize disk usage. Basically page out stuff you know won't be needed. If it was smart enough it could order the data through module usage and compile the independent ones first, then only the ones that are simple dependencies, etc). The benefits to such a system is that larger projects get the biggest boost(there are more independent modules floating around. Hence at some point it becomes a non-issue. I have no idea what you're talking about here, sorry. I'm compiling modules separately already to object files. I think that helps reduce memory usage but I could be mistaken. I think the main culprit now is my attempts to (ab)use CTFE. After switching to DMD 2.066 I started adding `enum val=f()` where I could. After reading the discussions here I went about reverting most of these back to `auto val=blah` and I'm building again :-) DMD 2.067 is now maxing out at ~3.8GB and stable. bye, lobo
Re: readln() doesn't stop to read the input.
On Friday, 27 March 2015 at 04:37:34 UTC, jonaspm wrote:
Please, i need your help, I tried this:
write(Write p: );
readln(p);
p = chomp(p);
writeln(Write q: );
readln(q);
q = chomp(q);
but the result is:
Write p: Write q:
and doesn't pause to read keyboard input... what's wrong?
Thanks in advance!
This works for me on Linux:
---
import std.stdio;
import std.string;
void main()
{
char[] p, q;
p.length=1024;
q.length=1024;
write(Write p: );
readln(p);
p=p.chomp;
write(Write q: );
readln(q);
q=q.chomp;
writeln; writefln(p=%s, q=%s, p,q);
}
---
bye,
lobo
Re: DMD compilation speed
On Tuesday, 31 March 2015 at 19:20:20 UTC, Jake The Baker wrote: On Monday, 30 March 2015 at 22:47:51 UTC, lobo wrote: On Monday, 30 March 2015 at 22:39:51 UTC, lobo wrote: On Sunday, 29 March 2015 at 23:14:31 UTC, Martin Krejcirik wrote: It seems like every DMD release makes compilation slower. This time I see 10.8s vs 7.8s on my little project. I know this is generally least of concern, and D1's lighting-fast times are long gone, but since Walter often claims D's superior compilation speeds, maybe some profiling is in order ? I'm finding memory usage the biggest problem for me. 3s speed increase is not nice but an increase of 500MB RAM usage with DMD 2.067 over 2.066 means I can no longer build one of my projects. bye, lobo I should add that I am on a 32-bit machine with 4GB RAM. I just ran some tests measuring RAM usage: DMD 2.067 ~4.2GB (fails here so not sure of the full amount required) DMD 2.066 ~3.7GB (maximum) DMD 2.065 ~3.1GB (maximum) It was right on the edge with 2.066 anyway but this trend of more RAM usage seems to also be occurring with each DMD release. bye, lobo As far as memory is concerned. How hard would it be to simply have DMD use a swap file? This would fix the out of memory issues and provide some safety(at least you can get your project to compile. Seems like it would be a relatively simple thing to add? It's incredibly slow and unproductive it's not really an option. My primary reason for using D is that I can be as productive as I am in Python but retain the same raw native power of C++. Anyway, it sounds D devs have a few good ideas on how to resolve this. bye, lobo
Re: Novel list
On Wednesday, 25 March 2015 at 23:08:52 UTC, Walter Bright wrote: On 3/25/2015 7:52 AM, wobbles wrote: On Wednesday, 25 March 2015 at 12:21:32 UTC, Martin Krejcirik wrote: On Wednesday, 25 March 2015 at 12:01:15 UTC, wobbles wrote: The DOES POORLY AT... column is good reading here for how D could improve ( though some of the comments are stupid. D has an annoying syntax!?) doeas poorly at annoying syntax = not annoying syntax This list isn't not confusing! Irregardless, not no how not no way! I've worked in code bases with similar issues! bool isNotDisabled = false; bye, lobo
Re: Solution to problems:
On Monday, 23 March 2015 at 21:34:09 UTC, Jake The Baker wrote: If D had an ide that could do the following I think development and testing could be better managed. 1. IDE that works with a centralized server to be able to change D versions at a drop of a time. e.g., click Master and it checks to see if you have the latest, if not it downloads it, configures it, and sets it up hands free to be used. (If it requires any interaction to work then it is a bug) 2. Patches, bugs, and everything else can be accessed through this IDE. Collaboration can be made between groups of people and individuals. Announcements could be made by head honchos. (In fact, this software could be more generic and used by anyone for any purpose of collaboration in programming... e.g. with php). One can see open bugs, issues, workarounds, etc at a click. 3. Projects could be collaborated on easily with people being able to watch(RD) another persons session(say for debugging help or whatever). 4. The ability to connect resources to projects. e.g. insert a note over a function that links to the D documentation about a bug. 5. etc. If such an IDE existed so that anyone could simply run it, open a bug and start working without having to go through a massive change(by quick, I mean click of a button), then I think people would be more willing to help. The number one reason I don't contribute is that I don't have the time to dedicate to maintain all the knowledge and software/organization to fit it in my schedule. I suspect that is most everyone excuse too. I don't want to spend 30mins to an hour to download the latest version, compile it if I have to, make sure all the configuration stuff is correct, create a setup program... just to find out there is a bug in the latest version at the end. I'm simply not that dedicated to D. Again, I suspect most people aren't. You have really dedicated people here but not enough to get everything that needs to be done, done. Instead, find out how to leverage all the people that would help if you make it worth their time. It might be slower in the short term but better in the long term. In 10 more years I doubt Andrei or Walter will have as much energy to do all the work that they are doing... Better build the infrastructure now while there is time. VCS (Git in this case) and Make are tools of the trade. If a developer cannot use these tools following instructions provided in the Wiki [1] they probably won't have much in the way of useful contributions to Phobos or the compiler. Bye, lobo [1] http://wiki.dlang.org/Pull_Requests
Re: Benchmark of D against other languages
On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
On 2 April 2015 at 08:15, Martin Nowak via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/01/2015 10:31 PM, novice2 wrote:
Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization.
It requires another compiler/linker phase, so it's not easy to
achieve,
maybe the LDC/GDC people have LTO running?
GCC5 comes with a big announcement about devirtualization.
https://www.gnu.org/software/gcc/gcc-5/changes.html#general
It is impossible to do a good job. There are 2 conditions that
break
most opportunities that the compiler may have to improve this:
1) The class is a pointer (duh, in D, all classes are pointers,
so
that condition is implicit).
2) That DLL's exist.
If a DLL may exist, and a class is a pointer (it is), sourced
from an
'impure' location, then it is impossible for the compiler to
generally
do anything at all about final.
It may theoretically be able to do something in the case where
the
class is proofably contained within a 'scope' confined
space/function,
but that particular case is almost mutually exclusive with
cases where
polymorphism is actually useful in the first place, so it's not
really
practical. I also imagine the complexity in the compiler would
be off
the charts.
Basically, if it is _possible_ for a class pointer to come in
contact
with dynamically loaded code, the compiler must conservatively
abandon
any attempt to optimise.
virtual by default is completely wrong for D.
And don't say 'speculative' devirtualisation. What an
abomination!
Just fix the problem; don't have every function be virtual in
the
first place!
+1
Even an escape would be useful so one can do this:
final class Hack {
virtual void func() {}
}
It would then be trivial to stick a final in front of the class.
It would also be required to declare final when instantiating the
class, to work with third-party libraries that don't use final,
i.e.
auto klass = new final Class();
I'm not a language developer and I don't know D that well yet so
I'll stop there before I embarrass myself too much! :D
bye,
lobo
Re: D casually mentioned and dismissed + a suggestion
On Wednesday, 13 May 2015 at 05:13:55 UTC, Shachar Shemesh wrote: On 12/05/15 21:35, FujiBar wrote: Walter would probably violently disagree with the no decent development tools assessment. But I got to say that people used to Visual Studio and XCode (like myself) not being impressed by D's 1980s-style bare basic command line tools is not surprising. I don't think the command line aspect of things is justified. With that said, C++ has some really good cross referencing tools (e.g. in eclipse) that D not only does not match, but with CTFE, I do not see how it /can/ match. I actually miss those occasionally. What bothers me most about D, however, is that the toolchain itself isn't there to pick up its share of the load. Transitioning between versions of the compiler requires a task with several days' worth of work behind it, and getting the code to compile on both dmd and gdc is a full time task for someone here. With DMD's optimizer not worth much, this is a real issue. And this is before mentioning stability. I've lost count of the number of times my compilation failed with an assert thrown by dmd, and just last week I've had to refactor the code around a consistent segmentation fault by the compiler when trying to compile it. It got better for it, but ideally I'd like to refactor my code because I want to, not because the compiler crashes unless I do so. Shachar Interesting. Since = DMD 2.05x I haven't had any real stability problems with each new release. Each release still breaks my code in some way because each new compiler version improves on the last and detects latent bugs in my code. My only concern now with a new release is the compiler's memory usage growing. bye, lobo
Re: Pitching an investment bank on using D for their bond analytics
On Wednesday, 15 April 2015 at 22:32:53 UTC, Kapps wrote: On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a year wrote: A friend has been invited to be a consultant for an investment bank that would like to build a set of analytics for fixed income products. The team is currently quite small - about 5 C++ developers - and the idea is to start with a proof of concept and then build on it as there is further buy-in from the business. One of the biggest issues I can think of would be code breakage. While we're the point where most compiler updates no longer break my code, if you expect to use a codebase from 2 years ago without having to update your code, you'll be disappointed. In the last 2 years each breaking change I've encountered has been to close holes where latent bugs may lurk ... and often were lurking! I welcome these breaking changes in production code. bye, lobo
Re: Any plans to support STL value types?
On Saturday, 16 May 2015 at 12:22:00 UTC, QAston wrote: On Saturday, 16 May 2015 at 09:20:37 UTC, Kagamin wrote: Currently D frontend can't use such idiom: it has classes, which support inheritance, but are reference types, it also has structs, which don't support inheritance and are value types, and they don't mix. In this case inheritance is just a code/structure sharing tool. D has mixins and alias this to do that. This is what I currently use now for composition of structs where I'd consider using private inheritance in C++. The semantics are not identical of course, e.g. construction and initialization differ for one, but it works very well in my situation. bye, lobo
Re: Why aren't you using D at work?
On Thursday, 18 June 2015 at 01:13:10 UTC, Chris Piker wrote: On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote: [...] I work in an academic setting, so there's alot of freedom. About the only thing really holding me back is that the local sys-admins can't: $ yum install gcd on CentOS 7. If D compilers were available in the standard software distribution channels for RedHat based Linux systems, D would be considered mainline enough for our use. Can you install to $HOME ? bye, lobo
Re: Progress on Adam Wilson's Graphics API?
On Saturday, 30 May 2015 at 14:35:29 UTC, Rikki Cattermole wrote: On 31/05/2015 2:31 a.m., ketmar wrote: On Sun, 31 May 2015 02:28:51 +1200, Rikki Cattermole wrote: On 31/05/2015 2:27 a.m., ketmar wrote: On Sun, 31 May 2015 01:35:41 +1200, Rikki Cattermole wrote: Great example, if you wanted to play some music cross platform what D library what you use? SDL audio. ;-) Okay lets ignore libraries that is not D. Like that one. i bet Devisualisation is using Xlib/XCB, so it's out of competition too, for example. ;-) Well then lets call a spade a spade and start writing our own operating system shall we? Personally I think it is more reasonable to assume certain libraries will be installed. Such as for Windows user32 and GDI. Where by there is no real alternatives. Like X11 for *nix. In other words, system libraries are fine to use. As you have no real choice in the matter. Now SDL on the other hand, you cannot assume will be installed or available. Unless you want to go bundling that or using static libraries. Still defeats the purpose of expanding D's library base. Why do people always want to reinvent such well tested libraries? Slap a nice D API over the top and reuse the hard work of others. Besides SDL is pretty much ubiquitous on all platforms D supports. You could even package up dependencies with your bindings and the end-user wouldn't have to worry. Honestly though if someone isn't willing to learn how to obtain SDL for their chosen platform, even if it requires building from source. then they should probably forgo programming as a career or hobby. bye, lobo
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 05:17:27 UTC, Adam D. Ruppe wrote: On Sunday, 31 May 2015 at 04:46:51 UTC, lobo wrote: Again, I wonder why would you reimplement what you get from libpng? I've actually had people ask me what magic I did with my png.d because it often generates smaller files than libpng. It is easier to use an leaving out unnecessary bits made it faster and more efficient! (for our use cases, the full lib is surely useful for other cases) The thing with those libraries is they do everything, which makes them bigger and more complex. There's a place for that, sure, but it isn't necessarily better. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. Fun fact: curl is actually pretty buggy... and a pain to use too. I like it and use it for a lot of things, but I also replaced it (and again, like with the png, a lot of the things it does aren't necessary for me anyway) I know cURL has numerous bugs, I work with them everyday :) But so do many many others and that's partly my point; the majority of bugs are exposed pretty quickly with that many users. I'm also not convinced that a D PNG or cURL (or whatever) implementation, used en masse, wouldn't grow to include all those 'missing' features and end up just as bloated. But now without lots and lots of users to help report all those bugs. Anyway, it's a moot point given that I probably won't ever have the time to really contribute more than bug reports for D ;-) I just finished your book by the way and thought it was a terrific read. Nice work! bye, lobo
Re: Progress on Adam Wilson's Graphics API?
On Sunday, 31 May 2015 at 02:14:53 UTC, Rikki Cattermole wrote: You're missing a large part of what I'm saying. I understand what you're saying, I just disagree ;) I'd argue well tested and maintained dependencies are more important than what language they are written in. For people just learning the language and getting started, saying go download x for your platform won't be enough. Look at how we are handling curl right now. No, for any e.g. library or window creation libraries and likes. Must have an agreed interface that is not specific to e.g. SDL. SDL may implement them. But out of the box experience must not rely on 3rd party. s/bindings/wrapper/ Sorry, I should be more specific, but as I said in my earlier post; slap a nice D interface over the top of the C library. In D this is trivial. E.g. such an image library there wouldn't be a JPEG implementation but would be a PNG one. Because of the complexity of implementing a JPEG reader/writer. Which is ridiculously hard compared to PNG which is actually really simple. Again, I wonder why would you reimplement what you get from libpng? Think of all the real world tests, tweaks and optimization you're throwing away by not using libpng. As for libcurl, well if a pure D curl impl is written for Phobos it will be 100s to 1000s of additional LOC that require testing and maintaining. The effort of that alone would be greater than what is currently required from Phobos devs and end-users with a 'C' dependency. If dub supported compiling C that would be awesome for my own bindings/wrappers. bye, lobo
Re: std.database
On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole wrote: On 28/05/2015 4:57 p.m., Robert burner Schadek wrote: On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote: Shouldn't the statement be reusable? Yes it should. I added this use case: auto stmt = con.statement(insert into table values(?,?)); stmt.execute(a,1); stmt.execute(b,2); stmt.execute(c,3); struct Table; Table a, b, c; con.insert!Table(a); ... if you use CTFE to create the statement string there is no reason to reuse it. it will be string literal, that's even better! Think Big. Think D the other code is Java not D Then you open up table names, property serialization ext. ext. Please no. That is an ORM's job. I'm saying this from experience. +1 for decoupling ORMish stuff from the DB driver layer but I agree with Robert, std.database should have an ORM layer on top of its DB drivers. It's powered by D and writing an ORM layer in D is easy. The hard part, as is always the case, is agreeing on the API for Phobos inclusion. bye, lobo
Re: Working on new binary serialization module for phobos (hopefully)
On Monday, 1 June 2015 at 19:41:58 UTC, Jacob Carlborg wrote: On 2015-06-01 21:22, CraigDillabaugh wrote: I noticed there hasn't been any activity on the Github repo for 8 months. Why is that? Do you consider this a completely finished product, or are you held up by the PHobos review process? I just haven't worked on it for a while. Working on the , at least, third review process isn't really motivating. +1 for orange. I have used cerealed as well and liked it but with it except orange it's easy to add and switch between custom archiver formats. I couldn't figure out a way to do this with cereraled without hacking it. bye, lobo
Re: Status of Deimos bindings
On Monday, 25 May 2015 at 21:33:15 UTC, FreeSlave wrote: What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now: 1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry. 2. No consistency on names. There're repos named with lib prefix and without it either. 3. I could not find information on how to propose new binding to Deimos. Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library - D language bindings - Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them. Thoughts? If you submit a PR adding dub support for to a Deimos repo it will be pulled. It just needs someone with enough time (and interest) to write and test the dub.json files for all the repos then register those packages with code.dlang. bye, lobo
Re: What is the current status of D build systems?
On Friday, 31 July 2015 at 23:59:07 UTC, Yuxuan Shui wrote: On Friday, 31 July 2015 at 22:40:25 UTC, Trent Forkert wrote: On Friday, 31 July 2015 at 00:13:42 UTC, Yuxuan Shui wrote: [...] Oh hey, that's me! [...] I've got a handful of work-in-progress changes I've yet to push publicly, and even more I've yet to commit. (Yes, I have weird work habits.) [...] Hi, I just want to let you know I've tried to build my project with your cmake fork, and it worked like a charm :) Good to hear it's still alive. Let's hope the situation about shared libraries can improve and you can move on. [...] I use CMake on mixed C/D projects and dub for D-only projects. On one project I'm using CMake to invoke dub to keep the D libs up to date and no another I invoke CMake from dub to build the C cruft. I find both work extremely well and are much better than shell scripts or plain Makefile bashing. bye, lobo
Re: DIP81: Writing files at compile time
On Wednesday, 12 August 2015 at 18:57:05 UTC, Adam D. Ruppe wrote: I've been looking at a company's build system recently and it makes me think this is a bad idea: we have enough problems tracking import dependencies and changes as it is without other files being written in the middle of the process too. I'd prefer it if these were always done as separate steps so it can be more easily integrated into other build scripts. (Build systems and scripts suck btw, but they suck less than the confusion caused when files can be read and written arbitrarily by the compiler, which already has hidden dependencies). +100
Re: Where will D sit in the web service space?
On Tuesday, 18 August 2015 at 18:22:09 UTC, Mint wrote: On Thursday, 13 August 2015 at 14:31:10 UTC, karabuta wrote: Oh! someone thinks typescript is a programming language. Typescript runs in which browser? :) (Because when I use typescript, I worry about two things in my development process, .js and .ts) Oh! Someone thinks D is a programming language. D runs on which processor? D just transpiles into ASM after all. Oh! Someone thinks ASM is a programming language. ASM runs on which processor? x86 just transpiles into the processor's native instruction set. CPUs haven't actually executed x86 directly in the better part of a decade. x86 CPUs never directly executed x86 bytecode, they're all CISC architectures.
Re: D for Game Development
On Thursday, 30 July 2015 at 21:27:09 UTC, deadalnix wrote: On Thursday, 30 July 2015 at 15:10:59 UTC, Brandon Ragland wrote: It's a dog because Java is a dog. But that's not because of the GC. It's not really that bad either, I can open up Minecraft at any time and have it sit in the background quietly using ~800Mb ram and virtually no cpu time. Either your kid has tons of mods in their Minecraft or your computer is a bit dated. Now compare that kind of resources consumption with any game based on Quake III engine. While you are at it, compare the graphisms. Still not convinced ? Measure latencies, which are critical for most games. The OP is talking about indie games not AAA blockbusters. In general D is great for writing indie games, you just need to be aware that the GC is not the best and use @nogc where possible. It's not difficult and probably less overhead than writing the same code in C++. As for the Java GC, well Minefcraft does very well and has millions of happy blockheads playing it. bye, lobo
Re: D for Game Development
On Thursday, 6 August 2015 at 22:48:50 UTC, Tofu Ninja wrote: I really feel like D needs to get over it's not invented here syndrome, a much easier path would to just use a pre existing cross platform windowing library. Its laughable that the people in D want to reinvent this stuff. It's been done, just use the already working version! Why have all this great c and c++ interop if we never use it. I have the same gripe with how the experimental.image is doing image loading/saving, there are plenty of already existing image libraries that already support every image format you could ever dream of. Just use them, they will work 1000x better than any reinvention that we do here. +1 If only the effort writing native-D reinvented unproven, untested wheels was spent writing quality D wrappers over existing proven and tested libraries bye, lobo
Re: D for Game Development
On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote: *whispers* Hey hey you. You want tests? Well here is something you'll like[0]. Oh and check out[1]. [0] http://www.libpng.org/pub/png/pngsuite.html [1] http://forum.dlang.org/post/zxbexpwmirzdkewhq...@forum.dlang.org Well done you've written a library to pass some tests. Now fix the bugs that you haven't found yet and scalability issues you aren't aware of...the things that really only spring up when you get 1000+ users thrashing it each week. In the meantime I'll use D bindings to FreeImage or similar ilk that's gone through the wringer several times over. Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries. bye, lobo
Re: Writing/Creating files at compile-time
On Monday, 10 August 2015 at 07:50:29 UTC, Ola Fosheim Grøstad wrote: Ugh… please don't add more ugly features that has to be ripped out to bring the language to a sane state. A compiler should be able to compile all programs on a read only filesystem. If the language requires a filesystem to compile then I consider the language broken and in need of redesign. While I agree with you I am curious; where would the compiler place its artefacts and why can't export write to the same place? The way I see it files created by export would be transient anyway, generated each time you compile. bye, lobo
Re: Kinds of containers
On Monday, 26 October 2015 at 19:31:26 UTC, Ulrich Küttler wrote: On Wednesday, 21 October 2015 at 18:49:26 UTC, Andrei Alexandrescu wrote: On 10/21/2015 12:25 PM, Jonathan M Davis wrote: My experience with immutable containers is that their performance is trash precisely because you can't mutate them. That's actually the experience in the Scala community. Over and again people start with immutable containers all over the place because they're cool, and end up with mutable containers because they work. -- Andrei Ranges and loops. Same story. Ranges are cool, loops get stuff done. You are conflating ranges and iteration. A range needs something to drive it, whether it be an explicit loop or some higher abstraction from std.algorithm. bye, lobo
Re: zip packages to pack modules
On Tuesday, 29 September 2015 at 05:24:49 UTC, tcak wrote: [snip] Why not DUB? I have never use DUB ever, and not planning to use it. Nobody else has to use it as well. I don't think anyone should be forced for this. The proposed feature allows to simplify downloading packages and using them in a projects very quickly and easily without needing any tool. I used to feel this way about DUB too, insisting on my Makefile or CMakeD for larger projects. I then tried dub, initially just for a quick prototype, but it was so quick, productive and seamless to use that I decided to switch immediately. Now my only regret is that I cannot go back and reclaim the time I wasted with other build tools on D projects. bye, lobo
Re: Shout out to D at cppcon, when talkign about ranges.
On Wednesday, 30 September 2015 at 22:51:24 UTC, H. S. Teoh wrote: On Wed, Sep 30, 2015 at 10:32:16AM -0400, Andrei Alexandrescu [...] I watched most of the video (mainly the first half where he goes through the C++ version of the code), and I have to confess I couldn't help noticing just how ugly the C++ syntax is. This is a key reason I am using D. I really like C++14+boost but that syntax brings me back to D every time. I mean, overloading operator|() for chaining, seriously? UFCS is superior any day, IMNSHO. I seem to recall that in a previous on ranges Niebler said that operator|() was simply available and had a vague notion of chaining thanks to *nix shell. He went on to say it would probably need to change to get through the ISO committee. I hope it does. If the current plans for overloading operator.() get up I wonder how well it would fit as a replacement operator. And overloading operator%() for string interpolation, ugh. (Though this one seems to be a Boost thing, not specific to the ranges proposal.) This is also a Python thing so it's quite prevelant in the wild. I find D's ~ much nicer, although minutely slower to type than % And this is on top of the usual ugliness of C++ template syntax. Not to mention the RANGE_FOREACH macro (I assume it's a macro), where D's foreach has supported natively for years now. (D has seriously ruined my life; I simply can't bring myself to go back to C++ anymore. At least not voluntarily.) Also, this seems to confirm that C++ is gradually falling to the position where it's playing catch-up with respect to innovations in newer languages like D and Rust. The fact that ranges are being proposed for the C++ standard library is a big endorsement of D, IMO. C++ has been playing catchup for the last 10 yrs and it's been an amazing transition for the language. If ranges are accepted into ISO C++ I can't imagine it would be long before for(auto e:range). [snip] One great action item is to backport some of Eric's ideas to the D example. Currently Eric's final code looks nicer than the D code. -- Andrei Do you have a list of ideas that should be backported? I really liked the namespaces view:: and action:: because it is immediately clear just reading the code what was lazy and what was not. bye, lobo
Re: Shout out to D at cppcon, when talkign about ranges.
On Thursday, 1 October 2015 at 01:54:22 UTC, bitwise wrote:
On Thursday, 1 October 2015 at 01:32:17 UTC, bitwise wrote:
I don't think it would be that hard to make something this
possible:
for(int x : iota(0, 5).to(3))
printf("%d ", x);
Curiosity got the best of me:
http://ideone.com/RoJxLa
output doesn't show up for some reason, but it works.
Bit
Yes, that's what we have always done with iterators. The point is
users shouldn't have to write or instantiate iterators explicitly
for any custom range.
bye,
lobo
Re: Shout out to D at cppcon, when talkign about ranges.
On Thursday, 1 October 2015 at 05:47:25 UTC, Eric Niebler wrote: ...[snip]... Hope that clears things up. It does, thank you. Eric P.S. I see lots of people here assuming that C++ is playing catch-up to D because D has ranges and C++ doesn't yet. That is ignoring the long history of ranges in C++. C++ got ranges in the form of the Boost.Range library by Thorsten Ottoson sometime in the early 00's. Andrei didn't implement D's ranges until many years after. The ranges idea is older than dirt. It's not a D invention. Fair point, I did overlook boost.range when considering the C++ range options. bye lobo
Re: Idioms you use
On Monday, 28 September 2015 at 21:40:45 UTC, Freddy wrote:
Are any D idioms you use that you like to share?
Heres one of mine
---
enum ctfe =
{
return 0xdead & 0xbad;
}();
---
What does this do and where would it be useful in my code?
For D idioms I usually go here...you may want to submit a PR:
http://p0nce.github.io/d-idioms/
Phobos is another good source of how to do X in D.
bye,
lobo
Re: Indicators and traction…
On Wednesday, 23 September 2015 at 16:22:02 UTC, Nick Sabalausky wrote: [snip[ FWIW, Python hit pretty big success with a different approach: Appeal to people's innate desire for instant gratification. By the time they discover the downsides, they're already knee-deep. (Obviously I'm not suggesting this was intentional, just seems to be the way it played out.) Instant gratification in Python == 10x more productive in Python. This is why Python succeeds. D can compete in this market using dub and rdmd. D can also compete in the Java/C#/C/C++ markets, a place where Python often falls short. bye, lobo
Re: Voting For std.experimental.ndslice
On Sunday, 13 December 2015 at 05:10:17 UTC, Jack Stouffer wrote: This is the voting thread to decide if the proposed addition to Phobos, std.experimental.ndslice, should be accepted. [...] Yes
Re: 50% inative
On Wednesday, 25 November 2015 at 08:41:05 UTC, Iain Buclaw wrote: On 24 November 2015 at 19:04, duff via Digitalmars-d < digitalmars-d@puremagic.com> wrote: [...] If members wish to leave, they may request to do so. Ousting people is not an acceptable attitude towards any member in our community, long standing or not. I am aware of some of whom you've chosen to be vocal about have been around or contributing for 10 years, whilst others are active but do so under a work-related github account. All attended Dconf, most on a yearly basis, where were you? don't feed the trolls :-)
Re: I hate new DUB config format
On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote: I think that using SDL format was big mistake. Not only I do not want to spend time in learning yet another dead config format that now use only one project -- DUB. In time when DUB used json it was not perfect, but at last it was standard and everybody can read it. Now when I come to code.dlang.org I can't simply do copy-past of dependence. I need go to docs page, and read how to include it. Also I do not see any projects that are migrate to SDL. Everybody continue to use JSON. So please, return JSON back as default, or very soon we will see that nobody do not submit packages to code.dlang.org and nobody do not use DUB for their own projects. Please vote about SDL config format http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67 If SDL will stay by default I will prefer to move to any other build system or will downgrade to old version of DUB. A 20-page bikeshedding bonanza! Atypical D forums...and a pity that the priorities of core D devs is diverted to this spittle of a forum post when D has much bigger fish to fry. JSON/SDLang both have zero friction; if you use Dub+JSON you can become fluent Dub+SDLang in less than 1 minute for the first time. Pick one for your project and move on, both are supported. bye, lobo
Re: I hate new DUB config format
On Sunday, 29 November 2015 at 01:20:41 UTC, lobo wrote: On Wednesday, 25 November 2015 at 10:17:02 UTC, Suliman wrote: [...] A 20-page bikeshedding bonanza! Atypical D forums...and a pity that the priorities of core D devs is diverted to this spittle of a forum post when D has much bigger fish to fry. JSON/SDLang both have zero friction; if you use Dub+JSON you can become fluent Dub+SDLang in less than 1 minute for the first time. Pick one for your project and move on, both are supported. bye, lobo Gah! s/Atypical/A typical
Re: I hate new DUB config format
On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote: On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad wrote: On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote: [...] No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already. [...] I've never heard of Red, do you have a link? Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible. http://www.red-lang.org/ bye, lobo I believe the main difference between Red and Rebol2 is that Red exposes more of the H/W driver and OS layers.
Re: I hate new DUB config format
On Monday, 30 November 2015 at 21:05:08 UTC, Ola Fosheim Grøstad wrote: On Monday, 30 November 2015 at 20:42:23 UTC, Suliman wrote: Should we try to implement yet another language for writing building config? No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already. Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system. I've never heard of Red, do you have a link? Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible. http://www.red-lang.org/ bye, lobo
Re: I hate new DUB config format
On Tuesday, 1 December 2015 at 09:43:24 UTC, Idan Arye wrote: Red is not Rebol2 compatible - it's outright impossible to have a single script file that'll run without errors on both Rebol2 and Red. The reason is that Rebol2 requires the first thing in the file to be a `REBOL` preamble, while Red requires it to be a `Red` preamble(though it's generous enough to allow a shebang before it). Since you can only have one preamble, and it can't be both `REBOL` and `Red`, I refuse to call them compatible even if every Rebol2 command can be copied to a Red script and run in there! Meh, beyond s/Rebol/Red all my R2 code runs with Red. At any rate, please don't use any Rebol dialect in DUB(or for anything else, in that matter. Just - don't use it). Many languages have awkward quirks, but Rebol seems to be a collection of awkward quirks with a programming language somtimes accidentally hiding in between, created by someone who thought Perl is too readable and shell scripts have too strict type systems. Actually I find Rebol has less quirks than most languages. It does have one alien looking syntax though. bye, lobo
Re: [dlang.org] getting the redesign wrapped up
On Sunday, 10 January 2016 at 22:46:34 UTC, JohnCK wrote: First of all, the site looks better than the old version. Congratulations and now the criticism: I don't want to hurt anybody's feelings. But look the DMD's Image compared to GDC and LDC: http://i.imgur.com/TrnuxcB.jpg Really looks like a joke. I would say this seems more like 90's but I have doubt if it's older than that. Please let's go change that. JohnCK. I kinda like it :) It's better than that inbred bucktoothed gopher thing Go has for a mascot...it is all subjective. bye, lobo
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 03:56:02 UTC, tsbockman wrote: On Thursday, 16 June 2016 at 02:53:38 UTC, Andrei Alexandrescu wrote: [...] Numerous other mentions were made of this project in various contexts on the forums, in GitHub pull requests, and on the bug tracker - including discussions in which you participated. 'posts with "checkedint" in the title' is too narrow of a search filter. [...] Malicious intent is not required to make the act offensive; you're still jumping into a project a year in the making and demanding that I choose between investing an additional six months (wild guess) of my time working on things I don't care about (at best), or canceling the project (which has otherwise received generally positive feedback so far). I am not too upset mostly because I had a variety of reasons for pursuing this, not all of which depend on getting it into Phobos. [...] That is part of the problem, but this is also a fine example of a broader pattern that I have noticed in D's review process: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? I don't think people are doing it on purpose - it's just easier to start with the trivial nit-picks, because you don't need a deep understanding of the code and the problem domain (or decision-making authority) to complain about a missing ' ' or something. But, that doesn't change the fact that the process still feels almost perfectly designed to waste contributors' time. Unless the PR is a complete mess, (9) and (8) should be debated *first*, before worrying about any of the other stuff. Why waste people's time fixing trivialities, if it's all going to just be deleted or rewritten anyway? Has this work/design been submitted as a DIP? I cannot find it. I thought all Phobos additions of any magnitude were required to pass the DIP submission first in order to avoid this sort of situation. If there is a DIP that was accepted then to have it knocked back now would suck. Without a DIP you have to expect the design could be turned down by any core developer when they first get the opportunity to review it, no matter how long after the work was initiated. bye, lobo
Re: D vs Rust
On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote: I have loved C++ when I first started learning it a pair of years ago (then I stopped for some time for some work reasons), and quite recently I have discovered D, which seems apparently a better language from the design point of view, especially in supporting OO design and modularisation, maybe I am just wrong since I know just a little of D so far, but I really had some problems just in setting up a simple OO project, i.e. importing classes, there are .h and .cpp files, etc, which only make everything confusing and make you learn stupid things instead of being productive. D also seems to have a cleaner syntax in general. C++ is becoming more and more a mess because they keep introducing new functionalities to make C++ compete with new languages, and I'm starting hating it. Languages should not just be powerful but simple enough to be productive. Apart from this, what are the real advantages of D over Rust? They seem to be similar languages in what they want to achieve. Rust seems to be younger and the syntax seems to be slightly different from the C-like syntax. I am not such concerned or interested with the syntax advantages of a language over the other, but more about in general what one does better than the other. Overall, which one has a better design and a more promising future? Which one is more performant, in which situations? If you could answer all these questions it would be nice. I'm still deciding which one to learn and invest my time on, but I would like to have also your more experienced and expert opinion. Learn both. You will be a better programmer for it and will be in a position to make up your own mind which one *you* prefer. I come from a heavy C/C++/Java/Python background and for me productivity is paramount. Syntax is very important because it has an impact on my productivity. I find Rust syntax really annoying. Little things in D like UFCS and optional parens make a huge difference. Big things like D templates and compile time reflection power is so easy to tap into and use that it drives Rust into the ground. For me memory safety is not a problem. Yes it bites occasionally, but never enough that its worth giving up productivity everywhere else. bye, lobo
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' We’re all talk [...] On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: [] Interesting timing! At my workplace we have a geekfest video session once a month and last week it was this: https://youtu.be/-F-3E8pyjFo It's worth a watch and it covers very similar ground. The presenters discuss their experiences developing subversion and other FOSS projects. bye, lobo
Re: Females in the community.
On Thursday, 17 March 2016 at 22:36:41 UTC, maarten van damme wrote: This very sexist and you are clearly either very young or a closet misogynist Great, so you answer a poorly thought out attempt to encourage women to join this community by bashing on younger people? The comments don't deserve diplomacy and are highly offensive. The OP needs to realise we're not all soft and mushy creatures incapable of cutting code. Besides the OP himself said it was a brutal opinion and therefore it deserves a brutal answer. And this is the internet after all so it's the place to have pointless debates.
Re: Females in the community.
On Thursday, 17 March 2016 at 16:17:46 UTC, Karabuta wrote: Are there any female programmers using D? :) Moreover, the socia Media representation of D sucks. I think we need a female, at least someone soft and mortal who actually understand how to communicate and build a community. Coders suck at these things and its not helping. This is not about gender balance crap, it about building a community. Forgive me for my brutal opinion. Destroy :) This very sexist and you are clearly either very young or a closet misogynist. If you want more women to join the D community first you need to understand why your dull and inane comments are extremely degrading. And it isn't your use of the word female - figure it out then grow up. bye, lobo
Re: Does a Interpretation-Engine fit in phobos ?
On Thursday, 30 June 2016 at 11:09:10 UTC, ketmar wrote: On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote: Off-topic: Is it possible/feasible/desirable to let dmd use dub packages? please, no. not everybody out there is dub fan. You can always use dub to fetch packages into ~/.dub/packages and build them. The artifacts are then available for whatever build system you choose for your own project. I don't use DUB for my own projects because it drops garbage all through my source tree. The day it can do out of source builds is the day I'll revisit the DUB bazaar. bye, lobo
Re: dpldocs: xlinking and Documented destructors and postblits
On Wednesday, 1 March 2017 at 06:19:30 UTC, lobo wrote: On Wednesday, 1 March 2017 at 05:18:59 UTC, Adam D. Ruppe wrote: I stumbled across std.typecons.Unique in my doc website today and realized there was a postblit in the source, but I didn't display the documentation comment. [...] Is it possible to use your tool to generate the docs for my own code? Thanks, lobo Thanks, I'll give it a try. lobo
Re: dpldocs: xlinking and Documented destructors and postblits
On Wednesday, 1 March 2017 at 05:18:59 UTC, Adam D. Ruppe wrote: I stumbled across std.typecons.Unique in my doc website today and realized there was a postblit in the source, but I didn't display the documentation comment. [...] Is it possible to use your tool to generate the docs for my own code? Thanks, lobo
Re: DerelictSDL2 crashes
On Friday, 26 August 2016 at 21:26:13 UTC, unDEFER wrote:
Hello!
I'm trying compile SDL "Hello, World"
---
import std.stdio;
import derelict.sdl2.sdl;
//Screen dimension constants
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
int main()
{
DerelictSDL2.load();
//The window we'll be rendering to
SDL_Window* window = null;
//The surface contained by the window
SDL_Surface* screenSurface = null;
//Initialize SDL
if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
printf( "SDL could not initialize! SDL_Error: %s\n",
SDL_GetError() );
}
else
{
//Create window
window = SDL_CreateWindow( "SDL Tutorial",
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH,
SCREEN_HEIGHT, SDL_WINDOW_SHOWN );
if( window == null )
{
printf( "Window could not be created! SDL_Error: %s\n",
SDL_GetError() );
}
else
{
//Get window surface
screenSurface = SDL_GetWindowSurface( window );
//Fill the surface white
SDL_FillRect( screenSurface, null, SDL_MapRGB(
screenSurface.format, 0xFF, 0x00, 0x00 ) );
//Update the surface
SDL_UpdateWindowSurface( window );
//Wait two seconds
SDL_Delay( 2000 );
}
}
//Destroy window
SDL_DestroyWindow( window );
//Quit SDL subsystems
SDL_Quit();
return 0;
}
---
$ dmd -I/path/to/DerelictSDL2/source
-I/path/to/derelict-util-2.0.6/source main.d
/path/to/DerelictSDL2/lib/libDerelictSDL2.a
/path/to/derelict-util-2.0.6/lib/libDerelictUtil.a -gc
It compiles but on running crashes (as shows valgrind) in
SDL_FillRect function.
BUT in gdb it runs successfully and I see red window.
What I'm doing wrong? How gdb can make not working code working?
dmd 2.071.1
Thank you!
I tried your code in Arch x86_64 using dub and it worked for me.
This is the dub file I used:
---
name "testsdl"
targetType "executable"
dependency "derelict-sdl2" version=">=2.0.0"
dependency "derelict-util" version=">=2.0.6"
dependency "derelict-gl3" version=">=1.0.18"
---
If you're not familiar with dub and want to test these are the
steps I took.
0. Get dub [1]
1. mkdir -p testsdl/source
2. Copy your source code from OP into a file
"testsdl/source/app.d"
3. Copy the above dub config into a file "testsdl/dub.sdl"
4. cd testsdl; dub build
It should pull in the dependencies and build a program called
"testsdl".
bye,
lobo
[1] https://code.dlang.org/download
Re: ESA's Schiaparelli Mars probe crashed because of integer overflow
On Sunday, 27 November 2016 at 05:43:11 UTC, Shachar Shemesh wrote: On 26/11/16 07:50, Walter Bright wrote: I'd like to know what really happened with the code. But as someone who has worked on flight critical systems for airliners, the designs are required to account for any single failure of anything. That means all inputs must be validated for "reasonableness", and the same for outputs. If any of this is outside reasonable bounds, there must be failover to a backup method. My experience is slightly different. More accurately, I think your experience is too narrow. Yes, civilian aviation code gets a very high level of scrutiny. Number's I've heard range from 1:9 to 1:18 ratio between resources spent writing the code and resources spent testing it. Code is written to extremely high standards, that relate to the level of dependency flight safety has on the code. So, code actually flying the aircraft > code used to display flight critical information to the pilot > code used to display information the pilot may depend on > code used to display generic information. That last category, BTW, may run Windows and off the shelf applications. So that part corroborates Walter's story, BUT THIS ONLY APPLIES TO CIVILIAN AIRCRAFTS This level of standard does not apply to: * Military aircrafts * Spaceships * Auto car industry * Medical equipment I'm sure there's more Even drones, until fairly recently (around 2008), were completely unregulated. I'm talking about huge unmanned flying platforms, some as big as four seat airplanes. In some of those fields, things aren't as bad as that. The car industry is slowly getting better. High financial stakes in the space field cause caution. The military aviation field is done by much of the same players as the civilian aviation, and thus some care is carried over. As far as regulations go, however, we're screwed. Shachar My real world experience differs from yours but probably it comes down to the organisation you're with and for larger companies even which group. I've worked in military aviation, commercial drones for mining and exploration, not military, and medical devices and it was all heavily regulated software. I haven't come across too many cowboy outfits. I cannot speak for the other industries you mention such as automotive. The problem we face today in medical is not the lack of scrutiny and regulation but that regulations have not caught up with the security issues. The latest FDA guidelines address this somewhat for for pre and post market devices but there are many devices out there running a full linux with nothing more than SSH disabled. The majority will still have a root user account and probably even enable root over serial console. bye, lobo
Re: PDF generation in D?
On Tuesday, 15 November 2016 at 15:23:29 UTC, Adrian Matoga wrote: On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote: On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote: On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote: I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf This. Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf. Then that begs the question about how to generate ps in D and just kicks the can down the road. PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here. "Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables. Cairo can render to a postscript surface and PDF surface[1]. Maybe there is something in gtkd that suits your needs[2]? [1] https://www.cairographics.org/manual/cairo-PDF-Surfaces.html [2] http://gtkd.org/
Re: Linux Kernel in D?
On Sunday, 18 December 2016 at 03:05:13 UTC, Whatsthisnow wrote: On Sunday, 18 December 2016 at 00:10:47 UTC, sarn wrote: [...] I am basing the kernel on Linux because, well, I like Linux, and its the only complete kernel with free source that I currently know of. Given that it is widely Used as an OS kernel, it kinda made sense to port it, give it a new engine under the hood so to speak. I would like to keep it as close to the original as possible such that linux programmers will still have a generally familiar environment to work with, rather than having to learn an entirely new kernel. [...] I'd be inclined to start with a smaller OS like Plan9. Even FreeBSD would be simpler, althoguh no less gargantuan than Linux, it is better organised and documented IMO. Anyway good luck with this, even if you don't finish you're bound to learn a lot in the process. bye, lobo
Re: Gui in D: I miss this project
On Thursday, 12 January 2017 at 07:24:43 UTC, aberba wrote: On Wednesday, 11 January 2017 at 15:33:36 UTC, Sai wrote: After all, when someone wants a cross platform D GUI library, the ONLY current usable choice is DLangUI. I disagree. There is no need for a pure D GUI library. It is a lot of work for little value and we'd be better off with improved C++ interop first. I have several cross platform projects in industry now running on GtkD. It works out of the box on Linux and was trivial to get going on Windows and Mac. It is built on a stable base and has a D api that is easy to use. GtkD could use some more hands to really improve the D experience so I'd argue that project would be better suited to immediate D foundation support (after C++ interop of course). bye, lobo
Re: wrong isInputRange design
On Saturday, 3 December 2016 at 17:29:47 UTC, rumbu wrote:
On Saturday, 3 December 2016 at 16:37:21 UTC, Jerry wrote:
On Saturday, 3 December 2016 at 11:52:00 UTC, rumbu wrote:
[...]
[...]
[...]
Is that the exact code? isInputRange checks to see if the type
has "front" defined.
https://github.com/dlang/phobos/blob/v2.072.0/std/range/primitives.d#L162
Also "string" is just an alias of an array,
"immutable(char)[]". So an array should have "front" defined.
Can you post more code?
No, an array should not have "front" defined according to D
language specification. "front" for arrays is defined in
std.range.primitives. That's the problem, I cannot have two
specialized functions (one taking arrays and one taking
ranges), because std.range.primitives hijacks any char array
and transforms it in a range). front, empty, popFront must not
be defined for arrays in the same module as isInputRange.
Exact code is irrelevant, but you're welcome:
string constructor:
https://github.com/rumbu13/numerics/blob/master/src/numerics/fixed.d#L978
range constructor
https://github.com/rumbu13/numerics/blob/master/src/numerics/fixed.d#L1104
This works for me when specialising for input ranges, strings and
arrays.
auto f(T)(T val)
if(isInputRange!T && !isSomeString!T && !isArray!T) {}
auto f(T)(T val)
if(isSomeString!T) {}
auto f(T)(T val)
if(isArray!T && !isSomeString!T)
bye,
lobo
Re: D future ...
On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote: On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote: On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote: [...] https://issues.dlang.org/show_bug.cgi?id=16991 Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure. Maybe you could fix one or two? As you say they're trivial and apparently no one else is doing it. bye, lobo
Re: D future ...
On Tuesday, 20 December 2016 at 08:20:32 UTC, LiNbO3 wrote: On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote: On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote: On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote: On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote: [...] https://issues.dlang.org/show_bug.cgi?id=16991 Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure. Maybe you could fix one or two? As you say they're trivial and apparently no one else is doing it. bye, lobo And have the patch wait in the PR queue until the end of time, not even acknowledged at all ? The lack of focus goes hand in hand with the lack of manpower with some not-so-great results like we're seeing right now, at least IMO. The perceived lack of focus is another matter, which I agree is disconcerting. I say perceived because I'm sure there is focus and a plan but it isn't visible from the outside. The core dev team seem to jump from one thing to the next with nothing going pushed thought the last 10% to completion so it all feels 90% complete. bye, lobo
Re: anyone using msgpackrpc-d ? it's currently broken and doesn't seem maintained
On Thursday, 15 June 2017 at 04:14:22 UTC, Timothee Cour wrote: Msgpack rpc with vibe.d works. We used it. you mean with msgpackrpc-d? If so, it works, until you run into https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 (when server sends >= 4090 bytes, client hangs forever). we switched towards http + asdf not sure what asdf is? Probably this: https://github.com/tamediadigital/asdf
Re: D needs to get its shit together!
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote: Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down. [...] I don't know what is so hard about tar -zxvf dmd.XYZ.tar.xz or unzip dmd.XYZ.zip. Am I missing something? Perhaps rather than developing a wall of text maybe you could spend the time and energy learning how to compile and link code using an actual compiler instead of an IDE framework. You would then have the skills to use D anywhere with/without the flavour of the month IDE. bye, lobo
Re: D-Man emoji
On Monday, 11 September 2017 at 23:24:32 UTC, user1234 wrote: On Monday, 11 September 2017 at 23:01:06 UTC, Walter Bright wrote: Here are some D-Man cartoons: https://github.com/dlang/dlang.org/pull/1648 which we sometimes use to decorate D related web pages: http://dlang.org/safed.html http://dlang.org/dstyle.html It seems we are under-utilizing our mascot, D-Man. Wouldn't it be nice to have a set of D-Man emojis that can be linked to? or that we can use in the D forums? Anyone want to contribute some? No drawing talent required! I drew some, and I have the talent of a second-grader. [I know that because my mom saved some of my 2nd grade art, and things haven't improved.] The mascot seems to be used here at least: https://www.google.com/maps/d/edit?mid=1euIpoA6stFHlmIk1m9qbVHwP_64 Who's this D user? Dewitt Office of Gulag Director 42.53839, 129.93283
Re: Symbols missing, unmangle!
On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote: It would be nice if, when symbols are missing, they are unmangled! Error 42: Symbol Undefined _D12mMunchhousin12iMunchhousin11__T4GoTsZ4GoMFS12mMunchhousin18__T10MunchhousinTsZ10sMunchhousinfE12mMunchhousin9eGoffZv (void Munchhousin.Munchhousin.Go!(short).Go() I know some like to read nonsense for fun, but I don't. Sure, I could learn, but it is a useless skill only good for interpreting link errors, writing compilers, and being the life of the party, none of which I want to do for a living. Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()" Is this not the missing symbol? I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd. bye, lobo
Re: HTOD
On Wednesday, 23 August 2017 at 13:25:20 UTC, 12345swordy wrote: On Tuesday, 22 August 2017 at 19:55:53 UTC, Jacob Carlborg wrote: On 2017-08-22 19:47, 12345swordy wrote: Use Clang frontend? DStep [1] is doing that. It handles both GCC and Microsoft extensions. [1] https://github.com/jacob-carlborg/dstep "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Do you know another language or tool that can call C++ natively? I'm looking for native C++ interop either built in or via tooling. bye, lobo
Re: HTOD
On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote: [...] nim: it supports both targetting C++ (as well as C or javascript) and also calling C++ via foreign function interface, eg here are some links: https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim https://forum.nim-lang.org/t/1056 for D, there's a project to support full C++ natively using clang library is calypso, unfortunalty I haven't been able to use it, either from OSX or ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, hoping someone can help here! On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d <digitalmars-d@puremagic.com> wrote: [...] Thanks, I'll revisit Nim. As a team we're testing new languages as a larger plan to switch from C++. Nim we struck off 6 months ago because we found it not quite production ready. bye, lobo
Re: HTOD
On Thursday, 24 August 2017 at 05:56:02 UTC, Timothee Cour wrote: On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d <digitalmars-d@puremagic.com> wrote: On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote: [...] nim: it supports both targetting C++ (as well as C or javascript) and also calling C++ via foreign function interface, eg here are some links: https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim https://forum.nim-lang.org/t/1056 for D, there's a project to support full C++ natively using clang library is calypso, unfortunalty I haven't been able to use it, either from OSX or ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, hoping someone can help here! On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d <digitalmars-d@puremagic.com> wrote: [...] Thanks, I'll revisit Nim. As a team we're testing new languages as a larger plan to switch from C++. Nim we struck off 6 months ago because we found it not quite production ready. bye, lobo Would love to hear more about your reasoning as I'm also occasionally re-visiting it, do you have any writeup? No write up I can release at this stage because there are some business confidential aspects in the final report. We're ~30 Python, Java and C++ programmers. Our testing involved 1 developer month in each language implementing scripts to parse into data, a basic library read and interpolate data on a 3D regular grid, a small GUI application to display regular grids and tool chain testing where we produced a metric tonne of autogenerated code to see how well we could integrate into our existing build infrastructure and what build times would be like. From memory Nim had four main issues: a) 4 compiler ICEs. Our metric was >2 during testing and it was out, so this alone blew Nim away; we were deliberately harsh. D had 1 ICE that was a known issue with core team member comments on the bug report. b) Nim compilation was slower than other languages (we count the C compilation as part of the same package) c) Our Python devs found Nim was not Pythonic enough compared to other languages for hack n' slash quick scripts while keeping it maintainable and clean. d) Our developers (Python, Java and C++ people) preferred other language syntax bye, lobo
Re: Symbols missing, unmangle!
On Wednesday, 30 August 2017 at 22:21:52 UTC, Johnson wrote: On Wednesday, 30 August 2017 at 22:07:29 UTC, lobo wrote: On Wednesday, 30 August 2017 at 20:23:18 UTC, Johnson Jones wrote: [...] Your error message already displays "void Munchhousin.Munchhousin.Go!(short).Go()" Is this not the missing symbol? I don't read mangled names either and I've found ddemangle tool helps. It ships with dmd. bye, lobo It might be the same. If that is the case then it would be nice if it didn't display the junk that gets in the way(e.g., add a switch). I don't want to have to hunk and peck for stuff(even if it's nearly obvious in some cases). In VisualD, the mangled crap is on a long line that I have to scroll, which is time consuming. Even if wrap is on it still isn't pretty. I mean, if the logic is "It shows the information" then why not just display it directly in binary and let the end user convert it in their head. If they are too stupid to do so then create an online demangler site and a few college classes to teach them how. At some point it becomes ridiculous. Technology is suppose to make our lives easier, not harder. Usually these things are left the way they are until someone gets tired of it and fixes it, it's not that it can't be done, it's that no one seems to care(or it would have been done or the time is now). Dunno about VisualD, never used it. I'm using Vim and have it piping the output through ddemangle automatically so mangled names are not an issue. I'd assume VisualD can do the same. Sounds like you might be that someone who got tired of it and cares enough to implement the necessary pull request.
Re: [OT] vim tip with column limits
On Monday, 9 October 2017 at 00:24:02 UTC, Jonathan M Davis wrote: I've wanted this for ages and just figured out how to do it, so I figured that I'd share for those vim users who care. [...] This presentation gave me a few vim ideas, you might also like it. https://www.youtube.com/watch?v=aHm36-na4-4 bye, lobo
Re: [OT] Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?
On Friday, 24 November 2017 at 23:36:08 UTC, Bobb wrote: On Friday, 24 November 2017 at 20:29:23 UTC, codephantom wrote: On Friday, 24 November 2017 at 12:10:28 UTC, Nick Treleaven wrote: On Thursday, 23 November 2017 at 06:35:17 UTC, codephantom wrote: I love not being able to edit posts. It's so convenient. It's not as much of a problem as not being able to hide all posts by a user who repeats arguments, derails the conversation onto irrelevant side discussions and judges individuals instead of the idea they are conveying. So...you've just described your own post...you moron. Fuck you. Quality post right here. One shouldn't discourage the enthusiasm, arrogance and ignorance of youth. Keep trying codephantom you will get it one day. bye, lobo
Re: @ctfeonly
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? Shouldn't the linker do this already? Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code. bye, lobo
Re: My first experience as a D Newbie
On Thursday, 19 October 2017 at 21:18:43 UTC, Rion wrote: On Thursday, 19 October 2017 at 18:10:04 UTC, H. S. Teoh wrote: Told by whom? The responses here seem to be a good indicator that he is wasting his time. The past responses in similar topics. Even Andrei or Walter can be convinced over time, if one is persistent enough. :-D There have been cases of this in the past. Of course, this presumes that one cares about the issue enough to persist in the face of opposition, which may or may not be the case here. You mean like those where people are told, if you write a proposal it may get accepted. Then the author does all the work, writes the code changes, gets pushed to make more changes, gets ignored over time and loses interest, only for year later it showing up again and the process repeats? And nothing gets done to the point the author simply moved on to other languages. Yes, those have been very successful ( sarcasm ) in persuading people to put time into D development. D has a bad track record with implementations of proposals, even when the actual code has been written. There has always been a standard: Walter writes it, its going to get accepted with a high ratio in one form or another. Somebody who is not a core member, well ... But this is my last response on this. Moving on to a different language because from my point of view, D will not be very open / marketing focused to non C++ developers. And some people seem very willing to push people there buttons when topics like this come up. As we see in this topic. I regret that the actions of few constantly ruin the work of others ( to bring people in ). What seems to be a recurring theme. But let bygones be bygones. Good fortune to you all. I have been rung out several times in the D, Python and C++ communities trying to get various proposals up over the yrs. I dare not count the hours that have gone into each and I have to say that D is the most forgiving and helpful community when it comes to feedback and help. For me the proposal process, i.e. drafting, prototype implementation etc., is the best personal learning and development experience money can't buy and the acceptance of a proposal is second to this. That is what I get out of submitting proposals. bye, lobo
Re: Maybe D is right about GC after all !
On Monday, 1 January 2018 at 05:29:06 UTC, Ali wrote: On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 So .. and this is more of a question, to the maintainers and creators of D, what does this mean for D, what is the road map for D - More support for GC free programming or - More commitment to the GC - Something else It would be nice to hear from the creators of D, what is their vision for future development and enhancement https://wiki.dlang.org/Vision/2017H2
Re: Shouldn't invalid references like this fail at compile time?
On Wednesday, 24 January 2018 at 02:28:12 UTC, Mike Franklin wrote: On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright wrote: Microcontroller code tends to be small and so it's unlikely that you'll need to worry about it. I think you need to get involved in programming microcontrollers again because the landscape has changed drastically. The microcontrollers I use now are more powerful than PCs of the 90's. The project I'm currently working on is an HMI for industrial control with a full touchscreen 2D GUI. The code base is 240,084 lines of code and that doesn't even include the 3rd party libraries I'm using (e.g. 2D graphics library, newlib C library, FreeType font rendering library). That's not "small" by my standard of measure. And with devices such as this being increasingly connected to the Internet, such carelessness can easily be exploited as evident in https://en.wikipedia.org/wiki/2016_Dyn_cyberattack And that's not to mention the types of critical systems that run on such platforms that we are increasingly becoming more dependent on. We better start worrying about it. Mike Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support. Even the hokey FreeRTOS can be configured to throw a hardware exception on nullptr access. I work on critical systems SW developing life support and pace makers. For us nullptrs and memory management is not an issue. It is not hard to design these problems out of the critical component architecture. The bigger problem is code logic bugs and for that we make heavy use of asserts and in-out contracts. We don't use D, it is all C++ and some Ada in the older systems. bye, lobo
Re: Shouldn't invalid references like this fail at compile time?
On Wednesday, 24 January 2018 at 04:15:27 UTC, Mike Franklin wrote: On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote: Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support. I don't see how the OS can help if the underlying hardware doesn't have an MMU. That being said, admittedly, the more capable microcontrollers do have an MPU that can be configured to throw a hardware exception. OK I'll state here that personally I don't agree with the segfault argument if the nullptr access can be detected at compile time. Anything that can be done at compile time should not be pushed out to runtime. That said you can architect code so that nullptrs go away and the MMU is not necessary. E.g. no pointers and no allocations after main() are just two of a number of steps you can take. Good engineering works; in the 10yrs I've been with the Health Care Devices group we haven't had one memory corruption issue in a critical component. The last memory corruption issue we had in non-critcal was 4yrs ago, in older C++ code. Memory corruption really is becoming a thing of the past in modern C++. Now the biggest problems for us are security because everything has to be internet enabled! We don't use D, it is all C++ and some Ada in the older systems. Why don't you use D? Mike We're looking into D but at the moment but the general consensus is that the tooling is not mature enough on ARM (STM32) or Atmel AVR32 (used in our older devices). Rust is in the same boat. We have ~250 devs and there are basically three groups, C/C++, D and Rust. But it pains me to say that all three groups agree that modern C++ is probably going to win in the end. And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable. bye, lobo
std.logger sharedLog usage
Hi,
I'm trying to use std.experimental.logger and I'd like the
logf(), tracef() style functions to log to a file and stdout.
(note: I can use sharedLog.logf(), sharedLog.tracef(), but I
prefer just logf())
So I did this:
shared static this() {
auto ml = new MultiLogger();
ml.insertLogger(stdout, new FileLogger(std.stdio.stdout));
ml.insertLogger(applog, new FileLogger(applog.txt));
sharedLog = ml;
logf(This is a test); // Doesn't work
}
Which doesn't work, so I'm wondering if it's possible to do what
I want.
thanks,
lobo
Re: std.logger sharedLog usage
On Sunday, 29 March 2015 at 12:37:23 UTC, Robert burner Schadek
wrote:
On Sunday, 29 March 2015 at 01:36:24 UTC, lobo wrote:
Hi,
I'm trying to use std.experimental.logger and I'd like the
logf(), tracef() style functions to log to a file and stdout.
(note: I can use sharedLog.logf(), sharedLog.tracef(), but I
prefer just logf())
So I did this:
shared static this() {
auto ml = new MultiLogger();
ml.insertLogger(stdout, new FileLogger(std.stdio.stdout));
ml.insertLogger(applog, new FileLogger(applog.txt));
sharedLog = ml;
logf(This is a test); // Doesn't work
}
Which doesn't work, so I'm wondering if it's possible to do
what I want.
thanks,
lobo
just add the line stdThreadLocalLog.logLevel = LogLevel.info
before logf and it should work. The default LogLevel of the
MultiLogger and FileLogger is high than the default LogLevel of
stdThreadLocalLog. (I will fix that)
Thank you, lobo.
Re: Passing myself, a struct, as a C callback context
On Monday, 30 March 2015 at 02:53:36 UTC, Paul O'Neil wrote:
I'm registering a callback with some C code. The simplified
story is
here, but the actual code is on GitHub [1] at the end if you
care.
The call looks something like this.
void register(void(*fp)(void*), void* context);
I have a class that holds state for the callback and registers
itself:
final class Klass
{
void method()
{
register(callback_function, this);
}
}
As of dmd 2.067, doing this is deprecated. Is there an
idiomatic way
to do this?
[0] Actual code is at
https://github.com/todayman/dubik/blob/master/source/vibe/core/drivers/rx.d#L177
. The msg object eventually gets passed to the registration
function.
Thanks,
This is only deprecated for class not struct. This code below
works fine:
---
import std.stdio;
extern(C) void f2(void* ins) {
auto s = cast(S*)(ins);
writefln(f2():%s, s);
writefln(f2():%s, *s);
}
void f1(void* ins) {
auto s = cast(S*)(ins);
writefln(f1():%s, s);
writefln(f1():%s, *s);
}
struct S { // -- change to class to get deprecated message
int value = 10;
void f() {
f1(this);
f2(this);
}
}
void main()
{
auto s = S();
s.f();
}
---
bye,
lobo
Re: std.logger sharedLog usage
On Sunday, 29 March 2015 at 01:36:24 UTC, lobo wrote:
Hi,
I'm trying to use std.experimental.logger and I'd like the
logf(), tracef() style functions to log to a file and stdout.
(note: I can use sharedLog.logf(), sharedLog.tracef(), but I
prefer just logf())
So I did this:
shared static this() {
auto ml = new MultiLogger();
ml.insertLogger(stdout, new FileLogger(std.stdio.stdout));
ml.insertLogger(applog, new FileLogger(applog.txt));
sharedLog = ml;
logf(This is a test); // Doesn't work
}
Which doesn't work, so I'm wondering if it's possible to do
what I want.
thanks,
lobo
Hmm, I should read code before posting. logf() etc. are using
stdThreadLocalLog so this does what I want:
shared static this() {
auto ml = new MultiLogger();
ml.insertLogger(stdout, new FileLogger(std.stdio.stdout));
ml.insertLogger(applog, new FileLogger(applog.txt));
stdThreadLocalLog = ml;
logf(This is a test); // works :)
}
Minor nitpick: This isn't clear in the docs of std.logger.
Throughout sharedLog is referred to as the default logger, not
stdThreadLocalLog.
Other than that I'm finding std.logger is really easy to use,
nice work Phobosians!
bye,
lobo
Re: Release D 2.067.0
On Saturday, 28 March 2015 at 14:12:19 UTC, Vladimir Panteleev wrote: On Saturday, 28 March 2015 at 05:35:57 UTC, ketmar wrote: On Sat, 28 Mar 2015 04:55:47 +, Vladimir Panteleev wrote: But honestly, there already exists so much information on how to use DustMite... ...that people in bugzilla keep asking what it is. Not knowing what something is and not wanting to learn how to use it are different things. ANYONE should be able to use DustMite or Digger to reduce a test case down to reasonable size. having a big codebase that you didn't wrote and never read took 12 hours to dustmite. not that i can just leave it unattended though, as compiler itself segfaults sometimes, and that effectively leaves dustmite frozen. so it not only eats resources of my box (and i have a work to do, and that work involves compiling big codebases too), but it requires my attention. but yes, it's entirely my fault that i cannot afford such resources and asking for help, i know. Honestly, did you even try? https://github.com/CyberShadow/DustMite/wiki/Detecting-a-segfault-in-dmd-itself https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout https://github.com/CyberShadow/DustMite/wiki/Useful-test-scripts Or did you just give up after the first difficulty, saying, well, I tried? Do you think your time is more valuable than that of D contributors' or something? This attitude is crap and is becoming more frequent on the forums. The D development team is not interested in listening to their user base unless the user base is willing to contribute back to D language development with PRs. Good luck with that because most end-users will not bother even trying to file a bug report, let alone distill it down with some tool in the compiler download. They'll just move on in another language that doesn't require effort fighting compiler/language bugs. bye, lobo
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 02:34:04 UTC, Jakob Ovrum wrote: On Thursday, 26 March 2015 at 02:04:26 UTC, Laeeth Isharc wrote: [snip] It would have been better if several languages were used in comparison to Go. Overall the blog post is a bit immature with little rigor and too much emotion. The code comparisons that aren't idiomatic for either language nor behaviorally equivalent. It reads like a D-zealot had decided to write this blog before they even clicked the download link for the Go compiler. And so, their experience was never going to be anything but negative. That said, Go is unpleasant and probably the most boring language I've had to write code in. bye, lobo
Re: Calypso: Direct and full interfacing to C++
On Thursday, 16 April 2015 at 00:47:31 UTC, Elie Morisse wrote: Sorry for the lack of updates, progress was a bit boring for the past 2 months and consisted mostly in crawling my way up a bottomless pit of errors generated by « import (C++) Ogre.Light; ». And then this happens: https://paste.kde.org/pse8pqzch :D The compilation speed could be improved, more bugs should get triggered by actual usage of Ogre, but close to everything gets mapped, semantic'd and codegen'd and this is the milestone I've been working towards for months. Last week also introduced was the Clang module map file support, which helps breaking namespaces into smaller pieces and thus makes probably most C libraries usable right now without having to maintain bindings, only a module map file which may also be generated by clang-modularize. Wow, this is great stuff! I'd love to get this working with VTK! I currently have half-baked bindings that still have a bunch of bugs. This looks like a much more interesting approach. bye, lobo
Re: dsource.org moved
On Thursday, 16 April 2015 at 23:32:17 UTC, Stewart Gordon wrote: On 16/04/2015 03:35, Rikki Cattermole wrote: On 16/04/2015 11:25 a.m., Stewart Gordon wrote: snip How would we go about committing updates to it when this is done? Let's say there is a new function in gdi.h added. You would look for the file: core/sys/windows/windows/gdi.d And add the function declaration. Or if it is a whole new file: Add: core/sys/windows/windows/newFile.d Add line: public import core.sys.windows.windows.newFile; To: core/sys/windows/windows/package.d Basically the same process as now, except spread out across more files. I don't understand - how would an average member of the D community get into the DMD package on dlang.org in order to apply these updates? Get DMD, Druntime and Phobos and build them: http://wiki.dlang.org/Building_DMD Make your changes and test. Contribute your changes back to D using pull requests. http://wiki.dlang.org/Pull_Requests bye, lobo
Re: mixin template question
On Sunday, 12 April 2015 at 03:51:03 UTC, Paul D Anderson wrote:
I don't understand why the following code compiles and runs
without an error:
import std.stdio;
mixin template ABC(){
int abc() { return 3; }
}
mixin ABC;
int abc() { return 4; }
void main()
{
writefln(abc() = %s, abc());
}
Doesn't the mixin ABC create a function with the same signature
as the actual function abc()?
It compiles with both included and writes abc() = 4. If I
comment out the actual function then it writes abc() = 3. The
actual function takes precedence, but why don't they conflict?
Paul
As the manual says (snippet below) the surrounding scope
overrides mixin
http://dlang.org/template-mixin.html
---
Mixin Scope
The declarations in a mixin are ‘imported’ into the surrounding
scope. If the name of a declaration in a mixin is the same as a
declaration in the surrounding scope, the surrounding declaration
overrides the mixin one:
int x = 3;
mixin template Foo()
{
int x = 5;
int y = 5;
}
mixin Foo;
int y = 3;
void test()
{
writefln(x = %d, x); // prints 3
writefln(y = %d, y); // prints 3
}
---
bye,
lobo
Re: dsource.org moved
On Friday, 17 April 2015 at 21:34:07 UTC, Stewart Gordon wrote: On 17/04/2015 02:19, lobo wrote: On Thursday, 16 April 2015 at 23:32:17 UTC, Stewart Gordon wrote: snip I don't understand - how would an average member of the D community get into the DMD package on dlang.org in order to apply these updates? Get DMD, Druntime and Phobos and build them: http://wiki.dlang.org/Building_DMD Why would one need to build DMD in order to make changes to a set of API bindings? Make your changes and test. Contribute your changes back to D using pull requests. http://wiki.dlang.org/Pull_Requests Has Walter promised us that every pull request for the WindowsAPI bindings will be put in right away? Even if he had, what would be the point? It would greatly slow down the whole process. We have SVN repositories so that people can just put their updates straight in, and everyone else not only has access to the update straight away but can obtain it with either a one-line command line invocation or a few mouse clicks. The only problem is that the SVN server that is currently hosting the bindings doesn't work properly. We already have a potential solution: moving it across to Github. As such, I'm going to see if I can figure out how to do this. Stewart. Sorry, my mistake. I thought you were asking about how to contribute bindings back to Phobos. bye, lobo
Re: Arch Linux D package update
On Thursday, 4 June 2015 at 14:46:39 UTC, Dicebot wrote: gdc - now uses 5.1 gcc base and 2.066.1 frontend - patched to correctly use system zlib library (resulted in linker errors before) dtools - switched back to use dmd as default compiler dub - switched back to use dmd as default compiler dcd - new package, release 0.6.0 - only x86_64 for now (upstream bug) - provides systemd service : `sudo systemctl enable dcd.service` to start automatically upon system startup - provides default /etc/dcd.conf with stdlib paths for Arch Linux Thanks for this work. The arch packages got me started in D because there was so little friction to try it out. I probably wouldn't have bothered otherwise because I was a happy pig in C++ mud at the time. bye, lobo
optimizing struct/class members
Hi, In C++ it's important to layout struct/class members correctly for performance reasons. Is the same true in D? Thanks, lobo
Re: optimizing struct/class members
On Tuesday, 7 July 2015 at 00:23:38 UTC, John Colvin wrote: On Monday, 6 July 2015 at 23:24:00 UTC, lobo wrote: Hi, In C++ it's important to layout struct/class members correctly for performance reasons. Is the same true in D? Thanks, lobo Short answer: yes. thanks, lobo
Re: Necessity of D Library (and/or Core Library)
On Saturday, 23 May 2015 at 06:35:50 UTC, Anthony Monterrosa wrote: Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? I have become very interested in how programming languages do their magic; how they interact with the computer itself, and their inner mechanics. This eventually led me to resources that said the line between a language and its library differs between languages, and I was wondering where D stood on that line. Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. P.S. I'm only a freshman computer science student, so if some of this should be basic, I simply don't know it yet. Thanks in advance! I have some bare metal code that works without Druntime. The compiler injects code that references some druntime components, which causes the linker to barf if they're not defined somewhere. You can simply define them as global void* vars like so: --- module kernel.kmain; // So we compile without druntime. extern(C) __gshared void* _d_dso_registry; extern(C) __gshared void* _Dmodule_ref; extern(C) __gshared void* _d_arraybounds; extern(C) __gshared void* _d_assert; extern(C) __gshared void* _d_unittest; // rest of code here --- This was back in DMD 2.065 so things may have changed between then and now. bye, lobo
Re: Why approxEqual not working for integers in dmd 2068-b2
On Tuesday, 28 July 2015 at 07:42:32 UTC, Daniel Kozák wrote: Even if this will be considered as non compiler bug, it is a regression on phobos side and should be addressed. So please fill a bug report on http://issues.dlang.org done, thanks https://issues.dlang.org/show_bug.cgi?id=14842
Why approxEqual not working for integers in dmd 2068-b2
Hi all,
I have a bunch of unittests for template code taking any numeric
type. Because I'm lazy I just use the approxEqual for both
floating point and integer comparisons in these tests.
In DMD 2067.1 everthing compiled OK but in 2068-b2 I get the
errors shown at the end of this post for integer types.
I'd like to know if it is OK to use approxEqual like I am in
unittests and why approxEqual was changed, if it was intentional,
for learning more about good use of D language
Thanks,
lobo
Test code:
---
void main() {
int a = 10;
assert(approxEqual(10, a));
}
---
Errors:
src/phobos/std/math.d(6718): Error: std.math.fabs called with
argument types (int) matches both:
src/phobos/std/math.d(3415): std.math.fabs(real x)
and:
/src/phobos/std/math.d(3421): std.math.fabs(float x)
/src/phobos/std/math.d(6725): Error: std.math.fabs called with
argument types (int) matches both:
/src/phobos/std/math.d(3415): std.math.fabs(real x)
and:
/src/phobos/std/math.d(3421): std.math.fabs(float x)
/src/phobos/std/math.d(6726): Error: std.math.fabs called with
argument types (int) matches both:
/src/phobos/std/math.d(3415): std.math.fabs(real x)
and:
/src/phobos/std/math.d(3421): std.math.fabs(float x)
/src/phobos/std/math.d(6736): Error: template instance
std.math.approxEqual!(int, int, double) error instantiating
hack.d(13):instantiated from here: approxEqual!(int, int)
Failed: [dmd, -v, -o-, hack.d, -I.]
---
Re: asm+D build bootloader
On Tuesday, 27 October 2015 at 12:13:13 UTC, guodemone wrote:
sorry,My english is poot.
file asm.h
[...]
Can ldc work with C header files? I don't think it can but I
could be wrong.
Here's how I build my 32-bit bootloader and link with my kernel
main (you will have to replace names etc.):
---
nasm -felf -o kickstart32.o kickstart32.s (I don't have an asm.h)
gdc -m32 -gdwarf-2 -nostdlib -fPIC -c -o kernel32.main.o kmain.d
ld -nodefaultlibs -melf_i386 -z max-page-size=0x1000 -T
linker32.ld -o kernel32.bin kickstart32.o kernel32.main.o
---
For this build setup you will need a linker script. Here's mine
in case you don't have one. 'kickstart' is the entry point in my
kickstart.s. Replace names and offsets as required for your code.
---
/* Use -melf_i386 or -melf64_x86-64
* to specify the architecture
* ld -nodefaultlibs -melf_i386 -z max-page-size=0x1000 -T
-o
*/
ENTRY (kickstart)
SECTIONS{
. = 0x0010;
.text :{
code = .; _code = .; __code = .;
*(.text)
*(.rodata)
}
.rodata ALIGN (0x1000) : {
*(.rodata)
}
.data ALIGN (0x1000) : {
data = .; _data = .; __data = .;
*(.data)
start_ctors = .; *(.ctors) end_ctors = .;
start_dtors = .; *(.dtors) end_dtors = .;
}
.bss : {
sbss = .;
bss = .; _bss = .; __bss = .;
*(COMMON)
*(.bss)
ebss = .;
}
end = .; _end = .; __end = .;
}
---
I got a lot of info from these sites:
https://www.cs.cmu.edu/~410-s07/p4/p4-boot.pdf
https://en.wikibooks.org/wiki/X86_Assembly/Bootloaders
http://wiki.osdev.org/Bare_bones
(NOTE: wiki.osdev.org has a lot of incorrect information, but it
was useful as a starting point when I got stuck moving to a
64-bit kernel)
bye,
lobo
Re: Can you give me your files[kickstart32.s kmain.d linker32.ld makefile]?
On Wednesday, 28 October 2015 at 11:01:14 UTC, guodemone wrote: My english is poor. My code to build is wrong.so need make some improvements. I would like to refer to your 32-bit code, make some improvements. My Email: 704975...@qq.com very very thank you. I've uploaded a dummy kernel with bootloader to Github. Hopefully it will help you. https://github.com/swamplobo/lyrebirdos A few points: * The Makefile uses DMD but if you prefer you can use the gdc_Makefile to switch compilers easily. * This example uses GRUB, which you can replace this if you wish. I did once I got things working (I've now gone back to GRUB because it has some nice features). * I use qemu, VirtualBox and real hardware to test. I recommend testing in a VM before trying real hardware. * The name Lyrebird OS is just the name I chose, rename to whatever you like. * Keep at it because it's very rewarding watching your own kernel grow. bye, lobo
Re: very very thank you
On Thursday, 29 October 2015 at 06:13:17 UTC, guodemone wrote: 衷心的谢谢你,(very veryvery thank you in english) You're welcome, hope it helps :)
Re: why does this error out?
On Tuesday, 10 November 2015 at 04:34:22 UTC, Cauterite wrote: Here's the output I get (DMD v2.068.2): [1, 3, 10, 12, 21, 30, 100, 102, 111, 120, 201, 210] core.exception.AssertError@std\range\package.d(4603): Assertion failure iota.front() is complaining the range is empty from this line. harshads.filter!(h => h > 1000).front.writeln; your hardas has no values > 1000 so the filter is empty. hardwas was seeded with iota(1,256), so the maximum value will be 252. bye, lobo
Re: why does this error out?
On Thursday, 12 November 2015 at 02:36:23 UTC, lobo wrote: On Tuesday, 10 November 2015 at 14:25:19 UTC, steven kladitis wrote: On Tuesday, 10 November 2015 at 05:14:29 UTC, lobo wrote: [...] with dmd 2.069 I always get --> [1 and then the error no matter what I canhe that line to. Hmm, that's different to what I get. On linux 64 bit with dmd 2.069 I get this: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 18, 20, 21, 24, 27, 30, 36, 40, 42] core.exception.AssertError@std/range/package.d(4691): Assertion failure Note the assertion is same as before; hardas has no values > 252 so filter!(h => h < 1000) results in an empty range. bye, lobo that should be filter!(h => h > 1000)
Re: why does this error out?
On Tuesday, 10 November 2015 at 14:25:19 UTC, steven kladitis wrote: On Tuesday, 10 November 2015 at 05:14:29 UTC, lobo wrote: On Tuesday, 10 November 2015 at 04:34:22 UTC, Cauterite wrote: Here's the output I get (DMD v2.068.2): [1, 3, 10, 12, 21, 30, 100, 102, 111, 120, 201, 210] core.exception.AssertError@std\range\package.d(4603): Assertion failure iota.front() is complaining the range is empty from this line. harshads.filter!(h => h > 1000).front.writeln; your hardas has no values > 1000 so the filter is empty. hardwas was seeded with iota(1,256), so the maximum value will be 252. bye, lobo with dmd 2.069 I always get --> [1 and then the error no matter what I canhe that line to. Hmm, that's different to what I get. On linux 64 bit with dmd 2.069 I get this: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 18, 20, 21, 24, 27, 30, 36, 40, 42] core.exception.AssertError@std/range/package.d(4691): Assertion failure Note the assertion is same as before; hardas has no values > 252 so filter!(h => h < 1000) results in an empty range. bye, lobo
Re: Looking for a language to hang my hat on.
On Monday, 16 November 2015 at 22:39:17 UTC, Dan wrote: I am a very new c++ programmer, having just learned the language this year. A few months ago I completed a course on Coursera that dealt with the security aspect of c (which I don't know, but it is similar enough): https://class.coursera.org/softwaresec-008 The course highlighted just how dangerous c/c++ can be. My reaction to the course has been an increased use of shared/weak pointers over standard pointers, more judicious use of "assert" and increased use of destructors, where class pointers are destroyed via the destructor so I don't need to worry about memory leaks as much (all of my non-vector arrays are created/destroyed via a class w/ template). Some of this slows programs down, but in reality it does not have much of an impact. But doubt will always linger that I caught every vulnerability. Therefore I am shopping for a language that codes like c++ but is safer. It sounds like D may fit that requirement. My platform of choice is 64-bit Fedora using Code::Blocks (yes, I use an IDE as a crutch). It seems that D supports this combo. I have been lurking on this site over the past few weeks trying to decide when (and if) to make the transition. Can anyone here who has already made that transition tell me how smoothly it went? Any major unexpected problems? Advice? thanks! Dan Start using D now. It's not all or nothing so you don't have to give up on C++. I have several projects that contain both C++ and D intermixed. D will make you a better C++ programmer, but especially C++ template programming. D metaprogramming is so easy to read, write and understand compared to C++ and many of the patterns still apply when you're standing knee deep in C++it. I also find the D standard library, Phobos, is a great codebase to learn from. Compared to the STL (except perhaps the original [1]) it's a great example of how performant D code can still be readable and maintainable. bye, lobo [1] http://www.stepanovpapers.com/butler.hpl.hp/stl/stl.zip
Re: Atila's article on Reddit: "Rust impressions from a C++/D programmer, part 1"
On Monday, 16 November 2015 at 00:50:50 UTC, Adam D. Ruppe wrote: On Monday, 16 November 2015 at 00:40:33 UTC, The Old One wrote: My point: until you can easily write D bare-metal code, without any runtime, and honestly without garbage collection, it just isn't a Real Systems Language. It really isn't hard. Yes, there's a learning curve to get started, but it isn't really hard once you make that initial investment. +1 Bare metal in D is easy now. If a programmer isn't resourcful enough to figure it out (D.learn + RTFM) then they will do little more in C/C++/Rust/whatever than turning on an LED or two. bye, lobo
