NSIS Special Build - Logging and Long String (8192 byte) - nsis

I have found special builds of NSIS for Advanced Logging and Long strings (8192 bytes), but I need to incorporate both into an installer.
I do not have a developer environment set up where I could compile my own version of makensis, so I was hoping that somebody with this Advanced Logging and Long string configuration could share their makensis.exe and stubs.
Any help would be greatly appreciated.
Thanks.

You can try this but I'm not sure what the log limit is, if you need to log strings > 2000 bytes you should file a bug report to get the logging fixed...

Related

Tokenization is skipped for long lines for performance reasons. The length of a long line can be configured via `editor.maxTokenizationLineLength`

I'm at a loss here. I have a Node.js server built for my project and out of nowhere, I started getting this error when I try to run the server in VSCode:
Tokenization is skipped for long lines for performance reasons. The length of a long line can be configured via editor.maxTokenizationLineLength.
I had edited some of my functions in my controller before this started. I discarded all changes but the error still persists. I don't understand what has changed for this to happen. Any advice would be greatly appreciated.
My code is here if you want to take a look
https://github.com/Kevinclane/timeclock
I fixed this problem by increasing Max Tokenization Length in VSCode :
Go to File--> Preferences--> Setting
Search for Max Tokenization Length
Change the default value to 2000000
I hope this will help
Apparently, just toggling the options for breakpoints on caught and uncaught exceptions causes it to fail... Doesn't make sense, but it works now.
This is not actually an error as such. If you assign really long length string to a variable, you might see this:
However, you will be still able to use that variable.

Ezjail and /etc/jail.conf in FreeBSD 10.2

I have a question regarding the following warning when using
Ezjail-3.4.1 on FreeBSD 10.2
/etc/rc.d/jail: WARNING: Per-jail configuration via jail_* var "enter code here" iables is obsolete. Please consider to migrate to /etc/jail.conf "enter code here"It is my understanding that this has changed in FreeBSD 9.0 but since 10.2 the new way is the default method and that warning is being generated.I haven't been able to find any information about this on google, a lot of users mentioning the errors but ignoring them because their jails still work.AFAIK in 10.0 the rc.d/jail script converts the old-style jail_
variables into a temporary jail.conf to handle the jail. So the warning
is generated by rc.d/jail
Regards
Mr-Hill
As you found out, jails on FreeBSD 10.x use a new configuration method. From /usr/src/UPDATING:
20131010:
The rc.d/jail script has been updated to support jail(8)
configuration file. The "jail_<jname>_*" rc.conf(5) variables
for per-jail configuration are automatically converted to
/var/run/jail.<jname>.conf before the jail(8) utility is invoked.
This is transparently backward compatible. See below about some
incompatibilities and rc.conf(5) manual page for more details.
These variables are now deprecated in favor of jail(8) configuration
file. One can use "rc.d/jail config <jname>" command to generate
a jail(8) configuration file in /var/run/jail.<jname>.conf without
running the jail(8) utility. The default pathname of the
configuration file is /etc/jail.conf and can be specified by
using $jail_conf or $jail_<jname>_conf variables.
Please note that jail_devfs_ruleset accepts an integer at
this moment. Please consider to rewrite the ruleset name
with an integer.
ezjail was never updated to use this new method, but that's ok: FreeBSD still accepts the previous method. You can ignore this warning.

Oracle Data Integrator Oracle to Excel encoding

I try to export my Oracle view data to Excel sheet using Oracle Data Integrator.
English text is exported good, but russian (cyrillic) is wrong!
Help me please, how can I configure datasources and encoding.
After export to excel data has cp1252 encoding, but there is no place where such encoding is configured!
Information:
Oracle DS use jdbc:oracle:thin and
NLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251
(in windows registry and environment variables(same to database).
ODI starting with product.conf:
AddVMOption -Dfile.encoding=Cp1251
AddVMOption -Dsun.jnu.encoding=Cp1251
AddVMOption -Duser.language=ru
AddVMOption -Duser.country=RU
(and I see such values in Help-About-Properties.
Excel DS use jdbc:odbc and
charSet=cp1251
property.
Oracle 12c, ODI 12c.
If I execute simple java code with
-Dfile.encoding=Cp1251
option - russian language displays correct, but not over ODI...
I would be glad any advice!
I want to answer my own question.
May be it is obviously for anyone, but I found solution not fast...
I need to change Windows property Current language for non-unicode programs. from English to Russian.
So I even not need "AddVMOption -Dfile.encoding=Cp1251" options in ODI - they are set correct after changing property.
Hope this information to be helpful for someone.

Windows Store TriageDump.dmp without debug information

Greetings people,
My Windows Store game has been released for more than three weeks now, and I started getting crash reports. I could download the TriageDump.dmp file and have it opened in Visual Studio 2012, but it did not help much, I am constantly getting "No Debugging Information" error message when I click on "Debug with Native Only":
Also, the tool-tip on my Dashboard shows no information of the crashing function (could "Unknown" here mean inlined function or lambda expressions in concurrent::task?):
I would like to believe that I have done everything the way it should be done, of course I may be wrong. Here are some additional information that might be helpful in finding the issue:
It uses DirectX and written purely in C++ (without C# or XAML)
Project setting: C++\General\Debug Information Format = Program Database (/Zi)
Project setting: Linker\Debugging\Generate Debug Info = Yes (/DEBUG)
The game is made up of two native modules: Labyrinth.App.exe and Labyrinth.Core.dll
The generated APPXUPLOAD contains both APPX and APPXSYM files
The APPXSYM file contains both Labyrinth.App.pdb and Labyrinth.Core.pdb
I'm on x64 development machine, and the triagedump.dmp is for x86
I did click on "Include public symbol files, if any, to enable crash analysis for the app" when generating APPXUPLOAD file:
Please let me know if you spotted the issue or suspected something that's wrong above. Thanks in advance for your help, guys! :)
The very same problem here. MS had that working in the past though.
Actually if you still have the .appxsym around you can easily extract the .pdb out of that. The appxsym is just a .zip file it seems.
You can load these pdbs then as symbols after loading the triagedump.dmp.

Windows mobile 6.5 - best way to read and write from and to a config file

I have a handheld device running WM6.5 and trying to put together an application that should prompt the user for some information (login, password) and save it to a file for later use.
Have tried app.config files but unfortunately it requires System::Configuration, I can add the DLL but can't get the code to run, it requires CRL or something like that which I can't configure this being a mobile app - the required option is missing from the project/solution configuration section.
I am using Visual Studio 2008 C++
What's the best way to make this happen? Precisely, 1) write a string somewhere and 2) read it back later on.
TIA
Later edit:
I have tried using a binary file, like this
// write to config file
std::string s="helloworldhelloworldhelloworld";
ofstream ofile("test.txt",ios::binary);
ofile.write((char*)s.c_str(),strlen(s.c_str()));
ofile.close();
And then I have tried reading it back like this
// read config file
char read_str[60];
ifstream inf("test.txt",ios::binary);
inf.read(read_str,60);
inf.close();
LPCTSTR application_settings = CA2W(read_str);
What happens is it adds some garbage at the end of the string, if the string is longer less garbage, otherwise more.
Is there a way to sort out this conversion issue?
Turns out, project was using Unicode and had to use wifstream and wofstream to be able to properly read the strings, rather than attempt to convert them from ANSI to unicode.
This should be a reminder for me to stay away from strong typed languages in the future. Too bad there's no other significant choice for Windows Mobile. Spent a bunch of hours on this, I could have used that time for something else.

Resources