January 09, 2014
On Wednesday, 8 January 2014 at 01:27:28 UTC, Walter Bright wrote:
> On 1/6/2014 3:47 AM, Dwhatever wrote:
>> Compared to C/C++, D is very hard to get to work in the embedded/OS less environment because of this.
>
> It's not that hard. Use the -betterC switch to prevent ModuleInfo records and their dependencies from being emitted, and then you can write D code that has zero dependence on druntime or phobos.

-betterC?  That flag isn't even documented.  Though I suggest
renaming it to something that doesn't reference a different
language.  -bare or -minimal or -noemit or something.
January 09, 2014
On Wednesday, 8 January 2014 at 02:54:40 UTC, Mike wrote:
> On Wednesday, 8 January 2014 at 01:27:28 UTC, Walter Bright wrote:
>
>> It's not that hard. Use the -betterC switch to prevent ModuleInfo records and their dependencies from being emitted, and then you can write D code that has zero dependence on druntime or phobos.
>
> As the creator of D and a significant author of the runtime, I think you are taking a lot for granted.  I think from your perpective, it probably isn't all that hard, and certainly as I study D and the runtime, it is becoming significantly easier.  But in comparison with C, Dwhatever is right... it's a bear, but I don't necessarily believe that that's bad.

The runtime contains years of accumulated cruft, and it obviously
biased towards the way DMD works.  I'd personally like to see the
"rt" portion at least get a thorough once-over along the lines of
what you're doing to see if parts can be simplified or discarded,
and to determine whether there are any hidden costs to using
language features.

> Furthtermore, the way the D Runtime is organizized, it's quite difficult to see the abstractions (if there are any). Putting some weight behind this issue (https://d.puremagic.com/issues/show_bug.cgi?id=11666) would certainly help.

We'll have to rely mostly on input from GDC and LDC here.  The
current stdc header design is the one that was the easiest for me
to maintain when I was the sole runtime developer and we were
targeting a handful of platforms.  That's clearly changed, but I
don't know what workflow is ideal for the other compilers.  I do
think we may need to stick with manually written headers though,
as much for copyright reasons as anything.  That said, if the
runtime at least were modified to not use the C library at all,
we may eventually be able to detach it completely.  I think we're
probably already down to a small number of functions (memset,
memcpy, and a few maths routines).

> The origin of this thread was really about a porting guide; an excellent idea!  You can wait several months for me learn D and the runtime and I'll create one, or you and the other D Runtime authors can create one and show us just how easy it is.  A simple wiki post like this (http://wiki.osdev.org/Porting_Newlib) would be an excellent start.

The old wiki pages are here:

http://dsource.org/projects/druntime

Also, this may still be relevant:

http://dsource.org/projects/tango/wiki/ChapterC

The information is pretty sparing, but it should provide a decent
starting point and explain at least a bit of the rationale behind
the current design.  The most notable design change since these
were written is that I decided it's reasonable for all portions
of the runtime to import anything in "core", so the separate
compilation aspect isn't quite as true as it once was.  This also
means that not every extern (C) function defined in, say,
core.exception may actually be needed any more from a design
perspective, though I still very much like having the GC interact
with the thread library via the provided extern (C) thread_*
routines.  I think one could easily argue that if the runtime
ever needs to create a Thread, it should do so via a proxy
function instead of directly instantiating the class to retain
ease of porting D to platforms where threads aren't desired.
January 09, 2014
On 2014-01-09 19:39, Sean Kelly wrote:

> I do think we may need to stick with manually written headers though,
> as much for copyright reasons as anything.

Why not an automatic solution? Why would the copyright matter if it's manually or automatically translated?

> The old wiki pages are here:
>
> http://dsource.org/projects/druntime

Here's a list of runtime hooks:

http://wiki.dlang.org/Runtime_Hooks

-- 
/Jacob Carlborg
January 10, 2014
On Thursday, 9 January 2014 at 20:16:14 UTC, Jacob Carlborg wrote:
> On 2014-01-09 19:39, Sean Kelly wrote:
>
>> I do think we may need to stick with manually written headers though, as much for copyright reasons as anything.
>
> Why not an automatic solution? Why would the copyright matter if it's manually or automatically translated?

Because of this clause from the Boost license page:

"The conceptual interface to a library isn't covered. The
particular representation expressed in the header is covered, as
is the documentation, examples, test programs, and all the other
material that goes with the library. A different implementation
is free to use the same logical interface, however. Interface
issues have been fought out in court several times; ask a lawyer
for details."

I suspect that an automatic translation might be subject to the
"representation" issue, while a manual rewrite should not.
January 10, 2014
On 2014-01-10 01:02, Sean Kelly wrote:

> Because of this clause from the Boost license page:
>
> "The conceptual interface to a library isn't covered. The
> particular representation expressed in the header is covered, as
> is the documentation, examples, test programs, and all the other
> material that goes with the library. A different implementation
> is free to use the same logical interface, however. Interface
> issues have been fought out in court several times; ask a lawyer
> for details."
>
> I suspect that an automatic translation might be subject to the
> "representation" issue, while a manual rewrite should not.

I see, that sucks :(. I guess this is a fine line since you very well could en up with the same result of a manual and automatic translation.

-- 
/Jacob Carlborg
January 10, 2014
On Friday, 10 January 2014 at 00:02:22 UTC, Sean Kelly wrote:
> On Thursday, 9 January 2014 at 20:16:14 UTC, Jacob Carlborg wrote:
>> On 2014-01-09 19:39, Sean Kelly wrote:
>>
>>> I do think we may need to stick with manually written headers though, as much for copyright reasons as anything.
>>
>> Why not an automatic solution? Why would the copyright matter if it's manually or automatically translated?
>
> Because of this clause from the Boost license page:
>
> "The conceptual interface to a library isn't covered. The
> particular representation expressed in the header is covered, as
> is the documentation, examples, test programs, and all the other
> material that goes with the library. A different implementation
> is free to use the same logical interface, however. Interface
> issues have been fought out in court several times; ask a lawyer
> for details."
>
> I suspect that an automatic translation might be subject to the
> "representation" issue, while a manual rewrite should not.

IANAL and I agree that this may be a somewhat legally murky topic, but Android extensively uses automatically translated headers and I don't think it has caused them much of a problem.  Well, other than that whole Java mess with Oracle, ;) which Google won. I count 632 header files in the platform headers that I'm using for Android/x86 that contain the following notice:

 ***   This header was automatically generated from a Linux kernel header
 ***   of the same name, to make information necessary for userspace to
 ***   call into the kernel available to libc.  It contains only constants,
 ***   structures, and macros generated from the original header, and thus,
 ***   contains no copyrightable information.
January 10, 2014
On Friday, 10 January 2014 at 07:32:49 UTC, Jacob Carlborg wrote:
> On 2014-01-10 01:02, Sean Kelly wrote:
>
>> Because of this clause from the Boost license page:
>>
>> "The conceptual interface to a library isn't covered. The
>> particular representation expressed in the header is covered, as
>> is the documentation, examples, test programs, and all the other
>> material that goes with the library. A different implementation
>> is free to use the same logical interface, however. Interface
>> issues have been fought out in court several times; ask a lawyer
>> for details."
>>
>> I suspect that an automatic translation might be subject to the
>> "representation" issue, while a manual rewrite should not.
>
> I see, that sucks :(. I guess this is a fine line since you very well could en up with the same result of a manual and automatic translation.

Yeah, this is also one reason why I chose the header format I
did.  It works directly from the spec and so imposes a structure
of its own rather than inviting direct ports of existing headers.
  But I'm really just guessing here, since I don't have any legal
background.

One issue I'm not sure about regarding automatic translation
(assuming this is deemed acceptable).  Say you're trying to
translate pthread.h on a Posix system.  The declarations for that
file might be required to live in sys/types.h, but in actuality
live in a smattering of files in other locations (usually
bits/whatever) all selected by a pretty complex chain of
preprocessor conditions.  If we were to do an automatic
translation, how would this all work?  One thing I like about the
current approach is that the result is succinct and legible,
despite requiring more work to generate.
January 10, 2014
On 2014-01-10 19:35, Sean Kelly wrote:

> Yeah, this is also one reason why I chose the header format I
> did.  It works directly from the spec and so imposes a structure
> of its own rather than inviting direct ports of existing headers.
>    But I'm really just guessing here, since I don't have any legal
> background.
>
> One issue I'm not sure about regarding automatic translation
> (assuming this is deemed acceptable).  Say you're trying to
> translate pthread.h on a Posix system.  The declarations for that
> file might be required to live in sys/types.h, but in actuality
> live in a smattering of files in other locations (usually
> bits/whatever) all selected by a pretty complex chain of
> preprocessor conditions.  If we were to do an automatic
> translation, how would this all work?  One thing I like about the
> current approach is that the result is succinct and legible,
> despite requiring more work to generate.

Yeah, I know. That's one of my big problems with DStep, what to do about includes. Many types are hidden behind a typdefs to make it cross-platform. The actual type is usually in an internal architecture specific header file.

The advantage would be to have all the declarations automatically translated but then manually put in the correct files. It does not necessarily need to be, run one command and it's all translated. Automatic translation could help even if it's not completely automatic. Just to avoid any manual errors.

-- 
/Jacob Carlborg
1 2 3 4 5 6 7 8
Next ›   Last »