OSDev.org

Actually, you can just read my code if you want to see how it's implemented. You apparently didn't read the above, where I said it was NOT implemented in C, for the specific reason that I needed higher level language features.

Enfilades are of the form:

with a ulong version. This means that there is a dynamic array of 64bit ints, indexed by 64bit ints, indexed by 64bit ints, plus one more 64bit int for a version. Likewise, the indexing within a document is done via 64bit ints. A transpointer contains two of these (a start and an end) each for both target and location, plus one more (a threespan, which points to the program used to run it). A transclusion is like a transpointer, except with only a start for the location (since the target is inserted in the start position when the document is viewed). Doing this in C would not be easy, if only for the fact that the dynamic arrays would be painful to implement and maintain.

From the above, you should see (if you are in fact reading it) that is is not a simple pointer at all. An enfilade is not a simple bytespan either, so your traditional pointer has very little to do with it.

Yes, Xanadu is unpopular, however I believe (and I am not alone on this) that the ideas presented there are extremely valuable, even though mismanagement led them to lacking a stable final product. And, you should note that they DID release a number of usable, working proofs of concept, so they are not in fact vaporware.

And yes, this is high level. That doesn't mean it's not part of an OS. XANA is an OS that includes some rather high level data structures in some rather uncommon places, but it still functions as an OS, and is not in fact an application.

And if you want information on how arithmetic can be done on the addresses, you should probably check the code as well. I'd be willing to explain some other time, but if you're going to simply challenge everything I say without trying to comprehend it, I don't see any reason why I should go through the trouble, when it's already written and out there.

I took a look at the source. I could see nothing that shows any of the concepts that you talk about a lot. Nothing that I could find is actually implemented into source code of any programming language that is included in you're tar ball.

\aileta\
Aileta, is apparently something of place holder since it has only empty function implementations present in it.
\internal\
A lot of generic implementations. Some stuff very important to the D language, but nothing in depth that you have been talking about that is actually related to the Xanadu Project, or even the Enfilade word.
\klib\
A heap management routine that increases a pointer by the amount allocated. Apparently just to get something in place to continue on with other stuff like most of us do.
\libm\
Generic standard library like things.
\lua\
I see a LUA source folder that you are trying to integrate into the kernel for something.

\nucleos\
Mostly generic things. Nothing new or very exciting here in my opinion. A general kernel framework. Seems to setup a IDT table with one handler for IRQ1 which I assume is for the keyboard.
\std\
Very similar to the libm and internal folders. Is there something I am missing?
\typeinfo\
Not sure if you wrote this or it is something like the \internal\ folder.
\xulib\
Not sure whats is going on in here, but it appears to be the most interesting folder.
--mem.d
Seems to be some type of memory management scheme appearing that looks better than the just advance the pointer on alloc() calls forward.as you do in \klib\.
--util.d
Once again a dead file. I assume the intention is a place holder.
\Documentation\
I then went to documentation folder and found out that the \xulib\mem.d is supposed to be a managed heap. It actually looked not just unfinished but unrefined in a actual practical situation.

Of course I could dabble in this folder for quite a while, but the point was that I was not understanding what you where talking about because you had already implemented it and all I needed to do was look at it by downloading the source. So... Am I wrong?

So... there was one interesting file that appears to be something that you are attempting to work on but other than that. What are you talking about?? I am lost. How about you help point me to where this stuff is.



I am having a lot of trouble finding this. I could be wrong! However I really need some assistance in where to locate a implementation for the programming language D in you're kernel source tar.

If this stuff is there please let me know so I do not end up smearing you're name with a bad image when you really do have something going.

It's actually in src/xulib/estage (most of the stuff that I'm speaking of). The actual filesystem is implemented in src/klib/estage , and the EPL code (which is about to be refactored) is in src/xulib/stage2 .

src/xulib/util.d is actually not a placeholder -- it contains very simple functions that are actually quite useful in many cases (since structs are passed by value, it is useful to be able to create blank forms of a given struct type, and detect whether or not a given struct is blank, since one cannot return null).

mem.d is not the complete memory manager. In fact, most of the memory manager functionality is in gc.d (integrated with the garbage collector) and src/xulib/heap.d

src/klib includes not just the heap stuff, but also the basic stuff like i/o, idt, reading from the keyboard, writing to the screen, and unfinished VGA graphics.

src/internal and src/typeinfo are mostly just stuff from D I had to hack around with to get everything working. src/std is mostly that, though there are a good number of completely new implementations.

src/lua is the core lua interp code, which I plan to use in the kernel eventually as a command line.

But the stuff i'm talking about is mostly in the subfolders of src/xulib . Most of it is compiled in currently, despite the fact that it is designated as a separate stage.

There's a good portion of stuff that IS placeholders, but that's mostly because I had to do so much work just to get D code to boot (the memory manager, all the std lib stuff, internals, etc).

By the way, src/libm is probably going to be factored out soon, since I don't think I'll actually need the math libs.

Also, the tarball you downloaded isn't quite up to date (I got more things working since then, which are on the SVN, but I'll upload a new tarball soon).

I have coded basically all the things I've mentioned in terms of enfilades, transpointers, transclusions, and the filesystem. The things I have yet to implement are the UIs, networking, a VFS layer on top of the filesystem (to mount things), and the said refactoring of the EPL code (which is currently src/xulib/stage2/cell*.d ). I have a more complete form of src/xulib/stage2/xtp.d , however it requires regex, which I have yet to implement (D relies upon the C regex functions, which I alas must reimplement).

Oh, and D has its main site at http://digitalmars.com/d . I'm using GDC to compile this (the D frontent for GCC, which is linked to at said site)

I found it. It does appear you at trying to implement it. Lets get it working so you can actually demonstrate it in the "Project Announcements & Test Requests" sub forum instead of talking about it working.

I want to SEE it work, and apply it to a operating system in a way that entangles the kernel in the concept, otherwise it is just a bunch of vaporware.

Thats a harsh reality but the truth. No one is going to believe something that does not demonstrate it or pull them into learning about it.

Well, that's my next step (which is why I've been talking about it so much). It's already integrated into the FS (in fact, it basically IS the FS), and even in the bytecode's current form (which is entirely incomplete), it forms the basic structure. The next step is the interaction between the user and the FS (on a ramdisk), which I am about to impelement a UI to accomplish. Any bugs in the system itself (which compiles and such, though that doesn't necessarily mean it works) will present themselves when using the UI.

The reason I posted this here is because it was the initial project announcement (project is starting).

Ok. Show me it working..

Yes - everything in the whole universe is completely useless and should not be discussed until it works exactly as you want.

Lol. Well he has a point -- I suppose this forum is more geared towards release announcements and such. I'd be almost to the 0.01 release right now if the ethernet card in my server hadn't b0rked :-/. Basically I ran into an odd problem with the Z2, which ended up being in fact a problem with my associative array code (which I took directly from D/Phobos's PD library code, with minimal changes). But in the end, it ended up being a problem with my implementation of _d_new(), which was probably a standin code anyway. I'm in the middle of doing a fix right now, but the current code is stuck on the server and I need to get it off and over to another computer so I can finish fixing it up. Though the Z2 works okay otherwise (the problem only popped up when I was working on adding a document to the FS).

Is XANA from a cartoon TV-show? Theres a whole bucnh of video clips on various project XANA sites (e.g. myspace page, http://profile.myspace.com/index.cfm?fu ... =172946813).
It would appear ailita or whatever the folder is named is a character from said tv program.

I'm confused...

Yes. XANA is the name of an AI in the show Code Lyoko (which I have only seen a few episodes of). The reason we named it that was because XANA was short for Xanadu (our inspiration), it was catchy, and it was a reference that people could pick up (as you just did). To go further, in Code Lyoko, the name XANA was a reference to (the same) Project Xanadu -- shown by the fact that in the pilot the virtual world was called Xanadu, and made numerous references to Project Xanadu. Also, in some of the clips in which a character is programming, a lot of the "code" looks vaguely like a cross between the Matrix and a ZigZag UI (and a bit more like the Z2, which was designed off of a simplification of the ZigZag, and which we use as a default UI). My friend, fellow developer Jon Kopetz, used to be a fan of the show, and so I attribute most of the references to it in the code to his constant mentioning of it to me in years past.