Re: Analysis of D GC
On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html --- Dmitry Olshansky This was posted on reddit: https://www.reddit.com/r/programming/comments/6ic52d/inside_ds_gc/
Re: Go 1.9
On Mon, 2017-06-19 at 19:07 +, Ecstatic Coder via Digitalmars-d wrote: > […] > > But Go still doesn't have proper generics, which keeps it > light-years behind D in terms of expressivity. Go doesn't have, and likely will never have, generics in the C++, D, Chapel sense, but then Rust doesn't either. Go has two routes for achieving the goal that C++ generics (and hence D and Chapel generics) were intended for. You have to use the idiomatic approach for the language. Saying Go is behind D is missing the point that the languages are different and have to be used differently to achieve the same goal. > Still time to convince people to use D instead of Go then... The only way of doing this is to have lots of problems programmed idiomatically in D, Go, Rust, Kotlin, with unbiased compare and contrast notes. You end up finding different languages are best in different problems. Which is hardly a surprise. Generally it is the libraries that are the truly key factors. And do not underestimate personal choice, different language gel with different people (though there is some Stockholm Syndrome effect with some people). For me just now, D beats C++ for working with Gtk and GStreamer. For other problems I go with Go, or partake of Python. C++17, or more likely C++20, may make C++ interesting again. I though C++11 had, but in the end it didn't. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 02:23:48 UTC, safety0ff wrote: On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html --- Dmitry Olshansky Good overview, however: the binary search pool lookup is used because it naturally supports variable sized pools. IMHO, simply concluding "A hash table could have saved quite a few cycles." glosses over the issue of handling variable sizes. Pools are granular to 256kb irc, so the trick is to keep them 256kb aligned in memory. Then a map from 256kb chunks to pools is easily created. --- Dmitry Olshansky
Re: Analysis of D GC
On Monday, 19 June 2017 at 22:50:05 UTC, Adam D. Ruppe wrote: What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing? This is mostly because I wanted to abuse lazy commit of POSIX. Now that I think of it Windows is mostly ok, except for the fork trick used in concurrent GC. As Vladimir pointed out on Windows there are other ways to do it but they are more involved. --- Dmitry Olshansky
Re: Embedded Systems (STM32) LDC Absolute minimal runtime
On Monday, 19 June 2017 at 10:24:29 UTC, Dan Walmsley wrote: I have played around with the betterC flag and it looks promising. I would also like to have use of classes, however as soon as I try to use a class I get many link errors. see below: It is my understanding that the DMD -betterC switch currently only disables generating ModuleInfo. Walter's recent pull request (http://forum.dlang.org/post/oi9v2q$23ms$1...@digitalmars.com) makes it do a little more. It is also my understanding the -betterC is just an idea at the moment, and what it should do has not yet been defined. The undefined reference to `_d_dso_registry' comes from removing the -betterC flag. I understand these other symbols would be provided by object.d, however I am unable to find an object.d that will compile on LDC, and ideally a minimal implementation. The most minimal implementation I'm aware of is this: https://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22 If you're targeting STM32, you may also be interested in this: https://github.com/JinShil/stm32f42_discovery_demo I haven't tested either of those in quite some time, so I doubt the will compile out of the box. But basically, what you need is a minimal runtime implementation that implements the features of D that your code is using, and unfortunately, some that your code isn't using but is required by the compiler just to get a build. C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main9TestClass3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:9: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `ldc.register_dso': C:\dev\repos\STM32DBlinky\Blinky\main.d:(.text.ldc.register_dso+0x60): undefined reference to `_d_dso_registry' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x4): undefined reference to `_D6object6Object8toStringMFZAya' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x8): undefined reference to `_D6object6Object6toHashMFNbNeZk' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0xc): undefined reference to `_D6object6Object5opCmpMFC6ObjectZi' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data.rel.ro._D4main9TestClass6__vtblZ[_D4main9TestClass6__vtblZ]+0x10): undefined reference to `_D6object6Object8opEqualsMFC6ObjectZb' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestClass7__ClassZ]+0x0): undefined reference to `_D14TypeInfo_Class6__vtblZ' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o:(.data._D4main9TestClass7__ClassZ[_D4main9TestClass7__ClassZ]+0x28): undefined reference to `_D6Object7__ClassZ' `_d_assert_msg` and `_d_dso_registry` and those symbols with `_d_invariant` in them look like missing druntime implementations. You can see an old and unmaintained list of such "runtime hooks" here: https://wiki.dlang.org/Runtime_Hooks. Each compiler (DMD, LDC, and GDC) have their own druntime implementation, unfortunately. LDC's implementation is here: https://github.com/ldc-developers/druntime I suspect the `.data.re.ro.*` symbols are the result of an error in your linker script. That is you haven't added that `.data` section to your linker script, so the symbols aren't being populated. I'd have to see your linker script and source code before I spend to much mental energy on it, though. No compiler that I'm aware has a druntime implementation for the ARM Cortex-M architecture, so the onus is on you to build implement whatever features the toolchain is complaining about. Mike
Re: Replacing Make for the DMD build
On Mon, 2017-06-19 at 14:52 +, Vladimir Panteleev via Digitalmars-d wrote: > […] > We will likely need to continue providing shim makefiles which > invoke the replacement build system for the foreseeable future. > The big problem here is that all make targets are essentially > part of their public interface, so if we are to avoid breaking > anyone's scripts or workflow, they must be kept working. > Otherwise, I don't disagree. The usual approach is to leave the old system in place, put the new system in place, and run in parallel. Then people can remove their dependency on the old system over time. Then you deprecate the old system, and then remove it. The new system does not have to replicate any part of the old system, it just has to produce the end products. […] > The current build system has a number of problems caused by the > components being in separate repositories. For example, if you > change a file in Phobos and want to rebuild the documentation > (dlang.org), the latter won't know that only a single file > changed in the former, because the dlang.org makefile is not > aware of the rules governing the building of Phobos files. > Furthermore, both the dlang.org makefile and the Phobos makefile > have a target for building Phobos documentation, but they work in > different ways and produce different results. A replacement build > system that can achieve correct interoperability as described > above would score a lot of points towards being accepted. > > More importantly, if we accept a proposal for three repos and on > the fourth one we run into a blocker (or even the replacement > simply being very unsatisfying), then that would put us in an > unpleasant situation. So, I think that requiring working > replacements for all components makes sense as a prerequisite for > any single component being switched over to the new build system. GStreamer seems like a good model here as they have dealt with this exact same situation (well not exact, they do not have the dlang.org problem in the same way). As part of their trialling Meson to replace Autotools, they created a build repository that pulls in all the other repositories such that the whole structure has a well-defined architecture, all paths are known. Thus you get a nice simplification that enables a global build as well as individual repository builds. Of course they have made the decision to trial on the real repositories, with the option to delete it all and return to using Autotools. This has a major benefit, it is the real repositories being worked on and anyone can chip in at any time. This approach also leads to earlier "buy in" from more people. Though in GStreamer case Meson is the natural step on from Autotools, so there is perhaps less argumentation over options, before heading to a trial. […] > Will you have some time to chat about Reggae on IRC tomorrow? I > should be around about 12 hours from now for about 12 hours since > then. Possibly, what time are you thinking of? I haven't used IRC, well not in over 20 years anyway, so I would need data on connecting. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Analysis of D GC
On Monday, 19 June 2017 at 23:52:16 UTC, Vladimir Panteleev wrote: On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. Looks like I'm not the only one itching to have a go at D's GC :) This will very likely be my DConf 2018 project. However, I have slightly different plans: I see no problem in eventually uniting our efforts. - The GC should be usable as a library (mainly to facilitate testing). - Support for all platforms D already supports from the start. - Use design-by-introspection when applicable and design-by-contract elsewhere to split the design into modular components. Nice. A pool could have many different structures, the collector could then introspect on that. Sadly this almost doubles the effort so I will not go there. - Make the GC configurable (using policies) and swappable at runtime. (No need to get clever, just treat previous implementation's pools as opaque void[]). - Support concurrency on Windows via anonymous memory-mapped files. Yeah I recall Rainer and myself discussing this approach, it had some downside such as you need to remap each pool individually. Still doable. - Support generational collection using write barriers implemented through memory protection. Super slow sadly. That being said I belive D is just fine without generational GC. The generational hypothesis just doesn't hold to the extent it holds in say Java. My hypothesis is that most performance minded applications already allocate temporaries using region allocator of sorts (or using C heap). - Integrate existing GC work - don't reinvent the wheel. - More, much more debugging facilities! Integrate Diamond and Valgrind interoperability. I could use help on thus one. - Gray-marking and compacting. - Still need to look at immix. I have some past work that I'd like to integrate (an experimental generational GC I wrote like 9 years ago for D1, Diamond, and Valgrind integration I have in a fork somewhere.) --- Dmitry Olshansky
Re: Analysis of D GC
On Monday, 19 June 2017 at 23:10:43 UTC, Ali Çehreli wrote: On 06/19/2017 03:35 PM, Dmitry Olshansky wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html --- Dmitry Olshansky Very informative, thanks. However, I can think of many reasons like appreciation the efforts of the original authors to tone it down a little bit like changing "mistake" to "optimization opportunity", "criticism" to "observation", etc. :) I could call it a problem :) Still one reason I didn't go to D blog to post this is because it's a critique followed by a promise of action though. Ali --- Dmitry Olshansky
Re: What is the state of Microcontroller support in d?
On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote: Hi you still around, I'm starting to investigate these issues and see if I can start using D in some of my embedded projects at my company. I've got stuck at the hurdle of trying to use minilibd with Ldc compiler, did you make progress since this post?, IMO microcontroller support in D is only slightly better than non-existent. I tried about 2 or 3 years ago to move the ball forward on it, but just ran into way too many obstacles. The nail in the coffin for me was https://issues.dlang.org/show_bug.cgi?id=14758. To enumerate some of the problems (I don't have the energy for an exhaustive list, so these are just off the top of my head at the moment) 1. Compiler-runtime coupling. The compiler expects too much of the runtime to exist even when what it requires has no hope of ever being executed in the resulting binary. So, it forces us to implement silly hacks and stubs just to get a build. 2. The compiler adds things that aren't even needed in the resulting binary, and does so in a way that prevents --gc-sections and LTO from removing them. For some of my code, the binary was so large it wouldn't even fit on the microcontroller's flash memory. 3. Many of the veterans in the D community support the current dependency the runtime has on C standard library bindings, stating that they are required (which is not true). Furthermore, they want to make the problem worse by adding C++ standard library bindings as well. I submitted pull request to begin moving these bindings to Deimos, and make the dependencies private for individual platforms' ports, but only encountered resistance and misunderstanding. 4. The D gatekeepers have become very averse to anything that would cause too much disruption, making me believe that the fundamental changes that are needed to make microcontroller programming in D a reality will never be accepted. 5. Too many pull requests sit in "purgatory" for way too long without any progress. I believe that trying to move my changes forward would be an uphill battle, and ultimately not worth the frustration. 6. Rust has "minimal runtime" as one of the pillars of its language design philosophy. You can truly pay-as-you go while you build your system. This is how it should be, and unless you're looking for a fight, you'll probably be better off there: http://blog.japaric.io/quickstart/. That's where I'm allocating my resources these days. Mike
Re: dmd -betterC
On 6/19/2017 11:28 PM, Mike wrote: As I understand it, this requires some cooperation between the compiler and the linker. We don't control the linker. We could do a lot if we did, but we don't.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 08:31:30 UTC, Walter Bright wrote: On 6/19/2017 11:28 PM, Mike wrote: As I understand it, this requires some cooperation between the compiler and the linker. We don't control the linker. We could do a lot if we did, but we don't. I know, but you do know what linker features exists and how the linker works, and could generate better intermediate code that could allow the linker to more effectively identify and remove dead code.
Re: dmd -betterC
On 6/20/2017 1:31 AM, Walter Bright wrote: On 6/19/2017 11:28 PM, Mike wrote: As I understand it, this requires some cooperation between the compiler and the linker. We don't control the linker. We could do a lot if we did, but we don't. To clarify, I have experience writing and working with linkers. Doing one is a full time job for a team of one alpha programmer + a couple regular ones. You might think a linker is easy, and conceptually it is. The trouble comes from all the undocumented behaviors it is expected to do exhibit. Worse, these expectations change constantly without warning. And lastly, we support lots of platforms. Multiply the above by the number of platforms. It's not practical for us.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote: Hi you still around, I'm starting to investigate these issues and see if I can start using D in some of my embedded projects at my company. I've got stuck at the hurdle of trying to use minilibd with Ldc compiler, did you make progress since this post?, IMO microcontroller support in D is only slightly better than non-existent. I tried about 2 or 3 years ago to move the ball forward on it, but just ran into way too many obstacles. The nail in the coffin for me was https://issues.dlang.org/show_bug.cgi?id=14758. To enumerate some of the problems (I don't have the energy for an exhaustive list, so these are just off the top of my head at the moment) 1. Compiler-runtime coupling. The compiler expects too much of the runtime to exist even when what it requires has no hope of ever being executed in the resulting binary. So, it forces us to implement silly hacks and stubs just to get a build. 2. The compiler adds things that aren't even needed in the resulting binary, and does so in a way that prevents --gc-sections and LTO from removing them. For some of my code, the binary was so large it wouldn't even fit on the microcontroller's flash memory. 3. Many of the veterans in the D community support the current dependency the runtime has on C standard library bindings, stating that they are required (which is not true). Furthermore, they want to make the problem worse by adding C++ standard library bindings as well. I submitted pull request to begin moving these bindings to Deimos, and make the dependencies private for individual platforms' ports, but only encountered resistance and misunderstanding. 4. The D gatekeepers have become very averse to anything that would cause too much disruption, making me believe that the fundamental changes that are needed to make microcontroller programming in D a reality will never be accepted. 5. Too many pull requests sit in "purgatory" for way too long without any progress. I believe that trying to move my changes forward would be an uphill battle, and ultimately not worth the frustration. 6. Rust has "minimal runtime" as one of the pillars of its language design philosophy. You can truly pay-as-you go while you build your system. This is how it should be, and unless you're looking for a fight, you'll probably be better off there: http://blog.japaric.io/quickstart/. That's where I'm allocating my resources these days. Mike How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? I was so hopeful for D when I saw how nice the syntax is, I saw rust and I didn't get the same feeling, not that I wont give it a chance, I just feel as you know embedded systems is dominated by C and C++ and D seems closer to those than Rust. To be fair I was impressed with the -betterC flag and that actually looks nice I you just want a C replacement but no classes, etc. I have not been able to get even a minimal project to compile when a class is introduced `Error: Missing class declaration: TypeInfo_AssociativeArray` Will take a look at rust, but would be keen to know if you could be motivated by the SystemD / EmbeddedD idea?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote: 6. Rust has "minimal runtime" as one of the pillars of its language design philosophy. You can truly pay-as-you go while you build your system. This is how it should be, and unless you're looking for a fight, you'll probably be better off there: http://blog.japaric.io/quickstart/. That's where I'm allocating my resources these days. @offtopic: How do you see the future comparing D and Rust? Are you enjoying Rust?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 08:48:05 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? [...] Regarding not being able to --gc-sections, perhaps this was fixed in LDC? http://forum.dlang.org/post/cxjubpxxknlkqvdgy...@forum.dlang.org
Re: dmd -betterC
On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that.
Re: Replacing Make for the DMD build
On Tuesday, 20 June 2017 at 07:24:26 UTC, Russel Winder wrote: The usual approach is to leave the old system in place, put the new system in place, and run in parallel. Then people can remove their dependency on the old system over time. Then you deprecate the old system, and then remove it. The new system does not have to replicate any part of the old system, it just has to produce the end products. Yep; same as what was done with ddmd. Possibly, what time are you thinking of? I haven't used IRC, well not in over 20 years anyway, so I would need data on connecting. Sorry Russell, I thought I was replying to Atila :) But you are of course welcome on IRC. The D channel is on Freenode (#d). If you don't want to install an IRC client, there is a web portal at http://webchat.freenode.net/.
Re: dmd -betterC
On 6/20/2017 2:00 AM, ixid wrote: How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that. As long as the compiler supports separate compilation, it has to emit certain information that may or may not be used by other modules. For example, the list of imported modules, which is used by the startup code to determine the order of static construction. The compiler cannot know which of those will have static constructors and which won't.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 08:48:05 UTC, Dan Walmsley wrote: How about creating a fork and calling it "SystemD or EmbeddedD" just 1 compiler (LDC probably), do you think its realistic idea? It would take a very dedicated and talented individual, or a small team of talent to do that. I'm not that individual, and there doesn't seem to be much interest from the D community to pull it off, IMO. I was so hopeful for D when I saw how nice the syntax is, I saw rust and I didn't get the same feeling, not that I wont give it a chance, I just feel as you know embedded systems is dominated by C and C++ and D seems closer to those than Rust. I had the same initial reaction to Rust, and still do to some extent. Rust does not have the modeling power and efficient code reuse that D does. D allows you to write code the way you think about it. Rust requires you to change the way you think about your code. But D requires too many silly hacks and compromises just to get a build that works. Rust allows you to incrementally build up your system (pay-as-you-go) without any nonsense. Despite my criticism, I think D has much more potential than Rust, I just don't think it will ever be realized without a fork. To be fair I was impressed with the -betterC flag and that actually looks nice I you just want a C replacement but no classes, etc. If -betterC were ever fully implemented it would indeed be a "Better C", but it would also be a "Worse D" and I'd be forever disappointed that I couldn't individually pay for the features I wanted. I have not been able to get even a minimal project to compile when a class is introduced `Error: Missing class declaration: TypeInfo_AssociativeArray` Stick with only structs until you get it working, then you can tackle classes. Will take a look at rust, but would be keen to know if you could be motivated by the SystemD / EmbeddedD idea? It would be a huge tangent from what I really want to do and would require a different skill set than what I currently possess. While I'm confident that I could acquire the necessary skills to pull it off, I only have the resources to contribute to such an endeavor on a part-time basis. It's not something I can do right now. I want to program machines that interface with the physical world. I don't really want to have to build my own custom toolchain to do it (But I wouldn't mind contributing to one). Rust is also slowly improving, and if some of their RFCs ever get implemented, it will obtain much more modeling power like D. That's where I'm placing my bets at the moment. Mike
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 08:52:20 UTC, Wulfklaue wrote: @offtopic: How do you see the future comparing D and Rust? Are you enjoying Rust? I'm not enjoying Rust; I just believe it is currently better than D and has a better future. As I stated in my previous posts, Rust does not have the modeling power of D. D allows you to program the way you think, Rust requires you to change the way you think. However, there are a few RFCs and issues that Rust is working through that could change that. I don't see the same kind of progress and discussion happening in D... except today :-) That being said, let me offer a counter-opinion that occurred to me some time ago. Many embedded systems programmers are not software engineers; they are electrical engineers that write code. A "better C" may be exactly what some of these types would like; I'm just not one of them. Mike
Re: Analysis of D GC
On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote: On Mon, Jun 19, 2017 at 10:35:42PM +, Dmitry Olshansky via Digitalmars-d wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html [...] Very interesting indeed! One question about killing the no interior pointer attribute: would this be problematic for 32-bit platforms? And if so, what do you plan to do about it? Keep the current GC as version(32bit) and your new version as version(64bit)? Yeah if said 32-bit application makes use of no interior pointer attribute then using old gc is an option. I have no plans for this broken attribute. One (potentially crazy) idea that occurred to me while reading your post is TLS allocations. I haven't thought through the details of how this would interact with the existing language yet, but would it make sense for some allocations that you know will never be shared across threads to be allocated in a thread-local pool instead of the global pool? I.e., in addition to the global set of memory pools you also have thread-local memory pools. Then you could potentially run collections per-thread rather than stop-the-world. This needs spec updateon interaction between TLS and shared, in particular the current trend of lock + cast away shared is problematic. Also the implicit cast to immutable of a result of unique expression. On Mon, Jun 19, 2017 at 10:50:05PM +, Adam D. Ruppe via Digitalmars-d wrote: What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing? He mentioned the "fork trick", which I assume refers to how Linux's implementation of fork() uses copy-on-write rather than immediately duplicating the parent process' memory structures. There was a D1 GC some time ago that depended on this behaviour to speed up the collection cycle. AFAIK, Windows does not have equivalent functionality to this. To the best of my knowledge all of D's current target OSes support this save for Windows. T
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote: Regarding not being able to --gc-sections, perhaps this was fixed in LDC? http://forum.dlang.org/post/cxjubpxxknlkqvdgy...@forum.dlang.org My last test with LDC is here: https://issues.dlang.org/show_bug.cgi?id=14758#c14 Try to get that code to compile with LDC and let me know what `objdump -s -j .rodata test` gives you. Mike
Re: Analysis of D GC
On 6/20/2017 12:04 AM, Nicholas Wilson wrote: On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote: http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html This was posted on reddit: https://www.reddit.com/r/programming/comments/6ic52d/inside_ds_gc/ Also on hacker news.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 09:36:54 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 08:54:01 UTC, Dan Walmsley wrote:
Regarding not being able to --gc-sections, perhaps this was
fixed in LDC?
http://forum.dlang.org/post/cxjubpxxknlkqvdgy...@forum.dlang.org
My last test with LDC is here:
https://issues.dlang.org/show_bug.cgi?id=14758#c14
Try to get that code to compile with LDC and let me know what
`objdump -s -j .rodata test` gives you.
Mike
No longer compiles:
"Error: Missing class declaration: ModuleInfo
Please check that object.di is included and valid"
So I add
`
struct ModuleInfo
{
}
`
but then ldc crashes...
added an issue here:
https://github.com/ldc-developers/ldc/issues/2174
Re: dmd -betterC
On Tuesday, 20 June 2017 at 09:21:05 UTC, Walter Bright wrote: On 6/20/2017 2:00 AM, ixid wrote: How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that. As long as the compiler supports separate compilation, it has to emit certain information that may or may not be used by other modules. For example, the list of imported modules, which is used by the startup code to determine the order of static construction. The compiler cannot know which of those will have static constructors and which won't. How much of that could be made lazy?
Re: What is the state of Microcontroller support in d?
20.06.2017 12:33, Mike пишет: That being said, let me offer a counter-opinion that occurred to me some time ago. Many embedded systems programmers are not software engineers; they are electrical engineers that write code. I'm sure this is very important thing - many who writes code are not software engineers at all. I can't imagine my colleagues switch to Rust, it' impossible because Rust is too hardcore. But I can imagine they switch to D easily. And this is power of D. I've read your posts early and I think you're right, at least at general. I guess dlang should make these changes that allow using D at embedded systems.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 09:46:13 UTC, Dan Walmsley wrote: No longer compiles: "Error: Missing class declaration: ModuleInfo but then ldc crashes... I had to use code from my minimal runtime experiment here and merge it with some of the code in the TypeInfo bloat issue. Here's code that compiles. object.d https://dpaste.dzfl.pl/f7496296301a test.d https://dpaste.dzfl.pl/6a97b6f7fccf How to compile --- `ldc2 --version` LDC - the LLVM D compiler (1.2.0): based on DMD v2.072.2 and LLVM 4.0.0 built with DMD64 D Compiler v2.074.0 Default target: x86_64-unknown-linux-gnu `ldc2 -m64 -defaultlib= -debuglib= -conf= -betterC -release object.d test.d -oftest` `objdump -s -j .rodata test` test: file format elf64-x86-64 Contents of section .rodata: 4005fd 74657374 2e546573 74436c61 73733100 test.TestClass1. 40060d 74657374 2e546573 74436c61 73733200 test.TestClass2. 40061d 74657374 2e546573 74436c61 73733300 test.TestClass3. 40062d 74657374 2e546573 74436c61 73733400 test.TestClass4. 40063d 74657374 2e546573 74436c61 73733500 test.TestClass5. 40064d 74657374 2e546573 74436c61 73733600 test.TestClass6. 40065d 74657374 2e546573 74436c61 73733700 test.TestClass7. 40066d 74657374 2e546573 74436c61 73733800 test.TestClass8. 40067d 74657374 2e546573 74436c61 73733900 test.TestClass9. 40068d 48656c6c 6f0a006f 626a6563 742e4f62 Hello..object.Ob 40069d 6a656374 006f626a 6563742e 54797065 ject.object.Type 4006ad 496e666f 00547970 65496e66 6f5f5374 Info.TypeInfo_St 4006bd 72756374 00547970 65496e66 6f5f436c ruct.TypeInfo_Cl 4006cd 61737300 54797065 496e666f 5f456e75 ass.TypeInfo_Enu 4006dd 6d005479 7065496e 666f5f43 6f6e7374 m.TypeInfo_Const 4006ed 006f626a 6563742e 4572726f 7200 .object.Error. RESULT -- * The TypeInfo bloat problem still exists. * The problem is even worse as you now have to add even more silly hacks and stubs to get a build. This problem has been known for more than 3 years, and it's only getting worse. Move on. There are better alternatives. Mike
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote: I had to use code from my minimal runtime experiment here Sorry, I forgot to add the link for my minimal runtime experiment: https://github.com/JinShil/minimal_druntime_experiment Mike
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: 3. Many of the veterans in the D community support the current dependency the runtime has on C standard library bindings, stating that they are required (which is not true). Furthermore, they want to make the problem worse by adding C++ standard library bindings as well. The C++ bindings should be opt-in.. I submitted pull request to begin moving these bindings to Deimos, and make the dependencies private for individual platforms' ports, but only encountered resistance and misunderstanding. 4. The D gatekeepers have become very averse to anything that would cause too much disruption, making me believe that the fundamental changes that are needed to make microcontroller programming in D a reality will never be accepted. Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause! 5. Too many pull requests sit in "purgatory" for way too long without any progress. I believe that trying to move my changes forward would be an uphill battle, and ultimately not worth the frustration. That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time!
Dub version
Homebrew on OSX El Capitan installs Dub 1.3.0, but the Dub page says the latest version is 1.2.1. Are we in a time vortex? -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: Analysis of D GC
On 2017-06-20 06:37, ketmar wrote: it is higly depends of undocumented windows internals, and not portable between windows versions. more-or-less working implementations of `fork()` were existed at least since NT3 era, but nobody considered 'em as more than a PoC, and even next service pack can break everything. I'm wondering what Windows 10 is using to implement "fork" for Windows Subsystem for Linux. If it's using these internal functions or something else. -- /Jacob Carlborg
Re: Analysis of D GC
On 2017-06-20 01:52, Vladimir Panteleev wrote: - More, much more debugging facilities! Integrate Diamond and Valgrind interoperability. Don't for get the Clang sanitizers, assuming they work using LDC. -- /Jacob Carlborg
Re: Analysis of D GC
On 20/06/2017 12:41 PM, Jacob Carlborg wrote: On 2017-06-20 06:37, ketmar wrote: it is higly depends of undocumented windows internals, and not portable between windows versions. more-or-less working implementations of `fork()` were existed at least since NT3 era, but nobody considered 'em as more than a PoC, and even next service pack can break everything. I'm wondering what Windows 10 is using to implement "fork" for Windows Subsystem for Linux. If it's using these internal functions or something else. It wouldn't surprise me to learn that it was a posix layer specific syscall, meaning we can't from a native Windows process.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime
experiment:
https://github.com/JinShil/minimal_druntime_experiment
Mike
Mike,
I think good news:
I built a slightly different example, because I don't have access
to the linker you have, I just had the arm-none-eabi one and I
used ldc 1.3.0-beta2.
I compiled using these flags:
-march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g
-defaultlib= -conf= -oftest -better
and I got 0 rodata no rtti (I did do -gc-sections) if I don't
gc-sections it complains about loads of missing runtime stuff.
I tried then to instantiate a class, but it just crashes in
hardfault:
final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }
extern (C) void _d_callfinalizer (void *p)
{
}
class Point
{
this (int x, int y)
{
X = x;
Y = y;
}
int X;
int Y;
}
void Main()
{
scope p = new Point(2,2);
p.X = 1;
p.Y = 1;
int x = 0;
x++;
}
Perhaps D needs to be aware of my stack? I will take a look at
your linker script. But at least there is 0 type info data after
-gc-sections has run.
Re: Analysis of D GC
On 2017-06-20 06:54, ketmar wrote: "...the dubious optimization of no interior pointers..." this is the ONLY (i emphasise it!) way i were able to make my e-mail and irc clients to not leak memory, and keep using GC. on 32-bit systems false pointers *is* a problem, and NO_INTERIOR really helps. turning NO_INTERIOR into something dog-slow (or noop) will make D unusable on 32-bit systems for anything more complex than helloworld and throwaway scripts. particularly, any app that should work for weeks or monthes without restart (yep, i want my mail client to Just Work, and i'm not rebooting my PC that often) will be *forced* to ditch GC. while NO_INTERIOR requires some coding discipline, it is invaluable in IRL apps. You need to move to 64bit. Apple is already deprecating support for 32bit apps and after the next version of macOS (High Sierra) they're going to remove the support for 32bit apps. -- /Jacob Carlborg
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote:
On Tuesday, 20 June 2017 at 10:41:10 UTC, Mike wrote:
On Tuesday, 20 June 2017 at 10:39:47 UTC, Mike wrote:
I had to use code from my minimal runtime experiment here
Sorry, I forgot to add the link for my minimal runtime
experiment:
https://github.com/JinShil/minimal_druntime_experiment
Mike
Mike,
I think good news:
I built a slightly different example, because I don't have
access to the linker you have, I just had the arm-none-eabi one
and I used ldc 1.3.0-beta2.
I compiled using these flags:
-march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g
-defaultlib= -conf= -oftest -better
and I got 0 rodata no rtti (I did do -gc-sections) if I don't
gc-sections it complains about loads of missing runtime stuff.
I tried then to instantiate a class, but it just crashes in
hardfault:
final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }
extern (C) void _d_callfinalizer (void *p)
{
}
class Point
{
this (int x, int y)
{
X = x;
Y = y;
}
int X;
int Y;
}
void Main()
{
scope p = new Point(2,2);
p.X = 1;
p.Y = 1;
int x = 0;
x++;
}
Perhaps D needs to be aware of my stack? I will take a look at
your linker script. But at least there is 0 type info data
after -gc-sections has run.
Actually about the stack was a red herring the code did actually
work!
my only issue is now when I add a method I get:
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function
`_D4main5Point3SumMFZi':
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference
to `_D9invariant12_d_invariantFC6ObjectZv'
C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference
to `_d_assert_msg'
C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function
`_D4main4MainFZv':
C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference
to `_d_eh_resume_unwind'
Whats the invariant object thing?
Re: dmd -betterC
On 2017-06-20 03:51, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. BTW, how are asserts handled? Isn't assert usually a macro in C? -- /Jacob Carlborg
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. I'm going to shove it in a GitHub repo give me 10 mins.
DIP 1009--Improve Contract Usability--Preliminary Review Round 1
DIP 1009 is titled "Improve Contract Usability". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on July 3 (3:59 AM GMT July 4), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors. Thanks in advance to all who participate. Destroy!
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. https://github.com/vitalElement/STM32DBlinky
Re: dmd -betterC
On 2017-06-20 03:51, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" druntime function. Not sure if anyone cares about macOS 32bit. Does the TLS implementation depend on druntime on any other platforms? -- /Jacob Carlborg
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote: https://github.com/vitalElement/STM32DBlinky I don't see the linker script
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 11:53:07 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:50:56 UTC, Dan Walmsley wrote: C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main5Point3SumMFZi': C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_D9invariant12_d_invariantFC6ObjectZv' C:\dev\repos\STM32DBlinky\Blinky/main.d:26: undefined reference to `_d_assert_msg' C:\dev\repos\STM32DBlinky\Blinky\build\obj\main.o: In function `_D4main4MainFZv': C:\dev\repos\STM32DBlinky\Blinky/main.d:44: undefined reference to `_d_eh_resume_unwind' Whats the invariant object thing? Please publish your source code and your linker script. https://github.com/vitalElement/STM32DBlinky commands to build were: Compile: ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release main.d -ofmain.o ldc2 -c -O0 -march=thumb -mcpu=cortex-m4 -mtriple=thumb-none-linux-eabi -g -debuglib= -conf= -oftest -betterC -release stm32f4xx_startup.d -ofstm32f4xx_startup.o Link: arm-none-eabi-gcc -mcpu=cortex-m4 -Wl,-Map,output.map -nostdlib -mfpu=fpv4-sp-d16 -mfloat-abi=hard -nostartfiles -Wl,--gc-sections -O0 -Wl,-T"link.ld" -oBlinky.elf attribute.o object.o main.o stm32f4xx_startup.o -Wl,--start-group -Wl,--end-group If you need windows binaries for arm-none-eabi I can give you some.
Re: CTFE Status 2
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %] has
just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:00:28 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:58:21 UTC, Dan Walmsley wrote: https://github.com/vitalElement/STM32DBlinky I don't see the linker script sorry, committed linker script now :)
Re: D needs to get its shit together!
On Mon, 2017-06-19 at 14:43 +, jmh530 via Digitalmars-d wrote: > […] > dub is more like conda, Anaconda's package manager. Good point. Also I should separate dub the executable from Dub the repository of stuff more carefully. > What I mean is one thing that someone can download and install > one file and everything just works. For instance, one download > and a (Windows) user has DMD/LDC/DUB, DlangScience/Mir/Lubeck, > and some of the database and plotting libraries installed. > Basically, reduce the amount of time for a Python/R/Matlab user > to get up and running on D. Would help get new users. Continuum Analytics do a great job with Anaconda/Miniconda but they have an income stream against which they can post the costs of the people and equipment to keep it working and up to date. Dub, both executable and repository, seem to have a little volunteer labour, and hence maintenance is not reliable, in the sense of there is no guarantee effort can be put into it. But yes, I'd say putting effort into something like Anaconda/Miniconda for D and it's packages would be a good idea. I am guessing extending dub so that when it downloads and builds executables, it can also install them in a platform specific way. For the package managed platforms by building a local package and installing it? I am guessing the next step would be packaging dmd, rdmd, ldc2, and gdc? -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: dmd -betterC
On Tuesday, 20 June 2017 at 11:58:47 UTC, Jacob Carlborg wrote: On 2017-06-20 03:51, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" druntime function. Not sure if anyone cares about macOS 32bit. About macOS 32-bit. Am I the only user? Things are OK now. The older LDCs will work targeting newer macOS 32-bit for a while I guess, so maybe 32-bit can be phased out (especially TLS which I don't use). Not sure who else uses it.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote: I think good news: The bloat is still there, but for some reason it's in the .text section. `objdump -s -j .text test` ... 80004a8 9efe80bd 80b5fff7 9afe80bd 80b5fff7 80004b8 96fe80bd 80b5fff7 92fe80bd 80b5fff7 80004c8 8efe80bd 80b5fff7 71feffe7 00200028 q .( 80004d8 02d1ffe7 ffe7f9e7 80bd6d61 696e2e54 ..main.T 80004e8 65737443 6c617373 31006d61 696e2e54 estClass1.main.T 80004f8 65737443 6c617373 32006d61 696e2e54 estClass2.main.T 8000508 65737443 6c617373 33006d61 696e2e54 estClass3.main.T 8000518 65737443 6c617373 34006d61 696e2e54 estClass4.main.T 8000528 65737443 6c617373 35006d61 696e2e54 estClass5.main.T 8000538 65737443 6c617373 36006d61 696e2e54 estClass6.main.T 8000548 65737443 6c617373 37006d61 696e2e54 estClass7.main.T 8000558 65737443 6c617373 38006d61 696e2e54 estClass8.main.T 8000568 65737443 6c617373 39006865 6c6c6f0d estClass9.hello. 8000578 0a00
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:22:42 UTC, Mike wrote: On Tuesday, 20 June 2017 at 11:47:49 UTC, Dan Walmsley wrote: [...] The bloat is still there, but for some reason it's in the .text section. [...] damn! If we push to have this fixed after that we are pretty close to having something usable are we not?
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] The C++ bindings should be opt-in.. [...] Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause! [...] That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time! I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:35:38 UTC, Dan Walmsley wrote: On Tuesday, 20 June 2017 at 11:11:20 UTC, Seb wrote: On Tuesday, 20 June 2017 at 07:51:47 UTC, Mike wrote: [...] The C++ bindings should be opt-in.. [...] Hmm, I would definitely recommend to submit a DIP about the proposed changes. "Unfortunately" D is so big now that changes need to be carefully evaluated. Providing such an analysis in a DIP, will vastly help your cause! [...] That's a problem about missing reviewers. However, usually reviewing other work will help a lot to speed up your PRs and also you shouldn't be afraid to ping your PRs from time to time! I am going to try and get a minimal example working so I can fully evaluated what is needed, and then I will try and submit a DIP. Ignoring the bloat issue before, any ideas why I might be getting hard fault when trying to create object on the stack?
Digital Mars resource compiler: boost licensed?
Is the rcc from bup.zip now boost licensed too? If so, I think we should include it in the 32 bit windows setup.
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %]
has just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);
These will pass with newCTFE:
static assert(fmadd(0x1.acp+2, 0x1.16p+3, 0x1.4cp+0)
== 0x1.168f5cp+4);
static assert(fmadd(0x1.acp+2, 0x1.16p+3, -0x1.4cp+0)
== -0x1.47a8p-7);
Proving that newCTFE's floating-point-math works the same as
runtime-floating-point math.
Which is not surprising since the interpreter uses same code as
the runtime version.
At-least if you bootstrap dmd with itself.
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 04:35:27 UTC, ketmar wrote: H. S. Teoh wrote: He mentioned the "fork trick", which I assume refers to how Linux's implementation of fork() uses copy-on-write rather than immediately duplicating the parent process' memory structures. There was a D1 GC some time ago that depended on this behaviour to speed up the collection cycle. and it was even ported to D2, and worked. sadly, using `fork()` has it's own set of problems -- `fork()` itself is in no way a flawless expirience. like you can fork while other thread is inside glibc's `malloc()`, and BOOM! alot of glibc is locked forever, as `malloc()` lock is never released in child process. some other libraries may try to intercept `fork()` to do unnecessary "cleanup", and so on. Since we are in control of what child does I see this as no issue. Just call mmap and do bump a pointer allocation.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote: If we push to have this fixed after that we are pretty close to having something usable are we not? Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there. If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it. But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way. Mike
Re: Dub version
On Tuesday, 20 June 2017 at 11:33:30 UTC, Russel Winder wrote: Homebrew on OSX El Capitan installs Dub 1.3.0, but the Dub page says the latest version is 1.2.1. Are we in a time vortex? The latest DUB release is indeed 1.3.0 - see https://github.com/dlang/dub/releases. It looks the downloads page hasn't been updated. Looking at the source code [0] reveals that code.dlang.org should automatically pickup the latest version, though from my brief look I can't tell why it hasn't done so. [0]: https://github.com/dlang/dub-registry/blob/master/views/download.dt#L17
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 11:49:49 UTC, Jacob Carlborg wrote: On 2017-06-20 06:54, ketmar wrote: [...] You need to move to 64bit. Apple is already deprecating support for 32bit apps and after the next version of macOS (High Sierra) they're going to remove the support for 32bit apps. I highly doubt that ketmar would have any intention of touching macOS regardless ;) Besides, there are many domains where the x32 ABI is a more worthwhile upgrade from i688 than x86_64.
Re: What is the state of Microcontroller support in d?
On Tuesday, 20 June 2017 at 13:45:31 UTC, Mike wrote: On Tuesday, 20 June 2017 at 12:32:46 UTC, Dan Walmsley wrote: If we push to have this fixed after that we are pretty close to having something usable are we not? Depends on your definition of "usable". Fixing the bloat issue would remove a current road block, and at least allow progress to continue. IMO, to make D a pleasant experience on the ARM Cortex-M platform, we'll need to implement the entire druntime including threading, GC, exceptions, dynamic arrays, etc... even if those features are not used. This is because D just hasn't been designed and implemented in a modular fashion to allow one to pay-as-they-go, and as you experienced in one of your other posts today, you just get too many undefined references and other odd errors that have nothing to do with your code. The only way to make those errors go away is to ensure everything in druntime is there. If the bloat problem were solved, we could at least continue working towards that end. But it's not immediately apparent to me how much overhead a complete runtime implementation will add to as simple microcontroller application, and how well the compiler and linker can optimize and remove that overhead. We may encounter other roadblocks like I did with the TypeInfo bloat, and have to fight a major battle to get something done about it. But I don't want to have to implement the entire druntime in order to start making progress. It shouldn't have to be that way. Mike I completely agree with you here, its a real shame! Id be happy to put some effort into this, I don't know if you can help me put pressure on the right people to get the bloat thing fixed. It seems like its probably fixed in dmd compiler, but none of the others. I think ldc2 is the compiler that has the most potential because it can easily be compiled unlike the gdc one and then dmd one doesn't seem to support arm out the box unless things changed recently. I'm happy to have a GC on a system like stm32, as I read it only collects on calls to new, and most sensible embedded designs would just allocate at initialization and not during runtime. Threading I think we could easily use freertos or something underneath. Which just leaves dynamic arrays and exceptions which I know next to nothing about right now :) Firstly who do we need to talk to about the bloat in LDC?
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 11:44:41 UTC, rikki cattermole wrote: On 20/06/2017 12:41 PM, Jacob Carlborg wrote: On 2017-06-20 06:37, ketmar wrote: it is higly depends of undocumented windows internals, and not portable between windows versions. more-or-less working implementations of `fork()` were existed at least since NT3 era, but nobody considered 'em as more than a PoC, and even next service pack can break everything. I'm wondering what Windows 10 is using to implement "fork" for Windows Subsystem for Linux. If it's using these internal functions or something else. It wouldn't surprise me to learn that it was a posix layer specific syscall, meaning we can't from a native Windows process. The Windows Subsystem for Linux is build on a new form processes called picoprocesses. There's a whole API build specifically to service WSL, that's not otherwise available (AFAIR) for security reasons to normal processes. I highly recommend watching this talk: https://www.youtube.com/watch?v=36Ykla27FIo and browsing through this repo: https://github.com/ionescu007/lxss which reveals many interesting details about that part of Windows. I have watched that talk a while ago and maybe I have misremembered something, but my understanding is that using the WSL infrastructure is off limits for normal Win32 processes and as such is not suitable for implementation of CoW pages for D's GC. (I watched that talk specifically because I was interested if some of that could be used in druntime.)
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 07:11:10 UTC, Dmitry Olshansky wrote: On Monday, 19 June 2017 at 22:50:05 UTC, Adam D. Ruppe wrote: What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing? This is mostly because I wanted to abuse lazy commit of POSIX. Now that I think of it Windows is mostly ok, except for the fork trick used in concurrent GC. As Vladimir pointed out on Windows there are other ways to do it but they are more involved. --- Dmitry Olshansky BTW, Rainer Schuetze has studied this in detail and has written down some of it here: http://rainers.github.io/visuald/druntime/concurrentgc.html
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote: limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE. Nice!
Re: Replacing Make for the DMD build
On Tuesday, 20 June 2017 at 09:08:32 UTC, Vladimir Panteleev wrote: On Tuesday, 20 June 2017 at 07:24:26 UTC, Russel Winder wrote: [...] Yep; same as what was done with ddmd. [...] Sorry Russell, I thought I was replying to Atila :) But you are of course welcome on IRC. The D channel is on Freenode (#d). If you don't want to install an IRC client, there is a web portal at http://webchat.freenode.net/. In that case, what were you replying? :P I'm serious, I'm lost now. Atila
Re: Analysis of D GC
My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html --- Dmitry Olshansky Many thanks for your efforts Dmitry :) May I ask you if you plan to make a soft real-time GC similar to the one implemented in the Nim language ? https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/intern.html#debugging-nim-s-memory-management What is great about it is that we can call it regularly to collect memory a bit at a time, giving it a maximum delay for this operation. Being able to manually specify the maximum GC delay is what makes Nim compatible with game development, as collections can be made iteratively, and on a per-thread basis. In the worst case, we know that just one of the application threads will be delayed for a few milliseconds between two frame renderings, which is generally acceptable for games and other similar applications. Moreover this opens to opportunity to call the GC only in the main menu or the pause menu for instance, but not during actual gameplay, so that even these few lost milliseconds will always remain unnoticed. This is probably why Nim's author was once paid to wrap an open source game engine (Urho3D), and improve the language's native compatibility with C++ libraries. https://forum.nim-lang.org/t/870
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 15:16:01 UTC, Ecstatic Coder wrote: My take on D's GC problem, also spoiler - I'm going to build a new one soonish. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html --- Dmitry Olshansky Many thanks for your efforts Dmitry :) May I ask you if you plan to make a soft real-time GC similar to the one implemented in the Nim language ? https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/intern.html#debugging-nim-s-memory-management What is great about it is that we can call it regularly to collect memory a bit at a time, giving it a maximum delay for this operation. No incremental GC, sorry. It may grow thread-local collection one day, once spec is precise about what is allowed and what is not.
Re: Embedded Systems (STM32) LDC Absolute minimal runtime
I believe you can do without any runtime at all, but it's a tradeoff, see also https://forum.dlang.org/post/tmofjecvnqdthvete...@forum.dlang.org
Re: CTFE Status 2
On Tue, Jun 20, 2017 at 12:07:00PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
>
> limited Support for 32bit floating point ops [+, -, *, /, %] has just
> landed in newCTFE.
Awesome!
> float fmadd(float a, float b, float c)
> {
> return b + a * c;
> }
>
> pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
> pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);
Awesome stuff. Can't wait to get my hands on the newCTFE engine for my
math code!
T
--
Written on the window of a clothing store: No shirt, no shoes, no service.
Re: Analysis of D GC
On Tue, Jun 20, 2017 at 07:47:13AM +, Dmitry Olshansky via Digitalmars-d wrote: > On Monday, 19 June 2017 at 23:52:16 UTC, Vladimir Panteleev wrote: [...] > > - Support generational collection using write barriers implemented > > through memory protection. > > Super slow sadly. That being said I belive D is just fine without > generational GC. The generational hypothesis just doesn't hold to the > extent it holds in say Java. My hypothesis is that most performance > minded applications already allocate temporaries using region > allocator of sorts (or using C heap). [...] FWIW, here's a data point to the contrary: One of my projects involves constructing a (very large) AA that grows over time, and entries are never deleted. The AA itself is persistent and lasts until the end of the program. Besides the AA, there are a couple of arrays that also grow (more slowly) but eventually become unreferenced. Because of the sheer size of the AA, I've observed that GC collection cycles become slower and slower, yet most of this extra work is completely needless, because the only thing that might need collecting is the arrays, yet the GC has to mark the entire AA each time, only to discover it's still live. After some experimentation I discovered that I could get up to 40-50% performance improvement just by calling GC.disable and scheduling my own GC collection cycles via GC.collect at a slower rate than the current default setting. >From this, it would seem to me that a generational collector would have helped, since most of the AA will eventually migrate to older generations and most of the time the GC won't bother marking/scanning those parts. Of course, this is only for this particular program, and I can't say that this is typical usage for D programs in general. But I think D would still benefit from a generational collector. T -- What did the alien say to Schubert? "Take me to your lieder."
Re: dmd -betterC
On Tuesday, 20 June 2017 at 11:52:56 UTC, Jacob Carlborg wrote: On 2017-06-20 03:51, Walter Bright wrote: Is getting a whole lot better: https://github.com/dlang/dmd/pull/6918 You can now build D executables that do not link in anything from Phobos - only from the standard C library. BTW, how are asserts handled? Isn't assert usually a macro in C? I was curious about this as well when I saw the PR. Great to see that -betterC is getting some attention as well.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 08:36:38 UTC, Mike wrote: I know, but you do know what linker features exists and how the linker works, and could generate better intermediate code that could allow the linker to more effectively identify and remove dead code. You can write a linker wrapper that will do the analysis you want, remove unneeded sections, stub symbols etc, see basic technique at https://theartofmachinery.com/2016/12/18/d_without_runtime.html
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %]
has just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);
Cheer Guys!
64bit floating point is in!
Hit me with brittle numeric code please!
At the same time 64bit integer support was expanded.
Such that we can now return long and ulong values.
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
On Tue, Jun 20, 2017 at 11:57:55AM +, Mike Parker via Digitalmars-d wrote:
> DIP 1009 is titled "Improve Contract Usability".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
[...]
What would a body-less declaration of a function look like under the new
syntax? Hopefully not this:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in assert(args[0] != 0);// semicolon: ouch
in assert(args[1] > 1); // semicolon: ouch
// How do we end the declaration here? Another semicolon?
; // ouch
Having several semicolons outside a braced block makes declarations
harder to parse. External tools will no longer be able to just scan for
top-level semicolons to find the end of the declaration, but will have
to understand contract syntax too, even if that particular tool doesn't
care about contracts.
It gets worse if your contract involves calling another function; you'll
end up with:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in assert(args[0] != 0); // is this the end of the declaration?
in otherFunc(args[0]); // is this declaring another function?
// (i.e., a typo of int -> in?)
; // ouch
Also, I don't like the idea of putting contracts inside the function
body. As the DIP already mentions, this makes parsing of contracts more
difficult. It also causes cognitive dissonance (contracts are a part of
the function's signature, not its implementation).
It's even worse if you allow contracts in arbitrary places inside the
function body -- then even somebody reading the code wouldn't know, at a
glance, what the contracts are, without scanning the entire function
body! That makes contracts *harder* to read and use, rather than easier,
in direct contradiction of the purpose of this DIP.
Here's my counter-proposal: since the sig constraint line uses
parentheses (and yes, I deliberately planted a sig constraint above just
to make this point), why not go for syntactical symmetry? I.e., like
this:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1); // one semicolon to end them all
This also makes it possible to completely elide `body` or `do` when
there's a function body, since we no longer have the possibility of two
braced blocks appearing next to each other (i.e., `in { ... } { ... }`
that Timon strongly objected to). So we have:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1)
{
// function body here
}
Notice how the nice symmetry with the current syntax for functions with
sig constraints. Also, getting rid of "assert" also makes this syntax
less verbose, easier to type, and easier to read.
Furthermore, since we will retain backward compatibility with the
current verbose syntax, it's not a problem that using parentheses
implies we only allow expressions inside; if you need to write, say, a
for-loop in your contract, just use the old syntax:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in
{
// Complicated in-contract here requiring multiple
// statements: just use the current braced syntax.
int total;
foreach (arg; args)
{
assert(arg > 0);
total += arg;
}
assert(total < 1000);
}
do
{
// function body here
}
The idea is that one-line, single-expression contracts are the norm, and
complex, multiple-statement contracts are rare. So the common case ought
not need to pay for the extra syntactic load that's only rarely
necessary, but the (current) verbose syntax is still available when it's
actually needed.
For out-contracts, we could use the existing lambda syntax to avoid the
ugliness of having two parenthesized expressions next to each other:
// Body-less declaration
int myFunc(Args...)(Args args)
if (Args.length > 1)
in (args[0] > 0)
out (result => result > 10);
// N.B.: instead of: `out(result)(result > 10)` which is uglier.
// Full declaration
int myFunc(Args...)(Args args)
if (Args.length > 1)
in (args[0] > 0)
out (result => result > 10)
{
... // function body goes here
}
T
--
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss,
binary trees... and bugs.
How can I use ldc2 and link to full runtime on arm with no OS
I'm starting to make attempts to find out what is needed to make D finally work on low level embedded targets. I have been using LDC2, i compile each .d file to and .o file and link using arm-none-eabi-gcc. I have a demo available here: Www.github.com/vitalelement/stm32dblinky includes a linked script. I was originally trying to have a minimal run time approach but having read a lot here I don't buy the argument that these targets cant run with GC. So id like to now link to the full run time if possible and try out the GC. However there doesn't seem to be any guide on how to do this? I need to know, how does the run time know which area of ram to use for heap? In c/c++ usually we use linked script to provide an area of ram for this. How do I link in the run time and gc, etc? Many thanks Dan
Re: Abusive posts
On 06/19/2017 07:29 AM, Vladimir Panteleev wrote: The URL contains the RFC 850 Message-ID, so it can be looked up directly in an email / NNTP client Any idea how to do that in thunderbird?
Re: Abusive posts
On 06/20/2017 10:53 AM, Nick Sabalausky (Abscissa) wrote: On 06/19/2017 07:29 AM, Vladimir Panteleev wrote: The URL contains the RFC 850 Message-ID, so it can be looked up directly in an email / NNTP client Any idea how to do that in thunderbird? View menu | Headers | All exposes it for me. For example, it's the following for your message: Ali
Re: There really needs to be some moderation
On 06/18/2017 06:21 PM, Joakim wrote: On Sunday, 18 June 2017 at 21:44:11 UTC, Walter Bright wrote: For further questions about what constitutes professional decorum, I recommend reading "Emily Post" books on manners which are readily available. I would never read such a thing. I subscribe more to the Linus school that such books are written by schoolmarms who simply squeeze the negativity into other possibly more corrosive behavior: "Because if you want me to 'act professional,' I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways." https://arstechnica.com/information-technology/2013/07/linus-torvalds-defends-his-right-to-shame-linux-kernel-developers/ That is not to say I'd go around cursing like Linus, and again we agree these two went overboard, but it's not a big deal and I don't think it merits anything more than a warning, both here and in general. I'll stop responding after this, as I've now made my position clear, and we don't need to turn this into a big etiquette discussion. :) Hear, hear!
comp.lang.c thread about D
Funny. Someone replied to a post from 1988 concerning the D language. The original thread (not read yet) from 1988 even has messages from Walter. https://groups.google.com/forum/#!topic/comp.lang.c/y0uGj6tHe2E%5B201-225%5D original thread https://groups.google.com/forum/#!topic/comp.lang.c/y0uGj6tHe2E%5B101-125%5D
Re: Abusive posts
On 06/20/2017 02:02 PM, Ali Çehreli wrote: On 06/20/2017 10:53 AM, Nick Sabalausky (Abscissa) wrote: On 06/19/2017 07:29 AM, Vladimir Panteleev wrote: The URL contains the RFC 850 Message-ID, so it can be looked up directly in an email / NNTP client Any idea how to do that in thunderbird? View menu | Headers | All exposes it for me. For example, it's the following for your message: I meant looking up a post by its ID (not obtaining the ID of a post).
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote: Hit me with brittle numeric code please! […] Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated. Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start. — David
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote: On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote: Hit me with brittle numeric code please! […] Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated. Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start. — David Fixed.
Re: Replacing Make for the DMD build
On 06/19/2017 04:06 AM, Russel Winder via Digitalmars-d wrote: Reggae is D's pitch in the CMake and Meson class of meta-build tools. Why aren't all the D compiler and tool developments using it? I'm convinced a big part of that is because DUB is ubiquitous and incredibly helpful in the D world for package management, but plays very poorly with any build system that isn't DUB's internal one. I've blown enormous amounts of time trying to get my projects (that need DUB for dependencies) to use alternate buildsystems without DUB getting in the way, and never really succeeded. A. Figuring out how to obtain all the necessary import paths, link paths, etc to USE a DUB-repo-provided package (especially vibe) on the compiler command-line, and be sure that I'm actualy getting everything I need and that it won't be broken when the dependency is updated... B. Figuring out how to tell dub "quit trying to compile/link my files yourself" without screwing up part "A" above in the process... ...it's just a mess, and despite the rediculous amounts of effort I've put into trying to get that all working sanely, even I mostly just gave up, just use DUB to build everything (even though it's slow), and shy away from attempting anything that's part of the supposedly "0.1%" of use-cases (such as including any libs or components that aren't D) which DUB, by design, doesn't attempt to address.
Re: dmd -betterC
On 2017-06-20 14:11, Guillaume Piolat wrote: About macOS 32-bit. Am I the only user? Yes :) Things are OK now. The older LDCs will work targeting newer macOS 32-bit for a while I guess, so maybe 32-bit can be phased out (especially TLS which I don't use). I would guess LDC supports it as long as LLVM does. BTW, after the next version of macOS, High Sierra, Apple will drop the support for 32bit applications. You need to move to 64bit. -- /Jacob Carlborg
Re: Analysis of D GC
On 2017-06-20 16:03, Petar Kirov [ZombineDev] wrote: I highly doubt that ketmar would have any intention of touching macOS regardless ;) I somehow mixed up ketmar and Guillaume Piolat (which used to go by the alias p0nce). My mistake. -- /Jacob Carlborg
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote: At the same time 64bit integer support was expanded. Such that we can now return long and ulong values. Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated. The reason this broke was because we do not handle default arguments in calls correctly. I have added a bailout such that we will not try to call functions with default arguments. with that we should pass phobos uinttests again.
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 16:49:44 UTC, H. S. Teoh wrote: On Tue, Jun 20, 2017 at 07:47:13AM +, Dmitry Olshansky via Digitalmars-d wrote: On Monday, 19 June 2017 at 23:52:16 UTC, Vladimir Panteleev wrote: [...] FWIW, here's a data point to the contrary: One of my projects involves constructing a (very large) AA that grows over time, and entries are never deleted. The AA itself is persistent and lasts until the end of the program. Besides the AA, there are a couple of arrays that also grow (more slowly) but eventually become unreferenced. Because of the sheer size of the AA, I've observed that GC collection cycles become slower and slower, yet most of this extra work is completely needless, because the only thing that might need collecting is the arrays, yet the GC has to mark the entire AA each time, only to discover it's still live. After some experimentation I discovered that I could get up to 40-50% performance improvement just by calling GC.disable and scheduling my own GC collection cycles via GC.collect at a slower rate than the current default setting. From this, it would seem to me that a generational collector would have helped, since most of the AA will eventually migrate to older generations and most of the time the GC won't bother marking/scanning those parts. Of course, this is only for this particular program, and I can't say that this is typical usage for D programs in general. But I think D would still benefit from a generational collector. Interestingly the moment you "reallocate" to expand the AA it will be considered a new object. Overall I think your case is more about faulty collection heuristics, that is collecting when there is a slim chance of getting enough of free space after collection. T
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 19:01:06 UTC, Stefan Koch wrote:
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Just making sure that the Phobos unit tests pass at compile
time (with 64 bit reals, if that is what you support) should
be a good start.
— David
Fixed.
But how much of the std.math code are you actually executing with
newCTFE? What I meant is that if the std.math{,special}
implementations of the various mathematical functions work, there
shouldn't be any egregious issues. I'm not sure how much of it is
usually run during CTFE, though.
— David
Re: Replacing Make for the DMD build
On Tuesday, 20 June 2017 at 19:06:05 UTC, Nick Sabalausky (Abscissa) wrote: On 06/19/2017 04:06 AM, Russel Winder via Digitalmars-d wrote: Reggae is D's pitch in the CMake and Meson class of meta-build tools. Why aren't all the D compiler and tool developments using it? I'm convinced a big part of that is because DUB is ubiquitous and incredibly helpful in the D world for package management, but plays very poorly with any build system that isn't DUB's internal one. While the dub documentation is not always the best, it seems to me to be in a better state than reggae's. I've heard about reggae a bit on the forum, but I never really made any attempt to try to use it. dub seems a lot simpler for small projects. Maybe Atila could do a blog post with some simple examples and compare/contrast with dub?
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 19:37:47 UTC, David Nadlinger wrote:
But how much of the std.math code are you actually executing
with newCTFE? What I meant is that if the std.math{,special}
implementations of the various mathematical functions work,
there shouldn't be any egregious issues. I'm not sure how much
of it is usually run during CTFE, though.
— David
I just checked.
I execute exactly 0% of it.
It mostly bails out on || and &&.
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote: How do I link in the run time and gc, etc? In your case, you firstly need to cross-compile druntime to your target. This means compiling most files in the src subdirectory of LDC's druntime [1], excluding obvious ones like src\test_runner.d, src\core\sys, src\core\stdcpp etc. There are also a bunch of C and assembly files which need to be cross-compiled with a matching gcc. You'll need to do this manually via something along these lines: cross-gcc -c <.c files and .asm/S files> ldc2 -mtriple=... -lib -betterC -release -boundscheck=off <.o files generated above> -of=libdruntime.a Then try linking your minimal code against that druntime (and static C libs, as druntime is built on top of the C runtime, see [2]). Depending on what features you make use of in your code, you'll need to patch linked-in druntime modules to remove the OS dependencies and possibly reduce the C runtime dependencies as well. [1] https://github.com/ldc-developers/druntime. [2] http://forum.dlang.org/thread/mojmxbjwtfmioevuo...@forum.dlang.org
Re: Analysis of D GC
On Tue, Jun 20, 2017 at 07:14:11PM +, Dmitry Olshansky via Digitalmars-d wrote: > On Tuesday, 20 June 2017 at 16:49:44 UTC, H. S. Teoh wrote: [...] > Interestingly the moment you "reallocate" to expand the AA it will be > considered a new object. [...] This is not entirely true. The *table* itself will of course get moved to a new object, but most of the size of the AA comes from its entries, and those are nodes that stay in-place. You'll still have to scan references to the table, of course, but that's a lot better than scanning all the entries as well. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: Digital Mars resource compiler: boost licensed?
On 6/20/2017 5:53 AM, Adam D. Ruppe wrote: Is the rcc from bup.zip now boost licensed too? If so, I think we should include it in the 32 bit windows setup. The rcc.exe compiler is now Boost licensed. The rc.exe one is not - it's from Microsoft. Anything copyrighted by Microsoft in the Symantec/Digital Mars distributions is not Boost licensed.
Re: comp.lang.c thread about D
On 6/20/2017 11:10 AM, Patrick Schluter wrote: Funny. Someone replied to a post from 1988 concerning the D language. The original thread (not read yet) from 1988 even has messages from Walter. https://groups.google.com/forum/#!topic/comp.lang.c/y0uGj6tHe2E%5B201-225%5D original thread https://groups.google.com/forum/#!topic/comp.lang.c/y0uGj6tHe2E%5B101-125%5D I've been in this business a lng time :-)
Re: dmd -betterC
On 6/20/2017 4:58 AM, Jacob Carlborg wrote: How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" druntime function. Not sure if anyone cares about macOS 32bit. Does the TLS implementation depend on druntime on any other platforms? For a C implementation that doesn't support TLS, using it in D with -betterC won't work.
Re: dmd -betterC
On 6/20/2017 12:06 PM, Jacob Carlborg wrote: BTW, after the next version of macOS, High Sierra, Apple will drop the support for 32bit applications. You need to move to 64bit. I won't miss it. I don't think it'll be long before 32 bits starts disappearing from Windows and Linux as well. As a pragmatic matter, the D community doesn't have the resources to support systems that have been abandoned by their vendors. This is why D officially doesn't support Windows XP anymore.
Re: dmd -betterC
On 6/20/2017 4:52 AM, Jacob Carlborg wrote: BTW, how are asserts handled? Isn't assert usually a macro in C? https://github.com/dlang/dmd/pull/6901
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1
On 6/20/17 1:42 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 20, 2017 at 11:57:55AM +, Mike Parker via Digitalmars-d wrote:
DIP 1009 is titled "Improve Contract Usability".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md
[...]
What would a body-less declaration of a function look like under the new
syntax? Hopefully not this:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in assert(args[0] != 0);// semicolon: ouch
in assert(args[1] > 1); // semicolon: ouch
// How do we end the declaration here? Another semicolon?
; // ouch
Having several semicolons outside a braced block makes declarations
harder to parse. External tools will no longer be able to just scan for
top-level semicolons to find the end of the declaration, but will have
to understand contract syntax too, even if that particular tool doesn't
care about contracts.
It gets worse if your contract involves calling another function; you'll
end up with:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in assert(args[0] != 0); // is this the end of the declaration?
in otherFunc(args[0]); // is this declaring another function?
// (i.e., a typo of int -> in?)
; // ouch
Also, I don't like the idea of putting contracts inside the function
body. As the DIP already mentions, this makes parsing of contracts more
difficult. It also causes cognitive dissonance (contracts are a part of
the function's signature, not its implementation).
It's even worse if you allow contracts in arbitrary places inside the
function body -- then even somebody reading the code wouldn't know, at a
glance, what the contracts are, without scanning the entire function
body! That makes contracts *harder* to read and use, rather than easier,
in direct contradiction of the purpose of this DIP.
Here's my counter-proposal: since the sig constraint line uses
parentheses (and yes, I deliberately planted a sig constraint above just
to make this point), why not go for syntactical symmetry? I.e., like
this:
int myFunc(Args...)(Args args)
if (Args.length > 2)
in (args[0] != 0)
in (args[1] > 1);// one semicolon to end them all
This is much much better. The verbosity of contracts isn't really the
brace, it's the asserts. This also gives the compiler a better handle on
what causes the thing to fail (better error message).
Note that you NEED the semicolon for the DIP's proposal, because `in` is
also a binary operator, and could be misinterpreted. With yours, it's
not possible to misinterpret.
For out-contracts, we could use the existing lambda syntax to avoid the
ugliness of having two parenthesized expressions next to each other:
// Body-less declaration
int myFunc(Args...)(Args args)
if (Args.length > 1)
in (args[0] > 0)
out (result => result > 10);
// N.B.: instead of: `out(result)(result > 10)` which is uglier.
// Full declaration
int myFunc(Args...)(Args args)
if (Args.length > 1)
in (args[0] > 0)
out (result => result > 10)
{
... // function body goes here
}
I'm not understanding that last part. Current syntax would be:
out(result)
{
// check result
}
I'm concerned this would be ambiguous with the current syntax.
IMO, this whole proposal doesn't carry enough weight, either your
version or the DIP itself. I would not be in favor. Current syntax is
understandable, and not too verbose IMO.
-Steve
Re: Replacing Make for the DMD build
On Monday, June 19, 2017 1:45:27 PM MDT meppl via Digitalmars-d wrote: > On Monday, 19 June 2017 at 09:19:32 UTC, Dejan Lekic wrote: > > On Friday, 16 June 2017 at 06:30:01 UTC, Russel Winder wrote: > >> A direct question to Walter and Andrei really. > >> > >> If someone, let us say Russel Winder, create a CMake/Ninja > >> and/or Meson/Ninja build for DMD, is there any chance of it > >> being allowed to replace the Make system? > >> > >> If the answer is no, then Russel will obviously not waste his > >> time doing something that will not be accepted. > > > > Why? > > > > Why replacing a rock-stable Make with build-system-X that most > > likely adds another dependency. I am with Walter on this one. - > > We should continue using Make unless there is a real need for > > something else. DMD's makefiles are really simple! > > is there a point in disallowing several alternate build systems > residing in the dmd repository? > If it is just allowed to upload README-files and make-files of > alternate build systems etc, it would not be necessary to waste > time with this discussion here. Having alternate build systems means maintaining more than one build system. The main reason that a number of us would like to see make replaced is to _reduce_ the maintenance requirements, not increase them. - Jonathan M Davis
Re: dmd -betterC
On Tuesday, 20 June 2017 at 19:06:05 UTC, Jacob Carlborg wrote: On 2017-06-20 14:11, Guillaume Piolat wrote: About macOS 32-bit. Am I the only user? Yes :) Things are OK now. The older LDCs will work targeting newer macOS 32-bit for a while I guess, so maybe 32-bit can be phased out (especially TLS which I don't use). I would guess LDC supports it as long as LLVM does. BTW, after the next version of macOS, High Sierra, Apple will drop the support for 32bit applications. You need to move to 64bit. Good move from Apple. I distribute both bitness as Universal Binaries, most probably this will still work.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 20:48:29 UTC, Walter Bright wrote: On 6/20/2017 12:06 PM, Jacob Carlborg wrote: BTW, after the next version of macOS, High Sierra, Apple will drop the support for 32bit applications. You need to move to 64bit. I won't miss it. I don't think it'll be long before 32 bits starts disappearing from Windows and Linux as well. For ldc users on linux, 32-bit x86 compiler downloads are basically a rounding error: http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc ldc 1.1.0 was released with a native linux/ARM build also, the stats in that link show it was downloaded almost 30 times more than the linux/x86 build.
Re: Replacing Make for the DMD build
On Tuesday, 20 June 2017 at 21:26:02 UTC, Jonathan M Davis wrote: On Monday, June 19, 2017 1:45:27 PM MDT meppl via Digitalmars-d wrote: On Monday, 19 June 2017 at 09:19:32 UTC, Dejan Lekic wrote: > On Friday, 16 June 2017 at 06:30:01 UTC, Russel Winder wrote: >> A direct question to Walter and Andrei really. >> >> If someone, let us say Russel Winder, create a CMake/Ninja >> and/or Meson/Ninja build for DMD, is there any chance of it >> being allowed to replace the Make system? >> >> If the answer is no, then Russel will obviously not waste >> his time doing something that will not be accepted. > > Why? > > Why replacing a rock-stable Make with build-system-X that > most likely adds another dependency. I am with Walter on > this one. - We should continue using Make unless there is a > real need for something else. DMD's makefiles are really > simple! is there a point in disallowing several alternate build systems residing in the dmd repository? If it is just allowed to upload README-files and make-files of alternate build systems etc, it would not be necessary to waste time with this discussion here. Having alternate build systems means maintaining more than one build system. The main reason that a number of us would like to see make replaced is to _reduce_ the maintenance requirements, not increase them. - Jonathan M Davis No, as I noted earlier in this thread, all you have to do is keep the Makefiles up to date, and dump the maintenance burden for Meson/reggae build scripts on their proponents, who in turn don't have to keep them up to date. Once the project contributors have solid experience with the Make alternatives, you consider making a switch.
