In the StackExchange.Redis docs for scripting, it says a LoadedLuaScript can be used to avoid retransmitting the Lua script to redis each time it is evaluated. It then gives an example where the script is loaded into the server. I assume this shouldn't be done everytime you call the script, so where should the scripts be loaded?
Scripts are not persitent if redis server is restarted, so how should this be handled? Should they be loaded in ConnectionRestored event of the ConnectionMultiplexer? Presumably you would need to store them in a ConcurrentDictionary?
StackExchange.Redis handles Lua script caching internally. Normally you don't have to care about loading Lua scripts manually to redis.
StackExchange.Redis automatically transmits the Lua script to redis on the first call to 'ScriptEvaluate'. For further calls of the same script only the hash is used:
var prepared = LuaScript.Prepare(script);
prepared.Evaluate(someDb); // loads the script to redis and calls it
var prepared2 = LuaScript.Prepare(script);
prepared2.Evaluate(someDb); // calls the script by it's hash
LoadedLuaScript might be useful for edge cases like loading without executing.
I also clarified the official doku.
Background information
The library tries to call the script by it's hash and if the script is missing it gets a NOSCRIPT error and then transmits the script.
See ScriptEvalMessage:GetMessages in https://github.com/StackExchange/StackExchange.Redis/blob/main/src/StackExchange.Redis/RedisDatabase.cs
The behavior is also discussed and explained in the official StackExchange.Redis github repo:
https://github.com/StackExchange/StackExchange.Redis/issues/1246
https://github.com/StackExchange/StackExchange.Redis/issues/1371
I am trying to develop my own GtkPrintBackend ,
taking help from here:
https://mail.gnome.org/archives/desktop-devel-list/2006-December/msg00069.html
I want to test my print backend( by making the print dialog use my backend instead). How do I do that?
That is, how do I make the Print dialog use my backend instead?
Answering my own question here since I figured out a workaround:
I installed jhbuild and built the gtk+ module using jhbuild.
The source code of the corresponding module is downloaded in ~/jhbuild/checkout/<module-name> .
Modify the print backends under ~jhbuild/checkout/gtk+/gtk/modules/printbackends/ directory, and rebuild it (Find instructions to do that here).
Now when you launch a gtk application from the jhbuild shell, it will use the modified backend instead of the system default one.
I am writing an application that has multiple potential user interfaces and I am using MEF to inject the appropriate implementation during startup. One implementaiton of IDisplay uses ExcelDNA (Excel is the interface). The code launches Excel as a process through
var processInfo = new ProcessStartInfo
{
FileName = PATH_TO_EXCEL,
Arguments = PATH_TO_EXCELDNA_ADDIN
};
Process.Start(processInfo);
This works fine except that Excel is now in a seperate memory space so UI callbacks (i.e. Ribbon button clicks) cannot get access to any injected or assigned properties.
One possible solution is to launch Excel first then have ExcelDNA's AutoOpen() hook (which gets called once the add in has loaded in Excel) call the bootstrapper class to configure MEF however I'm wondering if it is possible to share memory between the C# and Excel processes? Would starting Excel via Excel.Application app = new Excel.Application { Visible = true; } resolve? I would try this but have not been able to find out how to specify the path of the ExcelDNA addin for it to load (like above).
Excel will always run as a separate process. So you can't share memory between the Excel process and another process. However, C# code can run inside the Excel process - this is exactly how an Excel-DNA add-in works.
You can also communicate between the Excel process and some other process. One option for this is to use the COM Automation interop - this is what you're doing when you call new Excel.Application from your own executable. You are starting a separate Excel process (or connecting to an existing running process), and then getting back an inter-process communication proxy (the Application object).
If you then want to tell that Excel process to load an Excel-DNA add-in, you can call Application.RegisterXLL(path_to_add_in) to have it load the .xll. How you hook up the Excel-DNA add-in and the rest of your code is still to be figured out.
You might still need some kind of cross-process communication, like .NET Remoting, WCF with named pipes or something like that.
I want to zip a file within a thread using the TZipMaster component.
The problem is, when I run the program from the IDE I get the error
(from windows)
"the program doesn't respond anymore.
-> Search online for a solution
-> Close program"
(or somehting like that I don't know the exact message in english.."
However, the ZIP files are created succesfully.
The last debugger output from Delphi 2009 is:
unload module: DelZIp179.dll
When I run the .exe directly, it seems to work fine and I don't get this error.
However I'm not sure if I can just ignore this error or it's better to fix it?
Thanks for you replies!
You get this error because your application is doing some heavy processing (zipping) in the main thread and is not processing Windows messages.
It is better to fix this - either you should process Windows messages while zipping (if TZipMaster supports that) or move zipping into background thread.
More info:
I inspected the TZipMaster source and there's a OnTick event which gets called periodically.
Write a OnTick event handler and call Application.ProcessMessages from inside. That should remove your problem.
This question already has answers here:
Can one executable be both a console and GUI application?
(9 answers)
Closed 6 years ago.
Is it possible to (and if so, how do I) make a single program work both as a console application and a GUI version using Delphi 2007?
What I am after is that if the program is run with the appropriate command-line options, it should function as a console program, printing output to the console using WRITELN, but if no command line arguments are given it should run as a normal Delphi GUI application?
The catch is that when running as a console application, the command line interpreter waits for the application to terminate before allowing you to enter a new command, whereas a GUI application started from the command line immediately returns you to the command line and the GUI application is started in a detached process. I want this behaviour retained.
I don't mind something like this:
IF GUI THEN StartApplicationAsGUI(ParamStr(0))
ie. I don't mind that I'll have to restart the application using some form of EXECUTE call to start it in GUI mode if needed, as long as the command line interface returns to the command line input when the GUI version is started.
I'd prefer a solution/suggestion that is along the lines of:
<Parse Comnand Line>
IF ConsoleMode THEN
RunConsole(Parameters)
ELSE BEGIN
Application.Initialize;
Application.CreateForm(...)
Application.Run;
END
(or vice-versa, ie. doing things a special way if GUI mode)
so that I can still use Delphi's IDE and VCL when making the GUI interface...
On Windows this is a little bit tricky. Actually the distinction between a console application and a GUI one is a single flag in the PE header. You can easily write console applications that create windows but that way you always have the console window around (you could hide it, though, but that wouldn't be nice when people run your program from cmd).
You can, however write a GUI application that creates a console if it needs to, using the AllocConsole function:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
If the calling process creates a child process, the child inherits the new console.
AllocConsole initializes standard input, standard output, and standard error handles for the new console. The standard input handle is a handle to the console's input buffer, and the standard output and standard error handles are handles to the console's screen buffer. To retrieve these handles, use the GetStdHandle function.
This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).
However, when run from cmd this will likely cause another console window to appear instead of re-using the existing one. I don't know whether a good solution exists there.
IMO, the best approach here is to have non-visual classes that actually do the work of the program. Then you can call that from a GUI program, and you can also call it from a separate command line program. Both programs are just wrappers around the functionality of your class(es).
This forces the design to be clean too - your classes necessarily are separated from the GUI layer of your application.
http://blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx
Windows has different values in executable's header for console and UI application (see more details here). So it seems to be impossible to make the same executable to work in both modes.
As an alternative, you can open a console in you UI app, but it will be new console, not the one you've started app from.
AttachConsole() may be used to get a hold of the parents console.
E.g. if the application is started from a cmdline shell, AllocConsole() can be avoided:
if not AttachConsole(ATTACH_PARENT_PROCESS)
then AllocConsole;
More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx