Make an arbitrary function safe to run? - emacs

I'm writing the docs of my program online, in a wiki, and my intent is to rip that content from the program itself, either from time to time or on demand.
For extra leetness, it would be cool to the get the display functions themselves online, but this I cannot do unless I'm assured that they are safe to run, ie, they won't modify important variables, make system calls, nor steal information from the user. Is this implemented on Elisp or implementable?

It sounds like you want to be able to run your elisp code in a sandbox. A bit of googling lead me to sandbox.el. I haven't tried it, but it might be a good place to start.

Related

Can user code create a new memory segment?

I've been researching about memory segmentation, and it's been giving me lots of ideas for potential ways in which user code could benefit from swapping out segment registers. Specifically, I am interested in the x86-64 architecture because that's what I have.
Is there any way in which a user-mode program can create a new segment, for internal use?
To what extent can a program configure its own address space?
I imagine the GDT is way outside of a process' reach, but can a process modify the LDT?
Sorry if I sound naive, this is new stuff for me.
I also imagine that, if there even is a way to do this, it will almost certainly pass through OS specific functions. How would one do this in, say, Win32? I have found GetThreadSelectorEntry (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getthreadselectorentry), but I haven't been able to find the equivalent SetThreadSelectorEntry.

IDs in Scratch: Cloud Variables

I have a multiplayer project which has some forever loops with checking code inside of them.
The problem is, multiple computers might process this and change crabx or craby due to lag in the variables dvotes, uvotes, lvotes, or rvotes. Only one machine should change this, though.
This can be easily solved by giving each player an ID like many people do in SQL. I would just check if the ID is 1, and that would be the "operating machine". I would then do all of these checks on that one machine. It would do things a Scratch server would do if you could program it...
The problem with this is that there is no way to detect when a player leaves the game. There is no block that is called "on exit" or "on stop button pressed". How would I go about doing this? I have seen people have a button which people click to exit, but some people will not click it/not even see it.
Thanks in advance!
Option 1
I've never been especially successful with cloud data myself, but I've heard the theory on this before:
Essentially, each player gets a "counter". Their computer then constantly increases that counter. If the counter ever stops increasing (which will be detected by the other computers, who are all looking after one another), the project will know that the user has left and one of the computers will take care of removing their ID and other data.
Obviously, this is much easier said than done. (As I said, I've never gotten complex cloud data to work well for myself, but I've seen it done successfully and explained.)
Option 2
Alternatively, you might be better off taking advantage of this cloud api created by MegaApuTurkUltra. I find that stealing from others tends to be the best way of solving problems when it comes to code. ;)

Emacs "on-request" completion interface for writing a major mode

I'm writing a major mode for a language and I want to offer completion after '.', or following a keypress. Completions are determined by sending a request to a backgound process using process-send-string and set-process-filter. The returned list of completions is dependent on the background process parsing the current state of the file and being instructed to give completions at that particular point.
I have tried using the popular autocomplete package, but it is really not written with this use case in mind. This is partly because it offers automatic suggetions (i.e. without keypress), which is a nice feature that I don't need. The function that you offer it to call needs to be called synchronously, and emacs process control is asynchronous. I have coded something up along the lines of https://github.com/Golevka/emacs-clang-complete-async, but it doesn't feel robust at all, and has been very fiddly to get it working.
I like the menus used in autocomplete, and would like to know what would fit best with my use-case, preferably while also looking nice.
You can wait synchronously for a background process's output with accept-process-output. You might like to take a look at gud-gdb-completions and gud-gdb-run-command-fetch-lines in a recent enough version of gud.el.

Is dynamic code insertion possible in iphone?

Each time i make small changes, i need to submit the app for approval and need to wait to review process to complete, so till what extent i can exploit dynamic code insertion or at least can i change the view of a view controller using the nib file which i will be downloading to document directory dynamically?
For the most part, the answer is no, and intentionally so. In particular, you cannot run executable code that you download. If you figured out a workaround to allow it technically (and I have at least one or two thoughts in mind on how I'd attack it), it would definitely run counter to Apple's approval process.
On the other hand, a nib file is data, not code. That you can definitely read from disk and instantiate using [UINib nibWithData:bundle:]. This is a pretty big hassle, though, and I don't particularly recommend it. But it's relatively straightforward (unless you want to correctly handle low memory situations, in which case it's a bit more of a hassle).
Of course you can always have dynamic code by putting it in a webview and writing it in JavaScript.
In the end, though, the review process is the way it is on purpose, and I recommend developers adapt their development cycle to include it. That generally means having fewer releases with heavier testing because "one quick fix" is expensive.

Tips for finding things in your program that are broken that you don't know about?

I was working on something for a client today when I found a way to break some functionality in our program.
(The code is really legacy code, it's been in development for about 10 years and I've only been working here for about a year.)
It didn't cause an error, or cause the program to crash, but if a user was using the program and duplicated the behavior I'm pretty sure they'd be holding up their "WTF?" flag.
In our program we have named fields (textboxes) and static text (labels) that can be linked with the textboxes. When the textbox is not filled in the label(s) that were linked to them disappear.
The functionality that I broke was, when you change the name of a textbox that already has one label or more linked to it, and save the file, without re-associating the one or more labels associated with the textbox, the formerly-associated labels appear when the textbox is blank.
Now my thinking on the matter is that a simple observer pattern could have solved this problem in the first place, but then I didn't write the code.
I was thinking that if I could dig up more situations like this with the guys in my shop, that maybe I could talk them into considering unit testing, decoupling, applying patterns where they are called for and the like.
So for this reason I was wondering if anyone had any tips for finding broken (but not error causing) functionality in any sort of app (web-based, desktop, etc...)
For an app to fail usability, it has to have a defined set of expected behaviors.
"Is this textbox SUPPOSED to do nothing when the enter key is pressed?" Maybe it is, maybe it isn't. I've seen apps where a tester/reviewer reports something that they ASSUME should work another way, when in actuality the client specifically asked that they DON'T want the form submitted on a return key press, but only a submit button click.
So basically you have to define proper behaviour before you can determine incorrect behavior.
Hire some testers.
If it has an interface, then one of my favorite unconventional test is putting 5-10 year old children in front of it. You'd be surprised what they can come up with (especially the younger ones). While this may sound like a joke, it isn't -- it really works, because children don't have the mindset of only going through "mindset" paths.
And yeah, children are the experts in "breaking things" xP.
Code inspections, i.e. reading the source code: if you had taken time to read/inspect the source code, looking for "smells" or even just looking for code whose behaviour you don't immediately understand and agree with, you might have been holding up your "WTF?" flag too.
Test, test, test.
Do unexpected things. Start doing one task and switch another to see if anything goes haywire. Use the back button when you're not supposed to. Open it in two windows. Let it time out.
Test in all browsers, especially IE.
You can find database connections/sessions aren't released by:
working out the minimum number of connections you need to do something
setting resource limits to that minimum number
ensuring one "run" of the scenario that should use exactly that number (and release it afterwards)
then run it again a few times... do you run out of connections?
I used to work in a company where programmers regularly used to forget to de-allocate db connections. The standard answer was to reduce the resource to a minimum to see if there's a leak - and to try to work out where it is by restarting the system and running different scenarios repeatedly.
The first hour of code review, with the first reviewer, will do the most to find quality problems. But here's the thing: You don't need to convince people of quality problems. You need to convince them of the value of fixing bugs, and of rewriting only when the present quality absolutely justifies it.
I've dealt with some seriously bad code in my time. But you can't just rewrite. You need a spec before you can even tell if the rewrite is an improvement.
Sometimes, you have to infer the spec from the code and then check it against some human somewhere. But by the time you've done that, you understand the code as written and are now better prepared to repair than to rewrite -- most of the time.
Repair proceeds by a process of small behavior-preserving modifications that render the spec more clear in the code. Then, when you find something that looks wrong, you don't just change it. You ask around until you find the person responsible for that decision, and you get them to show you where in the spec it says that behavior X is correct. (This conversation can take many forms.) If you're lucky, they'll tell you that behavior X is in fact incorrect, and then you've earned your pay.
assert()
Also unit testing with coverage analysis.
This is particular to the Visual Studio IDE, although it probably also applies to others:
During testing, always at some point run in the debugger with "Break when an exception is thrown" turned on.
This can often help expose exceptions which are incorrectly being silently caught and which represent bugs, but otherwise may not be evident.
Code reviews should always also include reviews of the unit test code.
The problem is that with ad-hoc testing it's impossible to know how much or how well a developer has tested their code. So, you're at the mercy of different developers definition of the word "done".
If you include reviews of the unit test code at the same time you review the production code you should have a good idea of whether the code is really complete; in that "complete" includes "tested". Not just "Hey, I'll throw it over the wall to the testers!".