How do I a produce an infinite loop using a JFugue pattern. I tried the following
while loop
for loop with a high counter
In both cases, weird sounds get produced which are overlapped. When I run with a small counter like 10 in a for loop, it works fine.
I need a pattern to run infinitely until the player is stopped by calling player.close() by an user action (say from UI).
There's not a specific way to make a pattern run forever. This is partly because JFugue compiles music strings into MIDI code, so a pattern that ran forever would just be a infinitely-long MIDI file. Of course, if you use a specific number of times to repeat a pattern, the pattern could be too long or too short for your needs. The best option might be to look into JFugue's RealtimePlayer class, and create a separate thread that keeps playing sections of the metronome pattern while the thread is still active.
Let me know if that helps you get on the right path!
Related
I have looked around but I can't seem to find that information anywhere so I guess this is not possible
but I would like to be sure.
Is there a way to break out of a loop when using lldb ?
(And if not why has it not been implemented ?)
Debug information doesn't encode source constructs like loops, if branches, etc. That's been true of all the debug formats I've had to do with. So there's really no way that lldb could implement step out of loop - it has no way to know that loops are a thing.
The cleanest way to do this, when it's possible, is to set whatever condition the loop is checking to the "stop looping" value. Then set a breakpoint outside the loop and continue and the iteration you are in will be the last iteration.
You can also use the thread jump command to move the PC out of the loop, continuing from that point. Be very careful using this, however, as it's easy skip over some code you probably should have run. For instance if there were objects scoped to the loop, they won't get destroyed if you jump the PC to some line outside the loop.
If you know line, where loop ends, you can step out of loop with thread until <line>.
This is the same as setting temporary breakpoint in <line> but only one time.
When I put a "pause" command into my program, I can precede it with a disp("Just finished averaging") or something of the kind, so I can read on the console which "pause" I am at.
But when I lose my patience with a program that's taking forever to complete, and hit Ctrl-C to see what is going on, I cannot see a way of finding out which code line I interrupted it at. The "whereami" command tells me I am in pause, which is obviously true but hardly helpful; it's like a GPS device telling me I'm in the driver seat. Oh yeah, I figured that myself, thank you Captain.
I am tempted to create a dedicated variable, say MyApproximateCurrentCodeLine, and updating it every few lines of code with hard-wired substitution commands. This would work but would take a lot of time to write, a similar amount of time to remove when I'm done, and would have to be repeated with every program I need to debug. Not to mention it's just plain ugly.
Is there a better way of finding the current execution point?
Once you have interrupted the program
[linenum, callername] = where()
will give you the full calling tree.
S.
Looked around with numerous search strings but can't find anything quite like this:
I'm writing a custom log parser (ala analog or webalizer except not for webserver) and I want to be able to skip the hard work for the lines that have already been parsed. I have thought about using a history file like webalizer but have no idea how it actually works internally and my C is pretty poor.
I've considered hashing each line and writing the hashes out, then parsing the history file for their presence but I think this will perform poorly.
The only other method I can think of is storing the line number of the last parse and skipping until that number is reached the next time round. What happens when the log is rotated I am not sure.
Any other ideas would be appreciated. I will be writing the parser in ruby but tips in a similar language will help as well.
The solutions I can think of right now are bound to be brittle.
Even if you store the line number and later realize it would be past the length of the current file, what happens if old lines have been trimmed? You would start reading (well) after the last position.
If, on the other hand, you are sure your log files won't be tampered with and they will only be rotated, I only see two ways of doing what you want, and I'm not sure the second is applicable to you.
Anyway, here goes.
First solution
You store the last line you parsed along with a timestamp. At the next run, you consider all the rotated log files sorting them by their last modified date, figure out which one you read last time, and start reading from there.
I didn't think this through, there might be funny corner cases you will need to handle.
Second solution
You create a background script that continuously watches the log file. A quick search on Google turned out this gem, but I'm not sure if that's even an option for you. Even then, you might want to integrate this solution with the previous one just in case your daemon will get interrupted (because that's clearly bound to happen at some point).
As you read the file and parse the lines keep track of the byte count. Save that. On next read, try to seek to that byte offset in the file. If the file is smaller than the byte count, it's a new file so start at the beginning.
I am making an app with a TON of features. My problem is that applescript seems to have a cut-off point. After a certain number of lines, the script stopps working. It basically only works until the end. Once it gets to that point it stops. I have moved the code around to make sure that it is not an error within the code. Help?
I might be wrong, but I believe a long script is not a good way to put your code.
It's really hard to read, to debug or to maintain as one slight change in a part can have unexpected consequences at the other part of you file.
If your script is very long, I suggest you break your code in multiple parts.
First, you may use functions if some part of the code is reused several times.
Another benefit of the functions is that you can validate them separately from the rest of the execution code.
Besides, it makes your code easier to read.
on doWhatYouHaveTo(anArgument)
say "hello!"
end doWhatYouHaveTo
If the functions are used by different scripts, you may want to have your functions in a seperate library that you will call at need.
set cc to load script alias ((path to library folder as string) & "Scripts:Common:CommonLibrary.app")
cc's doWhatYouHaveTo(oneArgument)
At last, a thing that I sometimes do is calling a different script with some arguments, if a long code fits for slightly different purposes:
run script file {mainFileName} with parameters {oneWay}
This last trick has a great yet curious benefit : it can accelerate the execution time for a reason I never explained (and when I say accelerate, I say reduce execution time by 17 or so for the very same code).
i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.