Re: Why not flag away the mistakes of the past?
On Thursday, 8 March 2018 at 17:14:16 UTC, Jonathan M Davis wrote: On Thursday, March 08, 2018 16:34:11 Guillaume Piolat via Digitalmars-d wrote: On Wednesday, 7 March 2018 at 13:24:25 UTC, Jonathan M Davis wrote: > On Wednesday, March 07, 2018 12:53:16 Guillaume Piolat via > > Digitalmars-d wrote: >> On Wednesday, 7 March 2018 at 06:00:30 UTC, Taylor >> Hillegeist >> >> wrote: >> > That way the breaking change was easily fixable, and the >> > mistakes of the past not forever. Is it just the cost of >> > maintenance? >> >> auto-decoding problem was mostly that it couldn't be @nogc >> since throwing, but with further releases exception >> throwing will get @nogc. So it's getting fixed. > > I'd actually argue that that's the lesser of the problems > with auto-decoding. The big problem is that it's > auto-decoding. Code points are almost always the wrong level > to be operating at. The programmer needs to be in control of > whether the code is operating on code units, code points, or > graphemes, and because of auto-decoding, we have to > constantly avoid using the range primitives for arrays on > strings. Tons of range-based code has to special case for > strings in order to work around auto-decoding. We're > constantly fighting our own API in order to process strings > sanely and efficiently. I'd agree with you, hate the special casing. However it seems to me this has been debated to death already, and that auto-decoding was successfully advocated by Alexandrescu and al; surviving the controversy years ago. Most everyone who debated in favor of it early on is very much against it now (and I'm one of them). Experience and a better I wasn't so much asking about auto-decoding in particular more about the mentality and methods of breaking changes. In a way any change to the compiler is a breaking change when it comes to the configuration. I for one never expect code to compile on the latest compiler, It has to be the same compiler same version for the code base to work as expected. At one point I envisioned every file with a header that states the version of the compiler required for that module. A sophisticated configuration tool could take and compile each module with its respective version and then one could link. (this could very well be the worst idea ever) I'm not saying we should be quick to change... oh noo that would be very bad. But after you set in the filth of your decisions long and hard and are certian that it is indeed bad there should be a plan for action and change. And when it comes to change it should be an evolution not a revolution. It is good avoiding the so easily accepted mentality of legacy... Why do you do it that way? "It's because we've always done it that way." The reason I like D is often that driven by its community it innovates and renovates into a language that is honestly really fun to use. (most of the time)
Why not flag away the mistakes of the past?
So i've seen on the forum over the years arguments about auto-decoding (mostly) and some other things. Things that have been considered mistakes, and cannot be corrected because of the breaking changes it would create. And I always wonder why not make a solution to the tune of a flag that makes things work as they used too, and make the new behavior default. dmd --UseAutoDecoding That way the breaking change was easily fixable, and the mistakes of the past not forever. Is it just the cost of maintenance?
Re: What is the state of Microcontroller support in d?
On Monday, 19 June 2017 at 20:01:01 UTC, Dan Walmsley wrote: On Friday, 8 April 2016 at 03:38:01 UTC, Taylor Hillegeist wrote: So, for me one of the greatest things about d is that it is compiled to machine language. But It makes me sad that this strength doesn't seem to be available in one of the most obvious places. [...] 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?, I'm still around I just haven't been working with D for a while. I see you were trying to put an effort together. That's really great, if there is anything I can do to keep the momentum let me know.
D-issapointed after using C# for a while.
In the past I have worked with D, C#, Java, Python and C and some other less popular languages. Most recently working with C# I suddenly realize the convenience and flexibility I had in D. One case in particular is with bit-fields in D they are a pleasure to use and implement, but in C# they are a mystery, sure they have Enums that are flexible for some cases, I suppose I just wanted to say thanks to the D community for their effort.
What is the state of Microcontroller support in d?
So, for me one of the greatest things about d is that it is compiled to machine language. But It makes me sad that this strength doesn't seem to be available in one of the most obvious places. There are some projects: minilibd: https://bitbucket.org/timosi/minlibd The example code is still waiting for decision what is the proper way to access peripheral registers in D code. The Discovery board Demo: https://github.com/JinShil/stm32f42_discovery_demo I actually was able to run the code on this board. These are very cool, I do notice that both of these use GDC. The discovery demo looked tedious to implement (https://github.com/JinShil/stm32_datasheet_to_d). I cheated and used a CMSIS .svd file to build the peripherals registers. https://www.keil.com/pack/doc/CMSIS/SVD/html/svd__outline_pg.html There are big hurdles: Typeinfo bloat. Register/Linker file configuation. Standardized build environments. More complete runtimes with examples :) better documentation on d runtime and what is needed for x functionality. But bottom line is it really isn't easy to do. I follow the examples for the most part. I feel like the Build environment was clunkly for micros and dub certainly was not the right build tool. I was just curious what is the story? I know its a goal that in time the community would love to reach.
Re: Calling .NET from D
On Saturday, 26 March 2016 at 14:15:18 UTC, Laeeth Isharc wrote: On Saturday, 26 March 2016 at 07:53:06 UTC, Taylor Hillegeist wrote: Found a simple way to call .NET managed code from un-managed D code. I didn't know about it so I thought someone else could find it useful. https://github.com/taylorh140/Calling-NET-from-D Thank you so much for this. This is very helpful indeed. I guess you might have looked also into going the other way around - calling D code from C#. Anything one should know beyond the standard pinvoke/C API described here? https://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx That looks pretty good. It seems to me as if microsoft wants managed to unmanaged calls,as opposed to unmanaged to managed, the link to pinvoke/C is probably more information than the total I gathered for reverse p-invoke (DllExport). If you need more information on any of the processes involved feel free to make it an issue for repo.
Calling .NET from D
Found a simple way to call .NET managed code from un-managed D code. I didn't know about it so I thought someone else could find it useful. https://github.com/taylorh140/Calling-NET-from-D
Re: embedded ARM support
On Monday, 9 November 2015 at 20:09:05 UTC, Timo Sintonen wrote: On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist wrote: Maybe I am wrong, But I believe that the low level community is awaiting the release of GDC/LDC compatible with 2.067 DMD front end. This will allow for volatile store/load. and hopefully begin a new era of D micro programming. I'm sure this isn't the whole story. but i get the feeling it is a major part of the minimal micro-controller involvement. Yes, that is the problem but the solution is not acceptable. We discussed about alternative solutions in gdc forum last year. Possibilities are to make something gdc specific or to use a custom data type. It was seen good to build this feature somehow into gdc but on the other hand there is a need to keep gdc as close to dmd as possible. In what way is the solution unacceptable? Solution is not easy to use. Solution is does not solve problem. Solution is not easy/possible to implement. Can not be implemented in a uniform way. Just curious? perhaps a link to the discussion would be good enough. thanks.
Re: embedded ARM support
On Monday, 9 November 2015 at 10:14:17 UTC, Timo Sintonen wrote: On Monday, 9 November 2015 at 08:49:57 UTC, Andrey wrote: On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote: https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like this? Yes. But I mean the real supported library, with header files, registers declarations and so on... That is realy low instructions. It is good for experiments and self-affirmation, but not usefull for daily work. It't not realy cool to declare manualy all needed registers adresses and manualy manage adresses for linker https://bitbucket.org/timosi/minlibd contains a modified runtime library and a toolset with a working example. It supports many D language features like object creation. There are some register definitions but it is far from complete. Suggestions and contributions are welcome. One thing why the project is going so slowly is the issue with accessing peripheral registers. The official D does not want to support register access directly, but only with library functions. In gdc it is possible with shared variables but this feature is unstable. There are some Cortex-m users hanging here but so far any big project has not been made. Maybe I am wrong, But I believe that the low level community is awaiting the release of GDC/LDC compatible with 2.067 DMD front end. This will allow for volatile store/load. and hopefully begin a new era of D micro programming. I'm sure this isn't the whole story. but i get the feeling it is a major part of the minimal micro-controller involvement.
What Features Should A GUI toolkit have?
So I have played with a few GUI libraries with bindings available through D. Personally I find that it seems like there is alot of effort being put forth on GUI projects. It is my experience that most project's fail or die, not because of lack of effort but lack of specification, many people start projects thinking, can i make it do this? how about this? and a project is born! but soon interest is lost and the project dies. But specification can lead to projects that become useful earlier, more stable, and live longer happier lives. At this point i think the following features are the most useful. -Ease of setup- dub integration is awesome, without it things are more difficult. This has very little to do with the actual toolkit. -Minimal dependencies- Personally If i can statically link a toolkit to my GUI and it has zero dependencies outside of the OS typically install. I am very happy. really the less that can be messed with the better. best in my opinion: DWT MiniGUI DGUI at least for windows. -Rock Solid Stable- So when I do the hello world application I resize the window push the buttons and do pretty normal things. But on some libraries I get weird stuff going on sometimes the window even becomes invisible. scary. best in my opinion: GTKD TKD -GUI EDITOR/BUILDER- Good- You can edit a static layout Better- you can edit a layout and re-size the window layout responds Best- you can edit the actual window in real time without recompile. Good- You have a pallet of basic widgets that you can place. Better- You have a pallet of basic widgets + custom widgets that you can edit. Best- You have the above + a database were people can share widgets :) -Widgets- Personally I think that all layout items like HBar should be children of widget that way i can make more modular component, but that's just my opinion. -Data Binding- Most of the time I use that data a widget represents and much less often the events they produce. -Ease of Use- Your tookits should work for you... not the other way round. -layout- I have seen some schemes like Winforms Dock,javaFX HBar, HTML5's float/static/absolute/realitive... Idk what seems the most freindly... HTML5/css seems the most complex. I have a dream H/VBar + align/distribution/wrap options. I know some of these are RAD things. I don't have an opinion on thread safe guis. personally I would like to see a GUI tookit that the community said... use X it is just the way to go for most things.
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves. Now, how I envision the library's design: The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop. The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework. Thanks, Aram So I don't speak for the community, but I like the idea of having a gui abstracting front end that targets backends, like Qt or GTK or Winforms. I know some people probably don't care as much about dependencies as me. But for me its always best to target a platforms native toolkit, I think it looks better. We should do a poll or something.
Re: Is there such a thing?
On Tuesday, 3 March 2015 at 10:37:49 UTC, Kagamin wrote: On Saturday, 28 February 2015 at 17:06:58 UTC, Dicebot wrote: On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... C is pretty much a standard for cross-language ABI Object files have no language-level compatibility, only linker-level compatibility. You can get function arguments wrong, and linker won't tell you. So, I don't thing C is very easy to pull data from, In fact i would guess the only way this would work is if the compiler produced standard data format like JSON or XML or YAML if you like that kind of thing. And then transformed it to native code. I think YAML would look nicer... I also know that some languages have certain capabilities. And this is a lot more complex of problem. But I hear about people making automatic binding generators and all sorts of 1 off tools, I just don't understand why there doesn't seem to be common standard solution.
Re: DIP74: Reference Counted Class Objects
On Sunday, 1 March 2015 at 13:13:58 UTC, bearophile wrote:
Jacob Carlborg:
@arc class Foo
{
T1 opAddRef();
T2 opRelease();
}
...
Alternative A gives a clear documentation it's a reference
counted class without having to scan the methods.
Assuming you want something like DIP74, this design design
seems safer than the design proposed in DIP74.
Bye,
bearophile
So, I don't know a huge amount about this subject. aka. (hold my
beer) but I do know that seemingly by default D has garbage
collection which is wonderful... but It is also wonderful to have
choices.
I see a story like the tortoise and the hare. Where the garbage
collector is like the hare, going really fast but then taking a
break. Reference counting is like the tortoise, a bit slower but
more predictable.
It is clear Reference counting takes more discipline, but unclear
to me how D will help/guide its users through process. it seems
like the @safe will disallow some obviously dumb things. which is
actually really awesome.
It is also unclear how combining both RC and GC will work, how
does the GC know not to scan the RC's territory? And if it does
is it actually beneficial to have RC?
As far as DIP74: In the Definition I am confused what UFCS has to
do with defining the opAddRef() and opRelease() methods. And also
why the are used in the fun() x.opAddref() example. I probably
have like 100 more dumb questions but lets leave it there. :D
Re: Would Lcl be better if it was in D?
On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
On Sun, 01 Mar 2015 22:40:28 +, Taylor Hillegeist wrote:
But still the question was about smaller executable when
compiling d
code. The linker needs to know which .o files to include, the
pascal
notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire
thing even
if your only using a single function or value from each. Then
again
perhaps I am wrong.
FreePascal learnt the "smart linking" trick years ago, so only
actually
used functions ends in linked binary. but LCL is very big
library, and FPC
can't drop out unused virtual methods, so resulting binaries
are big.
with D we have the same situation, maybe even worse due to
template
instantiation. compiler is able to merge identical template
instanses,
but... empty `void main () {}` is ~200 KB in D (GNU/Linux,
x86). adding
simple `import std.stdio : writeln;` increases binary size to
~300 KB.
and adding `writeln("hello!");` increases binary size to ~350
KB.
D binaries are big. ;-)
That seems like alot of KB for just a little bit of code. I
wasn't aware that void main(){} was anything but entry pointer...
;; pseudo-assembly-language
;; main(argc, argv, envp); call
push envp ;; rightmost argument
push argv ;;
push argc ;; leftmost argument ends up on top of stack
call main
I guess I'm confused about what is in there and why?
Re: Would Lcl be better if it was in D?
On Sunday, 1 March 2015 at 21:39:08 UTC, Mike James wrote:
On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist
wrote:
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in
it. well it was easy enough to do. but behold I saw the
executable and it was 14 MB, and I said 'well damn.' It seems
to me that pascal does not do lazy inclusion when it comes to
components of Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but
with much smaller executables?
Turn off the debug build - it's then only a few meg...
--
Yes, the debug does help quite a lot. I like the idea of LCL one
widget front end so you don't have to worry as much about
deployment. but i haven't found a good all static cross platform
solution for d.
so far my favorite GUI libraries so far are:
xwt: mono
LCL: Object Pascal
I like the write once compile anywhere of Lazarus. And I think it
makes more sense to target the platforms native widget library
than to force users to install one or package the whole library
with your executable.
But still the question was about smaller executable when
compiling d code. The linker needs to know which .o files to
include, the pascal notation is basically:
uses
thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
I assume the linker just auto-magically includes the entire thing
even if your only using a single function or value from each.
Then again perhaps I am wrong.
Would Lcl be better if it was in D?
So I was using the Lazarus IDE the other day, and i thought to
myself, what if i create an application with only a button in it.
well it was easy enough to do. but behold I saw the executable
and it was 14 MB, and I said 'well damn.' It seems to me that
pascal does not do lazy inclusion when it comes to components of
Lcl apart from pre-compiler directives.
I noticed some includes in d are inside of functions.
void foo() {
import thingIneed:subfoo;
subfoo();
}
would this allow people to use a large library like LCL but with
much smaller executables?
Re: Is there such a thing?
On Friday, 27 February 2015 at 21:15:10 UTC, H. S. Teoh wrote: On Fri, Feb 27, 2015 at 09:00:56PM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-02-27 20:49, Taylor Hillegeist wrote: >I just think its a shame that all over the place people are >compiling >code in different programming languages, and although all the >.o >files are compatible with each other there isn't a standard >cross >language way of defining a binding. But that would be making >people >agree on things... I think that's a completely different topic. [...] http://xkcd.com/927/ :-P T Yes, But in this case there is like 300 non-competing non-standards.
Re: Is there such a thing?
On Friday, 27 February 2015 at 07:26:06 UTC, Jacob Carlborg wrote: On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things...
Re: Is there such a thing?
On Thursday, 26 February 2015 at 21:37:46 UTC, Marc Schütz wrote: On Thursday, 26 February 2015 at 19:53:54 UTC, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? IIRC, Pascal unit files work that way. No interface source file is required to use them. That Looks pretty close to exactly correct: http://www.freepascal.org/docs-html/user/userse11.html It was still two files but it looks like the .ppu was analogous to a c header. like the compiler striped out all the necessary declarations. Very interesting... But I don't think it makes it easier to link to with d. The idea is pretty cool though. I wonder if other compilers do the work of creating sources with the logic striped out for use as a header only. One of the listed uses for a unit was if the developer wanted to hide his ip but allow others to use the code. Does D have a way of doing this?
Is there such a thing?
So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea?
