Making undo/redo work well with QTextDocument's and "replaceAll" operations - qt

How do I make a single 'replaceAll' operation be a single step in QTextDocument's undo stack?
It does not use QUndoStack, it has it's own. :(

Use beginEditBlock()/endEditBlock() to record all operations within as a single undo step, see the answer here https://stackoverflow.com/a/27113540/72312 for details.

Related

SYCL DPC++ auto detect device

This question might be trivial, unfortunately I haven't found the answer I was looking for.
I used dpct migration tool to port some cuda code to Intel DPC++ and then I further optimized everything I needed and eventually got rid of everything related to dpct expect the super handy
dpct::get_current_device();
which basically solves all the previous pain I had to put compile options to select the appropriate device and control them with Makefiles and so on.
Is there any way to do this without using dpct ?
I had a look at how dpct does this (here) but it looks pretty non-straightforward and it relies on other internal functions.
Is there any way to avoid this ?
I'm not totally clear from your question whether you want to 1) grab a handle to your device or 2) select a device on which to run stuff, so I'll try to answer both. Note that dpct::get_current_device() isn't actually selecting a device, it's just returning the device which you have already selected earlier in your program.
Typically when using SYCL we start with a sycl::queue, which we use to submit kernels, memory copy operations etc. From a sycl::queue you can access your device with:
sycl::device d = q.get_device();
But it seems like you may instead be asking for the simplest way to select a device. In this case, the simplest approach is to construct your queue with one of SYCL's provided device selectors:
sycl::queue q{sycl::gpu_selector()};
sycl::queue q{sycl::cpu_selector()};
sycl::queue q{sycl::default_selector()};
Note that the last option (sycl::default_selector()) is probably what dpct is currently doing for you.

Is possible create data faster?

I have an application how this:
If i have that add each answer one to one (and select the question), the process for the user is very hard.
Is it possible create with MOST a new process more faster and easy for the user? how?
Did you consider removing the whole answer entity and adding an array field to the question instead?

How to properly debug OCaml code?

Can I know how an experienced OCaml developer debugs his code?
What I am doing is just using Printf.printf. It is too troublesome as I have to comment them all out when I need a clean output.
How should I better control this debugging process? special annotation to switch those logging on or off?
thanks
You can use bolt for this purpose. It's a syntax extension.
Btw. Ocaml has a real debugger.
There is a feature of the OCaml debugger that you may not be aware of which is not commonly found with stateful programming and is called time travel. See section 16.4.4. Basically since all of the information from step to step is kept on the stack, by keeping the changes associated with each step saved during processing, one can move through the changes in time to see the values during that step. Think of it as running the program once logging all of the values at each step into a data store then indexing into that data store based on a step number to see the values at that step.
You can also use ocp-ppx-debug which will add a printf with the good location instead of adding them manually.
https://github.com/OCamlPro-Couderc/ocp-ppx-debug

How to handle tracebacks when importing lots of content with Transmogrifier?

Sometimes it is convenient to "keep going" when importing lots of content, ignoring tracebacks and other failures that may occur with certain content.
Is there any generic mechanism in Transmogrifier to make this easier? The only approaches I can see are:
Use only custom blueprints that try/except where appropriate.
Use a wrapper to execute the pipeline that changes the source blueprint input to be one-after-the-failure each time.
Neither of these appear particularly convenient or desirable, hence my question.
you only need to write one blueprint which will handle and ignore all "tracebacks" you might want. be sure to put it right after "source" blueprint and yield in try/except block.
...
def __call__(self):
for item in self.previous:
try:
yield item
except Exception, e
# here do with exception whatever you want
pass
I am aware that this is not a real workaround for that (common) issue, but here's my only solution: i use a lot of pipeline steps, each that make a single, well known, change to my items. If there's a step that i fear that can cause trouble i add a condition step (collective.transmogrifier.sections.condition) and simply drop potentially bad items. I think that a real solution could be to change the way the pipeline runner call each step, it should be responsible for managing exceptions in a customisable way. If someone else has a better solution i'm interested, me too.

SQLite insert performance

I need to write single lines to a file placed on a file server. I am considering utilizing SQLite to ensure that the writing of the line was successful and not just partially completed. However, as insert performance is really essential. My question is, what is the exact process (as it read this, write that, read this and so on) that SQLite goes through when it inserts a row to a table. The table does not have any indexes, nor primary keys, constraints or anything.
This is the most common bottleneck in my experience:
http://www.sqlite.org/faq.html#q19
Except for that, SQLite is really fast. :)
You should use transactions and thus try to avoid fsync()-ing on every INSERT. Take a look here for some benchmarks.
Also, be sure to properly set the two important pragmas:
synchronous (NORMAL)
journal_mode (WAL)
you can use explain for details what happens when you execute a statement: http://www.sqlite.org/lang_explain.html

Resources