Programming thread -

Gorilla Tessellator

kiwifarms.net
I get it. That does sound like an awkward situation. I've been fortunate that whenever my superiors have been coders themselves, they've been at least as good as me, and in one case far better and we had a good sort of apprentice/master relationship going on. But if I were in a situation like yours, I'd also probably just silently fix their code and hope they get Peter Principled to another team or something. I actually kinda like the whole puzzle-solving aspect of bug-fixing anyway, and a paycheck is a paycheck.
I like solving bugs too! Actually in the last year I got pretty good at debugging, I feel like a debugging pro :)
 

Shoggoth

kiwifarms.net
That sounds absolutely niggerlicious.
It is, but it's also a way to break out of a "pipe" instead of having a tower-of-power of if-else's. Would you find it less offensive if I we called it an error monad?
I have to avoid power-level. Let me just add that this person is higher in company organization hierarchy.
Of course I do notify about the bugs I found regularly. However, it makes me feel bad not only because of the wasted time, but also because he is supposed to be better than me, and I feel I should restrain myself not to look like I'm trying to undercut him or something.
I know that feel. I have to deal with a pretty old code base and I have the names of the guilty parties etched in my heart as I curse them nightly before turning in. One of them is a manager in the company today. The things he did warrant getting shot, buried, exhumed, then shot again for good measure.
 

Shoggoth

kiwifarms.net
I try to do all my control flow with call/cc.

No problem. Just use ContT to turn your monad into one where you can callCC.

Note that "abuse of the Continuation monad can produce code that is impossible to understand and maintain", which is useful for job security.
Thoughts about http://okmij.org/ftp/continuations/against-callcc.html ?
There's nothing inherently wrong with gotos.
Everything in the end is just JMP instructions, but there's a reason we don't use them anymore, mainly call conventions. There's nothing inherently wrong with gotos, I just wouldn't trust most people with them.
 
  • Agree
Reactions: Kiwi Lime Pie

cecograph

kiwifarms.net
I buy it, and the author is far more qualified on the matter than me. I'd just say that I've never used call/cc in my programs. I used it once in the internals of a compiler, where the intermediate language was continuation-passing style, and I used call/cc to implement a few primitive control flow constructs. But we never exposed call/cc itself in the main language.

The concept of call/cc is deeply profound, especially when you look at its Curry-Howard interpretation, and the story is that Schemers loved it for researching control flow concepts back in the day, but it's not something I've ever wanted to use seriously. Then again, I'm not a schemer, nor a New Jersey MLer, and while I've used the continuation monad a few times in Haskell, I never felt a pull to use callCC. That could just be my lack of experience and imagination. There are a couple of web-frameworks that pushed the idea of using continuations, notably Seaside in Smalltalk, so it'd be cool to look in places like that for cool uses of continuations and maybe call/cc.
 
Last edited:

Piss Clam

Squeeze me.
kiwifarms.net
So to continue with exceptions and debugging. I said to install windbg look at the help, but anyways back in the day the registry entry AeDebug controlled these things. So of course I'm talking WinNt....etc, but this is the flow of it. I was looking around for 'dr watson' which was the JIT debugger for windows, but it seems like win7/win8 or win 10 it got depreciated in favor of WER.

So here you go: I hope this helps somebody who is developing under winnt....along with the map files...etc. I should have posted this shit a couple of posts ago, but eh, my day is mostly drinking wine and eating cheese...you know?



Enabling Postmortem Debugging Enabling Postmortem Debugging

The most common application errors are called exceptions. These include access violations, division-by-zero errors, numerical overflows, and many other kinds of errors.


Applications can also cause breakpoint interrupts. These occur when Windows is unable to run the application (for example, when a necessary module cannot be loaded) or when a breakpoint is encountered. Breakpoints can be inserted into the code by a debugger, or invoked through a function such as DbgBreakPoint.


Windows can handle user-mode errors in a variety of ways. The following sequence shows the precedence used for error handling:


  1. If a user-mode debugger is currently attached to the faulting process, all errors will cause the target to break into this debugger.
    As long as the user-mode debugger is attached, no other error-handling methods will be used -- even if the gn (Go With Exception Not Handled) command is used.
  2. If no user-mode debugger is attached and the executing code has its own exception handling routines (for example, try - except), this exception handling routine will attempt to deal with the error.
  3. If no user-mode debugger is attached, and Windows has an open kernel-debugging connection, and the error is a breakpoint interrupt, Windows will attempt to contact the kernel debugger.
    Kernel debugging connections must be opened during Windows' boot process. If you are using Windows Server 2003 or a later version of Windows and wish to prevent a user-mode interrupt from breaking into the kernel debugger, you can use the KDbgCtrl utility with the -du parameter. For details on how to configure kernel-debugging connections and how to use KDbgCtrl, see Getting Set Up for Debugging.
    If Windows does attempt to contact a kernel debugger but there is no debugger running at the other end of the connection, Windows will freeze until kernel debugger is activated.
    In the kernel debugger, you can use gh (Go With Exception Handled) to disregard the error and continue running the target. You can use gn (Go With Exception Not Handled) to bypass the kernel debugger and go on to step 4.
  4. If the conditions in steps 1, 2, and 3 do not apply, Windows will activate a debugging tool. Any program can be selected in advance as the tool to use in this situation. The chosen program is referred to as the postmortem debugger. This is also known as the just-in-time debugger or the JIT debugger.
  5. If the conditions in steps 1, 2, and 3 do not apply, and there is no postmortem debugger registered, Windows Error Reporting (WER) displays a message and provides solutions if any are available. WER also writes a memory dump file if the appropriate values are set in the Registry. For more information, see Using WER and Collecting User-Mode Dumps.
Specifying a Postmortem Debugger

To set the postmortem debugger to WinDbg, run windbg -I. (The I must be capitalized.) This command will display a success or failure message after it is used. When WinDbg is the postmortem debugger, it will be activated whenever an application crashes.


To set the postmortem debugger to CDB, run cdb -iae or cdb -iaec KeyString. When the -iaec parameter is used, KeyString specifies a string to be appended to the end of command line used to launch the postmortem debugger. If KeyString contains spaces, it must be enclosed in quotation marks. This command will display no message if it succeeds, but will display a failure message if it fails. When CDB is the postmortem debugger, it will be activated whenever an application crashes.


To set the postmortem debugger to NTSD, run ntsd -iae or ntsd -iaec KeyString. When the -iaec switch is used, KeyString specifies a string to be appended to the end of command line used to launch the postmortem debugger. If KeyString contains spaces, it must be enclosed in quotation marks. This command will display no message if it succeeds, but will display a failure message if it fails. When NTSD is the postmortem debugger, it will be activated whenever an application crashes.


These methods will set the appropriate registry values so that the debugger will be automatically launched whenever an application crashes. The debugger command line will include the argument string -p %ld -e %ld -g. The -p %ld parameter specifies the process ID that will be debugged, the -e %ld parameter provides the event that caused the exception, and the -g parameter causes the debugger to skip the initial breakpoint. If the -iaec switch is used when installing CDB or NTSD as the postmortem debugger, the additional arguments specified as KeyString will then follow.

Note
On a 64-bit platform, use a 32-bit post-mortem debugger for 32-bit processes and a 64-bit debugger for 64-bit processes. To accomplish this, run one of the -I or -i commands discussed in this topic twice: once using the 32-bit version of the debugger (WinDbg, CDB, or NTSD) and a second time using the 64-bit version.


If you run an -I or -i command in a 64-bit debugger, the post-mortem registry value for 32-bit processes will not be changed if it was previously set.


Note Because the -p %ld -e %ld -g parameters always appear first on the command line of the postmortem debugger, you should not use the -iaec switch to specify the -server parameter because -server will not work unless it appears first on the command line. To install a postmortem debugger that includes this parameter, you must edit the registry manually.


Only a system administrator can alter the postmortem settings.


If a postmortem debugger has been installed, you can deliberately break into the debugger from a user-mode application by calling the DebugBreak function.

Editing the Registry

The postmortem debugging settings are stored in the registry. If you wish to control these settings, it is recommended that you use the WinDbg, CDB, or NTSD commands described above; these will automatically change the relevant registry keys. If you do need to manually edit the registry, do so very carefully, because improper changes to the registry may render Windows unusable. The postmortem settings are stored under this registry key:




HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug





On a 64-bit platform, the postmortem settings for 32-bit processes are stored under this registry key:




HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug





These are the relevant registry entries:




Debugger
This REG_SZ value specifies the debugger that will handle postmortem debugging. The full path to the debugger must be listed, unless the debugger is located in a directory that is in the default path.

Auto
This REG_SZ value is always either 0 or 1. If Auto is set to 0, a message box is displayed prior to postmortem debugging.

Registry Examples

The following values can be used to set WinDbg as the postmortem debugger:

Debugger = "Path\WinDbg -p %ld -e %ld"
Auto = 1

The following values can be used to set CDB as the postmortem debugger:

Debugger = "Path\CDB -p %ld -e %ld -g"
Auto = 1

In these examples, Path is the directory where the debugger is located, -p %ld specifies the process ID that will be debugged, -e %ld provides the event that caused the exception, and -g causes the debugger to skip the initial breakpoint.




Security Vulnerabilities

If you are considering enabling postmortem debugging on a computer that you share with other people, see Security During Postmortem Debugging.








Send comments about this topic to Microsoft


© 2015 Microsoft. All rights reserved.
 
  • DRINK!
Reactions: Marvin

Piss Clam

Squeeze me.
kiwifarms.net
What’s good projects for a person to program, as a hobby, when all you can do is basic, first-year student, C++ command line programs?
There are plenty of sites that you can do open source programming and collaboration. I would advise you to learn how to debug and RE programs as stated before. Using a kernel debugger just to explore will show you the world. Make sure you install the symbols for the OS, so you can at least understand somewhat what you are stepping thru.

I'd also advise you to join some place like: https://www.codeguru.com/ if you want to garner experience and have your questions answered. If you are a student then be warned, they don't do your work for you :)

Codeguru is not exactly a kernel level site, it's more of a C++ and windows development site. If you want to learn at that level then just web search around for kernel level development.

There is also a wealth of information in the older newsgroups. If you want to do sockets level programming then I suggest you read the RFC's (Request for Comments) which details all the internet protocols sitting atop the tcp/ip stack. For other network programming then you have to read the specs...there are far more protocols than just tcp/ip. If you want to really get down in the mud, then write a packet analyzer. That would be a good project and teach you a lot. If I remember correctly the older SunOS systems were the first to allow promiscuous mode.
 

Dandelion Eyes

kiwifarms.net
What’s good projects for a person to program, as a hobby, when all you can do is basic, first-year student, C++ command line programs?
One of the first things I programmed when I learned C was a maze solver. You provide a file with a maze as text with tiles represented as symbols, e.g:
  • # is a wall
  • _ is a walkable tile
  • S is start
  • F is finish
And it finds a way using Dijkstra's algorithm and outputs it as another text file with path denoted with some other symbols, like "*".

I think it's a fun and moderately challenging project for a beginner.
 

SIGSEGV

Segmentation fault (core dumped)
True & Honest Fan
kiwifarms.net
One of the first things I programmed when I learned C was a maze solver. You provide a file with a maze as text with tiles represented as symbols, e.g:
  • # is a wall
  • _ is a walkable tile
  • S is start
  • F is finish
And it finds a way using Dijkstra's algorithm and outputs it as another text file with path denoted with some other symbols, like "*".

I think it's a fun and moderately challenging project for a beginner.
That sounds like a fun project. I'll have to brush up on Dijkstra's algorithm.
 

Kosher Dill

Potato Chips
True & Honest Fan
kiwifarms.net
A depth-first search ought to be good enough, unless you really need to find the shortest path through. Converting the maze into a graph in some sensible way in the first place seems like overkill to me.
 
  • Like
Reactions: ConcernedAnon

Least Concern

Pretend I have a waifu avatar like everyone else
kiwifarms.net
I think it's a fun and moderately challenging project for a beginner.
That sounds like fun. Make sure it is capable of detecting when a maze is unsolvable (there is no valid path from start to finish).

After that, write a tool which generates a random, but solvable, 10x10 maze. Then tweak it to prompt the user for the width and height of the mazes it generates. Make sure the user only enters numbers which aren't too big or too small. Make it so your generator can print to paper as well as the screen. Make your generator capable of generating mazes in 3D and your solver capable of solving them (at this point it may get difficult to print them to the screen in plain text).

Granted, both of these applications are pretty useless in the real world, but you gotta play tee-ball before making it to the big leagues.
 

Dandelion Eyes

kiwifarms.net
After that, write a tool which generates a random, but solvable, 10x10 maze.
Speaking of which, I actually wrote a maze generator that used Prim's algorithm. It was a huge mess of spaghetti code, but AFAIK, it worked as follows:
  1. Create a M x N maze with a wall between every two neighbouring tiles.
  2. Assign a random number to every wall.
  3. Treating tiles as vertices, walls as edges and those random numbers as weights, apply Prim's algorithm to the maze.
  4. Remove every wall, that's in the MST.
I didn't create any way to output the resulting maze in any usable form, but I visualized the maze by assigning every tile a color based on its depth within it, I even still have some pictures of that left:
out10.png
temp2.png
 
Tags
None