January 04, 2018
On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
> On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto wrote:
>> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim Grøstad wrote:
>>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins wrote:
>>>> [...]
>>
>> I perceived that there was a lot of hype around Python 15 years ago or so. Now, universities are replacing Java with Python as the introduction language and Python is also becoming the defacto language for scientific programming. Python is basically getting critical mass and is now managing to take on Matlab and perhaps  to some extent even C++/Fortran.
>
> Python has done well in those niches, but when is the last time you saw a popular GUI app written in Python?  That is the largest segment of the market, and Python has basically no uptake there.  Even Java got nowhere in the consumer GUI market, other than a few p2p apps like Vuze and the now-defunct Limewire, largely for piracy.
>

you could not be more wrong. there are tons of python gui applications. pygtk, pyqt and wxpython are great libraries that allows you to create desktop apps very easy and fast. D does not even have a good solution except for gtkD which is a one man show. if it wasn't for Mike we would not even have it. leadership does not care. remember qtd guys stopping everything because a bug was not getting fixed?

there's also one other thing: atom, vs code, spotify, slack are all running on electron. does it make it a better platform than python?
January 04, 2018
On Thursday, 4 January 2018 at 13:07:37 UTC, Mengu wrote:
> there's also one other thing: atom, vs code, spotify, slack are all running on electron. does it make it a better platform than python?

I found this example of using electron with Python:
https://github.com/keybraker/electron-GUI-for-python

Could probably use the same model for any language.


January 04, 2018
On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
> While the Orgs using D page is very nice ... I hoping to hear more personal stories ...
>
> So
>
> How do you use D?
> In work, (key projects or smaller side projects)
> in your side project, (github, links please)
> just to learn something new? (I would easily argue that learning D will make you a better C++ programmer, maybe not the most efficient way, but I a sure it i very effective)
>
> Did you introduce D to your work place? How? What challenges did you face?
>
> What is you D setup at work, which compiler, which IDE?
>
> And any other fun facts you may want to share :)

I am working for a german software company. There are various programming languages used.
I created several non customer facing tools in D for the projects I am involved.
Also I tried to make advertisements for the D Programming Language by creating
internal wiki pages, recordings, video channel with screencams and telling everyone
about that nice programming language called D.

To be able to write customer facing software in D I have to integrate the D
programming language into the existing build landscape (Jenkins/XMake). It was possible to
integrate D but there are rough edges.

Before I start I want to say a big thank you to Sönke and everyone involved
in the Dub project. Without Dub, the usage of D would not be possible at all!

1) There is a deprecated "version" attribute in dub.json. Dub now forces you to
specify the application version using git tags. As the build landscape itself creates git tags
which aren't Semver compatible, the deprecation of the "version" attribute is a great pain for me.
I solved the problem by "inventing" an own way to specify a version (version.txt file), which is a bad solution.
https://github.com/dlang/dub/issues/1301

2) During the official build no connection to the internet is allowed (e.g. code.dlang.org).
For the moment I have no possibility to run an inhouse dub repository.
This forces me to include source code of the dub packages I want to use, in my applications.

The company is running a big Maven repository in which I could store the dub packages
as zip files and which has http access to these artefacts. I would like to specify in my dub.json the url address to the zip file stored in the maven repository.
https://github.com/dlang/dub/issues/1134

3) It is not possible to run DMD with the microsoft linker and libs without adapting the sc.ini.
That is a pain! In the build infrastructure I can only use the dmd zip archive and not
the setup routine. Also the adapation of the sc.ini I need to automate in a python script (XMake build plugin).
Python does not like the sc.ini... due to duplicate keys...

Just compare with LDC windows 64. You only have to extract the zip archive, call vcvarsall batch
file which sets the environment variables and thats it!
https://issues.dlang.org/show_bug.cgi?id=17967

4) Every open source software I want to use, needs to go through an open source process before I can use it in customer facing software. Dub has a very annoying behavior. If I want to use a package A and it has an optional dependency to be package B, Dub fails if B is not available. That leads to the issue that even I do not want to use B, I need to go through the open source process for B due to the behavior of Dub.
I had this issue with the unit test frame work D-Unit. Fortunatelly the developer of D-Unit was kind and removed the optional dependency completely!
https://github.com/dlang/dub/issues/1272

I have also to say a big thank you to Adam D. Ruppe. He has created a great library with very helpful functionality like database access, http server, terminal, ...
and he is a very helpful and kind person.

My hobby project is to create a bridge between the Embarcadero RAD Studion (Delphi) and D.
The idea is to use all functionality from Delphi and RAD Studio (GUI designer, thousands of libraries) without writing one 1 line Pascal but write everything in D. At the moment I have already a windows demo application running, but I hope I can extend it to MacOS/Android/IPhone...
https://github.com/andre2007/delta-core-10-2-1
The package you see on github is written by hand. At the moment I am writing a Pascal Parser to
have everything generated by the Pascal Source files (VCL/Firemonkey/Indy/...) automatically.

Kind regards
André
January 05, 2018
On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote:
> On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
>> [...]
>
> I am working for a german software company. There are various programming languages used.
> I created several non customer facing tools in D for the projects I am involved.
> Also I tried to make advertisements for the D Programming Language by creating
> internal wiki pages, recordings, video channel with screencams and telling everyone
> about that nice programming language called D.
>
> [...]

Very interesting. Have a look at pegged and the work done by Bastian who has also been building a pascal parser - for a different dialect.
January 05, 2018
On Wednesday, 3 January 2018 at 17:50:01 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> These languages may all have these problems, but I don't see the connection to your original point about it not being good to think you're the best.
>
> Hm?  I tried to say that it is not good to think that you have the best programmers. Or that you are satisfied with only appealing to the best programmers.

Yes, but when I pointed out that it's fine to think you're the best as long as you stay focused on bettering the flaws you still have, you responded with points about memory management and how C++ can't be a "competitive high level language," seemingly ignoring the topic at hand.  Good to see you address it below.

> There are some assumptions about "best" in that attitude that isn't healthy for developing an ecosystem.  First of all, it might not be true, maybe the best programmers go elsewhere.  Second of all, programmers generally don't start out as "best".
>  And only appealing to experience programmers is not a good long term strategy.

Thinking you're the best doesn't imply that inexperienced programmers shouldn't show up, it just means they better think they have the ability to someday be similarly good. ;) And when you're smaller and trying to take on older languages with many more users, you need some identity to rally your much smaller group of insurgents: thinking you're the best is as good a rallying cry as any other.

Finally, D is hardly pitched as an "expert-only" language, given it makes pragmatic choices to use a GC by default and carry forward the popular C syntax.  It simply provides many more power tools that you can use, if you're so inclined to go farther and learn more.

> Anyway, you probably have a lot more great programmers using Javascript than any small language, measured in absolute numbers. And when growing a eco system it is those absolute numbers that matters. It doesn't matter if 99% are not good if the other 1% can grow your infrastructure. And well, right now that means developers can be very productive in that eco system (e.g. TypeScript, Angular, React etc).

What would be better, a million JS programmers with 10k great ones who "grow your infrastructure," or 150k D programmers with 30k great ones doing the same?  Holding everything else equivalent proportionally, I'd say the latter.  Of course, a very important factor could be how willing the million is to pay for better tools, as that will lead to great tools programmers from less-popular languages to swarm into JS for the money, but given how much of the time all these dev tools are free, particularly for JS, that doesn't matter as much.

Another huge factor is that you are fundamentally limited by the language, it doesn't matter how many great devs work on speeding up a fundamentally slow and inefficient language design, which a core team of great programmers wouldn't have put out there in the first place. :P

>> More programmers don't have a bachelors in CS than those who do.  I think you'll find the percentage who regularly use multiple languages is fairly low, let alone evaluating each one for each job.
>
> I think it depends on what type of developement we are talking about. But I see a lot of fuzz about fullstack developers. Not sure if that fuzz translates into something at scale, but "full-stack" is at least something that is mentioned frequently.

It's a high percentage without CS bachelors in most subfields of programming.  As for "full stack," a meaningless term which I bet actually has less CS bachelors than the percentage I gave. ;)

>>> Anyway, it is my impression that many C/C++ programmers also know Python and also have a good understanding of basic functional programming.
>>
>> So two tools in the toolbox is enough?
>
> Not sure what you mean by that. I meant to say that my impression is that most C/C++ programmers need a higher level language and also are capable of using other paradigms than what C/C++ encourages. Despite C++ being able to express a lot of the same things and also despite C++ being a language where you never really reach a full deep understanding of the language.

It's pretty simple what I mean: you were responding to my point that most don't really pick the best tool for the job, but have a single language that they try to hammer every nail with.  Saying that most C++ programmers also use python implies that having two tools that you choose from is enough.  In that case, you're basically agreeing with me, despite your previous statements otherwise, as I was saying we can't expect most programmers to learn more than one tool, ie a single language.

>> Your company is much more likely to bring in somebody with Java experience to write the Android portion.
>
> Mostly because of the iOS/Android frameworks, not really because of the languages.

That's why I included such knowledge of the needed frameworks in knowing a language platform earlier, as realistically it can be as important to getting the job done.

> Or rather, the Java language shouldn't be the stumbling block, but both of iOS and Android are rather bloated frameworks that takes time getting into. Which I think it is intentional. Both Apple and Google want developers to be dedicated experts on their platform and seems to deliberately go for changes that prevent cross platform tooling.

Could be, but that changes nothing about the reality that most programmers are just going to pick one language and some set of frameworks that are commonly used with it.

>> It is unrealistic to expect the vast majority of programmers to do any more than use one language most of the time.
>
> I don't know. Depends on what kind of development we are talking about.

That is the current reality, it doesn't matter what hypothetical kind of development you have in mind.

>> This actually argues for a single language: you're going to spend a ton of time tracking all those shifting frameworks so you won't have time for a new language too, but at least you won't have to learn a new language every time you pick up the new js framework of the day.
>
> I think there is another way, but it isn't available yet.
>
> Program transliteration and software synthesis should over time be able to offset some of these issues.
>
> Most imperative languages are fairly similar.  Most of the code we write, whether it is in Python, C+ or D would have a fairly similar structure.  In some sections you get something very different, but I don't think that is dominating.

Yes, that is part of the plan with betterC, to make it easy to translate C code to D.

>> The ongoing churn may help new languages with new users and companies, don't think it helps with users who already know a language well.
>
> I don't know. Seems that many in these forums have done work in Java, Go, Python, Rust and C++.

D users are the exception that prove the rule, the much larger majority not using D because they're already entrenched in their language.  That's because, unlike Go, D offers many more features than other languages, so it particularly appeals to such advanced users from other languages.

>> Seems like an oxymoron, tech changes so fast that I don't see how anything could be timeless, even if you really mean "will still be the same 20 years from now." ;)
>
> Right, but digital computing is a relatively new invention (and well, even electricity is relatively new ;-).  Over time one would think that something "timeless" would establish itself. But for now we can just say "stable".
>
> There clearly are some frameworks that have been relatively stable. Like matlab. I think that is because matlab has tried to closely model the domain that scientists have been trained in (linear algebra). But it is interesting that Python is making inroads there. That matlab is now perceived as not having good enough abstraction mechanisms, perhaps.
>
> On the other hand, the mathematical field of logic is also relatively new as it is conceptualized today, and some people are exploring paradigms such as probabilistic programming languages and what not… So right, "timeless" is not realistic at the moment as the basic foundation is still quite new and we are still learning how to make computers reason about first order logic… (building automatic theorem provers).

I don't think such stability will ever happen, because unlike electricity distribution or other older tech, software is infinitely malleable.  We're always going to keep stretching and twisting it in new ways, as we get more used to its plasticity.  We will do a better job of securing and developing it, but we're always going to keep changing it.

>> There's always new stuff other than that, eg more limited mobile hardware over the last decade has returned the tech market to earlier times, and native languages like Obj-C and Swift have benefited.
>
> Yeah, as you have pointed out many times, mobile CPUs are quickly catching up at the high end and also to some extent on the middle-end. What remains to be seen is how the mass-market low end picks up.  I think companies like Motorola is pushing the curve at the low/middle phone market as Samsung and Apple have taken the high end.

Sure, so you _could_ now run python on those newly powerful mobile CPUs, but Objective-C and Swift have used that decade when you _couldn't_ to entrench themselves in that market.  And as I've pointed out to you before, they're still much more efficient, so until battery tech get much better, you're going to want to stick with those natively-compiled languages.

>> Python has done well in those niches, but when is the last time you saw a popular GUI app written in Python?
>
> Many applications use Python (or Lua or Java or even Visual Basic) to tie the pieces together, including the GUI, but they use engines written in other languages for interfacing with the OS.

Which of those python-glued GUI apps has become popular?  That was the question: I can find toy apps in any language, that nobody uses.

>> Even Java got nowhere in the consumer GUI market, other than a few p2p apps like Vuze and the now-defunct Limewire, largely for piracy.
>
> JetBrain's products?

I wouldn't call developer tools consumer apps, as they're used by developers to do their job, so that doesn't really qualify.  I should also note that I meant consumer desktop GUI apps, as obviously Java does well on mobile, when it was made the default application language for Android, though they've paid the price for its inefficiency and lag and had to AoT-compile it starting with Lollipop.

>> While that market may be important to you, it is a small segment of the programming market.  It's nice that D libraries like Mir are targeting it, but it's not going to move the needle much.
>
> Mmm… it is a small segment of the revenue-based market, because scientific programmers are often the scientists themselves (no it is not important to me at the moment).  It is a fairly large segment though of the overall market. As it includes a lot of engineering. Just because those programs aren't sold, either because they are in-house, personal or with a very narrow user base (like researchers) doesn't mean that these programs are less important.

I don't think it's a large percentage of programmers or programs either, leaving aside revenue.  It used to be a significant chunk decades ago, but I believe it has dwindled to a small percentage as computing has spread everywhere else.

>> You may not even know that's because of generic programming, you just like all the great libraries.  IOW, you may think you don't need generic programming, but the libraries you do need do need it.
>
> That's right, but you need critical mass for it to matter.

I've given you an estimate of D users, you haven't said why that hasn't passed your critical mass threshold.

> Otherwise people will just use somewhat slower or somewhat more clunky libraries.  Go, Python and JavaScript are doing fine… without proper generics.

As I noted in an earlier thread in this forum, I can build a bike in a couple hours and get going faster out of the gate up to a top speed of 30 km/h.  However, the guy building his own car will take longer but eventually zoom by me at 150 km/h.

Those languages got farther earlier, but that's no guarantee they win the race.

On Thursday, 4 January 2018 at 07:51:56 UTC, Paulo Pinto wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto wrote:
>>> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>>>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim Grøstad wrote:
>>>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins wrote:
>>>>> [...]
>>>>
>>>>> Good programmers aren't stuck on any single language and will pick the tool best suited for the job at hand.  Good programmers are also good at picking up new languages.
>>>>
>>>> And who do you know who does this?  While I myself have espoused the idea of the best tool for the job in this forum, realistically, other than a small handful of coders, when does that ever happen?
>>>> [...]
>>>
>>> Everyone at my employer, a few thousand of them doing enterprise consulting.
>>>
>>> We specialize in a few large domains, and tend to jump between them every 6 months or a year, when switching projects.
>>>
>>> On my case, full stack development across JVM and .NET languages, with C++ for low level coding.
>>
>> How many of those few thousand are actually comfortable with C++ for low-level coding?  I think you've said before that it's not many. So okay, your colleagues switch between Java and C#, which is somewhat uncommon as many places are pure C# or Java shops, but those are the two most popular enterprise application languages, noted for their similarities.
>>
>> You can hardly use this as an example of having a toolbox of languages and picking the best for the job, say Erlang for some high-concurrency microservice or ruby for an app you need to get up and running quickly.  You're just using two of the most popular business languages and deciding which based on what the customer wants.
>>
>
> Not all of them of them are comfortable with C++, that is true.
>
> But they are comfortable with other languages, which I am not.
>
> Notice that "JVM and .NET languages, with C++ for low level coding." was my own skillset, not everyone at the company.
>
> Also I said JVM and .NET languages, not Java and C#. If you want me to be more precise, Java, Clojure, C#, F#, VB.NET and now getting into Kotlin due to future Android projects.
>
> I also do JavaScript, PL/SQL, pgSQL on occasion, and have helped some iOS projects when an extra helping hand is needed and I am low on project requests.
>
> I never like to specialize in any technology stack, it is the best way to outdate myself on a market that is fashion driven.

I suspect you are one of the small handful I mentioned, even in your company, who's comfortable with so many languages.

> Of course there are lots of details I don't master in every programming language, but as Wirth puts it, it is all about mastering CS concepts, algorithms and data structures. Also why Knuth used his own invented Assembly instead of choosing any programming language.
>
> To actually know every detail of programming language, or what its runtime library is capable of, there are books and web sites to get it from.
>
> Soft skills and domain knowledge in each market are more relevant than knowing every single detail of a programming language.

I suspect that is what most at even your company do: focus on a single language, much more of its details, and all those non-CS skills you say are more important.  Which is fine, that has been the natural order of things, a few generalists like you interacting with a bunch of specialists.

On Thursday, 4 January 2018 at 13:07:37 UTC, Mengu wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto wrote:
>>> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>>>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim Grøstad wrote:
>>>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins wrote:
>>>>> [...]
>>>
>>> I perceived that there was a lot of hype around Python 15 years ago or so. Now, universities are replacing Java with Python as the introduction language and Python is also becoming the defacto language for scientific programming. Python is basically getting critical mass and is now managing to take on Matlab and perhaps  to some extent even C++/Fortran.
>>
>> Python has done well in those niches, but when is the last time you saw a popular GUI app written in Python?  That is the largest segment of the market, and Python has basically no uptake there.  Even Java got nowhere in the consumer GUI market, other than a few p2p apps like Vuze and the now-defunct Limewire, largely for piracy.
>>
>
> you could not be more wrong. there are tons of python gui applications. pygtk, pyqt and wxpython are great libraries that allows you to create desktop apps very easy and fast. D does not even have a good solution except for gtkD which is a one man show. if it wasn't for Mike we would not even have it. leadership does not care. remember qtd guys stopping everything because a bug was not getting fixed?

Maybe I am, but you have not named a popular python GUI app like I asked, only some GUI frameworks that could be used to build such an app.  I wasn't saying that you couldn't write a python GUI app, but that it's probably not the best tool for the job.

> there's also one other thing: atom, vs code, spotify, slack are all running on electron. does it make it a better platform than python?

No, because it's still a bad framework, as posts like this show:

https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6

But at least they can show some real-world successes for app usage, even if they perform poorly because of the fundamental limitations of the language.  I don't think python has even gotten that far.
January 05, 2018
On Friday, 5 January 2018 at 11:49:44 UTC, Joakim wrote:
> Yes, but when I pointed out that it's fine to think you're the best as long as you stay focused on bettering the flaws you still have,

I don't think that thinking you're the best brings anything but disadvantages, actually… Except when you are advertising perhaps.


> What would be better, a million JS programmers with 10k great ones who "grow your infrastructure," or 150k D programmers with 30k great ones doing the same?  Holding everything else equivalent proportionally, I'd say the latter.

Well, that is not the scale we are talking about here, but actually the former is the better if it means that you get twice as many that are paid to grow the eco system full time.  If you compare JavaScript with D on that metric you are closer to a 1000:1 ratio or more in JavaScript's favour…  Not a fair comparison, but that's the reality that drives adoption.

When you reach critical mass within a specific domain a lot more people will be doing full-time eco system development… (Facebook, Google, Microsoft + a very large number of smaller companies).

The browser domain is very large, so not a fair comparison, of course.


> speeding up a fundamentally slow and inefficient language design, which a core team of great programmers wouldn't have put out there in the first place. :P

Doesn't really matter in most cases. The proper metric is "sufficient for that task at hand". So, if many people are paid to do full-time eco system development that also means that the tool is sufficient for a large number of use cases…

You can do the same in browsers as people do with Python. Use something else for those parts where speed is paramount: stream from a server, use WebGL or WebAssembly, or use the browser engine cleverly. For instance I've implemented instant text search using CSS for even IE9, the browser engines were tuned for it, so it was fast.

People use the same kind of thinking with C++/D/Rust as well, i.e use the GPU when the CPU is too slow, or use a cluster, or use a database lookup…

Bother computer hardware and the very capable internet connections people have (at least in the west) are changing the equations.

It is easier to think about a single entity like a programming language with a small set of isolated great programmers writing an application that will run on an isolated CPU, but the world is much more complicated now than it used to be in terms of options and the environment for computing.


> of programming.  As for "full stack," a meaningless term which I bet actually has less CS bachelors than the percentage I gave. ;)

I understand "full stack" to mean that you can quickly adapt to doing  database, server, client and GUI development.

> Saying that most C++ programmers also use python implies that having two tools that you choose from is enough.  In that case, you're basically agreeing with me, despite your previous statements otherwise, as I was saying we can't expect most programmers to learn more than one tool, ie a single language.

No.  The programming style for Python is very different from C++.  Just because many C++ programmers also know Python, doesn't mean that they don't benefit from also knowing other languages. I bet many also know JavaScript and basic Lisp.

> Could be, but that changes nothing about the reality that most programmers are just going to pick one language and some set of frameworks that are commonly used with it.

Ok. I personally don't find the standard libraries for Java and C# difficult to pick up as I go.   Google gives very good hits on those.

Application frameworks are more tedious, but they are also more quickly outdated. So you might have to learn or relearn one for a new project anyway.

> That is the current reality, it doesn't matter what hypothetical kind of development you have in mind.

That's not an argument… That is just a unfounded claim.

> D users are the exception that prove the rule, the much larger majority not using D because they're already entrenched in their language.

I don't really think D users are as exceptional as they often claim in these forums…

> when you _couldn't_ to entrench themselves in that market.  And as I've pointed out to you before, they're still much more efficient, so until battery tech get much better, you're going to want to stick with those natively-compiled languages.

Not convinced. I think most people on smartphones spend a lot of time accessing browser-driven displays. Either in the actual browser or as a widget in an app…

It doesn't really matter, because the dominating activity isn't doing heavy things like theorem proving or data-mining…

As long as the code for display rendering is efficient, but that is mostly GPU.

> Which of those python-glued GUI apps has become popular?  That was the question: I can find toy apps in any language, that nobody uses.

That's not right. Scripting is commonly used for the high level layer in productivity applications.

> I've given you an estimate of D users, you haven't said why that hasn't passed your critical mass threshold.

What estimate? Based on what? Using what method?

Does it hold up on Github?

If not, what is the explanation?

January 06, 2018
On Friday, 5 January 2018 at 00:38:05 UTC, Laeeth Isharc wrote:
> On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote:
>> On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
>>> [...]
>>
>> I am working for a german software company. There are various programming languages used.
>> I created several non customer facing tools in D for the projects I am involved.
>> Also I tried to make advertisements for the D Programming Language by creating
>> internal wiki pages, recordings, video channel with screencams and telling everyone
>> about that nice programming language called D.
>>
>> [...]
>
> Very interesting. Have a look at pegged and the work done by Bastian who has also been building a pascal parser - for a different dialect.

Thanks for the info, I try to make my parser easiliy replacable by a better solution like pegged. For the moment I try to get the generator working and cleanup things later. I will also have a look at the work of Bastian.

Kind regards
André
January 06, 2018
On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote:
> On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
>
> 3) It is not possible to run DMD with the microsoft linker and libs without adapting the sc.ini.
> That is a pain! In the build infrastructure I can only use the dmd zip archive and not
> the setup routine. Also the adapation of the sc.ini I need to automate in a python script (XMake build plugin).
> Python does not like the sc.ini... due to duplicate keys...
>
> Just compare with LDC windows 64. You only have to extract the zip archive, call vcvarsall batch
> file which sets the environment variables and thats it!
> https://issues.dlang.org/show_bug.cgi?id=17967
>

It seems with the recent version of DMD (2.078.0) there is new feature which
solves this problem (https://dlang.org/changelog/2.078.0.html#vs-auto-detection)

That's fantastic! Thanks a lot!
I will try it and then close the issue.

Also the new options for customizing the code coverage seems like you heard my wishes
within my mind;)

Great work!

Kind regards
André


January 07, 2018
On Thursday, 4 January 2018 at 15:52:15 UTC, Andre Pany wrote:
> My hobby project is to create a bridge between the Embarcadero RAD Studion (Delphi) and D.
> The idea is to use all functionality from Delphi and RAD Studio (GUI designer, thousands of libraries) without writing one 1 line Pascal but write everything in D. At the moment I have already a windows demo application running, but I hope I can extend it to MacOS/Android/IPhone...
> https://github.com/andre2007/delta-core-10-2-1
> The package you see on github is written by hand. At the moment I am writing a Pascal Parser to
> have everything generated by the Pascal Source files (VCL/Firemonkey/Indy/...) automatically.

Interesting indeed. I am working on putting my transcompiler up on github, but it is still very much a WIP, and will be for a long time.

The Extended Pascal PEG is available already, though: https://github.com/PhilippeSigaud/Pegged/tree/master/pegged/examples/extended_pascal

Bastiaan.
1 2 3 4 5 6 7
Next ›   Last »