The new parser

The_8th_mage Nov. 2, 2016, 6:03 a.m.
I got a new watch buffer parser that uses a evaluation graph layout,which ginger_bill told me to do. It's really easy to see where things breaks now, and it's also easy to change an operation from one thing to two. For example, the arr[disp] operation is defined as *(arr+disp). In order to reuse things, when i evaluate the [] op i just turn it into a two node tree that corresponds to the composite operation above. The same is true for the -> op.

I implemented almost everything in the parser except for casting operations, i even support functions that pass structs by value, something that visual studio doesn't support. I still feel that if they don't support it, they probably have a reason, so i keep looking for it,but maybe they don't have a good reason.

After the parser, I'll try to do some work on my university computers to check that esvd works there. It has the added bonus that they have 720p or 1080p screens there, so i can also debug the looks of esvd there. (i have a 4k with dpi correction, it looks fine on my screen.)

Everything feels good with the project, but i started going to the university again,and i started getting assignments. I'll try to find the time to work on it, but it's been hard so far.
Also, my sister is getting married in 10 days, and every single home assignment is due on her wedding day. I'll need to hurry up on the assignments to not work near the wedding day, so extra no esvd for the near future.

The bug hunt

The_8th_mage Sept. 16, 2016, 10:28 a.m.
Hello everyone,
going by what i wrote in last blog post, i'm heading to alpha, and what it means is that i went into full bug extermination mode. a lot of bugs were found, a lot of bugs were killed, and some of them were scrubbed under the rug.

it's been a while now since i crashed on a single threaded debugging, while the multithreadede one still has some small problems, particularly when several threads go into the same graphpoint together.
I don't quite like the architecture of the debugger, it's too complicated, and it goes through too much loops in order to do things. also, i would like my debugger to accept DEBUG_EVENTs sent from windows continuasly, and that means turning the debugging process into a seperate thread from the gui thread. that may mean less going functions from the gui layer and more going through a command queue to the debugger thread. i do think it's a bit of an overkill right now, and i want to finish some of the other features before i do it.

in the last week, i gave some people in the community (Zac Strange and hjortshoej) to try and run the debugger, it was a total disaster, and it crashed on them very quickly. some bugs were fixed after that. I would like to let other people run the debugger to see if it works on their machines, but i don't have a logging system in place now, so if it crashes on their computer i won't have lots of smart things to say.

i took out my old windows 7 laptop in order to see that it works on it, it does, but 720p is not a fun resolution for the debugger to work in right now. I also found 2 new projects that i didn't run on, and one of them had a function with many function calls, and that let me debug the step through code thoroughly. i am pretty compfident in it now.

Oh and one last thing, when you step through multithreaded code in my debugger, it doesn't jump from thread to thread like VS does. you can even put a graphpoint and it would only graph you that particular thread's variable. so cool. i would probably make it a checkbox thing if you want to look at only the current thread or all the thread, the latter good for debugging multithreaded work queues.
i feel like next week will be visualization week, adding things i wanted to the "draw as bitmap" feature, like highlighting specific pixels on the bitmap. i wanted it when i wanted to debug my glyph atlas code.

that's it for now,
the 8th mage.

look what we have here

The_8th_mage Sept. 1, 2016, 3:23 p.m.
a image of a new feature:

decided to stop perfecting the buffer for now, and head straight in order to get alpha going.

Anouncment to the public, be warn

The_8th_mage Aug. 28, 2016, 10:30 a.m.
I had a bug where whenever i issued a stepthrough i stalled, and i spent 3 hours debugging it today. When you write a debugger, you most likely use f10 to issue a step through. This is the story of the f10 key as a cursed key in windows.

Whenever you press f10 on windows, windows sends a WM_SYSKEYDOWN message to your WindowProc and if you don't intercept it and pass it to DefWindowProc(like you do with pretty much every message sent to WindowProc) it stalls your thread until at least the next input. msdn says it only sends a WM_SYSKEYDOWN to your WindowProc only on f10 and some other combination of ctrl and alts, see it for yourself about the other combos.

Windows, you hurt me with this, your api was some how sane before that.

Cleanup week

The_8th_mage Aug. 26, 2016, 1:34 p.m.

This week i felt like i was in a relatively good place in the debugger, and i wanted to do some cleanups before going forward. some of the cleanups were good, and took a great deal of complexity off the software and my mind,some may turn out to be not as good.

i cleaned the render queue inserts to take rects and thus simplifying the calls. the added simplicity of the calls got me to insert a tree view to the watch variables, and making the draw calls not go outside the watch variable 'window' by glScissor. i also added a scrollbar to be able to see more members and watch variables than would fit on screen.

Prior to this week i had a boolean flag for every thread in the process, specifying whether or not it's stopped by a breakpoint. I changed that to making 2 lists of 'running threads' and 'frozen threads' and i can proudly say that every place that had a need for threads got better by looking at only the one list that is relevant for it. It also helps in debugging a code, as i don't need to wait for the correct thread in operations that takes only frozen threads, eg. checking watch variable.

the less pleasent change was that a lot of functions in the debugger layer took two contexts: a Process context and a Shared context, of which only the shared context can be looked at by the ui side. i saw that happening, and thought that combining the two into a single struct would be better. In addition to that, after trying to run William Bundy's rituals game, i saw that it tries to open 2 processes, a SDL process that calls the game process, so i opted into making the single struct have a list of process context. the change was so big, it took about 5 hours of contious work just to go through all the compiler errors, and not everything works yet.

I don't remmember whether i said it in the previous post, but the watch variable window works without any immediate problems and that includes being able to graph any member or draw any member in a struct/union/pointer as bitmap. well, it worked before i added the scroll bar. it should be fixed by somebody next week.

I can proudly say now that the 'graph points' are great for debugging. 'graph points' are breakpoints that break the program just long enough to check the variables and then carry on. i know they are a great concept, because this week i had a bug in the debugger, something subtle i don't understand yet. for finding a piece of information about the bug that msvc didn't gave me, i opened the debugger in the debugger, while one of those opened a third program. using this method i learned something about what's going on. can't say that i know what to do about it, but it's at least something.

the next week will include me seeing that everything works with the new contexts, changing the gui system to something better, and having graphs work again. also, horizontal scroll bar, don't sound like a lot of work, as i already have the vertical one, but we'll have to see about that.

Thanks for reading, I'll be here next week,

First blog post

The_8th_mage Aug. 16, 2016, 7:39 p.m.
Writing a new blog after the last one died down feels like being home again, but unlike the previous one, this is much less personal and much more focused on the debugger i'm writing, and the day to day work i do to keep it going further. The second major difference is that i'm writing it in English, and as you might see, English is a second language for me after Hebrew, so please don't look down on me for my capital letters or my use of tenses.

Well lets get to it, as you might see in the home page, my debugger aims at letting people look at data in new ways without compromising the old ones, so for the time being i dedicate my time to have a normal watch variable buffer that can look at arbitrary structs and classes. today i finished some of it, and also i finished having the ability to graph each one of the members of a class by the index of the measurement. measurements are done while the debuggee and the debugger run, and you can specify for yourself on what function would you want to have a measurement on by using "graph points" which are implemented as breakpoints that just read the data of the watch variables and run the debuggee again.

The next things i will tackle are having a scroll bar to look at all of the watch variables and not the ones on top, having a "draw as bitmap" capabilities for every member you would want to look at, and getting the parser to call functions that have arbitrary structs parameters.

for the last week I have been streaming everyday at so come and watch me fight c, and say hi while you're there.
that's all for now,
The 8th mage.