Disclaimer: yes I know that this is not "supposed to be done" and "use interface composition and delegation" and "the authors of the language know better". However, I am confronted with a choice of either copy-pasting from the standard library and creating my own packages, or doing what I am asking. So please do not reply with "What you want to do is wrong, you are a bad dev and you should feel bad."
So, in Go we have the http stdlib package. This package has a number of functions for dealing with HTTP Range headers and responses (parsers, a struct for "offset+size" and so forth). For various reasons I want to use something that is very similar to ServeContent but works a bit differently (long story short - the amount of plumbing needed to do the ReaderAt gymnastics is suboptimal for what I want to accomplish) so I want to parse the HTTP Range header myself, using the utility functions/structs from the http stdlib package and then deal with them manually. Basically, I want a changed version of ServeContent :-)
Is there a way for me to "reopen" the http stdlib package to use it's unexported identifiers? ABI is not a concern for me as the source is mine, the program gets compiled from scratch every time etc. etc. and it does not need binary compatibility with older/other Go versions. I.e. I am able to ensure that the build is going to be done on a specific Go version and there are tests to check that an unexported identifier disappeared. So...
If there is a package called foo in the Go standard library, but it only exposes a MagicMegamethod that does the thing I do not need, and uses usefulFunc and usefulStruct that I want to get access to, is there a way for me to get access to those identifiers? Either by reopening the package, or using some other way... that does not involve copy-pasting dozens of lines from stdlib without tests etc.
There exist (rather gruesome) ways of accessing unexported symbols, but it requires nontrivial amounts of tricky code, so there's unlikely to be a net win.
Since you've outruled the "don't do this" direction, it seems that the answer is either NO or use the methods described in the post I linked to (and this repo).
FWIW I'd personally just copy the code I need from the standard library and tweak it to my needs. This would likely take less time than the time it took you to write this SO question :-)
The documentation says that it should be supported.
It seems that its not implemented in the gen.go file:
case types.Uint8: // types.Byte
return "uint8_t"
// TODO(crawshaw): case types.Uint, types.Uint16, types.Uint32, types.Uint64:
I read that i need to patch go mobile to support
But after changing the file to support Uint64, (go/src/golang.org/x/mobile/bind/gen.go)
And re init go mobile: gomobile init
The same error still appears, am i missing something obvious here?
I think the issue here is that Java does not have unsigned. Therefore interfaces to Java cannot have uint64 (and uint32 IIRC) file types as either global variables, function return values or function parameters.
You can use uint64 within Go mobile.
Two solutions based on the above:
Limit the exposure of illegal types to Java to a minimum
Convert uint64 to int64 in Go and convert from long to BigInteger in Java.
I solved this by patching Go mobile, inspired by this very StackOverflow post! I use "patch" very loosely, I don't encourage anyone to use this code as it is very purpose-specific.
I simply short-circuited the default case to return uint64 - you can see exactly what I did here: https://github.com/Sidetalker/mobile/commit/01eb11be69a781e71c7f00df6fc17b35f828f7a2
I needed to make a handful of other find/replace changes you can see on that branch to get it building properly, and I also had to fix what I'm pretty sure is a Go mobile bug with the byte type. All of this can be see on the branch.
Also, critically, I had to fully go get this project - making my changes and running gomobile init was not sufficient.
Don't use this code. Do mark this answered.
This is extremely strange, and I'm hoping someone will have some insights to make sense of this.
I have an F# 2.0 (Visual Studio 2010, targeting .Net 4.0) solution which works fine in the location where I originally created it, but if I try and copy it to a new folder (because I want to check it in to source control), I get some very odd errors when building. They tend to be along the lines of:
error FS0803: Invalid use of a type name and/or object constructor. If necessary use 'new' and apply the constructor to its arguments, e.g. 'new Type(args)'. Overloads are: None() : unit.
or
error FS0001: This expression was expected to have type obj option but here has type Some<'a>
These errors are only occurring for uses of the option type, a simple example of one such usage being:
let asOption e =
match e with
| null -> None
| _ -> Some(e)
Now, remember, this is a solution that compiles just fine in its original location. I've tried the obvious like Clean/Rebuild, deleting the obj and bin directories, restarting Visual Studion, and still, the same.
The reference DLLs are all the same in both cases, GAC'd DLLs are being referenced from the GAC, non-GAC'd dlls are copied and being referenced from the same relative path. Just for fun, I've even compared the output window text of the calls to Fsc.exe used to compile each solution to ensure the compiler is being called with the same arguments in both cases, and, naturally, it is.
Anyone have any idea of what may be causing this? Am I getting some strange limbo version of FSharp.Core.dll out of the GAC somehow? Am I just the most unlucky of the unlucky stiffs?
So the weird symptom had an equally weird cause.
It turns out one of the DLLs I was referencing (the ubiquitous "Core" junk-drawer dll every project has) must have some extension methods in place that are causing some issues with the type inference used by the compiler and visual studio.
When I remove the open MyProject.Core and replace any of the references to types I'm using with the fully qualified name, the strange errors magically go away.
So, at this point, two questions remain:
What kind of insane extension methods are in there that could be causing this
Why was the original solution/project unaffected by this? (I'm guessing this may be related to the order in which the references were passed into the call to Fsc.exe...but I'm not sure).
I may actually dig in enough to try and figure out the answer to #1. I'm not sure if it is exposing some sort of bug with the F# compiler (doubtful), or if my co-workers are just doing something unnatural with extension methods (highly likely)
UPDATE:
Looks like someone had some F# envy and created an Option<T> class in the Core project. Pretty much explains things. I've not experimented to see if the order of the includes on the Fsc.exe call make a different, but I have a feeling that is it.
References should almost never come from the GAC, they should come from Reference Assemblies. Post the fsc.exe command-line you are witnessing, perhaps it will shed more light. I am guessing the FSharp.Core reference is messed up somehow (perhaps related to the sigdata/optdata files that stand alongside its reference assembly?)
(Points for a very weird symptom, though!)
Assuming F# compiler is deterministic, there obviously must be some difference in how it is being invoked, perhaps in the environment variables. Have you tried running MSBuild from the command line? It usually helps with these kind of things.
One guess of what's going on is that F# infers different types for your code. Have you tried constraining it a bit to only have to deal with simple types? For example:
let asOption (e: obj) =
match e with
| null -> None
| _ -> Some(e)
Or else:
let asOption<'T> (x: 'T) : option<'T> =
if x :> obj = null then None else Some x
The later gets rid of the null constraint on the generic parameter.
First of - Hello and thank you for reading this,
I have one DLL which I do not have the source code but need to add some functionalities into it.
I made up another DLL implementing all these needed functionalities in C - using Visual Studio.
Now I need to insert the generated code from this new DLL into the target DLL (it has to be done at the file level {not at runtime}).
I am probably creating a new PE section on the target DLL and put there all the code/data/rdata from the dll I made up. The problem is that I need somehow to fix the IAT and the relocs relative to this new inserted code on the target DLL.
My question is:
What is the best way to do it?
It would be nice if Visual Studio came up with an option to build using only (mostly) relative addressing - This would save me a lot when dealing with the relocs.
I guess I could encapsulate all my vars and constants into a struct, hopefully MSVC would then only need to relocate the address of this "container" struct and use relative addressing to access its members. But don't know if this is a good idea.
I could even go further and get rid of the IAT by making a function pointer which would dynamically load the needed function module (kind of the Delay Load Module). And again, put this function pointer inside the "container" struct I said before.
The last option I have is to make it all by hand, manually editing the binary in hex... which I really didn`t want to do, because it would take some good time to do it for every single IAT entry and reloc entry. I have already written a PE file encryptor some time ago so I know most of the inner workings and know it can be done, just want to know your thoughts and maybe a tool already exists to help me out?
Any suggestions is highly appreciated!
Thanks again for your time for reading this!
Since you are asking for suggestions, take a look at the very good PORTABLE EXECUTABLE FILE FORMAT – A REVERSE ENGINEER VIEW PDF Document. The Section "Adding Code to a PE File" describes some techniques (and presents Tools) to add code to an existing PE image without having the code of the target image (your scenario) by manipulation the IAT table and Sections tables.
Very simple question that is apparently impossible to find a decent answer to: How can I make Visual Basic 6 stop changing my ^##*ing variable casing!?!
I know that the general opinion of a great many VB users is that this "feature" is actually quite helpful, but I doubt that they use it much with any source control system. This is absolutely INFURIATING when you are trying to collaborate on a project of any significant size with several other developers. If ignored, you produce thousands of false-positive "changes" to your files (even ones with no actual code changes!) that pollute the revision history and make it near impossible in some cases to locate the actual change that took place.
If you don't ignore it (like my office, where we have been forced to implement a "no unneeded case change" policy), you spend 5x the time you would normally on each commit because you have to carefully revert out VB's "corrections" on every file, sometimes reverting hundreds of lines to put in a one line change.
Surely there must be a setting, plugin, hack, etc. out there that can remove this unwanted "feature"? I am willing to take any method I can get as long as it doesn't require me to pick through piles of phantom diffs. And to squash a couple of complaints up front: No, I can't turn off case detection in my diff tool, that's not the point. No, we can't just make the case changes globally. We're working with hundreds of thousands of LOC being worked on by multiple developers spanning many years of development. Synchronizing that is not feasible from a business standpoint. And, finally: No, we cannot upgrade to VB.net or port to another language (as much as I would love to).
(And yes, I am just a tiny bit peeved at the moment. Can you tell? My apologies, but this is costing me time and my company money, and I don't find that acceptable.)
Depending on your situation adding
#If False Then
Dim CorrectCase
#End If
might help.
Here is a real world scenario and how we solved it for our 350k LOC VB6 project.
We are using Janus Grid and at some point all the code lines which referenced DefaultValue property of JSColumn turned to defaultValue. This was an opportunity to debug the whole IDE nuisance.
What I found was that a reference to MSXML has just been added and now the IDE picks up ISchemaAttributes' defaultValue property before the Janus Grid typelib.
After some experiments I found out that the IDE collects "registered" identifiers in the following order:
Referenced Libraries/Projects from Project->References in the order they are listed
Controls from Project->Components (in unknown order)
Source Code
So the simple fix we did was to create a dummy class/interface with methods that hold our proper casing. Since we already had a project-wide typelib we referenced from every project before anything other typelib, this was painless to do.
Here is part of the IDL for our IUcsVbIntellisenseFix interface:
[
odl,
uuid(<<guid_here>>),
version(1.0),
dual,
nonextensible,
oleautomation
]
interface IUcsVbIntellisenseFix : IDispatch {
[id(1)] HRESULT DefaultValue();
[id(2)] HRESULT Selector();
[id(3)] HRESULT Standalone();
...
}
We added a lot of methods to IUcsVbIntellisenseFix, some of them named after enum items we used to misspell and whatever we wanted to fix. The same can be done with a simple VB class in a common library (ActiveX DLL) that's referenced from every project.
This way our source code at some point converged to proper casing because upon check-out the IDE actually fixed the casing as per IUcsVbIntellisenseFix casing. Now we can't misspell enums, methods or properties even if we try to.
SIMPLE WAY: Dim each variable in the case that you want. Otherwise, VBA will change it in a way that is not understandable.
Dim x, X1, X2, y, Yy as variant
in a subroutine will change ALL cases to those in the Dim statement
I can sympathise. Luckily we're allowed to turn off case sensitivity in our version control diff tool!
It seems the VB6 IDE automatic case-correction occasionally changes case in variable declarations and references, perhaps depending on the order in which modules are listed in the VBP file? But the IDE doesn't tell you that the file needs to be saved. So the problem only shows up when you saved the file because of another edit. We briefly tried to prevent this by checking out all the files in a project and setting the case carefully, but it didn't go away.
I suppose you could list the variable names that are affected - the usual suspects are one letter names like "I", "X" and "Y", perhaps because they are used in standard event handlers like MouseDown. Then write an add-in that'll search for all declarations " As" and force the case to upper. Run the add-in on your modules before you check them in. You might be able to trigger the add-in to run automatically when you save in VB6.
EDIT: Something I've just thought of: adapt Fred's answer. From now on, every time you check in a file, add a block at the top to establish canonical case for the usual suspects. If nothing else, it's easier than reverting hundreds of lines by hand. Eventually you will have this block in every file & maybe then the problem will stop happening.
#If False Then
Dim I, X, Y ' etc '
#End If
I standardised the case across the codebase, normally by using the examples above (Dim CorrectCase), and removing it again.
I then triggered VB to save EVERY file, by doing a case sensitive search/replace of "End" with "End" (no functional change, but enough to get VB to resave).
Once that was done, I could then do a single commit to standardise the case, making it MUCH easier to keep on top of it at a later date.
In this example VB6 was changing the case of the following line following a typo I made when referencing a library: -
Dim MyRecordset As ADODB.REcordset
Ugly, and now every other instance of an ADODB.REcordset thus acquired the new misspelling. I fixed this as follows: -
Type in a new declaration as follows
Dim VB6CasingSucks AS ADODB, Recordset
Note the comma and space after ADODB. Hit [ENTER] for VB6 to check the line.
At this point all instances of REcordset change back to Recordset.
Delete your new declaration.
I don't know if this fix will help with enums/other variable names.
Specifically for controlling the case of enum values, there is a VB6 IDE add-in which may be helpful. Enums seem to have a slightly unique version of this problem.
As described in the link below:
The VB6 IDE has an annoying quirk when it comes to the case of Enum
members. Unlike with other identifiers, the IDE doesn't enforce the
case of an Enum member as it was declared in the Enum block. That
occasionally causes an Enum member that was manually written to lose
its original case, unless a coder typed it carefully enough.
...
However, if a project contains a lot of Enums and/or a particular Enum
has a lot of members, redeclaring the members in each of them can get
quite tedious fast. ...
Ref: http://www.vbforums.com/showthread.php?778109-VB6-modLockEnumCase-bas-Enforce-Case-of-Enums
...load and unload the add-in as needed via the Add-In Manager
dialog box. Usage is as simple as selecting the entire Enum block,
right-clicking and then choosing the "Lock Enum Case" context menu
item.
I have a similar problem:
in a bas module there I wrote :
Private sub bla_bla()
Dim K as integer
End Sub
so in a class module the Dim k as integer will automatically be replaced by IDE become 'Dim K as integer' <-- it's not logical but then:
I correct the bas module become:
Private sub bla_bla()
Dim k as integer
End Sub
then magically the problem in the class module was solved (still be k and not automatically replaced by IDE become K). Sorry I'm poor in English
I don't think there's any to do it. The IDE will change the case of the variable name to whatever it is when it's declared. But, honestly, back in the day I worked on several large VB6 projects and never found this to be a problem. Why are people on your development team constantly changing variable declarations? It seems like you have not established a clear variable naming policy that you enforce. I know your upset, so no offense, but it might be your policies that are lacking in this regard.
Unfortunately, according to this SO thread, alternate VB6 IDEs are hard to come by. So, your best bet is to solve this problem via policy. Or move to VB.NET. :)
Wow. I've spent a lot of time programming in VB6 and I have no idea what you're on about. The only thing I can think you're referring to is that intellisense will change the capitalization of variable names to match their declarations. If you're complaining about that, I would have to wonder why the hell they've been entered any other way to begin with. And if that is your problem, no, there's no way to disable it that I'm aware of. I'd suggest you, in one go, check out every file, make sure the caps on the declarations and uses of variables all match and check back in.