freenode/#mezzano - IRC Chatlog
Search
9:05:35
elderK
The main thing that's taking so much time, is trying to do define-binary-structure nicely.
9:05:48
elderK
I have been investigating using the MOP. But, after researching and reading into it, I've decided not to use the MOP.
9:06:04
elderK
Mostly becuase I don't think it is strictly necessary. And, I want to the system to be as ... free as possible, wrt to dependencies.
9:06:21
elderK
If you'd like, I can show you the intended "expansion" of the define-binary-structure macro.
9:06:47
elderK
So far, I've been building on the idea that we will support basic structural inheritance. Although, upon examination, I'm not sure how necessary this feature really is.
9:08:20
elderK
It's not that it is all that hard. It's that it's hard to do it in a way that I personally feel happy with
9:08:50
elderK
I've written several implementations that do what I want. But, they all have issues that piss me off.
9:10:07
elderK
Like, if I am destructuring some form while expanding the macro, do I just let the internal "error" condition propogate? Or do I translate it?
9:37:33
elderK
No. "Fragmented" things would be quite difficult to add. Think about how you'd specify them.
9:37:46
elderK
You'd be better to simply create an accessor yourself, a "virtual accessor" if you will.
9:38:19
elderK
Given how easy it is to deal with this, I don't see a need to have something like that integrated into the library itself.
9:44:09
elderK
ebrasca: Actually, I could write a macro that "generates" fragmented accessors for you
9:45:30
elderK
I'm not sure what form such a macro would take. But I imagine you'd say, like, create an accessor with this name, the read value will be these combined in this way.
9:45:49
elderK
The setter would be the same, but would destructure as expected. So, the low 16bits say, would go where youwant them, the high 16bits, etc.
9:46:19
elderK
Ideally, you would not be doing all your work in these structures, anyway. They are for parsing only.
9:48:10
elderK
Well, in general, you're reading a structure for a purpose, perhaps to populate something else. The actual binary format is an implementation detail - it's a source and a target. But it's not what you spend your time manipulating constantly.
9:48:39
elderK
There are architectural reasons for this, too. For instance, if you have a VFS, you use an higher-level idea of a directory or a file.
9:49:02
elderK
Rather than the concrete FAT or ext2 ideas. Their view of a directory or file or whatever, is an implementation detail - it's FS specific.
9:53:32
elderK
Well, that's the thing. You have to study various filesystems. And create suitable higher-level abstractions.
9:54:25
elderK
So, you have to come up with ways of describing these features without reference to any particular FS implementation.
9:54:56
elderK
It's like a pyramid of abstraction: The platform-specific or FS specific stuff is at the bottom.
9:56:01
elderK
Ideally, these details would have been worked out alread, for you. All you'd have to do is implemented the "low-level FS code"
9:56:35
elderK
It takes work to think of a suitable architecture. But a good architecture can be very useful - and reduce a lot of work.
10:04:25
elderK
ebrasca: Mezzano needs a lot of work when it comes to filesystems and stuff. This is something I'm hoping to help with :)
10:09:22
elderK
I'd need to spend more time examining Mezzano. But it may be lacking support for the things we need.
10:09:30
elderK
On UNIX systems, there is usually a virtual filesystem - a higher-level abstraction.
10:11:00
elderK
A better, more general idea, would be to take from plan9 the idea of first-class namespaces.
10:11:03
ebrasca
I like this image https://upload.wikimedia.org/wikipedia/commons/3/30/IO_stack_of_the_Linux_kernel.svg