dsnopek is currently certified at Journeyer level.

Name: David Snopek
Member since: 2003-08-26 16:47:10
Last Login: N/A

FOAF RDF Share This

Notes:
Developer of the following projects:

http://libksd.sf.net/
http://sagelib.sf.net/
http://savannah.nongnu.org/projects/xmldoom/
http://savannah.nongnu.org/projects/autoscons/
http://savannah.nongnu.org/projects/pyweb/

Currently involved as a contributor to the following projects:

http://www.scons.org/

** Desperately searching for a better note keeping system. Thanks to the Advagoto guys for this extremely useful system! **

Recent blog entries by dsnopek

Syndication: RSS 2.0
Pyml

Lately I have been doing a whole bunch of hacking on Pyml. I really want to get the low-level stuff handled so that it is vagely real-world usable. After that, I can hope for someone to even care about the userland API. Mainly, this effects the parser and compiler.

I started by working on the parser which had a few known problems with determining the various PIs properly. It was based on a single fairly complicated regular expression. This was great and mostly worked -- tweaking the regex ad infinitum could have fixed it. Unfortunately, it made acurately determining and maintaining the line numbers impossible. This is very important to ever having a Pyml line debugger. I tried a lex/yacc parser but settled on a quirky mode-based buffer thing. Not pretty but it gives me lots of control.

The initial Pyml compiler simply generated Python source code and passed it to the CPython compiler. It put everything on its own line since Python is very sensative to white space. This worked but, again, the line debugger! So I started attempting to join code that would be on the same line using the ';' symbol. I found some pretty esoteric Python syntax errors this way! They could be avoided by putting everything in a line continuation inside an exec() statement. Hey, this worked but created really ugly bytecode when disassembled using the "dis" module.

About here I started thinking, "Wow, this would be so easy if I could just generate by own bytecode." Embarking on a wild goose chase I explored compile.c, the "compiler" module and the ByteCodeHacks project. To summarize many hours of gimacing at the computer and writting on little peices of paper, this is a no go -- especially if we want to support many versions of Python portably.

So here is my solution: continue to generate python source and use ';' to connect lines. But I am going to use the "compiler" module to generate an AST to determine if the code fits the strange rules Python applies in this case.

One of these days, all this may result in some actual code...

First, I'd like to say that its great to have Advogato back!

The House That Xmldoom Couldn't Build

My parents are selling their home without a realator. So I made a web site for them to advertise the house. I wanted to build it as quickly as possible and then get it off my hands, so I decided that they needed to be able to build/edit it without me. Because of bugs I have been experiencing at work with Pyml and Xmldoom, I just threw together a Python CGI script with direct access to MySQL. Of course, I made these tools to make web development faster and easier -- mission not accomplished.

My parent's house

Assuming that Pyml was fixed up, I could easily have used it and maybe even saved some time. But the real problem is that the way I used SQL wouldn't have worked with Xmldoom, so I would have had to do all kinds of ugly "stuff" to accomplish the same thing.

The point is, that the current Xmldoom design is terribly limiting. I think, that soon I am going to have to make Xmldoom more like Propel (a similar PHP softwares) for Python. It has a very flexable runtime SQL generating engine. I can build the high-level XML definition stuff that Xmldoom has on top of that. Then I can work to expand the high-level stuff to cover all cases while still providing a low-level solution.

Roma

Before deciding that I would do the architectual re-write described above, I had already fallen in love with Creole (Propel's database abstraction framework) and planned to make a Python version called Roma (for the language spoken by the Romani, known as Gypsies in the US. Its a hog-pog combination of many European languages, which makes me think of how speaking SQL is!). I never really liked ADO but Creole is badass. Apparently, the author based it on JDBC. Which is great because then Xmldoom can use Creole for PHP, Roma for Python and JDBC for Java, this way continuing its language agnostic nature.

Anyway, while Xmldoom is reasonably useful in many cases, I think it has so far served as a toy to help me learn Python and DB programming better. Now I think I understand the problem and have done the research enough to really move Xmldoom into the realm of usefulness.

Pyml

But before I gut Xmldoom, I want to really spruce up Pyml and finally make a release. Since Savannah still doesn't have CVS commits back up, I am going to move it to Gna. I am working on fixing the parser, adding configuration files, and making a Python-based web server that will allow you to enter the pdb (Python debugger) and interactively step through your scripts. As far as I know, no web scripting language provides this feature but it seems really useful.

Thats enough for now...

Life

I am making a strong attempt at quitting smoking. Cold turkey like always. Today is not a good day to die ...

Also, I am starting work on the security camera software which I guess is going to be Nicholas and my current money making scheme. Mix that with starting on a new wine recipe and I should have more than enough to distract my nicotine addicted brain.

Work

I still have a ton of recieving work to do, but since inventory is tommarrow, I can't touch any of it. I think I'll leave soon to get to the really important stuff.

Ah, back to the land of the living or maybe just a little closer..

I just got back from a month long vacation in Ireland. Call me an escapist -- its probably true. And now I hope to get back to some real work. My immediate plans are to "product-ize" Xmldoom and attempt to make some money off of it. Very unlikely considering that it is a totally unknown project with absolutely no community around it. Which is why my next steps include writting user documentation. If I can attract users, I can get developers and then maybe some popularity.

Last year I e-mailed with Richard Stallman about the moral and philosophical implications of dual-licensing a product as GPL for free and proprietary for a fee. I figured that if anyone would find fault it would be Richard. Surprisingly, he thought that this was not contrary to the ethos of Free Software. I like to think of it as taxing proprietary software -- if only to help me sleep at night.

So the plan is allow anyone to build applications with Xmldoom under the GPL but if someone wants to make a non-GPL program out of it I rape them with license fees. Unfortunately, there are a number of problems with this:

  • Code Generation: Albeit the support for generating client code in Xmldoom is broken (in favor of using the runtime engine), it could be used to circumvent the GPL. Since the output code will carry the same license as the input code, Xmldoom becomes a pass-through entity and can't restrict its uses to Free Software.
  • Web Applications: My current primary use of Xmldoom is for web applications. Having the code used by the WWW doesn't constitute "distribution" in the GPL, thus allowing the user to license their app under any license they desire.
  • Non-GPL Runtime Engines: This is a problem similar to the GCC vs GCC-XML issue. The GCC guys don't like GCC-XML because it could allow a proprietary application to use the C++ parsing abilities of GCC to compile code without abiding the GPL. Xmldoom allows you (via the command line tool) to compile the input XML definition into a 'compiled' format that the runtime engine can use. This is useful for me because only one compiler need exist but I could easily write a runtime engine in any programming language I choose. This is bad because someone could write a proprietary runtime engine for their application again avoiding the GPL. Of course, currently only one runtime engine exists so we're safe for now.

These are all roughly symptoms of the same disease but they affect the sustainable Free Software status of this project as well as my ability to profit from it. Maybe its time I write Richard another letter ...

Hey guys. I don't know if anyone is truly interested in the dribble of some Free Software hacker and his fucked up life but I am running out of outlets for for my frustration.

I am having woman troubles. She left me. But I think there is hope yet to salvage our relationship. And on top of that, I may lose my job soon. Not to mention my home just getting robbed on Saturday.

Maybe this isn't my lifetime ...

14 older entries...

 

dsnopek certified others as follows:

  • dsnopek certified dsnopek as Journeyer
  • dsnopek certified rms as Master
  • dsnopek certified esr as Master
  • dsnopek certified DV as Journeyer

Others have certified dsnopek as follows:

  • dsnopek certified dsnopek as Journeyer
  • lerdsuwa certified dsnopek as Journeyer
  • salmoni certified dsnopek as Journeyer

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page