On Thursday, 13 February 2014 at 17:12:47 UTC, Sean Kelly wrote:
> For learning to program, I almost feel like getting a sandbox set up on the web would be better. The MIT project Scratch, for example, is fantastic for teaching programming. Unless you're talking about teaching in locations without internet connectivity, which is an entirely different problem.

That is what I was thinking, I feel like a little while ago someone posted a link to an online D compiler and IDE (maybe it was in cloud9), but I can't find it now and I remember it not being complete(maybe it only had highlighting and no compile or something like that... don't really remember).

Am Mon, 10 Feb 2014 18:11:37 +0000
schrieb "Steve Teale" <steve.teale@britseyeview.com>:

> What can be done to capture the attention of young people in the developing world?
> 
> Probably the most effective thing would be if it were possible to edit, compile, and run D programs on a cheap Android ARM phone.
> 
> Is this within the bounds of possibility?
> 
> There are millions of unemployed, bored, restless, and ambitious young men out there, who have saved their all to buy a cheap smartphone.
> 
> Any other ideas?
> 
> Steve

How did you get started?

My first language had these properties:

- it was pre-installed on my PC
- it was powering a game I played
- it was dead simple with good error detection
- I/O, audio, graphics was part of the language

It was QBasic on MS-DOS. Later with Windows 3.1 I switched to Delphi. The feature set and my usage patterns grew:

- the basic DOS graphics got replaced with window backdrops
  and "bitmap buttons", sound was provided with
  SndPlaySound("some.wav").
- The internet became a new I/O source and I queried a forum
  for new posts, a server for new Counter-Strike maps etc.

During this transition me and a friend from school tried stuff for fun, like exchanging disks with encoded messages that could be opened with our "secret network" software, for which we split up the work. The motivation was still much about making it look and sound cool and surpassing each other with fancy ideas and proving that they could be implemented.

I only came to D after I switched to Linux and dropped Delphi. By that time I wrote server code in Delphi and Java professionally and fancy graphics was no longer a priority.

I don't think D fills the QBasic niche quite so well and to be in the Delphi spot requires a much more ready to use environment with everything included. And by that I mean VisualBasic/C#/Delphi like IDE with accessible help, GUI builder, graphics and sound. (Which is much easier if your only target is Win32 :p)

-- 
Marco

Am Mon, 10 Feb 2014 23:06:51 -0800
schrieb "Adam Wilson" <flyboynw@gmail.com>:

> > I don't understand this at all.  We wouldn't stop shipping phobos with the compiler, it would just be in the format of a dub repo/several dub repos instead of it's own thing.
> >
> 
> I suppose as long as it's available by default that's OK.

Using dub is one way that works for one group of people.

For me the ideal situation that I strive to achieve is that it
is dead simple to install any D application using the Linux
package manager.
Thereby it should not matter if the app is 32-bit only, only
compiles with GDC or must use a static Phobos lib opposed to
the shared one. The package manager pulls in the correct
Phobos dependency in the required version and keeps track of
the installed files for a later uninstall when they are no
longer needed. Just as it works for any other popular Linux
app.

Then again if all you need is a quick setup for playing with DMD and external libraries in your home directory, dub is ideal.

-- 
Marco

On 12/02/2014 13:35, Daniel Murphy wrote:
> "Bruno Medeiros"  wrote in message news:ldfpa7$27s3$1@digitalmars.com...
>
>> There is not a chance in hell DMD would sucessfully be adapted for
>> these purposes. Maybe as fork, but not as the main stream. Even as a
>> fork I hardly see it happening (The Descent IDE went with this route
>> but it the semantic engine was buggy and quickly became very hard to
>> maintain.) The reasons are manyfold and I'm not going into detail, but
>> suffice to say a semantic engine for an IDE needs to be prepared to
>> run in an interactive/deamon mode to have a decent performance, not in
>> batch (run once) mode like a compiler. This adds several constraints
>> and requirements to the semantic engine architecture, something that
>> DMD is not prepared to. It would take a large engineering effort to
>> adapt it to that, and crucially, Walter would have to be involved, but
>> he has his hands full already.
>

Well, I need to revise my statements because, upon further thought, I dont find them entirely accurate.
I was thinking of the use case of making DMD an interactive semantic engine deamon, which I still think would take a miracle to get there (whilst at the same time having a decent measure of quality, that is).

But I understand now your idea is different, you just want to expose the current compiler functionality as a *library*, and let other users/programs use it as they see fit, correct? A deamon engine could then be built on top (or the compiler library embedded directly in IDE/tool code), but that would be a task for someone else.

Now, that goal (compiler as library) I do believe to be feasible, but still incredible hard (again, if you want to have something of quality that is). For example, the compiler library functionality needs to be prepared to be re-used within the same session. This means you need to do proper memory management, you can't just allocate blindly and assume its fine because the code is running under a compiler program which will then terminate once it's run once. From what I've heard some time ago, DMD code does nearly no memory management. Maybe this has changed in the meanwhile and the situation improved drastically (or a D port would bring in the GC and deal with this problem that way - but then we'd need the D port for that).
There is other minutiae of functionality which is also important (for example, good parser error recovery, with sensible AST and source ranges in the result nodes, etc.)

But anyways, those are secondary points actually. What I think is really crucial, is that we don't have a main-stream compiler in D. When DMD gets ported to D, and the main development of DMD happens there, in the D version, then I'll believe a reasonable compiler-as-library could happen.

> I disagree, this is 'the plan'.  Please, go into detail, I would love to
> find out about any roadblocks I've overlooked now rather than later.

What do you mean, are you going to invest a lot of work on that?

"Bruno Medeiros"  wrote in message news:le2i5p$28g5$1@digitalmars.com...

> [snip]

I know that a lot of work needs to be done before the frontend is ready to be efficiently used as a library, but that doesn't make it impossible.

> But anyways, those are secondary points actually. What I think is really crucial, is that we don't have a main-stream compiler in D. When DMD gets ported to D, and the main development of DMD happens there, in the D version, then I'll believe a reasonable compiler-as-library could happen.

I think you may have missed something!  This is coming in the near future.


I have been working on automatically converting the DMD fronted to D since dconf (and before).  I've produced working compilers on win32, linux32, and linux64, with the other platforms currently lacking only because I don't have a box set up for them.

The only outstanding work for dmd is fixing layout and commenting/formatting issues in the generated source, which I am slowly getting through.

I expect any issues encountered with the other platforms to be minor, and hopefully switching gdc and ldc will be fairly painless too.

I'm hoping 2.066 will be the first D-based dmd release and work on the C++ source will cease immediately after that.

https://github.com/D-Programming-Language/dmd/pull/1980
https://github.com/yebblies/magicport2.git

>  > I disagree, this is 'the plan'.  Please, go into detail, I would love to
>  > find out about any roadblocks I've overlooked now rather than later.
>
> What do you mean, are you going to invest a lot of work on that?

I already have!

"git log --merges | grep "\[DDMD\]" | wc -l" shows 217 merged pull requests tagged as DDMD, and there were quite a few before I started tagging them.

Converting to D is the first step to getting compiler-as-a-library from dmd. 

On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:
> On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:
clip
>>
>> Steve
>
> A D compiler that targets JVM or Dalvik directly is my personal dream...

I have no idea how hard this would be, but since D has a front-end to the GNU compiler collection GDC, and the GNU compiler collection has a backend (presumably) that generated Java byte-code, would it be possible to use the GDC front end and GCJ backend to do D -> JVM?

On 19 February 2014 16:03, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
> "Bruno Medeiros"  wrote in message news:le2i5p$28g5$1@digitalmars.com...
>
>> [snip]
>
>
> I know that a lot of work needs to be done before the frontend is ready to be efficiently used as a library, but that doesn't make it impossible.
>
>
>> But anyways, those are secondary points actually. What I think is really crucial, is that we don't have a main-stream compiler in D. When DMD gets ported to D, and the main development of DMD happens there, in the D version, then I'll believe a reasonable compiler-as-library could happen.
>
>
> I think you may have missed something!  This is coming in the near future.
>
>
> I have been working on automatically converting the DMD fronted to D since dconf (and before).  I've produced working compilers on win32, linux32, and linux64, with the other platforms currently lacking only because I don't have a box set up for them.
>
> The only outstanding work for dmd is fixing layout and commenting/formatting issues in the generated source, which I am slowly getting through.
>
> I expect any issues encountered with the other platforms to be minor, and hopefully switching gdc and ldc will be fairly painless too.
>

Once you get past the 6 months spent re-writing 70% of the existing gdc and ldc glue code. ;)

On Wednesday, 19 February 2014 at 17:22:37 UTC, Iain Buclaw wrote:
>> I expect any issues encountered with the other platforms to be minor, and
>> hopefully switching gdc and ldc will be fairly painless too.
>>
>
> Once you get past the 6 months spent re-writing 70% of the existing
> gdc and ldc glue code. ;)

Iain, there are two groups of programmers. One says "That should be quite straightforward." The other says "That sounds like a lot of work."

My experience in the software industry suggests that it is usually the latter group that gets the job done!

Steve

On 19 February 2014 17:16, Craig Dillabaugh <cdillaba@cg.scs.carleton.ca> wrote:
> On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:
>>
>> On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:
>
> clip
>
>>>
>>> Steve
>>
>>
>> A D compiler that targets JVM or Dalvik directly is my personal dream...
>
>
> I have no idea how hard this would be, but since D has a front-end to the GNU compiler collection GDC, and the GNU compiler collection has a backend (presumably) that generated Java byte-code, would it be possible to use the GDC front end and GCJ backend to do D -> JVM?

Ah, no. That is not the case.  GCJ is a native Java compiler.  No bytecode going on here...

There is JNI support in g++ -> gcj.  It's just a question of whether or not we want to add this to gdc (would involve changes to the dfrontend).

On 19/02/2014 16:03, Daniel Murphy wrote:
> "Bruno Medeiros"  wrote in message news:le2i5p$28g5$1@digitalmars.com...
>
>> [snip]
>
> I know that a lot of work needs to be done before the frontend is ready
> to be efficiently used as a library, but that doesn't make it impossible.
>
>> But anyways, those are secondary points actually. What I think is
>> really crucial, is that we don't have a main-stream compiler in D.
>> When DMD gets ported to D, and the main development of DMD happens
>> there, in the D version, then I'll believe a reasonable
>> compiler-as-library could happen.
>
> I think you may have missed something!  This is coming in the near future.
>
>
> I have been working on automatically converting the DMD fronted to D
> since dconf (and before).  I've produced working compilers on win32,
> linux32, and linux64, with the other platforms currently lacking only
> because I don't have a box set up for them.
>
> The only outstanding work for dmd is fixing layout and
> commenting/formatting issues in the generated source, which I am slowly
> getting through.
>
> I expect any issues encountered with the other platforms to be minor,
> and hopefully switching gdc and ldc will be fairly painless too.
>
> I'm hoping 2.066 will be the first D-based dmd release and work on the
> C++ source will cease immediately after that.

I'm glad to hear that, that sounds very promising. Especially since dogfooding the compiler has great importance that goes beyond just the compiler-as-a-library goal.

I think DMD will get there eventually, but... you think it will come as soon as the DMD 2.066 release already?? As in, the official DMD, not a fork. Walter and Andrei have said they are on board with that?

Also, Ian raises a good point, what will happen to GDC and LDC once that switch happens? They are both very important projects to be left hanging in the rain.
-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros