|
He's trying to read C++ source code in C# and extract all the function signatures: Parser or regular expression?[^]
He thinks Clang will do it - it might - but he has no idea how to use it, or any real idea of how much work is involved in reading C++ source code ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
LOL - ok.
Did someone already suggest he should just build a parser (or just use one that is already out there)?
|
|
|
|
|
Oh yes. But since we didn't build it for him ... 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thought I'd try writing a console app and run it elevated to update a json file in the Application Folder that has extreme security on the file. So far so good, but I'm trying to pass the json as it's written in the file over to the console app and it losses it's format and becomes invalid json.
At first it's a class object called rootObject. Then I serialize the class into a string that can be written directly as a file. So I'm missing something here. I figured it would be like sending json from a .Net controller to a client but I never really studied how it works. I googled it for awhile but it's all web stuff.
Any thoughts?
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
I think I got it, base64 string like an image
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
It seems liek you are trying to pass the json string on the command line when launching the console app, correct?
I'll assume that's a yes. The problem is quote marks on the command line are used to enclose arguments with spaces in them and that screws up your command line parsing.
For a requirement like this, I would not use the command line at all to pass a json file, or even use Base64 encoding to pass it either. Depending on requirements, I would start the command line app as a permanently running process for the lifetime of the app and have pass json and other commands and responses over a shared memory mapped file or named pipe.
modified 1-Feb-19 8:42am.
|
|
|
|
|
I changed the format to pass the data to Base64, but overall it was a bad idea to fix an even worst plan.
I'll move these files out of the application folder and dump this idea.
Thanks Dave!
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
I'm learning MongoDB. I'm working on a Repository<t> implementation for both MongoDB and LinqToSQL.
My MongoRepository Add method is
public override void Add(T entity)
{
var collection = GetCollection(CollectionName);
collection.InsertOne(entity);
}
This works fine. This writes out
_id:Binary('aE/9nTBrM0mkDMf6/GpSCg==')
FirstName:"John"
LastName:"Smith"
Class:"English 101"
Age:32
to the Students collection.
Then, my Get method has:
public override T Get(Guid id)
{
var collection = GetCollection(CollectionName);
var result = collection.Find(r => r.Id == id).FirstOrDefault();
return result;
}
and I call it like this
private static void GetStudent()
{
var student = _repository.Get(new Guid("aE/9nTBrM0mkDMf6/GpSCg=="));
Console.WriteLine(student);
}
The exception is "Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).'"
It seems that Mongo stores the Guid differently than in .Net. What's the right way to fix this? Not sure how to handle this.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
CodeProject is your friend: "3 Best Practices for GUID data in MongoDB" [^]
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Kevin Marois wrote: "aE/9nTBrM0mkDMf6/GpSCg=="
That's a Base64 encoded string containing the Guid bytes, so:
new Guid(Convert.FromBase64String("aE/9nTBrM0mkDMf6/GpSCg=="))
which returns: 9dfd4f68-6b30-4933-a40c-c7fafc6a520a
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Learn go debug - it is simple to learn and it will save you a LOT of time.
The first you can do is split the program out over multiple lines so it is easier to read and debug.
So instead of
string sub = line.Substring(line.IndexOf("<a name=") , line.Length - line.IndexOf("<a name=") - 6);
you can do something like:
string line = "<p class=\"rvps5\"><a name=\"4980_YM\"></a>";
int startPosition = line.IndexOf("<a name=");
if (startPosition >= 0)
{
int length = line.Length - startPosition - 6;
string substring = line.Substring(startPosition, length);
Console.WriteLine(substring);
}
Now set a breakpoint and step through each line. Inspect the variables as they are assigned to ensure they are the correct value. Once you do this, it will be evident that the startPosition is wrong, and the length does not match the length of the string. You will make mistakes like this ALL the time - we all do. Once you structure your code so it does less at once and spend 10 minutes learning debugging, you will fix errors like this in a few seconds.
In general parsing HTML is somewhat tricky to get right, and covering all different ways the same text can be represented is extremely difficult - but if your source text is consistent you should be able to get it working with this method.
|
|
|
|
|
Use a Regex:
(?<=<a name=").*?(?="></a>) Should do it.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
If the entire C# reference is open to you and you don't have to reinvent the wheel, you could parse it like it is xml and use Linq to Xml or an XmlReader. It goes much faster and has the added benefit of teaching you how to use these libraries to solve your problem.
I'm all for learning how to use regex and pattern recognition to parse strings if that is the exercise, but an important part to learn about programming is to make full use of the tools available to you rather than writing a solution that is already there, and most likely better optimized than what you can write.
|
|
|
|
|
I began the process of pulling stuff out of the registry and put them in a file called appSettings.json.
I installed the file in the target directory using WIX, and can't write to the file. The file has Admin level permissions, when you right click the file it shows the Shield.
When developing, it wasn't an issue. I didn't notice till I started testing the release version actually installed.
I tried modifying the file in WIX, but it doesn't do anything. I read the documentation and I'll swear that the code below is valid.
<Component Id="appSettings.json" Guid="6637d445-883d-46d6-a8b6-ad01e5814e27" NeverOverwrite="yes" Permanent="yes">
<File Id="appSettings.json" Name="appSettings.json" Source="$(var.AccountMate_TargetDir)appSettings.json" ReadOnly="no" >
<util:PermissionEx ChangePermission="yes" User="Users" Write="yes" WriteAttributes="yes" WriteExtendedAttributes="yes"/>
</File>
I'm wondering now if I should just move the file someplace else.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
Well this is a Wix installer issue and my mistake. this appSettings file, well I wanted it to persist with settings when doing an program upgrade so I made it permanent. Bu then that made the file read only. The ex:persmssion did work, but created special accounts instead with the read only permissions.
I'm thinking back to Original Griff saying not to use the registry, but the registry sure seems much easier to manage than a file in the Program Application Target Dir. Perhaps times have changed or I just didn't think it all the way through.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
The registry is - and was - easy to use, which meant it got abused, and badly. As a result, it's harder to use these days than it was (because badly written aps could do serious damage to a load of things) and that's not likely to get easier: quite the reverse.
Instead of that, there are environment folders (try typing "%appdata%" into the Windows explorer Address bar) which "separate" data and allow you to store what you want. (Where should I store my data?[^] shows how to use them in C#) and using XML, JSON, or any other format for data storage is pretty easy and flexible these days.
Pretty much as simple as using the registry, but with added flexibility and the ability to "share" info between apps: Instance Storage - A Simple Way to Share Configuration Data among Applications[^] for example.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I hear what your saying there about the registry, and tried avoiding it. but I had a bad plan as far as location goes. My code is solid for reading and writing my json file, but I located the file in the wrong place. I learned this after reading up some more and examining other packages like Docker and how they did it. If my json file was read only then it would of worked fine.
I'll migrate it to AppData, and figure out how to get it there during install, or generate it.But I will store the location of my program in the registry so my other exe's can launch correctly.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
The file should only be modified by an installer. If it is changed by the program, it is data. If it is data, it should be in another folder. You can manage security on that folder, and even choose to encrypt the data.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I'm in the process of changing the location now. I just have to fix my installer registry errors first.
Then change my code. I'll put my nLogs in the same place as well.
Thanks Eddy!
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
Np; look at it like this; "Program Files" and the like are statical libraries, only to be changed during install-procedures. They're also likely to have a different backup-strategy from the data in the user-accounts.
The data you're proposing might even have to survive an install/uninstall-attempt?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
That's what got me into trouble in the first place, was surviving an uninstall and upgrade.
Now I get it. Got my registry fixed now, so time to move that location.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
How many companies back up the registry on each machine? How often does a VM get replaced?
Put it somewhere the sysop expects it and where backups actually occur 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Now you lost me. I was going to place it in the Users AppData Folder.
It's just a client app, and the file stores the MongoDB connection string and the SMTP parameters to send mail.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
