Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)
On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson wrote: If you have any experience with either OpenCL or CUDA we'd love to have your input. Have experience with both, more CUDA than OpenCL though. Feel free to contact me.
Re: D garbage collector and real-time systems
On Wednesday, 28 January 2015 at 08:12:25 UTC, Mike wrote: On Wednesday, 28 January 2015 at 06:58:42 UTC, Tom wrote: Or is there now the possibility of disabling the GC altogether, or replacing it with a refcounting 'GC' etc? You can disable the GC: http://dlang.org/phobos/core_memory.html#.GC.disable I think it's important to note that there is three ways to go to minimize GC impact, by order of increasing difficulty: 1. Minimize allocations andthe size of scanned heap. This allows to still use the GC which is handy. Stay at this level if you need only speed. 2. Not enabling the runtime. This forces you to be fully @nogc but using the GC is a runtime error instead of a link error. Stay at this level if you need reduced memory consumption. 3. Not link with the runtime, or link with a minimal runtime. This is the hardest way and yield smaller binary size of all, along with the speed and reduced memory consumption. GC avoidance is a spectrum.
Strange bug when doing a custom build of druntime
Hi ! I'm trying to figure out what happens. http://pastebin.com/e6HPvjJ4 There's a full command line. It builds OK and works too. But there's some strange bug with bounds check. The code of _d_arraybounds is just: .text:000140014210 _d_arraybounds proc near; CODE XREF: j__d_arrayboundsj .text:000140014210 pushrbp .text:000140014211 mov rbp, rsp .text:000140014214 pop rbp .text:000140014215 retn I don't know why dmd ommits _d_arraybounds body. So if app built with that druntime tries to access out of bounds element it just crashes instead of throwing oob error. If i remove -release from command line when building druntime all seems to be OK. But i had seen that in win64.mak there's a release switch. Where can be a problem? Thanks for a help.
Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)
On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat wrote: On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson wrote: If you have any experience with either OpenCL or CUDA we'd love to have your input. Have experience with both, more CUDA than OpenCL though. Feel free to contact me. Great! I'll let you know when the compiler stuff is merged, probably in mir's public gitter.
Re: State of issues.dlang.org
On Tuesday, 25 October 2016 at 12:48:48 UTC, Vladimir Panteleev wrote: I don't think its state is much worse than that of a typical bugtracker for projects of this scale. What projects are those? For ones of similar size at the very least all issues get tagged. There are a bunch of issues that have nothing done with them. Anyways for the site itself, it seems to be lacking features. It is a standard Bugzilla instance. We do not develop the software. That doesn't make the point any less valid. If something is broke you fix it or replace it. When viewing issues as a list there isn't that much information about the issue, other than the summary. You can create custom views for whatever task you have at hand. Didn't know that, the setting was buried at the bottom of the page past the hundreds of errors. The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues. If something is unclear, please refer to the Bugzilla manual. Not unclear so much as the feature is there and is never used. If it is a bit bigger of an enhancement and needs a DIP to add the functionality. Feature requests that require a DIP do not belong on Buzilla. Who is to determine that? I see a lot of Buzilla reports that are large enhancements that should need a DIP. But they stay as open issues flagged enchancement. That's the point. There's no, or at least no one does say, this needs a DIP, closes the issue to remove it from sight. TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place. Err, no. Just because you haven't seen a Bugzilla instance elsewhere doesn't mean we should replace it. The UI is a bit 90's, but otherwise it has served us well. Umm, who said I haven't seen it elsewhere? If a system is un-maintainable that doesn't mean it's ok and should just be overlooked.
Re: DLang Youtube channel
On Friday, 28 October 2016 at 16:22:18 UTC, Patric Dexheimer wrote: There isn't a official D youtube channel right? Would be be nice to have all the D related videos spread on youtube centralized in one place :) Who handles YouTube for the community?
Re: State of issues.dlang.org
On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote: On 10/25/2016 05:17 AM, Jacob wrote: I think you're mistaken in thinking that no one looks at issues. I usually at least glance over newly filed ones, and often check if they're valid. Let me rephrase that then, no one does anything about the issues. I look at a lot of issues to, some that can easily be answered and the issue closed. But that's the problem, everyone is just an observer and no one does anything.
Re: State of issues.dlang.org
On 10/29/2016 07:14 PM, Jacob wrote: On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote: On 10/25/2016 05:17 AM, Jacob wrote: I think you're mistaken in thinking that no one looks at issues. I usually at least glance over newly filed ones, and often check if they're valid. Let me rephrase that then, no one does anything about the issues. I look at a lot of issues to, some that can easily be answered and the issue closed. But that's the problem, everyone is just an observer and no one does anything. Of course, I also close them if they're invalid, add tags, minimize test cases. And sometimes I can even just fix the issue. You're very welcome to do the same. If you see issues that can be answered and closed, please do so. This is a problem of manpower. That said, if you want to help out, fixing compiler bugs would probably be more effective than doing janitor's work on Bugzilla issues. It's also a lot harder, as far as I can tell.
Re: State of issues.dlang.org
On Saturday, 29 October 2016 at 17:14:20 UTC, Jacob wrote: Let me rephrase that then, no one does anything about the issues. you are plainly wrong. this is as right as your "noone does anything". it is especially fun considering that "ag0aep6g" often provides clarifications and further sample minimization for alot of bugs (it is alot for one man). and other people watching bugs too via rss or email subscriptions. DFeed also reports new bugs to IRC, so some IRC people are watching too. but if what you really complaining about is "bugfix rate"... this is completely different thing, and it has nothing to do with bug tracking software. p.s. and "resolution" feature *is* used. Vladimir is right about reading manuals.
Re: Linus' idea of "good taste" code
On Thursday, 27 October 2016 at 16:14:03 UTC, Dicebot wrote: On 10/27/2016 07:12 PM, Laeeth Isharc wrote: On Thursday, 27 October 2016 at 16:01:26 UTC, Chris wrote: On Thursday, 27 October 2016 at 15:54:59 UTC, Jonathan M Davis wrote: On Thursday, October 27, 2016 15:42:53 Chris via Digitalmars-d wrote: Not easy to be smart with Javascript ;) Sure, it is. Avoid it. ;) - Jonathan M Davis I wish I could! I wish we had DScript for browsers! I am hoping that when asm.js is more mature, then we can use the llvm back end to write at least part of front end in D. Would need runtime ported of course. I consider native compiler from D to WebAssembly to be one of possible unique breakthrough points for D in coming years. I asked Kai at dconf about what would be involved in porting to wasm, but I think he misheard me, as his answer was just generically about what was involved in porting to a new platform. Any thoughts on how much work is involved to port the runtime? And what other changes might be involved? The chap that used the C backend for LLVM wrote a little mini runtime but I guess didn't have to worry about the version blocks in the compiler front end as much. (don't recall what architecture he pretended to be compiling to). Glibc has obviously already been ported to run in browser by emscripten.
Re: What is the right level of abstractions for D?
I am going to talk as a person who mostly works with group 3 languages but will use whatever they need to use to get the job done (tm). > The reason for the split is that there are different levels of software > expertise and performance needs, and each of those groups is geared for a > different level. Show templates to a scripting user and they probably run > away screaming. The bit that sends group 3 people off screaming is static typing, once you have accepted the need to explicitly type everything then Template functions are pretty straight forward in D. > D can probably do well with groups 1 and 2, but the level > of power and expertise that is needed for those lower levels will scare away > people from 3. Those already using it for 1 and 2 may also be comfortable > with reusing D for scripting, but that's not attracting people from group 3, > ie those who only want something easy to use and don't want to know the > difference between a static and dynamic array. Again this boils down to static typing, once your group 3 programmer has accepted this then is is a minor issue. At worst case I could see a grumble then avoiding static arrays. > >> I've noticed that, for many of the people who don't "get" D, the problem >> they're hitting is that they're minds are so twisted around by the >> "polyglot" culture, that they're looking for "the one" tiny little niche >> that D is for, not seeing that, and thus missing the whole entire point. > > > Yes, this has definitely hurt D, being stuck between 1 and 2. People from 2 > probably look at D and think it's too low-level. People from 1 are always > looking to squeeze out _more_ performance, so the GC is a way for them to > just write off D. You and I think they're making a mistake, but maybe > they're not wrong for their own uses. > > As I said, the recent push for @nogc and C++ compatibility suggests that a > renewed effort is being made to focus on group 1, particularly when combined > with the D benchmarks for regex and recently math. I'm happy in that space > between 1 and 2, and the recent push to move languages from 2 to AoT > compilation suggests that is a good place to be. So maybe group 2 will also > come to us. :) Apart from in application scripting, I have replaced python with D at work. (I was largely using python because my brain and shell scripting are largely incompatible). The reasons for this was mostly because with D I can compile and distribute the binary without having to worry if the right version of python was installed on the target machine. For this whip up a tool to automate some file processing quickly I found D as pleasant as anything else I have used. The only thing missing are bindings for a high quality crossplatform gui toolkit. Where I see the future potential of D in regards to the levels 1,2 and 3 is having a team where different programmers are working at different levels within the same language on the same project. Take a game engine, typically you have low level engine guys (level 1) some guys on the engine team who aren't quite as good but don't have to be (effectively level 2) and the guys who do the level / ai scripting (level 3). I would quite happily use D as a high level language in a team where I had a good lower level team designing most of the stuff I use with my level of expertise in mind as they designed it. To this end the really critical things for me are that my level 1 guys can create code that performs in low latency environments without missing deadlines and can present their APIs in such a way that is easy/enjoyable for us level 3 guys to use (see the batch processing thread a little while back).
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Friday, 28 October 2016 at 21:05:33 UTC, bitwise wrote: On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Any news on this? Hmm. Why did I expect this? -_-
Re: Linus' idea of "good taste" code
On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote: Any thoughts on how much work is involved to port the runtime? And what other changes might be involved? The chap that used the C backend for LLVM wrote a little mini runtime but I guess didn't have to worry about the version blocks in the compiler front end as much. (don't recall what architecture he pretended to be compiling to). Glibc has obviously already been ported to run in browser by emscripten. I have actually meant something quite different - implementing new backend for DMD which emits wasm directly (possibly by embedding binaryen). That is more work than simply using LLVM stack as-is but would result in unique marketing advantage - existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is rather annoying. And native wasm backend for LLVM is in development for quite a while now with no clear ETA. At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :)
Re: Linus' idea of "good taste" code
On 10/29/2016 10:30 PM, Dicebot wrote: At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :) I looked at it for 5 minutes :-) and it looks like typical intermediate code that a compiler might generate. It wouldn't be hard to translate the intermediate code generated for the dmd back end to wasm. What I didn't see was any mention symbolic debug information, linking, or how to connect to system services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, moving target. Looks like a fun project, but I don't see how I could split off time to work on it.
Re: Linus' idea of "good taste" code
On Sunday, 30 October 2016 at 05:53:09 UTC, Walter Bright wrote: On 10/29/2016 10:30 PM, Dicebot wrote: At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :) I looked at it for 5 minutes :-) and it looks like typical intermediate code that a compiler might generate. It wouldn't be hard to translate the intermediate code generated for the dmd back end to wasm. What I didn't see was any mention symbolic debug information, linking, or how to connect to system services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, moving target. Looks like a fun project, but I don't see how I could split off time to work on it. It is not worth it, the web is dying. I was stunned to see this chart of mobile web usage in the US: https://mobile.twitter.com/asymco/status/777915894659964928 This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform.