Open L3nn0x opened 11 years ago
You can't debug in DevCPU yet. Debugging features won't be available until at least Release 1. I'm guessing you managed to find the Debug view. It's not in a usable state yet.
Oh, then I'll wait. :)
I expect good things though. ;) A lot of the DCPU debugging framework is already in place. In fact, I had hoped to have some of the debugging features available in Release 0, but my obsession over trying to get RCP's MemoryView to work with the DCPU ate up a lot of time.
Oh, and thanks for the report! I'll go ahead and mark this as an enhancement and target it for the Release 1 milestone, then close it when there's some form of usable debug system in place.
Your welcome. :)
What features do you plan to add / have in place already? The most important would be single-stepping, disassemlby view (with PC highlighted), stack view and breakpoints.
I am really looking forward to update 1, atm I have to use a 0x10c devkit for debugging, which sucks because I have to switch syntax etc.
What did you have in mind for a stack view?
And yes, the other things you mentioned are part of what's planned.
a stack view
Maybe a view of the stack ? XD
like in 0x10c DevKit, one line per word on the stack, representated in hex, ascii and offset from the last label know. so if main is 0x3a and the value is 0x3f (and there is no closer label) there should be main+5
There is no stack. "stack" is also ambiguous. You could be referring to a call stack, which doesn't exist on DCPU and would require a lot of guesswork on the part of the IDE (for any code even remotely complex, this would never work), or you could be referring to a point in memory from which you're building a stack using SP with push/pop/etc. values which, even if the IDE were to make a bunch of grande assumptions about how SP is being used, isn't going to work at all when you go multi-threaded. The stack isn't a real thing. It's just a pointer. If your OS gives program A its own stack at 0x2000, how is the IDE supposed to know that program A even exists as a stack-having thing and that 0x2000 is where the base of its stack was?
If you want to outline a specification for a general way to think of viewing "a/the stack", primarily how the IDE/debugger is supposed to decide, at any point in time, where the base of the stack is, then write up a specification for it and the memory view itself, including any assumptions the IDE/debugger should make, and then get some other developers to come in and comment on it so we can see if that's how everyone wants it to work, and I'll try to implement it.
To simplify what I'm saying I need in order to make any sort of "stack view", there are two things I need (this is all assuming we aren't talking about a call stack, but just everything in memory from SP to the yet-to-be-defined base of the stack):
There are other things I'll need too, but those are the key elements I'd need to actually start making a view like that. I can probably come up with the rest on my own. Thanks.
One solution may be to keep a log of all the values of SP, and print it. But it may be too complicated…
Well, I basically just said what the 0x10c DevKit did. I believe they just assume the stack to be between 0xffff and SP. And yes, they just treat every word as a pointer, they don't have a character view though, which is, if I think about it, not useful anyway.
Just to clarify, I'm not asking how DevKit does it. I've never used DevKit but I also don't need to know what it does. I just want to know how you think it should work. The way you've described that it works in DevKit sounds kind of silly to me, personally, considering that it's effectively broken for operating systems, or anything that uses a different stack base than 0xffff. I'm not sure there is a better way to do it, but just tell me what would be most useful for you and devs in general. What would you like to see in an entry and how do you want it to decide where the base of the stack is?
@Yamakaky That wouldn't really be complicated at all, but I'm curious what use that would be to you. That doesn't really sound like something I'd call a "stack view"; that's just a log. (not that it couldn't be useful, just that I don't imagine that's what people would want to see in a "stack view").
I really don't like that button being next to the Comment button. -_-
I don't really see an use for a stack viewer either. I'd prefer the hex view to higlight words based on pc, sp and the last word modified than a stack view (it'd have to refresh every time something changes). Much more useful to debug stuff. I'm not sure if that's possible though.
Anything is possible, though I'm not sure I understand exactly what you want highlighted in the hex view and in what way.
Update, by the way: I've been working on finishing the integration with RCP's debug/launch environment. I've got it to the point where I can control the DCPU using the regular RCP debug controls (suspend, resume, step over, terminate) and I have a little arrow showing the line of source code that corresponds with PC. I still have a good bit of work to do with it before everything will be working properly. For example, it will only show the root source document right now. I haven't looked into how to get it to jump between documents yet (though I know it is possible). I'll try to start regularly updating the development log at devcpu.com again, starting today.
You awsome \o/
Yay! That's really cool! :D
About the hex view, I'm thinking about highlighting the word pointed by pc, the word pointed by sp and the last modified word. With three different colors if possible. It'd be very useful while in step by step to understand what the program does.
Oh, and how will the clock react while in step by step ? I mean, if it ticks at the same speed as normally, then it won't be possible to test the implementation of the clock in step by step.
Oh, and I just had an idea : how about highlighting the word pc comes from? So if we jump, we can see just by looking at the hex view from where to where. I'm not sure it'd be useful though...
"highlighting the word pointed by pc, the word pointed by sp and the last modified word. With three different colors if possible." That sounds doable. I might have to make some modifications to the way the hexview works, but that's to be expected.
"Oh, and how will the clock react while in step by step ?" Right now, it resets the hardware tick countdown timer each time. I have a TODO in there to reevaluate the way I'm ticking hardware, to account for debugging actions. I'll be changing it to use cycle counts instead of real time to trigger hardware ticks.
"Oh, and I just had an idea : how about highlighting the word pc comes from?" I'm sure I could do that too.
That release is gonna be so awsome !! :D
The hexview is kinda broken anyway. The x-mouse coordinate is not correctly mapped to the window coordinate space, so when I click on, say, the 5th word the 3rd is selected.
Really? You should open an issue about it. :)
@S0lll0s On what platform? I wouldn't be surprised to hear that it's behaving strangely since I didn't finish writing it. It's only by chance that the state in which I left it actually compiled (otherwise, I would have removed it from the views extension before release). However, I've never observed this mouse alignment problem you're describing so it might be a platform-specific thing of which I'll need to try to be mindful when I go back to finish writing it.
I'm on Windows 7 x64, let me cross check in the last dev-build....
oh, hex view seems to be broken: http://pastebin.com/ma6tkZYG
@S0lll0s It isn't broken, at least not any more than a Lego set is broken when it hasn't been built yet; it just isn't finished. I don't think people understand what I mean when I say that it isn't finished. I mean that I started writing it and in the middle of coding the implementation, I stopped. I stopped typing after some line of code in the middle of a method and told myself that the memory view isn't a priority right now and I'll come back to it. I just never came back to it. It's only by luck of where I stopped typing that you are ever able to get it to do anything other than throw exceptions.
It's not a Release 0 Update 0 feature (not that I've ever published a list of Release 0 Update 0 features). I was going to hide it from the views list but a couple of people in the chat room asked me to leave it in so they could at least try to use it, and work around whatever didn't work, so I left it, tucked away in the "Show View" list.
I didn't really look at the exception you posted, beyond seeing that it said it failed to instantiate, but I can tell you from experience that that probably means you had it open when you started DevCPU or otherwise tried to open it when there weren't any DCPUs in the Device Manager. Assuming that were case, I've noticed that you can just close HexView and reopen it after you've created a DCPU.
Yep, I had seen this "bug", but actually it's pretty normal : it doesn't have anything to display, so it just throws an exception...
I'm with you @HerobrinesArmy ^^ I think you should use master for stable code, and branches for indev features. With this workflow, people will immediately see what feature is indev and what feature is stable.
@HerobrinesArmy I totally understand that, and I'm 'kay with it. I just thought the code from the "stable" Realease 0 build was still in-place.
And you should use tags to mark the releases ;-)
@Yamakaky milestones?
Nothing's stable in Release 0 Update 0; it's an untested indev snapshot. Honestly, I'm surprised it hasn't exploded anyone's computer yet. I'm not going to do branches yet. At work, I have to do an 18-step process to get changes from my workspace to the master, and for DevCPU, I'm not going to subject myself to checking out and rebasing and resetting and cherry-picking and merging and creating branches and switching branches and praying to the git gods that I don't derp and skip a step and have to figure out how much damage I just did and what I have to do to fix it, at least not until the first stable release. After that, I may make the master stable and make indev branches, but it's probably worth noting that DevCPU isn't really "open source" in the traditional sense, at least not yet. It's more "visible source" right now. That's why the license is so insane. It's not really my intention right now that anyone build DevCPU from the repository. The repository was switched from private to public primarily for transparency, so developers outside of Herobrine's Army wouldn't have to worry that the "the evil Herobrine" might be distributing software that was going to wipe their hard drives or something. =P
@Yamakaky Tags?
Your repository, your rules ^^
No milestones, I mean git tags.
EDIT : meh licence is terrific XD In fact, DevCPU is open source, but not libre ^^
Oh, I never thought to use tags. That's a good idea.
It works like static branches (bit tag <bla>
) or named commits (git tag -a <bla>
).
They may be accessed there.
I use the same EGit plugin while developing DevCPU that DevCPU has in it; it has full support for tagging.
@HerobrinesArmy that plugin sucks IMO. Just use real command-line git, much more / better options. And more fun :D
Also for the stack view, yes, that is kind of stupid. While making my OS i obviously had multiple stacks, and obviously they fucked that up. Although it would be good to view the next 4 or something words below SP in the manner I described.
I can probably make that happen.
While trying to debug my program (I'm not working with eclipse), I got the following error : 'Debug source Display' has encountered a problem. An internal error has occured.
Details : An internal error has occurred. java.lang.NullPointerException
Thanks for reading.