https://github.com/kaleidicforks/mkernel-d

I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work.  It seems to.  I didn't try loading with GRUB.  The dub.sdl isn't quite right, so best run ./build.sh

Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming.

On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
> https://github.com/kaleidicforks/mkernel-d
>
> I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work.  It seems to.  I didn't try loading with GRUB.  The dub.sdl isn't quite right, so best run ./build.sh
>
> Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming.

IIRC there used to be a protection supposed to prevent hijacking of package names, e.g someone that would register from a fork before the original package, blocking the original author, considered as more legit.

But https://github.com/dlang/dub-registry/pull/425/files seems to say that it should work now.

On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
> https://github.com/kaleidicforks/mkernel-d
>
> I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work.  It seems to.  I didn't try loading with GRUB.  The dub.sdl isn't quite right, so best run ./build.sh
>
> Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming.

I tried mine a while back using betterC but given I was already running without druntime the only noticeable difference was I no longer required these hacks;

//---
// So we compile without druntime
extern(C) __gshared void* _d_dso_registry;
extern(C) __gshared void* _Dmodule_ref;
extern(C) __gshared void* _d_arraybounds;
extern(C) __gshared void* _d_assert;
extern(C) __gshared void* _d_unittest;
//---
immutable auto VIDMEM_BASE = 0xFFFF8000000B8000;
static immutable ubyte egaBlack = 0;
st



GRUB worked as before for both 32 and 64 bit. But that doesn't mean much because my kmain was already extern(C) so the linkage was fairly typical.

bye,
Norm

On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
> https://github.com/kaleidicforks/mkernel-d
>
> I spent a few minutes on just turning the C code to betterC D - was curious to see if it would work.  It seems to.  I didn't try loading with GRUB.  The dub.sdl isn't quite right, so best run ./build.sh
>
> Cannot push to code.dlang.org - it complains about registering a forked package, even after renaming.

Really cool project.

On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
> ...

Nice indeed, maybe you should mention this on reddit?

Matheus.

On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote:
> On Sunday, 16 June 2019 at 16:14:26 UTC, Laeeth Isharc wrote:
>> ...
>
> Nice indeed, maybe you should mention this on reddit?
>
> Matheus.

Feel free to.  But I didn't do any work - I changed a few lines in the C code and of course it just worked.  So I would feel embarrassed posting to Reddit because the original author did the hard bit and I just made trivial changes.

You know I think Atila is right about social factors and integration being everything.   The objections to using D are just that - it's not really about what people say mostly, but those are excuses to rationalize how they feel.

One aspect of that is just showing something is possible.  Adam Ruppe's talk at dconf a while back has had a lasting influence on how we approach things, mostly for giving me permission to do what I'm naturally inclined to do anyway.  If you're not sure then bet a little time to try - the worst thing that can happen in user code is a segfault and so what.

For example our business is not primarily about network programming at a lowish level.  But when people say file transfers to Asia are slow because of the speed of light and latency one doesn't need to accept that.  It's quite a similar problem - latency and packet loss - to the days of 300 baud models and XModem and there's an obvious solution.  But before doing it myself I figured someone must have solved it and I found UDT.  I spent half a Saturday wrapping it so it built but wouldn't work and Robert Schadek finished the job in a day or two.  What's a decent performance improvement these days?  Well I'm pretty happy with a 300 times (not 300%) improvement in file transfer speed between regions!  And we can pull that plus libzfs in D plus our little language to have a tool for managing zfs snapshots and replication that makes everything simple because it's coherently designed and integrated.

Anyway I think sometimes a barrier to adoption is sometimes just nobody has yet shown the problem is easily solved using D in your domain.  We are in an age that's short on daring and ambition, which means a little bit of courage goes a long way.  Nobody could break the four minute mile.  One guy did it and then lots of people followed.

Most people closest to using D that aren't I guess will have a decent size C or C++ code base.  DPP keeps getting better in relation to
C++ and we want to get it to a stage where it can be used to expose an internal library that's still got a C++ interface but is being replaced step by step with D.  Thanks, Daniel Murphy for showing the way there, though we aren't able to do the translation programmatically.  DPP has paid for the modest support we provided many times over already even just considering direct benefits.

I wonder a bit about translation from C.  Rust 2C was a multi million DoD project.  We could steal the front end that dumps out the libclang C AST as CBOR.  I suppose it shouldn't be hard to translate that to C-style D programmatically.  It "adds nothing" to libclang in theory but it saves a lot of time as libclang is not the most complete or pleasant API I have seen.

If we had something dependable it would be much easier to move a C codebase incrementally to D because you could just do what you can manage at that time and you don't need that much imagination or courage because it doesn't end up being a big binary bet.  I guess translating C++ programmatically is a much harder, maybe almost impossible problem.  But C would be a start.

I have my hands full right now but I would play with doing it myself if I had more time...


Laeeth

On Wednesday, 19 June 2019 at 23:31:40 UTC, Laeeth Isharc wrote:
> On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote:
> ...
> One aspect of that is just showing something is possible.  Adam Ruppe's talk at dconf a while back has had a lasting influence on how we approach things, mostly for giving me permission to do what I'm naturally inclined to do anyway.  If you're not sure then bet a little time to try - the worst thing that can happen in user code is a segfault and so what.

What talk is that exactly?

On Thursday, 20 June 2019 at 19:54:19 UTC, Cym13 wrote:
> What talk is that exactly?

prolly this one:
http://arsdnet.net/annotated-transcript.html