Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Wed, 28 Dec 2016 15:48:46 +, deadalnix wrote:
> On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu
> wrote:
>>> A compiler enhancement can do this _without_ a language change.
>>
>> The language addition has additional benefits as described by DIP1005.
>> -- Andrei
>
> Yes, question is, are these specific benefits worth adding a language
> change ?
And the associated detriments. Just imagine opening up phobos and seeing:
// 1200 lines of code
with (import foo)
{
// 300 lines of declarations...
with (import bar)
{
// 250 lines of additional declarations...
}
}
All mixed in with structs and functions and conditional compilation, so
you have a sea of curly braces to wade through and indentation is only a
mild help.
Re: D future ...
On Wed, 28 Dec 2016 22:10:22 +, Satoshi wrote: > It's not so simple. I actually must know which functions can be called > by CTFE and which not. auto functions should have stripped body with > replaced auto for a specific type, etc. Currently, D header files don't support either of those features. You probably need a custom header generator, one that pays attention to UDAs (assuming you want to annotate functions according to whether they can be called at compile time; otherwise, there's a fair bit more work). Unfortunately, DMD's json output doesn't even write UDAs, so you can't use that to write your own header generator.
Re: D future ...
On Wednesday, 28 December 2016 at 06:48:09 UTC, Chris Wright wrote: On Wed, 28 Dec 2016 03:21:03 +, Jerry wrote: There's only so much time and money someone can give. It isn't that appealing when virtually no other language out there suffers from this problem cause they have an actual market behind them. Most languages have this problem. Most languages you actually hear about don't, because the marketing follows the money, and you hearing about a language follows the marketing. D is unusual in how complete it's become without significant corporate backing, and how popular it is despite lacking a killer application. Reminds me of markets. A stock that has obvious disadvantages people will not stop talking about that keeps making new highs - that's not a stock you want to be short.
Re: D future ...
On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote: On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc wrote: On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: So if you want to improve the language and its ecosystem, the best way is to contribute pull requests or $$$s - the Foundation now accepts individual donations, and it's also open to corporate sponsorship, I believe. Editor support: Sublime text and sometimes vim work well enough for me, though these things are very personal. For the others, have you contributed anything - time or money in making them better? If wishes were horses, beggars would ride. And contribution of either has a higher value than just the thing itself, because it also tends to energise the project - look at the frustration Basil experienced regarding his IDE project. It's good to have high standards, but one should have some appreciation also for the gift that people make of their time, work, and energy in ways that don't always lead to the gratitude that one might expect. There's only so much time and money someone can give. True. I really have very little time myself, but I was more annoyed by seeing the docs wrong and took the twenty minutes or so it took to fix them (slow, because I wasn't used to the process). My point is it's a continuum - not a question either of donating $500k and all of one's time or zero. It isn't that appealing when virtually no other language out there suffers from this problem cause they have an actual market behind them. One picks one's poison and lives with the consequences. D's advantage isn't shiny marketing, documentation, and polish. Yet its user base seems to be growing and people are building their businesses around it. I wonder why that is. In my experience it doesn't do much good to complain about a problem that is well understood unless one is going to do something about it too. And if one isn't contributing code, energy or resources in some other way that will at least make a dent in the problem, one shouldn't be so surprised if one's own preferences don't perfectly coincide with the preferences of those who are. Those markets fuel money being poured into the tools of the lanugage. It doesn't really matter how many users you have, it depends on the demographic of those users. If they are all students still in school, then you haven't really created a market. People are using D to do real work, and there's more money supporting D than ever before. It might not yet be gazillions, but give it time. Rome wasn't built in a year. Great things are achieved by taking baby steps, compounded over time. And if one does what little one can, others are inspired by it. Enthusiasm and a constructive attitude are infectious in my experience. D isn't a year old though. If the steps you take are too small, you can also end up being left behind. Tis possible, but I would happily bet against your view.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/28/16 10:48 AM, deadalnix wrote: On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote: A compiler enhancement can do this _without_ a language change. The language addition has additional benefits as described by DIP1005. -- Andrei Yes, question is, are these specific benefits worth adding a language change ? Right now you got : A/ No language change, get X. B/ Language change, get X and Y. It stand to reason that B should be evaluated on the benefit provided by Y, and Y only, rather than X and Y, as X can be provided without the language change. This is exactly what the DIP describes in detail. It consecrates sections to alternatives. Is anything missing? -- Andrei
Re: D future ...
On 12/28/16 8:17 AM, rikki cattermole wrote: If you don't hear about any fixes coming from a core dev in the next day or so, contact Walter directly. Yes please. Myself too. -- Andrei
Re: D future ...
On 12/28/16 3:35 AM, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. I'll ask the student in charge with the bug to give it priority. -- Andrei
Re: D future ...
On Wednesday, 28 December 2016 at 19:51:38 UTC, Jerry wrote: You don't need the source of the GUI framework to use a compiled program. If you are developing both the GUI and the IDE, then you don't need interface files. You can just use the D source code. Once you compile the IDE no one will have access to the interface files anyways, unless (like i mentioned above) for third party plugin developers. No, GUI framework is one part of project like Qt, GTK or WPF and IDE is an another part. That's including all the actual code bodies, you could probably write a regex to detect and select them. It wouldn't take as long as you think when you start erasing hundreds of lines of code with a single backspace. Anyways point is, it isn't really a showstopper. You could still have released your IDE without interface files to be used as an IDE and you could have made the interface files yourself if you really wanted to release the GUI. It's not so simple. I actually must know which functions can be called by CTFE and which not. auto functions should have stripped body with replaced auto for a specific type, etc. Main part of the project is GUI framework not IDE itself. IDE is made just for simplify GUI development by D'n'D Interface Builder. Like in VS or XCode or Qt Creator. Actually I want to release pre-alpha version of GUI framework just for a few people to show them progress, let them test it and get some feedback. I can generate header files and then fix it manually but first I need a full coverage tests to recognize where bugs are. But still, patching header files every time when I change something is not real.
Re: D future ...
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote: Personally I'm not really looking for an IDE, I've settled for a text editor with a plugin for it. IDEs tend to be bulky and not be very good at manipulating text or rather lacking features to do so. It depends on specific IDE. I don't see how the interface generator is stopping you from releasing the IDE anyways. It's GUI framework (set of libraries) what I cannot release. IDE is without the libs quite useless. You don't need the source of the GUI framework to use a compiled program. If you are developing both the GUI and the IDE, then you don't need interface files. You can just use the D source code. Once you compile the IDE no one will have access to the interface files anyways, unless (like i mentioned above) for third party plugin developers. Wouldn't be that hard but the project have 200k lines of code. Making header files manually is a wast of time what i don't have. That's including all the actual code bodies, you could probably write a regex to detect and select them. It wouldn't take as long as you think when you start erasing hundreds of lines of code with a single backspace. Anyways point is, it isn't really a showstopper. You could still have released your IDE without interface files to be used as an IDE and you could have made the interface files yourself if you really wanted to release the GUI. But the point is that D compiler specification[1] looks like this part works without a problem and is usable but it's a lie and nobody cares about it. Actually it will not ruin my project but complicates it. And this is not the way in which should business be made. 10 years of development and still some key features won't work properly. [1] https://dlang.org/dmd-osx.html#interface-files It's a feature that probably a few people actually use, odds are they forget about it when adding new features and potentially there are no tests for it either.
Re: [OT] Anyone familiar with the google tooling - SKIA as a static library (maybe for D) ?
On Wednesday, 28 December 2016 at 15:43:10 UTC, Joakim wrote: On Wednesday, 28 December 2016 at 14:23:03 UTC, Basile B wrote: I'd like to build SKIA[1] as a static library and interface it with D. However it's hard to build, I don't get anything to their build system, you need 'gen' to generate a 'ninja' file so you must build 'gen' but to build 'gen' you must..., wtf is this cluster fuck... Thanks for your help. [1]https://skia.org/ I have built it back when it still used gyp. I believe what you need to do is 1. Install depot_tools: http://www.chromium.org/developers/how-tos/install-depot-tools 2. Use gclient from depot_tools to get skia: https://skia.org/user/download 3. Use gclient to get gn and build skia: https://skia.org/user/build They give you all the steps, but it's confusing if you haven't done it before and don't read them carefully. Just follow their exact instructions in those three pages and you should be set up. Thanks. But step 1 yet looks like a complete charlie foxtrot (I clone it but nothing is build. So glicent...well goodnight...) I'll try this tomorrow.
Re: D future ...
On Wed, 28 Dec 2016 16:09:28 +, Chris Wright wrote: > On Wed, 28 Dec 2016 11:36:33 +, Satoshi wrote: > >> On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote: >>> On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On >>> Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: Making header files manually is a wast of time what i don't have. >>> >>> Write your own header generator. >> Yes, why not to write my own language. > > It should be significantly easier with dmd's json output. My apologies; dmd's json output suffers the same problem.
Re: D future ...
On Wed, 28 Dec 2016 11:36:33 +, Satoshi wrote: > On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote: >> On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On >> Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: >>> Making header files manually is a wast of time what i don't have. >> >> Write your own header generator. > Yes, why not to write my own language. It should be significantly easier with dmd's json output.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Saturday, 24 December 2016 at 19:16:40 UTC, Joakim wrote: Can we hold off on the performance discussion? Walter says this DIP isn't hard to implement (https://github.com/dlang/DIPs/pull/51#issuecomment-269077790), so we will run some numbers and see what we get. As you know, I too am skeptical of the benefit but Andrei has shown that import fanout has a non-negligible cost with his latest benchmark, and actual measurement will be the best way to decide. The "problem" is that you'd be essentially measuring how inefficient the current DMD import management is rather than anything else. When you push something on the user, you want to make sure it bring an actual benefit, not just allow to work around lousy existing implementation.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei Alexandrescu wrote: A compiler enhancement can do this _without_ a language change. The language addition has additional benefits as described by DIP1005. -- Andrei Yes, question is, are these specific benefits worth adding a language change ? Right now you got : A/ No language change, get X. B/ Language change, get X and Y. It stand to reason that B should be evaluated on the benefit provided by Y, and Y only, rather than X and Y, as X can be provided without the language change.
Re: [OT] Anyone familiar with the google tooling - SKIA as a static library (maybe for D) ?
On Wednesday, 28 December 2016 at 14:23:03 UTC, Basile B wrote: I'd like to build SKIA[1] as a static library and interface it with D. However it's hard to build, I don't get anything to their build system, you need 'gen' to generate a 'ninja' file so you must build 'gen' but to build 'gen' you must..., wtf is this cluster fuck... Thanks for your help. [1]https://skia.org/ I have built it back when it still used gyp. I believe what you need to do is 1. Install depot_tools: http://www.chromium.org/developers/how-tos/install-depot-tools 2. Use gclient from depot_tools to get skia: https://skia.org/user/download 3. Use gclient to get gn and build skia: https://skia.org/user/build They give you all the steps, but it's confusing if you haven't done it before and don't read them carefully. Just follow their exact instructions in those three pages and you should be set up.
Re: Red Hat's issues in considering the D language
On Friday, 23 December 2016 at 14:14:41 UTC, Russel Winder wrote: Strikes me that the really obvious thing to say is that DMD is the playground where whoever wants to can play with and progress the D front end in the knowledge that no-one is going to use DMD in production. People use LDC in production because it is the right thing to do: stable proven front end, stable proven backend, and yet up to date. What is not to like here? What is the problem here? If I need the lastest version for whatever reason, I can't get my LDC build, upgrade it and get it to work. DMD use its own nonsense brew of flags and command line syntax. If I find a bug, report it and get it fixed, I need to wait literally month before being able to use the bugfix in LDC. Or, in short, a playground is not appropriate for the reference compiler if you want to be anything else than a toy.
Re: Improvement in pure functions specification
On Friday, 23 December 2016 at 20:01:49 UTC, Andrei Alexandrescu wrote: $(P Destructors will always be called even if they appear to be strongly pure.) Any other special functions we should worry about? Andrei Why ?
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 12:39:46 UTC, Nemanja Boric wrote: Right, nothing wrong with threads, but super tricky to combine it with fork. So, it could be that one of your threads is using GC at the point of the forking, so it keeps the GC locked. Now you fork, and _all your threads don't exist anymore, they are vanished, and if you don't do some clever stuff in atfork handler, there will be no cleanup_ - you just have copy of the thread that called fork. So, the thread that should release GC lock doesn't exist anymore, and there's nothing to release mutex, and it will stay locked forever in your forked process. Thanks a lot for such detailed explanation!
[OT] Anyone familiar with the google tooling - SKIA as a static library (maybe for D) ?
I'd like to build SKIA[1] as a static library and interface it with D. However it's hard to build, I don't get anything to their build system, you need 'gen' to generate a 'ninja' file so you must build 'gen' but to build 'gen' you must..., wtf is this cluster fuck... Thanks for your help. [1]https://skia.org/
Re: D future ...
On Wednesday, 28 December 2016 at 12:55:17 UTC, YAHB wrote: Sorry, to be honest I didn't take you seriously. Your bug report, so the starter of this off topic fork, is barely understandable: impossible to understand if it was a language issue, an issue of the header function generator... Sorry, I didn't want to start OT I just want to point on some aspects of D from my view. My english is bad so I'm not able to express things as professionally as in my native language. But I think people here are enough intelligent to take me seriously regardless on how I write. Sorry...
Re: D future ...
On 29/12/2016 2:08 AM, Satoshi wrote: On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote: On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. ... Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590 You've got things reversed. The point of a company like Google or Sun backing a language is that things get done, like this bug fix, so that the language can be used for whatever that company needs it to do. You claim you want to make money off the language, yet you are demanding that volunteers immediately fix a bug that is holding you back. That's an odd business model. You have three options: pay to fix it yourself, use a different language that allows you to benefit from work paid for by more profitable companies like Google, or wait for volunteers to do it on their schedule. This is not unique to D. I'm reminded of Visual Studio not supporting C99 or Firefox not supporting certain HTML 5 features. I know that :/ I'm just responding to people who wants shift D to commercial companies but are doing different steps than they should do. Yes, it's true that I want to make money off the language so I should paid for that fix but in other way you want to promote D to others and this is the thing what's holding me back to do the same. And the bug will be fixed anyway, so. If you don't hear about any fixes coming from a core dev in the next day or so, contact Walter directly.
Re: D future ...
On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote: On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. ... Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590 You've got things reversed. The point of a company like Google or Sun backing a language is that things get done, like this bug fix, so that the language can be used for whatever that company needs it to do. You claim you want to make money off the language, yet you are demanding that volunteers immediately fix a bug that is holding you back. That's an odd business model. You have three options: pay to fix it yourself, use a different language that allows you to benefit from work paid for by more profitable companies like Google, or wait for volunteers to do it on their schedule. This is not unique to D. I'm reminded of Visual Studio not supporting C99 or Firefox not supporting certain HTML 5 features. I know that :/ I'm just responding to people who wants shift D to commercial companies but are doing different steps than they should do. Yes, it's true that I want to make money off the language so I should paid for that fix but in other way you want to promote D to others and this is the thing what's holding me back to do the same. And the bug will be fixed anyway, so.
Re: D future ...
On Wednesday, 28 December 2016 at 12:44:38 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote: But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. you'll be in front of another issue then: "dmd_personality"... unless you release the static library for DMD, LDC, GDC, + each version for each, basically debug + release...so already 6 ;] Nope :) Rikarin Studio is a package of precompiled druntime, phobos, Rikarin Framework (Async core, GUI AppKit, basic bindings...) bundled with LDC and own build tool distributed as a toolkit. User will not be able to choose between compilers :) This is what people need, not 800 variants of every tool where at least one cannot work properly. Sorry, to be honest I didn't take you seriously. Your bug report, so the starter of this off topic fork, is barely understandable: impossible to understand if it was a language issue, an issue of the header function generator... You can open a bounty for this.
Re: D future ...
On Wednesday, 28 December 2016 at 12:43:03 UTC, bachmeier wrote: On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. ... Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590 You've got things reversed. The point of a company like Google or Sun backing a language is that things get done, like this bug fix, so that the language can be used for whatever that company needs it to do. You claim you want to make money off the language, yet you are demanding that volunteers immediately fix a bug that is holding you back. That's an odd business model. You have three options: pay to fix it yourself, use a different language that allows you to benefit from work paid for by more profitable companies like Google, or wait for volunteers to do it on their schedule. This is not unique to D. I'm reminded of Visual Studio not supporting C99 or Firefox not supporting certain HTML 5 features. That was what I thought to propose to him: he could found a bounty. Bounties are for a product but the founder doesn't have to be in the company or, like here, in the organization.
Re: D future ...
On Wednesday, 28 December 2016 at 12:14:02 UTC, YAHB wrote: But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. you'll be in front of another issue then: "dmd_personality"... unless you release the static library for DMD, LDC, GDC, + each version for each, basically debug + release...so already 6 ;] Nope :) Rikarin Studio is a package of precompiled druntime, phobos, Rikarin Framework (Async core, GUI AppKit, basic bindings...) bundled with LDC and own build tool distributed as a toolkit. User will not be able to choose between compilers :) This is what people need, not 800 variants of every tool where at least one cannot work properly.
Re: D future ...
On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. ... Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590 You've got things reversed. The point of a company like Google or Sun backing a language is that things get done, like this bug fix, so that the language can be used for whatever that company needs it to do. You claim you want to make money off the language, yet you are demanding that volunteers immediately fix a bug that is holding you back. That's an odd business model. You have three options: pay to fix it yourself, use a different language that allows you to benefit from work paid for by more profitable companies like Google, or wait for volunteers to do it on their schedule. This is not unique to D. I'm reminded of Visual Studio not supporting C99 or Firefox not supporting certain HTML 5 features.
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 12:30:03 UTC, unDEFER wrote: On Wednesday, 28 December 2016 at 11:32:09 UTC, Nemanja Boric wrote: My other guess is that you're using D threads in your application? Of course I'm using D threads, but with it all is normally. Right, nothing wrong with threads, but super tricky to combine it with fork. So, it could be that one of your threads is using GC at the point of the forking, so it keeps the GC locked. Now you fork, and _all your threads don't exist anymore, they are vanished, and if you don't do some clever stuff in atfork handler, there will be no cleanup_ - you just have copy of the thread that called fork. So, the thread that should release GC lock doesn't exist anymore, and there's nothing to release mutex, and it will stay locked forever in your forked process.
Re: D future ...
On Wednesday, 28 December 2016 at 12:03:53 UTC, YAHB wrote: Making header files manually is a wast of time what i don't have. Write your own header generator. Yes, why not to write my own language. Pfff...too hard to use an AST visitor. And that wants to release a commercial IDE. Compiler design is not my business. Personally I don't get the point of writing an IDE if at a time or another you don't start working a bit around you know...D syntax, D grammar. Actually, I written an OS in D. True...an Outrageous Scam... So funny... https://github.com/Rikarin/Trinix Instead you seem to get stuck on first issue related to the language. First issue? Developers of LDC can respond and fix issue in a real time but developers of D frontend not. And that's the thing what pissed me off. But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. Then you could license the sources, simply. No, thanks. Just think to your strategy and try to be wise. Even Qt sources are available. There's at least 10 ways to waste a freelance commercial project. Qt is out of dated crap mostly useless for fast GUI development. Anyway, it's my project and I don't want to release source codes. No, it's not a freelance project, I got some money for dev and I already have clients waiting for stable release. There will be info soon. Personally I've been client of a commercial GUI framework, and we get the sources with the license. It worked, I mean that the developer had clients. I don't need to follow same rules as others do.
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 11:32:09 UTC, Nemanja Boric wrote: My other guess is that you're using D threads in your application? Of course I'm using D threads, but with it all is normally.
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 11:30:22 UTC, Nemanja Boric wrote: What you should do is following: 1. Allocate all needed data, convert all D strings into C strings, etc. 2. fork 3. exec immediately, not using anything from standard library between 2 and 3. OK, thank you.. I'm trying it and still haven't hanging.
Re: D future ...
On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. you'll be in front of another issue then: "dmd_personality"... unless you release the static library for DMD, LDC, GDC, + each version for each, basically debug + release...so already 6 ;]
Re: D future ...
On Wednesday, 28 December 2016 at 11:36:33 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: Making header files manually is a wast of time what i don't have. Write your own header generator. Yes, why not to write my own language. Pfff...too hard to use an AST visitor. And that wants to release a commercial IDE. Personally I don't get the point of writing an IDE if at a time or another you don't start working a bit around you know...D syntax, D grammar. Actually, I written an OS in D. True...an Outrageous Scam... Instead you seem to get stuck on first issue related to the language. First issue? Developers of LDC can respond and fix issue in a real time but developers of D frontend not. And that's the thing what pissed me off. But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. Then you could license the sources, simply. No, thanks. Just think to your strategy and try to be wise. Even Qt sources are available. There's at least 10 ways to waste a freelance commercial project. Personally I've been client of a commercial GUI framework, and we get the sources with the license. It worked, I mean that the developer had clients.
Re: D future ...
On Wednesday, 28 December 2016 at 11:18:10 UTC, YAHB wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: Making header files manually is a wast of time what i don't have. Write your own header generator. Yes, why not to write my own language. Personally I don't get the point of writing an IDE if at a time or another you don't start working a bit around you know...D syntax, D grammar. Actually, I written an OS in D. Instead you seem to get stuck on first issue related to the language. First issue? Developers of LDC can respond and fix issue in a real time but developers of D frontend not. And that's the thing what pissed me off. But what's the real issue ? You want to release a pre-compiled static library with headers ? Yes. Then you could license the sources, simply. No, thanks. Personally I've been client of a commercial GUI framework, and we get the sources with the license. It worked, I mean that the developer had clients.
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 11:30:22 UTC, Nemanja Boric wrote: On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric wrote: On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote: [...] Just a note here, string literals are already 0 terminated, so you don't need `toStringz` there. Ah, I just saw Stefan already made this remark, sorry. Given that you're in a forked process, it could be that you've just got your GC in a broken state (internal was locked prior to forking, and now you can't get the GC ever, since there's nothing to unlock it. What you should do is following: 1. Allocate all needed data, convert all D strings into C strings, etc. 2. fork 3. exec immediately, not using anything from standard library between 2 and 3. My other guess is that you're using D threads in your application?
Re: Hangs on toStringZ()
On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric
wrote:
On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
Hello I have very simple line with exec-command:
execl("/bin/bash".toStringz(), "/bin/bash".toStringz(),
"-c".toStringz(), command.toStringz(), null);
[...]
Just a note here, string literals are already 0 terminated, so
you don't need `toStringz` there.
Ah, I just saw Stefan already made this remark, sorry.
Given that you're in a forked process, it could be that you've
just got your GC in a broken state (internal was locked prior to
forking, and now you can't get the GC ever, since there's nothing
to unlock it.
What you should do is following:
1. Allocate all needed data, convert all D strings into C
strings, etc.
2. fork
3. exec immediately, not using anything from standard library
between 2 and 3.
Re: Red Hat's issues in considering the D language
On Thursday, 22 December 2016 at 08:33:55 UTC, Daniel Kozák wrote: ? I am on fedora and I have dmd, so it is not true :P Dejan Lekic via Digitalmars-d napsal St, pro 21, 2016 v 6∶36 : On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway! What I meant is that LDC is the only D compiler in the official Fedora/CentOS repositories.
Re: Hangs on toStringZ()
On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
Hello I have very simple line with exec-command:
execl("/bin/bash".toStringz(), "/bin/bash".toStringz(),
"-c".toStringz(), command.toStringz(), null);
[...]
Just a note here, string literals are already 0 terminated, so
you don't need `toStringz` there.
Re: D future ...
On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: On Wednesday, 28 December 2016 at 10:52:45 UTC, Satoshi wrote: Making header files manually is a wast of time what i don't have. Write your own header generator. Personally I don't get the point of writing an IDE if at a time or another you don't start working a bit around you know...D syntax, D grammar. Instead you seem to get stuck on first issue related to the language. But what's the real issue ? You want to release a pre-compiled static library with headers ? Then you could license the sources, simply. Personally I've been client of a commercial GUI framework, and we get the sources with the license. It worked, I mean that the developer had clients.
Re: D future ...
On Wednesday, 28 December 2016 at 09:37:06 UTC, Jerry wrote: Personally I'm not really looking for an IDE, I've settled for a text editor with a plugin for it. IDEs tend to be bulky and not be very good at manipulating text or rather lacking features to do so. It depends on specific IDE. I don't see how the interface generator is stopping you from releasing the IDE anyways. It's GUI framework (set of libraries) what I cannot release. IDE is without the libs quite useless. All it would really stop is potentially third party plugins. Even then you can just write the interface files yourself. Wouldn't be that hard, just coping the source file and removing function bodies for the most part. What you'd need to do if you were writing C++ code, but you would keep the header and source files in sync as you were developing. Wouldn't be that hard but the project have 200k lines of code. Making header files manually is a wast of time what i don't have. But the point is that D compiler specification[1] looks like this part works without a problem and is usable but it's a lie and nobody cares about it. Actually it will not ruin my project but complicates it. And this is not the way in which should business be made. 10 years of development and still some key features won't work properly. [1] https://dlang.org/dmd-osx.html#interface-files
Re: D future ...
On Wednesday, 28 December 2016 at 08:35:52 UTC, Satoshi wrote: I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. But nobody cares about fixing it because it doesn't give any benefits in opensource way to D or what. I don't know how there can be any others closed source/commercial libraries for D when the one of the key features won't work. Actually I wasted one and half year of developing project that I cannot release due to the bug. When I started I didn't even know that future existence of my project can depend on the compiler itself. Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590 Personally I'm not really looking for an IDE, I've settled for a text editor with a plugin for it. IDEs tend to be bulky and not be very good at manipulating text or rather lacking features to do so. I don't see how the interface generator is stopping you from releasing the IDE anyways. All it would really stop is potentially third party plugins. Even then you can just write the interface files yourself. Wouldn't be that hard, just coping the source file and removing function bodies for the most part. What you'd need to do if you were writing C++ code, but you would keep the header and source files in sync as you were developing.
Re: D future ...
On Wednesday, 28 December 2016 at 03:21:03 UTC, Jerry wrote: On Tuesday, 27 December 2016 at 16:36:10 UTC, Laeeth Isharc wrote: On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: So if you want to improve the language and its ecosystem, the best way is to contribute pull requests or $$$s - the Foundation now accepts individual donations, and it's also open to corporate sponsorship, I believe. Editor support: Sublime text and sometimes vim work well enough for me, though these things are very personal. For the others, have you contributed anything - time or money in making them better? If wishes were horses, beggars would ride. And contribution of either has a higher value than just the thing itself, because it also tends to energise the project - look at the frustration Basil experienced regarding his IDE project. It's good to have high standards, but one should have some appreciation also for the gift that people make of their time, work, and energy in ways that don't always lead to the gratitude that one might expect. There's only so much time and money someone can give. It isn't that appealing when virtually no other language out there suffers from this problem cause they have an actual market behind them. Those markets fuel money being poured into the tools of the lanugage. It doesn't really matter how many users you have, it depends on the demographic of those users. If they are all students still in school, then you haven't really created a market. Anyways most of the IDEs out there are made by a small team or only one person. Not only that but they almost all (if not all) rely on the same projects to get the features you would expect in an IDE. The DCD, DScanner, DFix, DFmt etc... All those tools also seem to be developed primarily by the same single person. Rust seems to be in a similar situation but at least it seems the rust team has plans for adding IDE support into the compiler itself. Something that is probably unrealistic for D. Seb posted a massive list of modules that can be standard candidates. And the response is more or less ignore it. People who work on Standard libraries are more motivated. Bring them into the fold. But it seems that they simple get ignored. Rome wasn't built in a year. Great things are achieved by taking baby steps, compounded over time. And if one does what little one can, others are inspired by it. Enthusiasm and a constructive attitude are infectious in my experience. D isn't a year old though. If the steps you take are too small, you can also end up being left behind. I'm working on a commercial IDE and GUI framework for a year and half and I'm not able to release any version due to this bug[1]. But nobody cares about fixing it because it doesn't give any benefits in opensource way to D or what. I don't know how there can be any others closed source/commercial libraries for D when the one of the key features won't work. Actually I wasted one and half year of developing project that I cannot release due to the bug. When I started I didn't even know that future existence of my project can depend on the compiler itself. Please, stop adding new features to D and start fixing existing ones. - Satoshi --- [1] https://issues.dlang.org/show_bug.cgi?id=16590
