I am using plugins for one of my Mac OS X(desktop) application. These plugins refer to a common file that contains base class implementation of both the plugins.
When the application refers to this common base class, the following message is displayed in the console by the system:
" is implemented in both and . One of the two will be used. Which one is undefined."
This console message is displayed from 10.5.x onwards.
However this does not cause any problem. But, I do not want my class name to be printed in the console. Can someone help to avoid this console message.
A possible way around is to #define the name of your class as something unrelated, so that it remains the same in your code, for your use, but is obfuscated in the executable.
I'd like a neater solution myself. I have searched quite a lot, and it seems that in general console messages are for solving problems, rather than for looking for them, and more specifically that this kind of message isn't really an issue.
One can also use an EXPORTED_SYMBOLS_FILE or an UNEXPORTED_SYMBOLS_FILE (these are the relevant build setting names) to state which symbols you do or don't want to export. Often, you want to export at least one, but it can reduce the number of names that are revealed.
Related
I’m using Intellilock in order to obfuscate and lock my SW.
I tried to use “simple” obfuscation options with following params:
and when decompiling the code (using JetBrain.dot peek) I got the following code:
Since the code IS runnable and since any idiot can understand that the second parm is the password – a breakpoint gives us the password which the SW uses in order to encrypt some files.
So I tried to check the two circled checkboxes (public types/all parameters). When Opening JetBrain.DotPeek – the result is fantastic – nothing is understandable.
But now the SW doesn’t open at all….
When looking into windows event viewer I get the following log:
.
Which means the static main couldn’t start even…
Any simple guidlines for how to normaly obfuscate my code?
Thanks!
So - I got a reply from IntelliLock support.
Obfuscating a public class requires obfuscating all dlls calling this class, such that all will get the new, obfuscated name.
So just adding all dlls is required.
I'm not sure yet [and will update hopefully] if skipping ignoring them will be sufficient.
I would like to add new match field of type OXM_experimenter class OVS source code, could anyone share proper document or steps to do it. It needs changes in many of the files and functions and understanding OVS source is somewhat difficult. If any added already and tested, can you guide ?
I successfully did this before, however, I don't have access to the code anymore, only bookmarks to stuff. There is an old thread in the mailing lists that may help you: Link and Link.
I wanted to handle PACKET_IN events in OVS a bit differently, so I followed the way of packets from the data plane through the upcall bit to ofproto-dpif-xlate.c. On the way, I stumbled upon a lot of constants. After adding my own to the enums, the last bit missing was the experimenter field, which was somewhere in the python scripts as described in the links above.
I hope this helps, I'm in the process of getting access to the code again I'll update my answer then. If not, the OvS discuss mailing list and archives may help you too.
We use obfuscation jar in our build and we use Log4j2 for logging purpose. However, the informative logs which we are logging as a string are being logged correctly. But, the logs in case of exception, i.e. the trace of exception or exceprion.getmessage() doesnot print the details. That too comes in obfuscated form, i.e. its not readable.
Any suggestions to overcome this problem?
That sounds like expected behaviour...
At runtime, class names and package names are scrambled, so stack traces may not look pretty.
Does your obfuscator not have a de-obfuscate function? I imagine it would generate a file with meta-data (mapping between cleartext names and scrambled names) when it does the scrambling.
If your users then have an issue they need support for, they send you their (scrambled) stack trace. You can unscramble that stack trace and make it readable again by using that meta-data file. (You should keep one for every version of your library that you publish.) That's how you would deal with support issues.
You are probably initializing your loggers like this:
Logger logger = LogManager.getLogger(MyClass.class.getName());
This way is useful during development when you rename / refactor your code a lot. But once you are satisfied with your code you should replace that line with a constant name like this:
Logger logger = LogManager.getLogger("my.package.MyClass");
This way the class name - i.e. logger name - wouldn't be obfuscated.
I'm currently creating a code named "SET". The code's name is an acronym, which has been defined for many (non programming) reasons, and therefore cannot be changed.
Problem: The easiest, and I believe the less painful way for the end-user to use my code would be naming the package "set".
But of course this is a problem since this conflicts with the built-in set function.
Question: What are the possible solutions? Some may be (there is probably more):
change the package name (eg. setb).
import setb
I would really really prefer not to, because then it will be different from the real name
make the package's name upper-case (SET)
import SET
It would be a straight forward solution, but I'm wondering: is this a pythonic proper naming for a package? Also, I find this a bit painful since all modules defined in the code will have something like "import SET.x.y..." (ie. upper-case, written a lot of times). But this is not a really big deal if this is a pythonic way.
keep the name "set"
import set
Well this is obviously not fine. But it would be a problem only if the user is using "import set", would not it be? This should not happen in "normal usage conditions", since the code will provides some scripts to use it, rather use it as a standard python module. But we never know, and it could be imported as it, and there may be even some problems I'm not seeing (with the built-in set).
I'm considering the solution 2., but I'm really not sure. Maybe this is not proper, or maybe you guys have a better solution.
PS: I've found some similar topics on the web and on stackoverflow, but it usually deals with names inside a script or module inside a package. The problem here is really related to the code's name (which is meaningful only written this way), and therefore related to the proper naming of the package's name.
EDIT
Selected solution: I've choosen to use "SET" as the package name. Although many good suggestions have been proposed here: pyset, semt, setool... or the more explicit "starexoplanettool" (expliciting the acronym). Thanks to you all.
EDIT #2
I like the "funny" solution of having a package named S, and a subpackage, E... to get finally:
import S.E.T
Thanks Don Question.
Why not spell out the meaning behind the acronym, and if the user is desperate for a shorter name, they can do import someetymologyterm as SET or whatever they prefer. Python gives them the choice, so it's not the end of the world either way.
Is this a pythonic proper naming for a package?
Under the circumstances, it doesn't matter.
Leading upper case is rare (ConfigParser, HTMLParser). Camel-case is rare (cStringIO).
But that doesn't make all upper-case wrong.
It just means you should pick a better acronym next time.
"set" is the English word with the largest number of definitions. It is the single poorest choice of acronym possible.
The point is not to conform to a community "standard" of more-or-less acceptable behavior.
The point is to write something that works.
(ie. upper-case, written a lot of times).
Hardly a concern. People actually run software more often than they write it.
People read and tweak more often than writing, also.
If you're worried about misspelling, there's copy and paste.
Also, even a cheap IDE like Komodo Edit can figure out how to code-complete an installed module with a long name.
If you have to choose such a misfortunate name, you could make the pain in the ass an ironic anathema! Just create a main-package "S" with a subpackage "E" and therein a subpackage "T".
Then you could do an:
import S.E.T
or
from s.e.t import xyz
or
import s.e.t as set_
you could even do some vodoo in the __init__.py file of the main-pacakge ;-)
Just my 2 cents!
Maybe I'm not getting it but this looks simply like a namespace problem.
Here is one way out. Prepend the path to the set.py onto the sys.path Before the import takes place. You can wrap this in a function which backs out the change after the import.
I'm in train so can't test this but that is what I would try.
We're trying to learn to use T4 Templates. I have a desire to use the System.Data.Entity.Design.PluralizationServices library in order to better pluralize some Entity Model names within my template, but I've come across some issues in the achievement of this goal.
Running code to generate output text. I think this is possible, but if it's not going to work, then there's no need to go any further. (I could call Date.Now.ToString() and get the expected result. I haven't tried anything much more complicated yet)
I am in a Silverlight App, and so I can't add a reference to the project for the PluralizationServices library in the place where I need the generated .cs file. I was planning on just moving the .tt file to a non-SL app, using the namespace and moving the generated file to the correct space. Haven't got that far yet, so I don't know how much trouble that will be, but it doesn't seem like it should be too hard.
My current problem is that when I import the namespace of the library, I get an "ErrorGeneratingOutput" and I haven't been able to move on past that yet.
I am having a hard time finding information about how the import command works, so I assume that it's just obvious. At the same time though, this one doesn't work so I wonder if it might be an exception to the standard.
<##import namespace="System.Data.Entity.Design.PluralizationServices" #>
I have no idea why adding this line (and only this line) causes everything to break. I haven't even started to try to use it yet! Is there something somewhere about libraries in T4 that I should know or read? Thanks!
Here a description of how the import directive works. Without knowing the actual error T4 reports when transofrming the template in your environment, I can only guess that you didn't add an assembly directive to reference the System.Data.Entity.Design assembly. If this doesn't work, look at the errors reported by T4 in the Error List of visual studio, which should be more helpful than "ErrorGeneratingOutput".