233 reputation
18
bio website datenwolf.net
location Munich, Germany
age 31
visits member for 3 years, 5 months
seen Jun 8 at 14:28
  • Physicist (German "Diplom" graduation)
  • Computer Science interests:
    • 3D graphics (Online and Offline)
    • signal processing
    • CPU architectures
    • compiler design and implementation
    • networks
    • embedded and realtime systems

Sep
7
comment Compiling OpenGL Assembly Language (ARB) assembly code
@Fr34K: GPU independence is what GLSL has been made for.
Sep
4
comment Critique of the IO monad being viewed as a state monad operating on the world
Well, this makes look the IO monad looking like a measurement/interaction in quantum physics. The world is a unknown state and only what you're directly interacting with gets a "real" value.
Jul
6
comment Debugger for file I/O development?
@rwong: After 2 sleepless nights I actually figured out the culprit. And like I suspected, it was a in-situ-change to the VI. In the data dump I got there's some additional double precision float in the per chunk headers, that was not included in file writing VI I was given. How I figured it: Well, I hacked up such a file I/O debugger myself, by having my code open the file in direct mode and having my I/O following hexviewer to keep in sync with /proc/$PID/fdinfo/$FD. Then I step executed my file reader in a execution debugger.
Jul
4
comment Debugger for file I/O development?
What I need is a tool, with which I can analyze how my program interacts with the file. And the libraries used are irrelevant, as right now it's just about getting the parser right with some library (heck right now I can do it with naked FDs and unbuffered). Only after this works it's going to be rewritten in the actual program code.
Jul
4
comment Debugger for file I/O development?
@mattnz: In this case it's actually not a C struct, but a LabView cluster dump. The memory layout of those is rather well documented, but it can happen that somebody makes an in-situ change to the cluster layout, that is not reflected by the reference VI I got here. The only way to tell this, is by stepping through the file and seeing the progress of my file pointer over the file. Add to this, that large bulks of the file are mmap the the file pointer just seeked over those areas and you begin to understand the problem.
Jul
4
awarded  Commentator
Jul
4
comment Debugger for file I/O development?
I have the VI this file was supposedly created with, but the pitfall here is, that its sooo easy to change the data layout of a binary dump without noticing. So the only way do pick this apart is reading the file, field by field, and also looking at the surroundings of the current file pointer position, if the context makes any sense. So technically I'm not writing the final reading code, but are first trying to nail down a working parser, which is then rewritten in the program propper. And no, a simple hexeditor doesn't suffice, because this a 6GiB of data of 1024 chunks with headers.
Jul
4
comment Debugger for file I/O development?
About assertions: Here is the first problem: There's no way to know if a value, you've read in is correct until you've read the whole file. And the only sanity check so far is, if after reading all the chunks in the file, the file pointer is exactly at the end of the file. If not, something went wrong. About the "reference implementation": The file itself is mostly a dump of a data acquisition program, done quick'n'dirty in LabView.
Jul
4
awarded  Student
Jul
4
comment Debugger for file I/O development?
Well, about your suggestion using XML: The file in question is about 6GiB in size. Basically it consists of a header of sampling parameters and then loads of sample dumps with the structure with the occasional descriptor inbetween.
Jul
4
comment Debugger for file I/O development?
Nice suggestion. But unfortunately my project is targeted for a Unix machine. There's neither ProcessMonitor nor IStream there.
Jul
4
comment Debugger for file I/O development?
@K.Steff: Well, the debugger could offer a intelligent display mode for those wrappers. After all FILE* is part of the C stdlib and hence works the same for all binaries on a given system. So even if FILE is meant to be opaque, a debugger could be equipped with implementation specific knowledge. If a program uses a non-standard libc, then the debugger could bail out with a "unsupported libc" warning.
Jul
4
comment Debugger for file I/O development?
Also: I have no problems writing binary file writers or parsers. It's only getting problematic, if the only kind of spec you have is some C header file with a structure without packing and alignment pragmas and somebody just dumped this into a file. If you could see the context of your parser, and also make interactive adjustments to its progres this would ease up deciphering such binary a lot.
Jul
4
awarded  Critic
Jul
4
comment Debugger for file I/O development?
I'm not asking for a magic file analyzer. What I'm asking for is a debugger that keeps track of the open file descriptors, shows the file in a hex editor and displays the current file pointer position therein. Again: I'm not asking for a structural analyzer. Say you got a FILE*, a int fd, or a HFILE and instead of giving you the numeric value of the handle, you get a display of the file contents around the current file pointer position.
Jul
4
asked Debugger for file I/O development?
Mar
4
comment Python is slowly replacing C in universities. Does this move degrade the quality of CS students?
@Lèsemajesté: In fact Donald E. Knuth invented MIX and later MMIX for exactly that reason: Teaching CS 101 using a orthogonal assembly instruction set executed on a VM.
Feb
13
awarded  Yearling
Oct
8
awarded  Autobiographer
Jul
5
comment Why do game developers prefer Windows?
Packaging up a binary so that it runs on all Linux distributions isn't that hard. Heck, the Blender developers do it with each release. There's only the one (well two, 32 bit and 64 bit) Linux release package of Blender.