Distraction! Or rather multiplexing.

I'm jumping between my personal projects right now cause I don't want to spent my free time with chasing hard-to-find bugs (I'm already doing this at work...). No wonder why I'm having different thoughts everyday. And it's great to have a blog like this to form words around all these topics.

Anyway, I have a couple of thing I realized yesterday - especially to help me finding those annoying bugs in my multithreading system. First of all, it can only be a problem in the event code itself. I never used it except for waiting on tasks and for ending the whole system - I remember that exactly this problem troubled me before. Sooo, I can keep my existing code and just need to worry about how to solve this particular problem. The even idea itself is perfect for multithreading and tasks. It enables me to efficiently manage problems. However, I know that some parts of the event system have to work cause I've already done successful test with thousands of threads with very broad and very narrow conditions. Yep, it needs to be the exitting of threads. It works in debug mode due to more time between events (I guess). I'll probably use the next week to pinpoint this damn problem and find a solution for it. There HAS to be something I don't see or notice at all. The system's too tightly designed to allow any unknow memory access problems, so I suspect it to be something that depends on thread lifetime. Better double-check whether task waiting and so on works as intended... To bad I can't use my debug output then!

The second realization is that if I want to find a memory management system for my programming language, I'll have to find a different approach rather than trying to believe that arbitrary code merging makes it possible to properly manage memory without constant malloc use. An idea I got yesterday was to define a structure for each function or piece of code. This structure is not just made of of plain old data but also of a number of different sizes/informations required for efficient code merging. First of all we have local data like variable-pointed data and literals. Second is the code we used besides variable declaration - essential for merging functions. Third is couple of a) the amount of space needed for local variables and/or bound parameters and b) the stack size we need to do temporary calculations. That's a first step to seperate different properties and make structures and functions ready for merging. Also, this would make it possible to create a function where you can output whole structures (possibly new ones) with initializer code for each property. The idea of seperating all kinds of stuff sounds very awesome to me due to that, but it's also hard to combine with my idea of how a simple programming language should look like. I'd need to sacrifice my current minimalism for a more descriptive setup if it comes to stuff like what gets into the resulting and what not, how to mark this and that, what's about pointer and external objects and so on. The interesting and flexible it could be, the more it goes away from a simple and clean approach. While writing this I thought about how Lisp solved functing merging but I can't exactly remember except that there's no proper way to do this but just to build lists of function calls. Actually, my syntax looks sorta like listing right now, so I'll probably take another brainstorming today and design my collected ideas about my current main concern: how to combine function, structure and member/method definitions in one package. I WILL think about how I would realize a type system in a LISP-like syntax for a static and dynamic context as well as what's easy to realize and practical while coding. It's all a syntax question I think and what features I want and how I want the data flow to be is something seperate from how to describe it. The best approach seems to be to just colect all the awesome ideas that are not bound to syntactical sugar and try to build on this. The classical C way defining and operation on stuff is rather disadvantagous. I've thinking too much without focussing on what's important to me - mindmapping ahead!

Third realization - in conjunction with programming languages - is some more thinkage about standard libraries. There are different approaches to what makes a standard library and a lot of stuff I'd put under "general library" will find it's way into RAD or scripting languages while more simpler languages like C or Erlang have a very distinct definition of a standard library as well as with what language the library was written. Personally, I'd describe a standard library as something that's not only use by almost every software but also what's completely portable and does have a minimum of system-specific properties. Also, hardware dependencies are other important factors as the language and the compiler should be able to generalize away too heavy differences. Yeah, I know - my beloved C fails at this point, but not many languages can succeed there. My view of standard libraries makes it a set of stuff written in the language itself to ease common, abstracted tasks. And I/O is common for sure but very different between applications, so a better approach would be to have a middle ware code with a user-implemented interface to the underlying system. That's a bit like Java, but isn't really able to do something good with it due to the language's/interpreter's design.

Yeah, that's it for now. A lot of thinkage but I enjoy thinking about it. It makes me feel productive and more bound to what I'm ranting about everytime I program. This way I can better at it while finding ways to destroy anything that might annoy me in the future. Atleast if it's about homebrew hobby stuff...

No comments: