I added a nice little lock for the cartridge holder cover. Now you only need to pull a lever back and opening/closing can be done without having to fear that all cartridges fall out. I did so many small changes to the locking mechanic that it ultimately resulted in a completely new version. Now you just need to pull two little nubs back and you can open the barrel. Closing is done is the same way. It uses the same principle as the cartridge holder, so it's (int theory) quite stable. The problem is that Lego isn't everything and that it was really complicated to figure out a construct that works for more than just a few openings until it breaks itself. It's an annoying position where most of the forces need to flow into the chamber frames: right over the collision point for hammer and cartridge. My cartridges need a T-shaped space above them trigger the shot which's just not that availabe. So I need to replan a rebuild the lock, probably resulting a rail-like structure above the chambers/trigger component. Originally, I planned to not attach a rail to this one but design one for the next model (which will rather work like a revolver without any breaking). So since I can't avoid putting such a thing on it, it can't harm to design it like a rail and not like a fix. This also enables me have proper sights or mount a scope if I get some appropriate lenses later. It seems that I only need two of them to create a galilean telescope and a couple more for a kepler telescope. So adding a rail on top is probably a good idea since I can then also mount dfferent scope for all kinds of distances and share them across several models. Oh and adding something to adjust the height may also be useful there. Let's see with what I'll be able to come up with. However, this locking really kills me. Never underestimate it's required heavyness when it comes to many connected parts - otherwise it might require rework over and over again.



Ok, the cartridge holder is done and makes a great rifle stock! Though I'd like a bit longer and the cover is missing, whatever. Also did some more changes to the whole structure and the hammers/pins, so that you can also cock them in the new configuration. Out of an ideaful moment, I realized that due to the very simple chamber design, I'd be probably possible to extend the bullet length on demand while needing only a small amount of changes. It would only need some enlargements here and there and everything would be done. Even stock would require some smaller changes as I'm planned to make a rather bigger cover for it instead of the previously small version. However, I did a quick test and it seems that I can theoretically choose whatever bullet I want/is possible and it still works - hitting harder, flying farther. If that's not a good news! I mean what's the point of wasting power if there are no deep changes to the overall construction. I also think that it should be possible to make a generally lengthy chamber and add little pins depending on the desired bullet length to let the chamber itself adjust it's point where the bullet stops going it. That's quite a cool solution but probably not possible when thinking about the current chamber configuration in total... However, it's, in theory, it's only a matter of having a little L-beam preventingthe bullet from falling out of chamber, interpretable as a one stud long barrel. I set the current maximum size for a cartridge to 16 studs - using the longest possible as a base. Quite interesting is also the fact that I used no left/right stabilizing beams longer than the old cartridge. These are usually there to prevent the bullet from choosing the wrong direction, but on those levels of rubberband stretching, it simply doesn't need any. This knowledge will help me designing a bigger and even farther shooting cartridge some day. However, I have one finished cartridge lying in front of me and compared to the shorter version it looks like it's magnum version. 4 studs longer than before and shoots like hell. I may take a few reads about ballistics before I try to get more out of it. A single test resulted in a far more flat curve but even more aprupt loss in speed - a more straight fall after around 15 meters I think. All in all, it seems as far as I could get with the 4x4 cartridges - I assume, for rubber bands, it doesn't matter what weight it has at such short distances. Double the distance and I guess there'll be a difference. It's probably also possible to lengthen the cartridges even more, but that would hinder them from fitting into the cartridge holder. Also making them longer results in heavier cartridges, bigger guns and much more frustration-heavy prototyping. How can I improve the cartridge power and range without blowing up the size? Maybe by using different rubber band guidings, rolls and so on. I could remember the exact result of previous prototypes... But judging from how all cartridges looked in the end, this is probably totally useless. So that's what I know from the last time I experimented: adding constant stretching to the rubber band doesn't affect range. Thinking in terms of bows, I read about steel bows and their less powerful shot compared to more flexible bows. So it seems that only the stretch length matters for range. Hm, this would effectively make all tries to reduce to bullet length useless unless I can find a way to guide the bullet non-linear to save overall length...

Sounds logcal to me. To more you can speed up the bullet in one direction you won't loose any power due to redirection. And since it's accelerates longer than with a shorter stretching, there is of course more speed. I also doubt that another material will server better than rubber cause rubber is the only way to keep the Lego pieces together. If I'd use another material, it would bend the whole construction cause it requires more force to pull. Only a thicker rubber band may server better by increasing the pressure on most parts. But wait, that's where the trade-off comes in, right? Yep, I think that's it. But geez, fuck it with those rubber bands. You never get the shit you want cause they are made for completely different things, not for shooting bricks and so on.

So there it ends, fine. Damnit. I may find someone who can help me improving performance without simply expanding the cartridge length all the time.



Since I need constant occupation to keep myself socially acceptable, I went once again from program design to Lego guns. So far, I did some major changes in the trigger component to fit grip and stock better. I also made the whole stock block more lightweight and ergonomic, does quite nicely fit my hand without getting in the way. It's basically a big thumbhole attached to the previous pistol grip (made it more "anit-skid", not sure whether to translation is correct here) with some minor modifications to make it usable for both right and left hand. Looks quite nice I have to say. I started to make an all-in-one cartridge holder right after the thumbhole, but got quickly turned off by how the bullet bounce back and forth when there are less cartridges in then the possible maximum allows. So I'm gonna replace it with a set of chambers, one for each cartridge, and design like an external unit. So I can simply replace it with a longer version or maybe completely detach the stock if I want.

Another idea I got when thinking about is that I could add a better (and longer) iron sight system when using the usually not occupied length of the stock. I hope to store atleast six cartridges there, so maybe 8 in total when also filling the chambers. This makes plenty of room for sophisticated iron sights or even a little scope with limited effectiveness! A chamber requires atleast 4 studs, that makes 4 * 6 =24 studs length for adding a better aiming system and a comb. The best Idea in case of the comb is (I think) to combine it with the cartridge holder cover. I can round it with smooth plates from newer models I used for grip parts since my third Lego gun ever. So I don't need to lean my precious face (ahaha, what a joke...) against edges. But I'm not sure how to comfortably combine those planned, longer iron sights with cocked hammers/firing pins. Quite long when fully out, I'll need to place them lower than the sights, making it a bit more annoying to operate. Whatever. I can still make the sights foldable, so cocking can still a joy.

And since this stupid browser keeps crashing with two blogger pages open, I simply stop writing at this point.

Got it

Yes, I found an interesting solution to using different calling conventions dynamically inside the program:

void a() {}

int main() {
void (*myfunc)(void) __attribute__((stdcall));
myfunc = a;

You effectively declare your function pointers and add the special __attribute__ notation to mark a specific flag used by the compiler. In case of calling conventions, you can simply add the desired convention as a word. Replacing the "stdcall" convention with "cdecl" does give no warning (opposed to the code above), since cdecl is the standard C calling convention. Quite interesting, indeed. So what's still left is to figure out how to pass parameters based on C code. I thought about exploiting variadic parameters, but these require atleast one other parameter. Too bad! As of standard cdecl calls, this is the only way to randomly put stuff on the stack. Shit. *sigh* Ok, it seems that this idea totally sucks and that I don't really know how figure out a solution without leaving C. Fuck it, seriously. Maybe writing the bytecode executer completely using assembler? This would limit me to a single architecture in the beginning. But atleast I'd be able to code them without problems.

Hmpf. Stuck again. I better really leave this for a few days.


Think I got it, atleast for Linux. So far, it seems possible for Linux to load, access and free libraries with only 4 functions to call! It's exactly like how I know it from my old Purebasic experiences. However, this isn't portable and specific. There exist libraries out there delivering all functionality to do this crossplatform, but I'm rather looking for a small and specialized library exactly made for loading and iterating through library functions. The bad thing about it is, that if you wan't to also get the parameter types, you won't have any luck. It's rather on assembly/machine level, so all parameter operations are done using their own calling convention. In the case of C, it's crucial cause I'll probably only using C libraries. It's interesting to finally find some informations about calling convention cause so often you read stuff like "_stdcall" or "cdecl" in source codes and you don't know that these actually flags so say the compiler what calling convetion to use here. So my language ones again adds a more compiler-specific element to it: calling conventions. I know I can simulate these using inline ASM. And I guess it's also quite portable when using only push and pop or so. But there almost always registers involved - I can't get around using architecture-specific commands there. But there more I try, the better and cleaner it gets. So we have a way to load and get library functions by name, their addresses and a fixed format for calling them. So our only command, namely "input > module > output" (output < module < input, respectively) is required to do things there. Quite interesting, a programming language only able to handle sequences, types, symbols, addresses and call functions! I bet this is the most horrible joke for a dozen of people out there. I still like coding C or C++, so combining the scripting language and libraries written in these two languages should make a fine combination (not only for bytecode execution, but also for the export-to-C thing as I don't need to rewrite my codes in for the other language). Quite a useless base without beeing able to decide what calling convention to use. It's usually all static in C, so dynamic access isn't possible as far as I know. Hm, this makes things more difficult. Not to say impossible without assembler or libraries/macros for special function calls. I read some articles about it and it seems that GCC doesn't do well with supporting different calling conventions. A wicked situation, indeed. Maybe I'll get an idea later. So far, dynamically loading libraries this ways marks a very, very cool idea. If I ever get this done, I'm the new king of the lab.

On a sidenode, I did some more investigations about how and where stacks are implemented nowadays and discovered that the language FORTH does a quite interesting job of handling parameters and stacks. The way it excludes all kinds of registers for normal use is really something remarkable and exceptionally unique. I always disliked the fact that I don't always know where my variables go in C code (yes I know, show the assembler code blabla), so Forth does it quite nice by always saying they go to the stack. I'm sure that performance, in the case of Forth's stack handling and C's usual register chaos for comparison, bases entirely on how the underlying machine handles them. But with some optimization for specific cases, I bet both concepts are equal and Forth will probably win the simplicity prize. So all in all I like the idea of it enough to keep in my head for later use. It's too bad that there's no really portable assembler nowadays. It should be something really simple, like only giving commands available for all commong machines while giving the option to use specific ones. Oh well, that race never ends. However, I still hope that I'll be able to improve the world of programming languages in this case by representing a more diverse set of calculation concepts.
I may use inline assembler to call functions in a custom format. Shouldn't be hard, watching for the few needed commands there. Though I might find a better solution it, maybe a library that already did all this stuff for me and I don't need to worry about playing with those "precious parts" of dynamically linking and calling.

Better than computer in computer

Screw this with the Computer in Computer idea, I've got a better solution. I figured that all this stuff with virtual hardware components can, in normal C or C++ programming, be replaced with some simple classes of course. Too bad you need to recompile it. So I asked myself: How to connect modules with the bytecode execution? How to get of recompiling the bytecode executer everything you want to add another module? It hit me like a slice of lemon wrapped around a gold brick: dynamically loaded libraries. I can remember that, in the first programming language I ever wrote, I used a command to load and assign a DLL file to a name. You could simply prefix the name followed a colon and add the desired function. This simple system allowed the user to randomly call functions by the names found inside the DLL files. Since the library I used for it simply pushed parameters on the stack, I think it's save to assume that they were loaded directly to RAM and then called with no big performance deal. Some people found it pretty cool and now I see where it fulfills it's role in my next programming language. So I can screw the whole instruction set/hardware system and represent everything as a dynamically loaded library. I don't how this is archievable in Linux architectures and how I can keep this system portable, but I can image some cool things using this. But still, every command would be a function call. When exporting to C code I better replace them with actual C code instead of function calls. I think I can solve this using special funcs in the DLL, too. Who knows. Let's see how this is going under Linux and Mac OS.


Computer executing computer

I forgot to take my laptop with me and had to waste around four hours while waiting on the lecture. During these four hours I figured out how my idea of a virtual computer (in every facet) might lead to a more interesting idea involving fixed hardware setups placable by the user and then testing how the software will work with the new restrictions or components. I don't intend to do any serious virtualization technology, rather a virtual (sand)box for testing exotic instructions sets and almost impossible hardware functionalities. And figured out that not every cool idea would be efficient enough for too instruction-heavy programs. This is mainly due to the fact that if I want a completely modular system with dynamic interfaces between them, it wouldn't work as well as when writing specialized commands working with built-in components (the curse of beeing dynamic). But that doesn't really matter here, as it serves as a completely customizable test bed and as a bytecode executer for my programming language. It's really a lovely idea to simulate instructions, execute generated code and and export it to C code all at once. And the more you test and extend your instruction set with things actually useful to what you want to program with it, the more you're able to seperate them. I'm still not sure how to combine two seperate instruction sets without two seperate virtual CPUs, but I'll also find a solution for that. But since it's a totally virtual and fictive environment, it should be possible to wire all components together and represent their interfaces all at once. Still, that's probably not how it will work. Every hardware component/module would need it's own code. A normal RAM is a huge block of in/out memory, a CPU takes commands and so on. Wouldn't I need to wire them independently? A CPU has also connections to the RAM and other components. I may say that one could also simulate the controller and circuits, but that's a bit over the top I think. What I want is to have a set of abstracted components with a simple and address-based interface. So it's probably the best to enable the CPU to initially list all connected components so one can use them from the bytecode. Hm, yeah. That might be a good idea. The bytecode itself will be crucial for the CPU, as one will may need to operate without any RAM or components attached (if the setup doesn't feature any of them). Some thoughts made me realize that it's probably also possible to split all instructions sets by having a central CPU only there for sending and receiving data from other, more specialized CPUs for integer or float processing, DSP calculations, etc. This way one could step-by-step expand the system while letting the CPU do only the things it was made for. But wait, it's garbage to call these CPUs. They would be like ALUs or so, parts of the instruction set. You see, depending on what logic you put inside each component, there is the possibility to go deeper or keep it more compact. For example, one could also put a single gameboy CPU inside a component. And you don't even not to split the RAM from it, simply integrate it and it serves as a dumb, specialized bytecode executer. I think depending on the performance of communicating between different components, I might create specialized ones (they work like in reallife this way: the farther they are away from the processor they are used in, the longer time it takes to access them).

Hm, sounds like a good sum-up. I don't care about something like that beeing already existent. The cool thing is, that this is designed to also work when exporting it to C code. I know that the bytecode and the syntax of my programming language in general will be quite bizarre compared to C-like languages or others. Then again, it's made in a way I alway wished to see programming languages: as it works internally without getting ugly, like assembler. I reduced the formal syntax enough to look like lisp with some angle brackets as parameter notation. There won't be any special symbols and no different angle types anymore. Just (module) names and in/out parameters. I'll then provide compile-time functionalities like marking sequence indices, inserting bytecode in the current line and so on. I think that's the best way to tackle it. Bytecode generation/inlining will be problematic, as I'd need to execute the code for generating with an executer (which I'm then writing the code for). So I may design the API without bytecode generation first to add it later. Though I'm wondering what the execution environment/system should then look like. The point is that is could theoretically be possible to use all kinds of instructions sets inside the bytecode generator and accessing whatever hardware you may want to generate it. But where to define this environment? I think that's another thing I need to add the bytecode: environment requirements. You send what you want, the generator (or any other) checks whether the ressources are there, shutting done if not. Hmmm, difficult! But I guess I could also wrap it again and say that you can create a compile environment inside the bytecode using special commands and let the generators run the programs you defined somewhere in the original bytecode... That's getting complicated to explain, but the idea is to drop all strange inbetween stages and include the possiblity to create environment using the bytecode. So you start the first bytecode with no environment and then another evironment using special commands and feed the latter with functions for bytecode generation and the final code itself that you want to use after it became generated. So you start one environment with a generic code for generating bytecode, save the temporary result and run it from the final enviroment.

A bit like normal programming, if not more complicated. In normal programming terms it becomes an own preprocessor for implementing proper code generation for a language without (like C). So yeah, it's just explained complicated and totally blown up. But it's way smarter. Could you simply extend your preprocessor during runtime with more memory or a debug interface for later bug hunting? Probably not. So instead of pimping the language, one does setup environments to extend the language with it's own possibilites and written in it's own code. Whoa, crazy. How can I only loose this knot in my head.

Getting a fast and conservative Gnome theme setup

I took the time to assemble a pretty responsive gtk/metacity setup for Gnome to reduce the drawing delay to more that just 50 or 60 fps from the usual Ubuntu themes. I used this benchmark table for gtk themes and also this one for metacity performance. I always preferred the classic Windows look, so it's no wonder that "Bluecurve" and "Bright" do the job for me to on both the aesthetical and performance side. It wasn't always like that. When I used Windows 2000 as a main system, I envied the guys having XP's look (I didn't install it for a number of reasons) but got quickly turned off as I was using it since the simple and classic interface was easier to grasp and performed better on my old machine. Looking at this benchmarks, it proves that those simple interface also give a minimal amount of screen delay you can also profit from (especially to check when an applications takes longer to react before redrawing).

As for icon rendering performance, simply choose one that's based on PNG files instead of SVG files, this way you get the fastest rendering performance. Font rendering is of course another major performance factor. It seems that most Linux fonts simply suck when rendering without any smoothing or blurring. I often use very small fonts, so using a non-smoothed setting does kind of destroy readability prettyness. That's why I prefer to leave the smoothing on, loosing a hefty bit of possible performance improvement.


Now let's go on back to guns

What a fabulously lazy day! Did nothing but keeping myself transported around 6 hours six in total, so I had a lot of time to spend and also came up with some more thoughts and about the next steps to take in my Lego gun design quest (also, there might be some mistakes in this post due to sleepyness). First of all, I want better ammunition. Maybe even bigger ones, as long as they give me better range and accuracy. Those tiny 3x3 cartridges are quit space-saving, but also don't do there job as reliable and painless as one would wish. Especially re-powering them requires patience and an accurate hand to reload them. I don't always mind doing so, so it happens to turn out differently. One idea to remove this was mentioned by me in another blog post, though this required some more space or even trickier construction (almost not possible in this scale). Not sure whether I can archive this in the current format, but 4x4 is simple too attractive in terms of firespace and extensibility. If I can get the best out of it (possibly buying newer and better rubbers), it deserves it's own gun model. My plan from now is to not take apart finished models but instead work towards a presentable design I can put behind the glasses in my locker. So that I can always show them off, review some of their parts and remember myself what I've already done. Since a new bullet design will be significantly bigger and longer than the current 3x3x13, I need to watch out for a potentially bigger "problem" when starting ANY design. But it's not always about the bullet. The trigger is important too and I don't want to keep this external trigger transporation like I'm using at the moment. And advancing into more sophisticated action system might be appropriate. What I learned is that planning too many features in one will result into too complex things, easily destroying the idea you had in mind. So if I want to get away from break-action designs, one-shot-per-barrel and so on, a good idea would be to just add another operation to alternate the chamber and not combining anything. So automatic cocking and chambering at once etc. Simply working up in the history of actually successful firearms. I did the muzzle loader, I did the cartridged breechloader and now I go the double-barreled cartridge gun done. Next step might be having preloaded chamber and alternate between them using a stable and strong mechanic, possibly involving gears. Don't know what it will be, but I have time to think about it. There's still a new bullet and triggerdesign wanting to be explored. Guns can be so exciting when do them by yourself. But I bet it's like with everything self you created and designed on your own. The lovely vaste fields of custom technology always motivates me.

I had to resist adding minor modifications and improvements here and there in the latest model. Plastic gunsmithing can be quite addictive when it comes to small and qick successes, like for everything else. I added a two-color red/green iron sight since I currently don't have the room for adding scope rings or so. I might extend this using one behind the stock or on the lock itself. There is probably plenty of room to get it done this. But what's bugging me is that, since the lock is big and long, I can't simply throw out the cartridges using gravitation anymore. In unlocked and opened state, it hinders the bullets from using a special pseudo rail-like construct I added to get them sliding out when you tilt the gun. I loved it when the lock wasn't there, so I'll probably a rubber somewhere to keep it up and get this kind of extrator back.


Today I took me the time to do no intensive thinking or whatever else stuff requiring my attention and/or preventing me from getting any sleep. I think I deserved it since everything went so well the last days. Dunday and monday won't be different - an easter weekend I usually spend this way. However, after some washing the dishes I a phenomenal idea. I'm still tinkering with my programming language and so on. Mostly cause I'm a lazy bum and cause I can't decide how to design the bytecode in detail. I slowly begin to understand, why it's common to simulate a reality-based instruction set instead of a custom one. Not only that it makes it more comparable to native execution and thus compilable. It's also a comftable to think about the execution in general. You have ressources, their are instructions and then there's memory. Every program uses it's interface to the computer (via OS or directly), so a virtual machine just gives an interfce for the bytecode it can work with. I always have so many ideas involving a bare environment with nothing but the instruction set and ressources accessible using special commands. So essentially not even a BIOS, just an abstract machine running in a set environment. Taking this as a base, you can do anything you want don't need to worry about the structures behind. Almost like an emulator, except that you don't try to adapt actual architectures. One could write it's own OS from the ground, get an excuse for making software rendering and so on. So this is idea. I write my own fictive computer inside a computer and will be able to experiment in every way I want. The interesting thing is, that all these "ressources" one could use in such a system would require an environment given by the virtual machine itself. So a monitor would be a simple screen opened by SDL/OpenGL/whatever, a RAM stick would be a bigger memory block allocated by the VM and every other ressource in the same way. What they all share is that it's alway a kind of "hardwired" interface to other programs representing the hardware. So a driver for the VM to control libraries outside the VM (therefore in the OS) which then again use drivers that send it to the real hardware. Sounds complicated, but is just a different way of interpreting the processes already going on in existing systems and VMs. The Point is, that in a VM that represents those things like memory and external code as hardware, it's possible to do some really interesting things (especially cause you can see those hardware ressources (which are actually other pieces of code) as standardized blackbox-alike interfaces) with simple abstraction and almost atomic representation of basic tasks inside a program. Some careful decisions inside the VM instruction set might include a "plug and play" ressource access system. That means that it should be possible to check for newly plugged devices such as additional monitors (=screens or just bitmaps, memory etc) or some completely abstract things: a "callback device" for interprocess communication or calls over network, a new processing unit for parallel processing and so on. What I'd usually try to write as a set of specialized and hardly abstract system could be written in a more simple and generic way. I know this might a equally hard to design and imagine as other approaches, but it's a step forward. I believe in a... let's say future, where it's possible to ease ressource handling and reduce redundancy in code. It's my idea of a system that's able to handle whatever is coming in from whatever location and use in an all-same way. Goodbye heavily specialized code, goodbye cloud of individual solutions.

Oh man, I kind of flow in another level consciousness level today. But you must admit, the idea is pretty cool. Not sure whether I covered the whole bandwidth of it in here, but it's a goal to work forward and it has almost nothing to do with my current programming language progress except that I should be a part of it. I always tried to figure a nice solution for calling external functions, but this one is the best so far I think. If you 3D graphics, you can simply create an interface definition and you can access it no matter what hardware, driver, graphics engine or whatever is behind. It WILL require many small programs with very low latency to get this efficiently. But converting the whole bytecode thing into C code would simply make it possible to include all the handlers and then having no latency when calling it's functions. I think that's an almost perfect integration into the language I had in mind. No weird library concepts, just an abstract computer handling data in a highly regular way. Amen.

Last step

Some tests I did proved that it shoots much farther without any barrel, so the design is so far the best one in my entire line of Lego guns. However, there's still something odd about the bullets: depending on how carefully you powered the cartrigde, the more or less accurate is it. I don't like that, but I won't be able to change it. It's not that I want to shoot millions of bullets with it. But once more it is an example for how important the cartridg in my models is. I can remember having similar problems with the previous 4x4 design where careful powering was crucial to accuracy. The rubber pushes the bullet forward, the bullet then accelerate forward depending on exactly how straight it was placed in the rubber band. A workaround for this would be to use a rolling element which could turn the angle between rubber and bullet so that nothing will disturb the accuracy except everything else. Nice idea, however, it needs a bigger bullet. Or atleast one with s rotating, round element at the end. hm, maybe it doesn't need to be in the bullet but before the bullet hooker comes. Yes, that could work. Somehow. Need to test that. The more finished I have in my history of Lego guns, the better their parts become. Of course, the assembly has it's weight, too. But creating frames and grips just doesn't add anything to the effectiveness and accuracy at this stage. If I ever get to the point where everything works as satisfiable as possible, there's probably a point where it's otherwise.

Written the stars it is! If I weren't so sleepy today...


Milestone reached

Out of a coincidence, I started to write a blog entry but forgot to post it. So now there a two news in one, bringing a fully functional double-barrelled Lego gun with some kind of break action. Oh no, it really is one. It was tricky to get by, but atlast it only required one non-working prototype for breech locking. However, there's more to tell than just this. I'll summerize it:
  • added grip
  • decreased trigger sloppyness
  • added a break-action chamber/barrel design
  • chamber pushes cartrigdes out of the barrel when not locked
  • locking is done by a giant hook going from upper chamber part behind the trigger group
  • improved trigger reliability by adding supporting curves
And some other details. The most interesting thing is the lock. It's a turnable part almost as long as the gun with hooks gripping into the gun's top. It keeps the chambers from "gravitationally" opening, assited by another, this time rubberband-powered, hook at the end that goes between the levers used to cock the hammers. So it's quite big and quite stable. Atleast as stable as it can go with such an action and Lego parts. I took me whole day and half night to get it done, so maybe I'll post some pics tomorrow. Or I'll extend it before. I don't know. I only know that frogs running over my keyboard still want to bake me a cake for Harry Potter's birthday party tomorrow.
Today is a good day! Atleast when judging from how I woke up today. However, I already found and fixed a mistake when trying to fire the bullets. I kind of twisted the rubberbands wrong and now I'm having a pretty responsive and qickly triggering Lego gun. Of course, the magazine is still sloppy, but I'll change that. I thought about how one could force the bullet to stay in one place and I think I found a good solution for that. It helped to experiment with slide-out mechanics - this can be used to lengthen the chamber itself on several occasions and then shortening it back. So the idea is to make a chamber which is shorter by default, stretchable and thus able to push bullets towards the lock. The only action I can think of that'd useful there is break-action. It allows the bullets to pop out will push it into the chamber when closing the breech. But uhhh, it's probably not so nice to chamber with a bullet potentially blocking while rotating the chambers.

Hmm... that's difficult! I can only think of something that's a) open from the top or bottom and b) pushes the bullet towards the barrel in one action, Let's see what I'll be able to come up with. It seems like a simple mechanical design question to me.
I should have known that. I continued my Lego work after a rather exhausting day and managed to basically finish the slide-out chambers. Unfortunately, it doesn't work as expected. The asymetric layout, shaky rubber band setup... All just not as good as I imagined before. I got it quite small compared a very, very early prototype. But still, with foreend and little levers for opening/closing the chambers it'll still weight a LOT of bricks. And even in this very moment I wouldn't want to consider it light. It's easy to give it up, but progress doesn't come from keeping outdated archievements. If I want to have a gun with good handling, I better drop everything going nuts prototypey. So what's left then? Break-action (which I ignorantly put aside), pseudo falling-block (having the bullet as the only falling element) and nothing else. And cause it's pretty late in here and some morons in the neighbourhood decided to steel my healthy beauty sleep, I need to go to bed. So it's up to next morning. All in all I need to find a way to a) open/close the chamber for cartridge exchange and b) lock it somehow. Locking on the top would be difficult - sights and firing pins/hammers are in the way. Locking on the side would be possible, though it' be the easiest to simple build a flap in front of the muzzle and load from there. That may be pretty uncool and almost the same like all models before, but it does atleast works without any problems. But there are also other possible solutions. I still kind of like the slide-out idea, though I know it doesn't work so good with rubbers. The more I think about it, the better it seems to completely drop the idea and also abandon it for later models if there isn't enough room to properly include a rack and pinion system. The problem with all these slide mechanics is that they need room I don't have. But I can put stick stuff at the frame and hope it locks properly. Whatever way is the most possible for it, my eyes closing in around two minutes, so better hurry before I fall asleep in front my computer.


Personal freedom, low-level programming and misguided old farts

When I think about what I really miss when studying informatics than it is a good relation between those rather modern-thinking developers using megabytes of hidden sourcecode within a single call and those who appreciate direct control using languages more close to hardware. From semester to another the latter ones begin to cease and you wonder where the classic and quality values of typical development went. In essence, they just speak more but don't get any actually new code done. They use existing technology to create irrelevantly trivial tasks and excuse their behaviour as science. To be honest, I don't like the term science and associated possible meanings, but I LOVE creating new approaches for already done "solutions" and rethink them in a more clean and atomic manner. Of course, this takes time, is more critical and error-prone - but in the end I feel better because I found some way to be close to the computer, it's initial purpose and knowledge about what's going on behind. It maybe that my lecturers do already know that, but it's questionable whether they actually believe it's of use to know that. I've seen their publication, their ways to create software and they simply work always on the same upper level of absraction and don't want to back off just one step. Either they have traumas from earlier assembler or even C experiences or they really never learned enough about it. It's like they ignore them by default. I can't look into their heads and I also don't want to. So it may be reasonable and all that, beeing a sign of dwelling too deep into their reasons.
However, I feel bound to the other side. Even if I'll never be able to program like I do know, I can do it on my own, bringing light to where once was darkness - to me and maybe to others. I started to rewrite things from the standard C library with a different philosophy, thinking more about compactness for the bytecode runtime I'll write for my own language. It's all about putting the right things in the right places. And function calls are always external.


Web shit

Web technology is totally blown. Guys behind invent abbreviations and synonyms as they go using totally silly concatenations. That's why there are prefessors and doctors only made by knowing all them though they don't even know how a computer works in detail. It's sad it has come so far and the whole academic degree system is totally useless to me. You can a degree above master with just about every stupid thing and nobody will ask you about how know about the stuff that's behind the stuff you're looking behind. It's sure that my software engineering lecturer doesn't know anything anymore about programming below Java. She seems to believe in a world with only web services, online stores and database transactions. And I bet she wouldn't even understand how the Java compiler she's using works.

Silly cunt.


Some quick ideas

Some ideas about what to add as extra or enhancement to the Lego gun itself came to my head and I think it's the best to sum them in a list instead of letting them float and then disappear:
  • cartridge storage in stock (store a multiple of two inside the stock body, can be opened/closed with a flap or latch)
  • detachable stock with thumb hole, converting the pistol grip
  • replace planned break action with chamber sliding out of the barrel, dropping cartridges on button push (per barrel) and chambering with a single push/insertion
  • flippable iron sight for each barrel (no barrel calibration possible with Lego)
  • maybe replace iron sight with some kind of primitive scope
  • or in other words, keep to scoping as modular as the rest
  • hence, detaching all other parts, too and storing them more compact
  • keeping any locking mechanic inside the barrel/chamber grip (no barrel, thus only chamber)
That's all what I came up with. I've made many different models so far, but they also ended up using some things here and there that could be made better by using the space inside stocks and grips more efficiently. I'll also figure out how useful and, most important, how possible the slide-out chamber would be. Since there will be enough room under the chamber, it might be a good idea to think about using the space for such mechanics. Though I'm not sure where to put the push buttons then. Maybe it will simply not be possible due to space constraint, who knows. Anyway, the cartrigde storage in stock is what might be the most possibble feature I think. It's a side-by-side gun, so there's plenty of room without bloating the stock to look bigger than the gun itself. I love thus buttstock cartridges holders. But my cartridges are much bigger than normal ones and I don't need to watch out for recoil. So the stock looses it's recoil transfer ability and there no logical for using the now free space, I think. However, I might only be able to store a maximum of four cartriges there (surprisingly, I only have four cartridges available so far). It'd be a length of 12 studs and 18 studs for two more (making 6 then). Plus seperation elements it's 15 studs minimum. But I should not concentrace on it at first, otherwise I might end up with extras instead of function.

Oh and I've also seen a rather rare locking mechanic in a movie lately. It looked rather non-functional, but consisted of pullable barrel, revealing and halfing the chambers. So you put in your cartridges, close the lock and it's ready to shoot. Seemed a bit doubtful to me. It's probably not able to handle other things than shotgun shells or so.

Ham er

Yay, hammers and trigger are almost final I think. I tried to use gears, but they loose power if not a proper shell. Impossible to use cause I needed an external connection between the hammer and the trigger. So I simply made a rather big transmitter directly connected the snapping hammer element. However, I just need to build the second one and click them together. Quite modular at the moment and I hope I can this style of expansion for all other modules, too. So it's time to design a trigger guard, a lock (I thought about a proper break-open) and a stock or atleast a pistol grip. I love these design parts! They don't carry too much annoying fails all the time. You can choose whatever you want and merge them to every combination coming to your head. This time I want to make it completely colored. I'm currently reading a about more interesting actions for single-shot rifles (mostly applicable to multiple barrels) and now that I solved the hammer problem I get more ideas, more urge to find more different, possible designs. I better write down how to assembler the hammer part along with the bullet design, so that I don't need to reinvent them later.



Hooray! I had enough time yesterday and build a hefty trigger component with multiple individually cockable hammers, occupying only a 3*4*z each depending on how much power you want to put into the hammering. So when combining multiple trigger frames you can save one stud in width for each added frame. Thinking about where to put the gears for triggering. Maybe I don't even gears, who knows. Without gears, the triggering goes probably easier. But with gears I'm able to redirect the triggering to a random place! Depending on how whether I want a side-by-side or over/under barrel, I might rebuild it with ease. It's pretty no problem to do so. If I think about... initially I thought side-by-side would be smaller, but maybe I did just not have the idea I have now. Hm, there are so many variants to choose! But some are probably easier and simpler than others. However, I bet I'll end up having either too many gears for comftable triggering or just a heavy frame/case. Hm, the heavy case shouldn't mind me, some weight is better for aiming.

Oh and there's also break action or another thing for it. While writing this I got a simple idea that works by simply muzzle-loading and putting a lock on top of it. Not as elegant, but in case of part recession I might consider using it...


good, bad, dunno

I'm glad I rethought everything and came up with another concept based on my old bullet designs. I did some simple tests, refined the locking mechanic to work for greater rubber band forces and whatever not. Now it's some kind of hammer working like a bullet with a hopefully gear-powered primer (like I used them before). It trigger a bullet with ease, You can pull with a handle... Everything worked fine so far! And the best is that it is very small, as long and wide as a normal bullet.

Though everything is fine, I'm a bit pissed off today. Meeeh, it's turning summer here and I hate it soooo much to not be able to wear a jacket while "traveling" from A to B. Cities stink so much, you'll regret running around without anything to prevent surrounding smell filling every single pore of your body. However, I have 3/4 days in a week I need to go somewhere, so it's definitely not as bad as always going out for a longer time.

Bah, summer. I like the sun, but I don't like how warm it always gets then.


The more I think about turning the bolt system into something painless to build, the more it goes away from it's bolt design. Either way a nice-to-build gun will turn out into something less complicated where the actual triggering and chambering is done differently. I'll probably justz keep the bolt lying 'round somewhere to remember myself how it worked and how much hard I worked on choosing the right springs... So it's better to focus on a reliable and modular transport of trigger action to fire pin release. If I have this done (and that means in a way I can put it somewhere), it might be the best solution for later models. I mean I also did this with the bullet. Now that the bullet is ready since a while, I really need a fitting triggering that doesn't work on simply pressing somewhere. Something like a hammer, not like in typical firearms. I tried some designs, but all of them could work better if they where essentially like the triggers + projectile releasers I created before the new bullet design. So why not take and alter it so that it doesn't fire projectiles, but the firing pin til a certain spot? Atleast it will make it possible for me to NOT think about unreliably small solution packed with so much functionality and special spots that nobody really wants to build or repair on their own.

Simplicity and reliability. What once worked, can also work again. Two essential facts to keep in mind when making mechanics.


Fuck it, I'm gonna screw this whole concept and simplify to bolt to not use any of this goddamn extractor. Lego can be really bitchy sometimes... On time it works, the other time it doesn't. I wish I could simply make molds and cast my own pieces. But this would qualify as something completely different without having the convenience to simply by new parts in a shop if I need more of them. Also, you can't test anything this way. A frigging shit I tell ya. However, without the extraction part I'll leave everything to gravity and load from the bottom, giving it a clean and closed upper part. I thought I could get it right this time. But it seems that this doesn't work like that. *sigh* Why isn't it possible without custom parts. I mean it's actually so simple to build a gun, but so complicated to make a gun that does more than a prehistoric stone axe. And even worse, you'll end up making everything so big and limited using Lego. Ok, ok. Better to come down and not throw everything away. I'll think about a new idea, a more modular one. I only need to configure some bits in the bolt, the frame itself is simpler due to my new technique (I used some frame parts I've barely used before, but they prove awesome for making 5x5 barrels). Maybe I can also combined the bolt idea with something different, more magazine-friendly. I really want to make this possible for me one day, no matter how many actions are necessary to operate the final model.

So I failed. Not too bad. Sometimes I really deserve it.



Sometimes, once in a while, I watch a good TV series I or someone else bough and drown myself in self in it's universe. Then, when everything's out of plot and playtime, you realized that know almost everything about every character in this series and you realize that you know more about them and their situation than you know about you. All the time when this comes to my head, I look around, seeing a fag sitting on a bed in his parent's house and making Lego guns if he's not playing videogames or working on something else geeky. You dad comes home, you see him looking old, almost with a touch of grey today and you just want to find a new life for yourself. You're used to the "standards" in your series, having what THEY do in mind and not what you did. I always did the stuff I think that is good for me and my future. I know how to make me happy in case I end up beeing sad. But nobody knows how to heal the facts of life dripping into the fabulous dream world you entered after inserting the first DVD of your beloved series.

I don't like coming back to reality so harsh. I better begin finding another series to get a fix til my schedule turns into a more "long away from home"-alike model. In those times I realize how awesome a boyfriend with the money to pay his own home would be. To bad I can't afford it without jobbing and then reducing the time I can work on getting better marks. But on the other hand - who wants to live with somebody just living in his home? Beeing a geek, a totally focussed and dreamy geek can be quite hard in a social way. Beeing a gay geek is again something completely different, not just another factor. Especially when it turns out that your beloved flame prefers to dig his nose in Lara Croft's cunt instead of other places more close to you. Sometimes I'd like to turn all game developers and character designers gay, so they don't create such virtual dreams of straight computer nerds.

We need more barely clothed heros with breastplates. Accompanied by their trusty, body-bound club made of 100% organic material. And yes, I know, that is not different from Lara Croft in the straight sense. I'm still a geek anyway, somehow I need to get satisfaction after those days of starving for a more love-coated life away from the typical gay scene I'm simply not following (not even here in Berlin) due to their general sillyness and culture. I begin to understand why there are so many internet relationships, people using Skype and whatever not stuff to see themselves with needing to get closer. So they don't to move their asses and can "simply" find someone without needing to dig too deep.

*sigh* Where are all the gay, glasses-wearing geeks when you need them. The stereotype tells there are as many as straight ones. And wearing a shield with "GAY STUDENTS INSERT HERE" on your back isn't truly a good idea to find them (I'm glad I didn't think of something like that...). Or it's me not seeing anything. This happens. Often.

Back and forth

So I created the gun body itself, beeing worried about how to stuff in, here and there... but as I was able to get closer to the final format, I noticed how it really isn't possible for me, in the current state and bullet format, to add any kind of magazine... The is that these bullet aren't really made to inserted in a bolt-action way. I designed them bullets to function compact and to slide horizontally. I also thought it would work nicely on a horizontal sliding, but not a combination of both, as it is in bolt-action rifle (the bullets come from the lower magazine, beeing held back by some limit in the clip or magazine until the bolt pushes them into the chamber, resulting in a mix of both directions). It hangs at this point and due to the piece choices chosen to make them as small as possible. So I guess I can't have everything at this moment. But I know it can probably work for a horizontal magazine. However, it might also work on a purely vertical magazine! The problem is, I think, just the combination of two directions and not a uniform one. If I can design a model purely based one direction or similar in "elevation" like a pumpgun, I think it can work better. Or even simply work... I dunno. In all cases, I'll will remove any resemblance to magazine-based designs and totally focus on a reliable and hangless operation/action.

I didn't think the magazined way of life could be so hard...

Finally a bit of Lego

So I was able to shut my monkey brain off and do something else instead of sitting infront of a computer screen and began to assembler some more bits of the longest in production gun model I'm working on. I got a good idea how to NOT care about implementing the lock inside the bolt itself. The point is, only if you compress the fire pin spring, you need to lock it somehow. If the shot was already fired, then the spring relaxed and you can open the lock without having to worry about it. I'm not certain how a real-world model handles this, but I also don't care as it doesn't matter for something with this "penetration level" of rather a pinch. However, removing the lock with a compressed spring would only result in triggering the bolt back in worst case, so nothing should happen I think. So the point is that you'd a) usually either unlock and pull the (ejecting) or b) push and lock the bolt. I designed my bolt end in a way that it's comftable to pull (similar to straight-pull bolt ends) and easy to push. But what most matters is that you can, in case of pushing, use only a part of the hand for pushing, so that the other fingers are able to operate a lock after compress the spring to it's max. Now it's time to think about locking in a larger way. I don't need to focus on tight designs, I can keep on using the frame. Better than before!


Never ever install any Microsoft Software

Especially not if it's something different than an operating system. I entered some kind of student thingy you can use to download their software for free and installed Visual Studio to look when it became more horrible or even maybe a bit less bad. But the more you install, the worse it becomes. I ended up having around 30 (!) individual installations just for testing this fucking thing. In the end, everything will stay, even after uninstallation except the IDE itself... Really, that's sooo bad, Microsoft. Sometimes I think all Windows users simply reinstall their system if something went wrong. The program itself is a complete farce - I still haven't found any way to NOT create a simple, local project with those stupid "Microsoft Team Foundation Server"s... HOW IN HELL IS SUPPOSED TO APPRECIATE THIS, EH!

I shouldn't complain, I knew the risk. Sometimes humans just do silly things, they want danger and trouble although they live in harmony with their surroundings and the spiritual nature of good development environments...


Design progress

Today was a very interesting day as I figured so many aspects of my programming languages design. Enough to that I brainstormed a major part of it's implemention and formal description (which is, if you already know what you want, not to hard to do at once). To my surprise, it turned out that I'd benefit more from seeing the language as something abstract, more reflexive than it was before. The essential concept of giving a program the ability to compile-time execute byte code that knows about names and types of parameters and the like is reflexion. Though not exactly during runtime, it's possible to put it in, too.

However, the approach I use to give the language it's generic features is afaik far far away from what C/C++ and other languages do. Instead of explicitely specifying each type and parameter for every function and adding functions instances as you need them, my approach is not convert it to implicite typing. Means you don't specify required types for input/output parameters but rather constraints about how the data it takes and gives should look like. Then, depending on the stuff passed as input and output, the bytecode compiler instanciates function bodies with the appropriate type informations to keep it as static as possible inside the final bytecode. So you will have 100% compatibility to normal C code and will be able to even use the output names and structures inside external header files, as long as the converter works flexible enough. And this implicite design brings also other questions like to how and it what manner types are to compare, how you can work with them, with reflexion, typeIDs during runtime etc... I came to this version when I was thinking about how to type and instanciate variables. So far, I got a very generic naming system done, that is part of a system to interpret sequences of bytecode as structures. So a long functions with variables and code in it will translate to a structure description, longer or shorter. Depending on how well I will be able to design the ways of checking for compatibility with other structures, it will translate to a mask usable for comparison. So taking this as a base for more sophisticated variable declarations creates the possibility to write code, structures and variables instanciation in the same syntax and same structure with NO massive ruleset required to parse it. There are a few rules and a few symbols combinable in a limited set of ways. The devil lies in generating and iterating through structures, making compilation a bit more calculation-intensive compared to rule checking. But that's not really something bringing down the time required for it. Most stuff is still done by the C converter later, so it's convenient to have an executable bytecode with less compiling on hand.

As you see, stuff's going on and well enough to say that it approximites an real programming language. I'll need to make some changes for the input/output parameter accesses another day, hm... More and more I think about how to take advantage of C libraries then. The problem is, executing bytecode doesn't give you the possibility to call C functions except if they are build into the executer. Sometimes it sounds better to create bytecode executers on demand, so that one will be able to execute the most common ones. Dunno, maybe I'll think about soo, but probably not. It's not that it's so essential for getting the code running here.

Against minecrafting

The title might sound a bit false, but I need to do something against this Minecraft addiction. I played more than three days with only pauses for food, sleep and pee. It has to stop RIGHT NOW. I can't believe how hilarious this must look. A grown man sitting infront of a screen and trying to build monster traps, Zen gardens, gold towers, land mines, sugar farms and whatever not in the end senseless stuff he can't just stop building. It's for sure the same thing I had with Diablo, Stalker and Fallout before - only that this game will always give you a new setup, making it incredibly addictive and tabula rasa at once. You can always start building, the possible things to do never stops. And even worse, the internet does add so much more information about how stuff works and so on. I still need to build a cannon, I still have no railroad system, didn't test a portal fast traveling system etc and so on. SO. MUCH. STUFF.

No, I need to do something against that! Today I was able to unchain myself from it for some hours and pixelated. Has been a long time since I did that with something deserving the "abstract art" category. Anyway, after this my head was clean from minecraftian thoughts and collected whatever stuff was floating in my head. And I found something interesting I might incorporate into my programming language. As the language will be translated to C and will have a build-int bytecode interpreter, everything program should, in theory, be able to execute bytecode if it uses those features. So why not extend this and do put the interpreter in, too? This is an interesting idea: A program that is able to a) generate and execute code in the language/bytecode it was written, b) parse it's own syntax due to recursion and a minimal tree structure in memory and c) supports combination of both to enable a build-in console-like functionality where you could thereoretically parse and execute user-written code during runtime. And a program that will be executed from a bytecode format will also completely know it's own code, making it effectively possible to create a program that improves or enhances itself over time... I like the idea of combining compiler, interpreter and resulting program. My current bytecode concept is very minimal, consisting of only a few things easily to include inside the a normal program with overhead I think. As long as I can keep the macros system up and running, it should be possible to continue with no further complications. The idea is getting better and better and the concept begins to take shape of a design document. And to implement a minimal but versatile parser/compiler inside the program is quite an interesting challenge - something I longed for a long time. Rendering and computer game technology is so boring cause everything's known and only takes time to test and implement. Earning your bread and butter this way is only interesting to me if there's a team you can work with, a set of people who know what the final result will be, so that you can focus and getting the stuff to work and feel that you really earned your money this time. But I don't want to generalize this - it get's interesting if you have tools and technology for experimenting on a higher, more abstract level. That's why it must be more fun to work an existing engine and already done concept to make it real with what have and what you can use.

However, I'm confident with this one.


Please just ONE alpha pixel

Editing individual alpha pixels in pixel art is a torture with modern graphics programs. Atleast when GIMP or Photoshop, it's all not made for pixelation. But well, the reason why I'm complaining is that can't just edit my minecraft skin in the way and with the program I want. I'm a longtime GraphicsGale user, but editing alpha channels was also luck and experimentation. In the end I forget it and need to figure it out later. So I just can't get my head accessories transparent and also tried Paint.NET. It's able to edit them individually as it seems, but kind of stupid in the sense that it handles color-only or alpha-only selections. So if you use the fill bucket, there's no way of filling a color's alpha value but an alpha value areas alpha value and so on. It's totally garbage in terms of interface decisions. So guess what I need to do one day? Right, making a pixelation program. And I'll NOT use any GUI toolkit for it, it'll be made of pixel-perfect 2D rendering. And with tools that are able to react on different channels as you've set them. A good pixel art programs consists imho of a very basic set of things but combined in a versatile and color channel-aware manner.

Computer graphics sucks so hard when it comes to such things. *sigh* I wonder if I should check out Pro Motion instead of GraphicsGale. Atleast you can pay it with Paypal instead of stupid credit cards... The reason why I haven't yet got a full version of GraphicsGale.

Mansion progress

Ugh, this game caught me again. So far I made a huge house with two floors. 3 rooms each and an entrance hall plus an occult room with a giant iron skull with lava flowing out of his mouth. I made a two block wide cable tray reaching from two bottom and lying between the rooms to wire all switches to the appropriate lights in the room and so on. It wasn't that easy to manage so many different circuits in such a tiny place (stacking vertically isn't always an option) and I still have have of the rooms left. And then I accidently blew up my entrance with the only dynamite block I was able to make, so I also have to reconstruct the main switch. Next time I'll simply use some kind of flint and steel fireplatch/torch light system and be happy with it. I know I wanted a completely wired house - there a many benefits: combinations locks for your treasure rooms, entertaining light shows, automatic on/off for room lights, etc... But this comes all at a cost and most of the time it's to sacrifice bright light and daylight, too. Even a single torch in a huge room does lighting better than an army of redstone torches. And it looks quite depressing, making it rather useless for a warm home you wish to come back to after an exhausting mine raid. And it also takes a LOT of room to wire up correctly. Not to mention the logic you need to make for automatic light switches! I used a memory cell-alike construct I found in the Minecraft wiki and a set of atleast two pressure plates for each one block wide entrance to the room. The bad thing about is that I already had double doors, so the wiring to keep preasure plates for door opening AND the for the memory cells would consume a lot of time - I dropped the automatic lights completely and went back to simple switches. But even then, making a simple OR for two switches can be challenging with already a shitload of cables in a 2xNxM space. Got exhausting over time and the poor lighting did not do me any favor. I'd be glad to have some kind of light bulb, so I don't need to wire so many of them just to get room barely visible.

So I'll simply put the roof and then move on to another home to create. I might make something that's on the side of a mountain instead on it. So I can life with the best view and don't need to worry about space for future wiring (I can simply keep the walls on the outside open and with free view on the planes while putting all wiring into the mountain itself). Oh and I need to make a monster trap. I recently found some gunpowder bits and think it's worth farming creepers just to get more TNT, build cannons and so (it's incredible that you can actually create such a thing). But I'll make it out of obsidian and rather small, so I don't waste so much TNT when shooting. However, I ccould also build a set of lined-up dispensers! Yeah, I'll make a fucking fortress out of it. With lava, spikes and the like.



The fastest VM

Oh my fucking god, this article really creeped me out by the fact that such a .NET blackbox compiler could outperform pure C code in terms of writing a virtual machine. I couldn't believe my eyes! But wow, wait - is that really true? Does it really perform all code in realtime or does it optimize it away like a normal smart C/C++ like GCC would do it? To my luck I found another series of comments besided the in the original one. And yes, it isn't even close to what the C code does. I already wondered what this "Emit" command was and how it behaved. But one single comment revealed that this command is part of system to directely executed a special bytecode that'll then get compiled and executed as native assembly. Combined with the .NET compiles probably also smart setup it results in native code and even better, probably a runtime of 0 secs cause it's able to detect statistical depencies and that the used set of VM instructions in always fixed and thus not necessary to execute during runtime.

It really creeped me out, seriously. All the time I read stuff like that, my world crackles a bit and I need to fix with a bunch of facts behind the mirror. If that's what people love about those languages, compilers etc - I don't see much future in terms of knowing what the computer really does. I don't like blackboxes. I can trust technology that simple but efficient by design and doesn't depend on a single monolithic monster but works as good as possible without taking too much complexity. And this VB.NET compiler seems like such a monster to me. Maybe it's just to far away from what I am used to and what I crave to work well. I hope I'll never need to program using .NET or so. Creepy stuff it does, you never really know when and how.


Aw, man. Nothing is more boring than a lecturer only sending his partner to his first meeting with the students. It means no real introduction by guy who'll actually do the stuff for the rest of the semester but instead you get something that's totally unrelated. Hmph.

Anyway, I could not build any Lego guns there, so I made some more notes and thoughts about the programming language I planned some time ago. I also wrote a blog post with more specific syntax and details behind, but I lost it eventually. So I'm quite far, farther than I thought. The basic syntax of function calls (the most important element in this language), how to define and declare stuff etc. You'll get the idea behind sending and receiving data to and from functions if you're familiar with modular synthesizer: they have input and output slots. It's designed to to get rid of the problem of designing inline function with reference or pointer parameters. Instead of always beeing aware of how they should be designed to tell it even the dumbest optimizer to inline, you can specify it by yourself and effectively passing zero parameters as all inputs and outputs are, when inlining, direct insertions of values put in by the calling line. I never the math-like function syntax of most programming languages. It often limites you to the use of mathematical notations, only one return type on a side and makes the language more difficult to parse with the addition of operators. I often think that I now have a set of variables, listing them as parameters as I type and then looking for the correct functions I want to call. You'll need to insert it before, you can't write from left to write in the way I think when writing quick or simple things. Yes, I know! It's just sugar on my cake, but I love sugar and so I do want it. Anyway, the actually interesting point beside notation is that I found some surprisingly smart way of operating with variable parameters during compilation and runtime. Since I only have some brackets, symbol names, ";" and "<", ">", it's quite easy to add more essential features with additional symbols. So the thing I talking about is the insertion of macros using the {} brackets. Not macros in the sense of C, no. But rather complete compile-time code blocks. So you can for example check for wrong bounds, wrong types etc - functions don't have a specified interface, they are rather declaration-less except for the name. So to check for correct parameter types you use a macro that'll access global, language-defined objects with information about how many input and output parameters are there, what type they are , whether they are variables, literals, arrays, etc... even their names and the name of the function! That said, you can check parameters with a single line by using logic and type equality. At this point, it wouldn't base on any rtti data but only the data the compiler also knows. It makes me amped to even think about it. It makes a couple of things easier: debugging (get function and variable names, even calling position), reflexion (you could take a look at the call tree, the context and such), auto decision between fixed and dynamic values (whether it's better to unroll a loop or so) and whatever not. So whatever is normally done by the language during runtime or by it's optimizers can, to a larger part, be done by such a system while still looking this the fixed version you'd normally write. But it requires the compiler to create function definitions by their call and thus a lot more evaluation and so on. Not sure where to put this macro - in the function body where it has the highest relevance? Also, when to instantiate can only depend on the number of input/output/types combination. So each different syntax will create an instantiation if the macro doesn't call back to the compiler and stop compilation process. It's also uncertain whether it makes sense to allow the macros to generate parsable strings or bytecode directly. I think the parsing stuff should be done once, cause it'd result in exponentially more work as every generated piece of code needs to be parsed. So I better move on continuing the bytecode/code insertion part inside the language and how to access the compiler structures. I think using the classic object.attribute syntax isn't necessary as I can abuse the in/out syntax for this, too. And on the plus side it gives you equal attribute/property access - x and doWeirdStuff are accessed/called/set/read in the same syntax, no need to introduce another element.

It's a language for lazy bums not interested in learning too many syntax rules and people who like to reduce every line of source code spent to overview's sake. That makes a reduced but quite ugly to look at code. It's not made for readability or relying on existing conventions. For example, "a<(<0));" would be the same as "a=b+(c==b?c:0)" in C. Everythings a function that'll eventually converted back to the C expression but delivering other features you don't have in C, especially those whether multiple go in and out, where code looks often the same but has only a few differences and so on. I'm convinced that the concept can prove worthy in reality, especially when the limitations of C can't help you expressing the code you really want in a time and cost efficient way.

However, future music and stuff. Back to doing anarchic stuff.