Reading News in the future!
Today the RSS feed reader I use called Liferea displayed something very strange. I’ve included a screenshot for you all to see.Yay for numbers wrapping around!
Today the RSS feed reader I use called Liferea displayed something very strange. I’ve included a screenshot for you all to see.Yay for numbers wrapping around!
As everyone should know by now, Thousand Parsec got accepted as a Google Summer of Code.
It’s been very hectic, but a load of fun. This graph shows how much extra traffic the SoC has produced. Our IRC channel which normally has about 9 people on it has had around 20.
I’ve been really busy commenting on applications and introducing the newbies. It’s really been a lot of work but I think it will be worth it in the end. The amount of progress which could be made in the 3 months SoC runs for is really huge. A $US 4500 payment is also a good incentive to actually finish what you said you would too.
We have 9 application so far, of which 8 are of very high quality. I would really like to see 30 applications in total, however being realistic we will probably only get around 20.
I upgraded my laptop to Feisty this weekend to see if there was anything good. One thing I have been hoping for is to get Beryl running on this laptop.
I tried a couple of times to get it working, however it starts of fine and then goes down hill. It just seems that my graphics card which is an evil Intel Extreme 855 just isn’t fast enough.
There are two main reasons I want Beryl,
There are also two “bugs” which prevent me from using beryl even if it worked.
I have to wonder however, these features shouldn’t really need a 3d desktop. For live preview they would, but I don’t really care about seeing my Video’s or 3d applications running while I’m just trying to find them. I guess it’s comes down to, 3d hardware is cheap, programmer time is not, hence it’ll only be done in 3d.
On a side note, I do like a bunch of new features in Feisty,
Overall, it’s not a major change, just a continually progress towards perfection.
Well, after the last post I thought I would give the Eagle to gEDA converter a try. At first I thought about reverse engineering the Eagle format and then output the result. This would have the advantage that you wouldn’t need to run Eagle to do this. I decided that this would be too much work and was about to give up, but then I remembered that Eagle has quite a good scripting language called ULP. About 2 hours later I have this script which converts “symbols” in an Eagle library to a gEDA symbol. As this seems so easy I may continue and see if I can make a converter for a complete Schematic and PCB. I’ve attached a picture of a symbol in both gschem and Eagle at the same time.Hope other people find this useful too. |
For the last 3 days I have been working on routing the Honours project. For the design I use CadSoft Eagle. However, it’s been annoying me quite a bit.Here is just a shortlist of things,
I’m thinking of moving to gEDA because it’s free software, I would no longer be restricted with what I do. However, it’s quite hard to use and doesn’t come with the extensive libraries that Eagle has. I’m thinking that I’m going to write a ULP script which converts EAGLE stuff to the format used by gEDA. We’ll see what happens. |
I spent today at a “conference” called NI Days, which was really just a day long pitch by National Instruments about their LabView software. It was however quite interesting, the two parts which caught my attention where the “graphical programming” and the “dll importer”.
The graphical programming worked by creating graphical boxes (which represent functions) and then wiring input and output together. The system looked like a very good for doing parallel and concurrent systems.
The problem with our current programming languages, like Python is that it doesn’t scale well, both in performance and code development time, to multiple processor and concurrent systems. Things like stackless and greenlets are attempts to make this much easier.
The problem with these “solutions” is that when using their system is then very hard to visualise where data is going and what critical paths exist (IE Where the system will block waiting for data). Graphical Programming would have a real advantage in this area. In the world of human resource scheduling, visualisation processes have long been used in the form of Gantt charts (or Gnat chart as my brain keeps making me type).
Another problem with these systems is they are based around message passing. When you want to move around and process large blocks of continuous data (such as when you are doing Software Defined Radio – which would otherwise fit perfectly into the blocked based concurrent systems) this sucks. The main reason the systems are based around message passing is because it gets rid of the problem of locks. Locking is the cause of most headaches in concurrent systems and involves horrible corner cases like “thread a has lock alpha and wants lock beta but thread b has lock beta and wants lock alpha”. By having data “flow” out of one system into another via a queue like structure (probably a circular queue for most systems) means many of these locking problems go away (as a queue is inherently lock safe).
The other thing which caught my eye was the “dll importer” which look suspiciously like how the ctypes code generator works. The importer uses the C header file to figure out how to call C code in a DLL. It then “automagically” creates the graphical elements which you then places and wire like anything else in LabView.
I think you could easily build a basic graphical programming language very quickly using some type of existing canvas (maybe Dia, Inkscape or wxFloatCanvas). It’s then just a matter of doing a ctypes (which uses FFI and gcc-xml) like system to automatically generate the graphical elements for currently existing code. You would probably want to output run on something like the Erlang VM (Erlang is a cool language with a syntax designed by retarded monkeys) so you have access to microthreads. The result would be something which should be easy to use, scales well and already has a huge amount of code which can be used.
Actual implementation is left up to the reader as I just don’t have the time to do it :/. I need to concentrate on Thousand Parsec, I may come back to it at some later date, but I doubt it. If you do end up doing something – please send me a line.