• eles (41/41) Sep 06 2013 I am starting a new thread, since I am afraid that the other one
• Iain Buclaw (18/55) Sep 06 2013 Yep - this is probably the big problem with deprecating volatile
• eles (5/10) Sep 06 2013 Frankly, but each day D becomes better, it becomes worse for
• Iain Buclaw (9/19) Sep 06 2013 It's still systems level, just in user-land applications.
• Dicebot (5/15) Sep 06 2013 Yes, I feel quite the same way and I have almost abandoned any
• Iain Buclaw (41/59) Sep 06 2013 And all I'm saying is that if you want to use it on bare metal then
• eles (17/28) Sep 06 2013 Yes, I know, the kernel provides an almost complete and fully
• Leandro Lucarella (16/49) Sep 06 2013 LDC used to have a --no-runtime switch or something like that, that
• eles (13/37) Sep 06 2013 That's good, but is rather a workaround for a limitation of the
• Iain Buclaw (16/40) Sep 07 2013 And you rephrase that question? I think you asked it wrong. :)
• Ramon (50/50) Sep 06 2013 OK, OK, completely overblown but for the sake of the point: Well,
• eles (18/24) Sep 06 2013 Unfortunately, in this case, it brings to my actual workplace
• Ramon (50/50) Sep 06 2013 eles
• Iain Buclaw (5/12) Sep 07 2013 You can thank GNU for that portable toolchain too... :o)
• Dicebot (13/19) Sep 06 2013 Lot of confusion comes from some earlier times when D was
• Ramon (49/69) Sep 06 2013 I tried to stay positive but you are right. This is a good
• H. S. Teoh (23/29) Sep 06 2013 [...]
• Ramon (36/47) Sep 06 2013 My intention was and is not ranting, nor saying D sucks, nor
• H. S. Teoh (20/44) Sep 07 2013 I did not intend to imply that you were ranting. I was only speaking
• Joseph Rushton Wakeling (11/17) Sep 08 2013 Of course, but many potential users don't have the free time to be able ...
• Dicebot (14/18) Sep 06 2013 I am mostly aware of this and have studied Xomb sources and
• Joseph Rushton Wakeling (7/11) Sep 08 2013 To what extent can that situation be improved with respect to Phobos? T...
• Iain Buclaw (7/19) Sep 08 2013 Wouldn't want to change Phobos in any way really, it serves it's purpose...
• Joseph Rushton Wakeling (2/3) Sep 08 2013 smalld... ? :-)
• Iain Buclaw (7/11) Sep 08 2013 libdrt?
• eles (21/24) Sep 06 2013 After some thinking, it wasn't about synchronization between
• Dicebot (4/5) Sep 06 2013 I think you need own light-weight runtime stubs linked with the
• eles (9/12) Sep 06 2013 Thank you, you are kind, I hope to have an working example. But,
• Iain Buclaw (5/16) Sep 06 2013 'p' should be marked as 'shared' in this instance.
• eles (12/21) Sep 06 2013 That will help, but it completely misleads. First, is not just
• Jacob Carlborg (7/13) Sep 06 2013 This might be a useful link:

"eles" <eles eles.com> writes:

I am starting a new thread, since I am afraid that the other one 
will become too cluttered with issues...

It is about this OS kernel:

http://wiki.osdev.org/D_Bare_Bones

I tried to duplicate the steps. However, on my x86_64 machine, 
the actual commands that I had to use are:

$nasm -f elf -o start.o start.asm
$gdc -m32 -nostdlib -nodefaultlibs -g -c -o kernel.main.o 
kernel.main.d
$LDEMULATION="elf_i386" ld -T linker.ld -o kernel.bin start.o 
kernel.main.o

(in order to emulate the 32-bits architecture).

The first command went just fine, the second command emitted 
warnings:

kernel.main.d:13: Deprecation: volatile statements deprecated; 
use synchronized statements instead
kernel.main.d:16: Deprecation: volatile statements deprecated; 
use synchronized statements instead
kernel.main.d:18: Deprecation: volatile statements deprecated; 
use synchronized statements instead

while the third one was merciless:

kernel.main.o: In function `main':
/home/user/bootloader/kernel.main.d:12: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:12: undefined reference to 
`_d_criticalexit'
/home/user/bootloader/kernel.main.d:15: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:15: undefined reference to 
`_d_criticalexit'
/home/user/bootloader/kernel.main.d:16: undefined reference to 
`_d_criticalenter'
/home/user/bootloader/kernel.main.d:16: undefined reference to 
`_d_criticalexit'
kernel.main.o: In function 
`kernel.main._D6kernel4main9__modinitFZv':
/home/user/bootloader/kernel.main.d:18: undefined reference to 
`_Dmodule_ref'
/home/user/bootloader/kernel.main.d:18: undefined reference to 
`_Dmodule_ref'

Any clues? It is because of the deprecated volatile statements?

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 6 September 2013 10:35, eles <eles eles.com> wrote:
 I am starting a new thread, since I am afraid that the other one will become
 too cluttered with issues...

 It is about this OS kernel:

 http://wiki.osdev.org/D_Bare_Bones

 I tried to duplicate the steps. However, on my x86_64 machine, the actual
 commands that I had to use are:

 $nasm -f elf -o start.o start.asm
 $gdc -m32 -nostdlib -nodefaultlibs -g -c -o kernel.main.o kernel.main.d
 $LDEMULATION="elf_i386" ld -T linker.ld -o kernel.bin start.o kernel.main.o

 (in order to emulate the 32-bits architecture).

 The first command went just fine, the second command emitted warnings:

 kernel.main.d:13: Deprecation: volatile statements deprecated; use
 synchronized statements instead
 kernel.main.d:16: Deprecation: volatile statements deprecated; use
 synchronized statements instead
 kernel.main.d:18: Deprecation: volatile statements deprecated; use
 synchronized statements instead

 while the third one was merciless:

 kernel.main.o: In function `main':
 /home/user/bootloader/kernel.main.d:12: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:12: undefined reference to
 `_d_criticalexit'
 /home/user/bootloader/kernel.main.d:15: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:15: undefined reference to
 `_d_criticalexit'
 /home/user/bootloader/kernel.main.d:16: undefined reference to
 `_d_criticalenter'
 /home/user/bootloader/kernel.main.d:16: undefined reference to
 `_d_criticalexit'
 kernel.main.o: In function `kernel.main._D6kernel4main9__modinitFZv':
 /home/user/bootloader/kernel.main.d:18: undefined reference to
 `_Dmodule_ref'
 /home/user/bootloader/kernel.main.d:18: undefined reference to
 `_Dmodule_ref'

 Any clues? It is because of the deprecated volatile statements?

Yep - this is probably the big problem with deprecating volatile
statements  (actually, volatile is no longer in the compiler).  You
are removing a low level feature and forcing users to use a high level
user-land feature instead.

The key thing you must know if you intend to do some low level pokery
is that you must ditch druntime and phobos and re-implement druntime
from scratch in the most minimalistic way possible (and so that it
doesn't depend on libc).  There is a minimal druntime kicking about I
think that an exokernel written in D1 uses... you could perhaps
recycle that.


Back to volatile.... the only (faintly close) alternative is 'shared'.
  But there's no equivalent to volatile statements other than
implementing your own low level thread library for use in kernel-land
to allow synchronized to work properly.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
   But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in 
 kernel-land
 to allow synchronized to work properly.

Frankly, but each day D becomes better, it becomes worse for 
systems programming. I'll have more&more difficulties to defend 
it as an acceptable solution at my workplace.

I am sorry about that, but I cannot do much about it... :(

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 6 September 2013 13:25, eles <eles eles.com> wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
   But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in kernel-land
 to allow synchronized to work properly.


 Frankly, but each day D becomes better, it becomes worse for systems
 programming. I'll have more&more difficulties to defend it as an acceptable
 solution at my workplace.

 I am sorry about that, but I cannot do much about it... :(

It's still systems level, just in user-land applications.

It has always been the case that if you want to enter kernel-space
with D, you have to drop phobos and implement a more low level
druntime.  For instance, the GC that comes with D is wholly infeasible
for use inside a kernel .


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Dicebot" <public dicebot.lv> writes:

On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
  But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in 
 kernel-land
 to allow synchronized to work properly.

 Frankly, but each day D becomes better, it becomes worse for 
 systems programming. I'll have more&more difficulties to defend 
 it as an acceptable solution at my workplace.

 I am sorry about that, but I cannot do much about it... :(

Yes, I feel quite the same way and I have almost abandoned any 
hopes to use it in C domain. Currently D is more like native 

definitely not the breakthrough.

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 6 September 2013 14:13, Dicebot <public dicebot.lv> wrote:
 On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
  But there's no equivalent to volatile statements other than
 implementing your own low level thread library for use in kernel-land
 to allow synchronized to work properly.


 Frankly, but each day D becomes better, it becomes worse for systems
 programming. I'll have more&more difficulties to defend it as an acceptable
 solution at my workplace.

 I am sorry about that, but I cannot do much about it... :(


 Yes, I feel quite the same way and I have almost abandoned any hopes to use

 cool in lot of applications but definitely not the breakthrough.

And all I'm saying is that if you want to use it on bare metal then
you have to strip out phobos and re-implement everything from
druntime.

- In a kernel, you don't have the liberty of using malloc, realloc,
free, or any other libc functions.  So these allocation routines that
are a part of the GC need to be re-written for use in the kernel.
- The GC that comes with D itself is a bit too heavy for use in a
kernel  ->  re-write.
- pthread library is also out -> write your own lock system specific
for use in the kernel.
- Using exceptions in a kernel?  You are having a laugh...
- The D compiler may generate calls to libc functions, such as memcmp
or fmod or pow -> avoid these like the plague.  (Actually this isn't
necessary a bad thing to note upon, as eg: gcc could do the same thing
also, and so Linux devs tend to write in a very peculiar way because
of this anyway).


But lets try to be positive. How would I pragmatically approach this?

Well, we are going to have to build a runtime from ground up either
way you look at it.

1) Minimal D runtime.

Only recent example I can think of is here: http://arsdnet.net/dcode/minimal.zip
Though this is for DMD only.

Older examples of a minimal D runtime are for D1.
https://github.com/xomboverlord/xomb/tree/unborn/runtimes

Ideally you'd want to try and marriage the two together.

2) GDC-specific modules.

Only set of modules you need to worry about are the EH modules
(unwind.d).  These are based off of libstdc++ EH functions, there is a
minimal C++ runtime here which is available here:
https://github.com/pathscale/libcxxrt/tree/master/src

Simply convert the EH routines over to D as required.

3) Entrypoint functions.

See Xomb link above for assembly files, etc.


4) glibc/pthread

Write your own replacements.  See for example how Linux does this
(kmalloc/kfree, etc).


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
 On 6 September 2013 14:13, Dicebot <public dicebot.lv> wrote:
 On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw 
 wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:



 And all I'm saying is that if you want to use it on bare metal 
 then
 you have to strip out phobos and re-implement everything from
 druntime.

Yes, I know, the kernel provides an almost complete and fully 
from-scratch reimplementation of the C standard lib. It would be 
almost impossible to rely on the libc provided by GNU, as the 
latter... relies on the kernel.

While reimplementing the C standard lib is simpler than 
reimplemented Druntime/Phobos, it could be argued that writing 
code using the libraries should be easier when relying on 
Druntime/Phobos, so this could be acceptable.

Problem is that D is needing those libraries not only for 
functions, but also for functionalities (of the language itself).

In C, you can use the language without a library, and I mean any 
subset of the language (yes, that will be a bare does-nothing 
application, but you know what you can rely on and what not).

In D you cannot. You have to avoid features *of the language* 
relying on Druntime and, worse, it is not even clear or 
guaranteed which of them.

Leandro Lucarella <luca llucax.com.ar> writes:

eles, el  6 de September a las 16:20 me escribiste:
 On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
On 6 September 2013 14:13, Dicebot <public dicebot.lv> wrote:
On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw
wrote:
On 6 September 2013 10:35, eles <eles eles.com> wrote:



And all I'm saying is that if you want to use it on bare metal
then
you have to strip out phobos and re-implement everything from
druntime.

 
 Yes, I know, the kernel provides an almost complete and fully
 from-scratch reimplementation of the C standard lib. It would be
 almost impossible to rely on the libc provided by GNU, as the
 latter... relies on the kernel.
 
 While reimplementing the C standard lib is simpler than
 reimplemented Druntime/Phobos, it could be argued that writing code
 using the libraries should be easier when relying on
 Druntime/Phobos, so this could be acceptable.
 
 Problem is that D is needing those libraries not only for functions,
 but also for functionalities (of the language itself).
 
 In C, you can use the language without a library, and I mean any
 subset of the language (yes, that will be a bare does-nothing
 application, but you know what you can rely on and what not).
 
 In D you cannot. You have to avoid features *of the language*
 relying on Druntime and, worse, it is not even clear or guaranteed
 which of them.

LDC used to have a --no-runtime switch or something like that, that
aborted compilation if a call to the runtime was emitted. I don't know
if it still does, but that's extremely useful if you want to use the
D subset that only generates assembly without calling to external
functions. D runtime is mostly written in D, and for obvious reasons
can't use those language constructions that uses the features you are
implementing. So is possible (although extremely inconvenient right
now).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
FINALMENTE EL CABALLITO FABIAN VA A PASAR UNA BUENA NAVIDAD
	-- Crónica TV

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 17:09:03 UTC, Leandro Lucarella 
wrote:
 eles, el  6 de September a las 16:20 me escribiste:
 On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
On 6 September 2013 14:13, Dicebot <public dicebot.lv> wrote:
On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw
wrote:
On 6 September 2013 10:35, eles <eles eles.com> wrote:





 LDC used to have a --no-runtime switch or something like that, 
 that
 aborted compilation if a call to the runtime was emitted. I

That's good, but is rather a workaround for a limitation of the 
language. Is D the first language with a compiler unable to 
compile its own standard library? There is no guarantee in the 
language that one day even the most innocent operation in the 
language won't require the standard library and what compiles 
with "--no-runtime" today might as well not compile tomorrow.

In C or C++, while the standard library is part of the language 
standard, is not part of the language per sé. It is not part of 
the compiler, after all. It is provided with.

 don't know
 if it still does, but that's extremely useful if you want to 
 use the
 D subset that only generates assembly without calling to 
 external
 functions. D runtime is mostly written in D, and for obvious 
 reasons
 can't use those language constructions that uses the features 
 you are
 implementing. So is possible (although extremely inconvenient 
 right
 now).

This will likely be the most limiting issue for the embedded 
world.

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 6 September 2013 19:40, eles <eles eles.com> wrote:
 On Friday, 6 September 2013 at 17:09:03 UTC, Leandro Lucarella wrote:
 eles, el  6 de September a las 16:20 me escribiste:
 On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
On 6 September 2013 14:13, Dicebot <public dicebot.lv> wrote:
On Friday, 6 September 2013 at 12:25:56 UTC, eles wrote:
On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw
wrote:
On 6 September 2013 10:35, eles <eles eles.com> wrote:





 LDC used to have a --no-runtime switch or something like that, that
 aborted compilation if a call to the runtime was emitted. I


 That's good, but is rather a workaround for a limitation of the language.=

 Is
 D the first language with a compiler unable to compile its own standard
 library?

And you rephrase that question? I think you asked it wrong. :)


 There is no guarantee in the language that one day even the most
 innocent operation in the language won't require the standard library and
 what compiles with "--no-runtime" today might as well not compile tomorro=

w.

I don't think that's true.  Any compiler operations being moved into
the library will be separate from the language keyword. eg: creal ->
Complex!real.


 In C or C++, while the standard library is part of the language standard,=

 is
 not part of the language per s=E9. It is not part of the compiler, after =

all.
 It is provided with.

C++ required a minimal runtime as it does emit library calls through
code generation (see libcxxrt link earlier in this thread) - there are
however compiler switches which mean that the c++ compiler will error
if you try to use any of these features.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';

"Ramon" <spam thanks.no> writes:

OK, OK, completely overblown but for the sake of the point: Well,
if you bend and strip down Clarion or php far enough, you might 
use it for
a kernel, too.

Frankly, when hacking the kernel you use C, period. There are
alternatives, Ada for instance but they have a price tag too. And
D, with all the warm feelings we might have for it, is not one of
those alternatives.

I wouldn't say D is intentionally "marketed" so as to make
people think D can be - reasonably - used where it can not, at
least not reasonably. But it's at least, let's say, selling
itself in a way that invites people to wrong conclusions.

This is not even so much a moral issue but a rather practical
one. I understand that dicebot and some others are enjoying
experimenting around the periphery of D-land and that's perfectly
OK; they are quite grown up experienced guys who, so it seems,
make their experiments for hacking and learning purposes.

eles on the other hand seems to have walked into a comittment 
(trying to avoid the term "trap") by believing that systems 
programming, "very C like", "doing right what C++ was meant to 
achieve" and the like can actually deliver
on the promises. Now, Pardon me talking straight, he is in danger
of looking like a fool to his peers - and D is in danger to look
like a bragging fullmouth that just can't deliver.
Because it allowed itself to sound like promising what it can not.

Let's be honest. D, as Iain correctly indicated, is a userland 
language
that has strengths in userland systems programming and offers
high efficieny, even some comfort and other goodies without
keeping the programmer away from the lower levels incl. (more or
less) direct access to C code.

That's a lot. That's great stuff. Kudos. *And that's damn enough
and good enough to afford honesty*, the honesty, for instance, to
say "D is not for kernels or for MCUs (other than fat arms etc),
period. As for stdlib/clib like stuff it's on its way but far
from having arrived".

A propos "on the way". Maybe we should concentrate more efforts
on reliability (as in "private" and "public" being properly
implemented and respected) and on really making phobos into a
properly designed and structured library.

If one convinces 1 person that something is good he might bring 3
others. If one allows 1 person to feel left alone or betrayed or
reasonably disappointed 30 other will be driven away.

There is good reason I respect and praise Iain. He delivered.

After days of frustration and being laughed at or even being 
attacked
I'm humming away productively since I switched to GDC. This, too,
didn't come for free; it like so many things D-related took some
efforts but it definitely was worth it.

A+ -R

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
 Let's be honest. D, as Iain correctly indicated, is a userland 
 language

Unfortunately, in this case, it brings to my actual workplace 

and so on. When really needed some pointer action, a bit of C 
will ensure that just fine: after all, grunt pointer work in code 
is less than 5% (don't count for that abstractions as arrays, as 


And you know C quite well, because, surprise, you are using it a 
lot for the kernel programming.

It was a time when Walter answered to some post telling that 
there are no OSs written with garbage collectors someting like: 
"maybe it should". Understanding that this will also mean better 
safety, as less memory leaks and so on.

Well, it seems that you could have an almost OS: the GNU without 
the Linux. And that OS will be something like D/C, just as today 
we have GNU/Linux. C standing for the kernel...

 There is good reason I respect and praise Iain. He delivered.

I concur.

 After days of frustration and being laughed at or even being 
 attacked
 I'm humming away productively since I switched to GDC.

I wish I could say the same.

"Ramon" <spam thanks.no> writes:

eles

Risking to find myself in hot water ...

I think that gc is grossly overestimated and it's too often 
painted in promised land colours. For one, there are, of course, 
trade offs; sometimes gc's advantages outweigh the disadvantages, 
sometimes not and close to hardware basically hardly ever.
Second, the problems to be solved by gc are equally 
overestimated, too. Looking back at many, many years of using C, 
memory management was basically never among the top trouble 
sources.

I don't know your situation in any detail but when doing work 
with MCUs (as in 8051, 68K, coldfire, mpc430, not as in Arm 
Cortex) I wouldn't even consider D.

D provides for interfacing C to quite some extent and I see that 
as extremely desirable and very much related (looking 
pragmatically) to D being C-like (unlike, say, Ada, which also 
provides quite nicely for interfacing C). I find that attractive 
for a simple reason; I don't need to switch my mindset and habits 
too much and can comfortably afford to follow the old and wise 
saying "Use the right tool for any job". Kernel, drivers etc -> 
C, userland system stuff, low level app stuff -> D, higher level 
stuff -> D with objects.
Yowsa, that's what I looked for.

If I were to criticize D then mainly for 2 points:
- It's following C's mindset too much on one hand and too little 
on the other hand. It seems visible to me that WB was driven by 
an itch and not so much by a vision (this is meant neither 
negatively nor positively; it's simply my impression and "driven 
by vision" doesn't necessarily lead to better results).
- It's not as consistent as I'd like it to be. phobos seems, uhm, 
worthy a discussion e.g. concerning at least its design (e.g. 
layers, OS interface), safety has been a concern but might have 
profitted by learning more from other languages, etc. Similarly 
there are bits all over the place but very little consistently 
implemented. That's another example why I value Iains work so 
emminently; he has brought us a complete and (at least 
principally) portable toolchain incl. debugging which is a 
conditio sine qua non.
As one example that relates to your situation, it might have been 
wiser to say "Our lower boundary is close to hardware or OS core 
stuff; we don't do that, that's were we cut off. But we provide a 
well designed interface to the tools of the plumbing trade, 
namely C and stdlib" rather than playing with the idea of (low 
level) system programming and not implementing it consistently.

But for fairness sake: Little (besides phobos, which *can* be 
improved) is in the way of doing it right, i.e. plumbing in C and 
anything higher up in D.

In case kernel and close to the metal jobs isn't the major part 
of your job it might be attractive to look at the C/D combo.

A+ -R

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 7 September 2013 00:17, Ramon <spam thanks.no> wrote:
 - It's not as consistent as I'd like it to be. phobos seems, uhm, worthy a
 discussion e.g. concerning at least its design (e.g. layers, OS interface),
 safety has been a concern but might have profitted by learning more from
 other languages, etc. Similarly there are bits all over the place but very
 little consistently implemented. That's another example why I value Iains
 work so emminently; he has brought us a complete and (at least principally)
 portable toolchain incl. debugging which is a conditio sine qua non.

You can thank GNU for that portable toolchain too... :o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Dicebot" <public dicebot.lv> writes:

On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
 Frankly, when hacking the kernel you use C, period. There are
 alternatives, Ada for instance but they have a price tag too. 
 And
 D, with all the warm feelings we might have for it, is not one 
 of
 those alternatives.

Lot of confusion comes from some earlier times when D was 
implicitly advertised as systems programming language. It simply 
gave too much hope - one needs to be get engaged deep into 
kernel/embedded industry to understand how freaking fed up some 
programmers are from C in that domain. Thus all the frustration - 
one sees the possibility of final salvation from 60 year old tool 


Which is pretty bold move because it has completely missed 
possible niche with zero alternatives and thus competence.

Eventually I got used to it and currently only try to make some 
buzz so that situation won't get even worse - but consequences of 
false advertising still roam across the internet.

"Ramon" <spam thanks.no> writes:

On Saturday, 7 September 2013 at 00:05:08 UTC, Dicebot wrote:
 On Friday, 6 September 2013 at 19:24:22 UTC, Ramon wrote:
 Frankly, when hacking the kernel you use C, period. There are
 alternatives, Ada for instance but they have a price tag too. 
 And
 D, with all the warm feelings we might have for it, is not one 
 of
 those alternatives.

 Lot of confusion comes from some earlier times when D was 
 implicitly advertised as systems programming language. It 
 simply gave too much hope - one needs to be get engaged deep 
 into kernel/embedded industry to understand how freaking fed up 
 some programmers are from C in that domain. Thus all the 
 frustration - one sees the possibility of final salvation from 
 60 year old tool stack only to find out that it in practice 


 Which is pretty bold move because it has completely missed 
 possible niche with zero alternatives and thus competence.

 Eventually I got used to it and currently only try to make some 
 buzz so that situation won't get even worse - but consequences 
 of false advertising still roam across the internet.

I tried to stay positive but you are right. This is a good 
example for what I meant and for what I perceive throughout 
different spots with D.

It strikes me as hard to understand when very important factors 
seem to be simply ignored. In the embedded world where 1KB can be 
a lot and where one tries to squeeze out another 50us or another 
200 Bytes other laws and priorities are valid than in userland 
where libraries in the MB range are seen as granted.

My point wasn't that C is perfect for embedded. My point was that 
D is the wrong tool there. If, on the other hand, one wanted to 
develop an improved "C2e" for embedded (and probably kernel) that 
language almost certainly would disappoint in the userland 
application development - those two worlds are just too different.

I don't mean to sound blunt but I see another point that rarely 
gets addressed. WB wanted to scratch an itch. That's OK and he 
was free to do that in any way he saw fit or felt fine. But - 
luckily for us - he went further and opened it and wanted, if I'm 
not very mistaken, D to become (more) widely used.
 From that moment on the target audience was to be heard and 
included.

Similarly I value AA's work very highly but I feel that we should 
have 1 (in words: one) complete and widely acceptable toolchain 
on the major platforms - and - have a reliable and reliably 
working version of whatever first before adding and changing 
things. Probably some wouldn't be happy with, say, Scite (with D 
support) and GDB (with D support) and, for instance, not yet 
supporting 64bit linux. But it would be a base to say "You *can* 
work. No let's go and enhance and grow D, it's standard lib and 
it's eco system".

Unfortunately the path chosen led us to a situation where D and 
phobos are somewhat floating, the advertisements aren't honest, 
unmistakable and to the point, and the tools are quite floating 
and often half-cooked or limited, too.

Let me shed light on what I mean from another perspective: There 
is a reason for a language having lots of alpha, broken, and quit 
projects in its environment. It very often (if not almost always) 
translates to: people discovered the language, were attracted by 
the first impression, even had a need for it, invested time, 
efforts, and know-how - and then left.

If we really want D to grow and spread, we will have to see and 
realize that and to think hard about it and about how to improve.

I'm sorry, honestly sorry, that I myself can not (yet) contribute 
much more than thoughts and constructive(!) criticism. I'm 
working on it and - thanks to Iain (I was just a split second 
away from leaving D) - I stayed. That's not much but it's the 
best I can give as a D newbie and it's much more than just 
leaving like so many before me.

Have a nice weekend, everyone -R

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Sat, Sep 07, 2013 at 05:35:48AM +0200, Ramon wrote:
[...]
 I'm sorry, honestly sorry, that I myself can not (yet) contribute
 much more than thoughts and constructive(!) criticism. I'm working
 on it and - thanks to Iain (I was just a split second away from
 leaving D) - I stayed. That's not much but it's the best I can give
 as a D newbie and it's much more than just leaving like so many
 before me.

[...]

Don't be sorry; D is really not *that* hard to learn (it's certainly
simpler than C++, speaking from my experience!). Once you get a good
grip on it, start making pull requests. Make the changes you'd like to
see happen. That's what I'm doing. I see a lot of flaws and problems in
various areas, but I don't see much value in complaining -- it often
only makes people angry and the problem still remains. Instead, I tell
myself, OK, I may not know everything about D, but I do know *something*
about programming, so I'm going to make the code changes and submit
them. If they don't like it, then it's a good opportunity for me to
learn how to make my code changes better; if they accept it, even
better, I made a difference.

I find that it's much more convincing for me to say "feature X is
broken, here's the code change to make it better", than to say "feature
X is broken, D sucks, you lazy bums better start working to fix X or
else I'm leaving".  It feels good to rant and get it off my chest, but
it feels even better to have my changes merged and feature X to get
fixed because of me.


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and
now it's killing me! -- Schoolboy

"Ramon" <spam thanks.no> writes:

On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
 I find that it's much more convincing for me to say "feature X 
 is
 broken, here's the code change to make it better", than to say 
 "feature
 X is broken, D sucks, you lazy bums better start working to fix 
 X or
 else I'm leaving".  It feels good to rant and get it off my 
 chest, but
 it feels even better to have my changes merged and feature X to 
 get
 fixed because of me.

My intention was and is not ranting, nor saying D sucks, nor
asking other to do work nor threatening. And this can found
proven in what I wrote.

Your personal attitude, which many others have, too, is one to be
respected and a necessary and productive one. Bot not the only
valid or constructive one.

Neither is there a need to decide; the options are not mutually
exclusive. As a seasoned programmer that I take you to be you
certainly can agree that leaning back and looking, incl. looking
critically at was has been done so far not only is not harmful
but it actually is positive and often even necessary. And you
will quite certainly also degree that a non trivial project will
need some planning and management.

Unlike what you seem to think, my point isn't hitting on D
(actually that's obviously nonsensical as I wrote just yesterday
or today that meanwhile I'm happily humming along with D).
But neither can it be a healthy attitude to ignore less pleasant
things or events. We should ask what's behind it and what we can
make better.

Simply fixing issues one at a time is not a solution per se but
rather one step in solving a problem albeit an important one.
Identifying reasons and patterns is also a step and often one
that considerably enhances the situation.

If today I'm a better devoloper than 20 years ago than not merely
by experience alone but by learning from mistakes and (in my case
an important lesson) by thinking extensively *before* I hack, by
learning the importance of good design and well proven principles
and, last but not least, by learning to recognize patterns in my
errors.

I try to be polite and respectful because I highly value the work
of WB, AA and others but I feel a suspicion that "shut up and
write code!" is not a solution but part of the problem in certain
regards.

But I respect your right to rant *g

A+ -R

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Sat, Sep 07, 2013 at 08:37:02AM +0200, Ramon wrote:
 On Saturday, 7 September 2013 at 05:35:04 UTC, H. S. Teoh wrote:
I find that it's much more convincing for me to say "feature X is
broken, here's the code change to make it better", than to say
"feature X is broken, D sucks, you lazy bums better start working to
fix X or else I'm leaving".  It feels good to rant and get it off my
chest, but it feels even better to have my changes merged and feature
X to get fixed because of me.

 
 My intention was and is not ranting, nor saying D sucks, nor
 asking other to do work nor threatening. And this can found
 proven in what I wrote.

I did not intend to imply that you were ranting. I was only speaking
generally.


[...]
 Neither is there a need to decide; the options are not mutually
 exclusive. As a seasoned programmer that I take you to be you
 certainly can agree that leaning back and looking, incl. looking
 critically at was has been done so far not only is not harmful
 but it actually is positive and often even necessary. And you
 will quite certainly also degree that a non trivial project will
 need some planning and management.

What I said doesn't preclude that. All I'm saying is, *after* you stand
back and look at what's there and find it unsatisfactory, you can write
some code and then show it to others and say, "The current way we do X
is unsatisfactory; here is my code to prove this (or better yet, here's
my code to do it a better way)."


 Unlike what you seem to think, my point isn't hitting on D
 (actually that's obviously nonsensical as I wrote just yesterday
 or today that meanwhile I'm happily humming along with D).

I never implied that you were hitting on D. As you said yourself, that's
nonsensical.


 But neither can it be a healthy attitude to ignore less pleasant
 things or events. We should ask what's behind it and what we can
 make better.

[...]

Well yes, what I was saying was just to take it one step further: once
you identify the problem, write the code to improve it and show that to
others. I don't think that kind of proposal will be easily turned down.


T

-- 
The fact that anyone still uses AOL shows that even the presence of
options doesn't stop some people from picking the pessimal one. - Mike
Ellis

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

On 07/09/13 07:33, H. S. Teoh wrote:
 I find that it's much more convincing for me to say "feature X is
 broken, here's the code change to make it better", than to say "feature
 X is broken, D sucks, you lazy bums better start working to fix X or
 else I'm leaving".  It feels good to rant and get it off my chest, but
 it feels even better to have my changes merged and feature X to get
 fixed because of me.

Of course, but many potential users don't have the free time to be able to do 
this, and even if they do, sometimes the techniques required to make the fix
are 
outside their understanding (and the time required for learning may be
prohibitive).

I don't think there's any excuse for ranting, but it's understandable that
there 
can be frustration in circumstances where a user says: "Hey, this feature is 
broken, having it work is really important for me," and that concern is not 
reciprocated by the principal developers.

I don't think D is particularly an offender here -- where it is, it's usually 
down to manpower rather than unwillingness to recognize problems.  But when 
anything like this happens, it's very demotivating to users.

"Dicebot" <public dicebot.lv> writes:

On Friday, 6 September 2013 at 14:09:15 UTC, Iain Buclaw wrote:
 And all I'm saying is that if you want to use it on bare metal 
 then
 you have to strip out phobos and re-implement everything from
 druntime.

I am mostly aware of this and have studied Xomb sources and 
runtime reimplementation quite closely at some point. Main 
problem for me that amount of micro-management required for D 
(because of all language/runtime magic) is much more intensive 
than with C (just throw away libc and be careful with stack) - 
and that largely shadows the value of using D instead of C in the 
very first place.

Once you step into this domain, compiler becomes your enemy 
instead of your trusty friend and this is the most frustrating 
part. Adam Ruppe minimal.d module is a promising approach of a 
common starting point for own runtime implementation but I 
honestly think it is as much language issues as implementation 
issue.

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

On 06/09/13 15:11, Iain Buclaw wrote:
 It has always been the case that if you want to enter kernel-space
 with D, you have to drop phobos and implement a more low level
 druntime.  For instance, the GC that comes with D is wholly infeasible
 for use inside a kernel .

To what extent can that situation be improved with respect to Phobos?  The
ideal 
would be to make it non-GC-reliant and agnostic with respect to how the runtime 
manages memory.

More generally, this makes a case for something like a well defined 
"dmicroruntime" which can be used as a general solution for embedded and 
low-level programming.

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 8 September 2013 13:00, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 06/09/13 15:11, Iain Buclaw wrote:
 It has always been the case that if you want to enter kernel-space
 with D, you have to drop phobos and implement a more low level
 druntime.  For instance, the GC that comes with D is wholly infeasible
 for use inside a kernel .


 To what extent can that situation be improved with respect to Phobos?  The
 ideal would be to make it non-GC-reliant and agnostic with respect to how
 the runtime manages memory.

Wouldn't want to change Phobos in any way really, it serves it's purpose.


 More generally, this makes a case for something like a well defined
 "dmicroruntime" which can be used as a general solution for embedded and
 low-level programming.

This could be done - don't like the name though. ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

On 08/09/13 15:04, Iain Buclaw wrote:
 This could be done - don't like the name though. ;)

smalld... ? :-)

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 8 September 2013 17:04, Joseph Rushton Wakeling
<joseph.wakeling webdrake.net> wrote:
 On 08/09/13 15:04, Iain Buclaw wrote:
 This could be done - don't like the name though. ;)


 smalld... ? :-)

libdrt?

Like libdruntime, but based on a minimalist contents of /rt/  :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
 Back to volatile.... the only (faintly close) alternative is 
 'shared'.

After some thinking, it wasn't about synchronization between 
threads as the error message was misleading. Was not about 
volatile statements, but about the POD volatile variables as in 
C, marked like that for the compiler to never optimize away their 
effect.

That is, whenever you write:

*p=3;
a=*p;

it should not blindly assume that a=3, since p could be the 
address of some hardware register, with continuously changing 
(ie: volatile) content. Besides, writing and reading to hardware 
registers (mapped address) has a side effect (a hardware one).

So, as a workaround, I dropped the volatile keyword in front of 
my variables and imposed the -O0 flag on the compiler, to avoid 
any optimization.

I still find myself facing those error:

undefined reference to `_Dmodule_ref'

(actually, the error message is printed *twice*, but *for the 
same line*).

Any clues?

"Dicebot" <public dicebot.lv> writes:

On Friday, 6 September 2013 at 13:34:33 UTC, eles wrote:
 Any clues?

I think you need own light-weight runtime stubs linked with the 
binary. Adam has done some nice experiments in that direction : 
http://arsdnet.net/dcode/minimal.zip

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 13:47:47 UTC, Dicebot wrote:
 I think you need own light-weight runtime stubs linked with the 
 binary. Adam has done some nice experiments in that direction : 
 http://arsdnet.net/dcode/minimal.zip

Thank you, you are kind, I hope to have an working example. But, 
with such state of facts, it will never ever never ever be 
accepted at my workplace.

My feeling is that is a language running forward so fast that 
tools and improvements will never catch up with it. Nor will real 
use...

That's its bad. My boss might not be joking when he says that 
using Java would be simpler.

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 6 September 2013 14:34, eles <eles eles.com> wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:
 Back to volatile.... the only (faintly close) alternative is 'shared'.


 After some thinking, it wasn't about synchronization between threads as the
 error message was misleading. Was not about volatile statements, but about
 the POD volatile variables as in C, marked like that for the compiler to
 never optimize away their effect.

 That is, whenever you write:

 *p=3;
 a=*p;

'p' should be marked as 'shared' in this instance.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"eles" <eles eles.com> writes:

On Friday, 6 September 2013 at 14:10:06 UTC, Iain Buclaw wrote:
 On 6 September 2013 14:34, eles <eles eles.com> wrote:
 On Friday, 6 September 2013 at 10:43:38 UTC, Iain Buclaw wrote:
 On 6 September 2013 10:35, eles <eles eles.com> wrote:

 *p=3;
 a=*p;

 'p' should be marked as 'shared' in this instance.

That will help, but it completely misleads. First, is not just 
about the data being shared, but it is about the hardware 
side-effect. If writing 3 to the *p register makes your 
front-panel LED to light up, you need to rely on the fact that 3 
is written (for real) at that address. And written when you ask 
it to be, not some 5 minutes later, because the compiler detected 
that no other thread accesses that variable, so decided to cache 
it. 5 minutes later the plane could be already landed. Without 
survivors.

"Shared" synchronizes within the D world. There is a world 
outside the D world, and I mean the hardware.

Jacob Carlborg <doob me.com> writes:

On 2013-09-06 11:35, eles wrote:
 I am starting a new thread, since I am afraid that the other one will
 become too cluttered with issues...

 It is about this OS kernel:

 http://wiki.osdev.org/D_Bare_Bones

 I tried to duplicate the steps. However, on my x86_64 machine, the
 actual commands that I had to use are:

This might be a useful link:

http://3d.benjamin-thaut.de/?p=20

It's a blog post that contains links to a druntime and Phobos fork that 
doesn't use the GC.

-- 
/Jacob Carlborg