I am updating from Hy 0.12.1 to the newest version 0.18.0, and I make heavy use of the import_buffer_to_ast function in my python code.
This function has been removed from hy.importer, I was hoping someone could lead me to a good alternative.
hy.importer comprises mostly internal Hy functions, which are liable to change without notice. You can try using new internal functions like ast_compile or hy_compile, but hopefully you can get what you need out of public functions like hy.eval, hy.read_str, and hy.read.
Related
I've recently been asked by my supervisor to prepare a solution in which multiple pieces of logic throughout our application can be reverted back to an earlier piece of code while the application is live. In effect, I need to prepare something like a flag or an indicator that can be dynamically activated to switch all instances of code in our application, from the new version back to the old one.
The new logic was prepared by a new member of our team and we are concerned about memory leaks that will emerge once the code goes to production, and we want a solution in place that will allow us to turn those changes off and return to the original code if necessary.
if (new_code == ON)
{
New Logic
}
else
{
Old logic
}
This project was originally meant to help get rid of build and compile warnings during our build process so it affects code ranging from function arguments to variable declarations, so there's no one single type of code that will be affected. We are running off a tuxedo stack but implementing a tuxedo config file to effect this change isn't recommended according to one of our senior developers. I'm not aware of a similar solution, though.
Any ideas? Thanks!
Would it work? Sure. Is it a good idea? No. You now have the risk of the new code, plus the risk of bugs in your switch code, plus the risk of what happens if you switch from one to the other in mid-run. You shouldn't be doing this, its far more likely to cause trouble than just deploying the changes directly.
What you should do- if you're really concerned about it, don't deploy it. Put it through additional testing until you're comfortable with it. Then when you do deploy it, have a plan to roll back to a previous version without these changes if something slips through testing.
call the function using function pointers.
make an API to change the function pointer to old or new depending on your need.
We have our sandbox upgraded to Winter '13, but our production environment is still on the old version. The following code prints "false" on our sandbox, but "true" on production. I can't seem to find mention of this on line, but it looks like they work differently!
Set<Id> x = new Set<Id>{
'012A0000000qv2wIAA'
,'012A0000000qv2xIAA'
,'012A0000000qv2yIAA'
,'012A0000000qv2zIAA'
};
System.debug(x.contains('012A0000000qv2z'));
Note that the Set contains 18-character IDs, and we're asking if it .contains() a 15-character ID. I don't mind it working one way or the other; just weird that it's behaving differently.
EDIT: Just noticed that if I explicitly cast the String to an ID, the behavior becomes consistent across environments:
System.debug(x.contains((Id)('012A0000000qv2z')));
So maybe Apex has changed the type-promotion rules in the new release?
I took a look into this. This is an unintentional change to the type manipulation logic in the new implementation of Set in Apex (the new impl supports user defined types, hooray!). I've filed a bug and we'll address this in a future patch (I'm not allowed to make promises as to when). Thanks for pointing out this issue and giving such a concise repro.
Greg Fee
I have a legacy C API that I need to add functionality to. Specifically I need to make some of this API's calls thread-safe, because a call like this:
A_DoFoo(HandleA a)
Uses an object shared by all handles of type A.
My first thought is to add a function to the API that looks like this:
A_DoFooEx(HandleA a, HandleB b)
Is this a normal approach?
(I only used the Ex suffix because of years of exposure to the Win32 SDK. Does it make more sense to give a more descriptive name to the function?)
Adding another function under a new name is the standard (and in fact just about the only) way to deal with this problem in straight C (in C++ you could add a new overload and keep the old name). I'm not a big fan of the Ex suffix, because it doesn't tell you what the difference between the old and new APIs is. On the other hand, don't saddle people with something long and heinous like A_DoFoo_ThreadSafe, that hurts readability.
In this case, I'd try to think of a name that indicates what the requirements on HandleB are. If you tell us what this API actually does, we can maybe make more specific suggestions.
I prefer writing wrapper for thread safe code. So I can embedded any thread un safe code and make it thread safe use wrapper.
You should always use a proper naming format.
it will help you easily maintain your code and make it more readable.
I have a question concerning the performance, reliability, and best practice method of using Extjs's update() method, versus directly updating the innerHTML of the dom of an Ext element.
Consider the two statements:
Ext.fly('element-id').dom.innerHTML = 'Welcome, Dude!';
and
Ext.fly('element.id').update('Welcome, Dude!', false);
I don't need to eval() any script, and I'm certain that update() takes into consideration any browser quirks.
Also, does anyone know if using:
Ext.fly('element-id').dom.innerHTML
is the same as
d.getElementById('element-id').innerHTML
?
Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution.
Thanks in advance for your help,
Brian
If you do not need to load scripts dynamically into your updated html or process a callback after the update, then the two methods you've outlined are equivalent. The bulk of the code in update() adds the script loading and callback capabilities. Internally, it simply sets the innerHTML to do the content replacement.
Ext.fly().dom returns a plain DOM node, so yes, it is equivalent to the result of getElementById() in terms of the node it points to. The only subtlety to understand is the difference between Ext.fly() and Ext.get(). Ext.fly() returns a shared instance of the node wrapper object (a flyweight). As such, that instance might later point to a different node behind the scenes if any other code calls Ext.fly(), including internal Ext code. As such, the result of a call to Ext.fly() should only be used for atomic operations and not reused as a long-lived object. Ext.get().dom on the other hand returns a new, unique object instance, and in that sense, would be more like getElementById().
I think you answered your own question: "Browser and platform compatibility are important, and if the two are fundamentally the same, then ditching Ext.element.dom.innerHTML altogether for update() would probably be my best solution." JS libraries are intended (in part) to abstract browser differences; update is an example.
#bmoeskau wrote above, update() provides additional functionality that you don't need right for your current problem. Nevertheless, update is a good choice.
Does someone know a library that I can use to read MP3 tags in Silverlight 3?
In WPF I was using taglib, but obviously I cannot reference it in Silverlight projects.
Taglib doesn't contain any unsafe code. Perhaps you can recompile it (with a few minor alterations maybe) to work in silverlight.
Have you tried just using Taglib's code? There's a decent chance it'll work without too much hassle.
Edit: Yes, I mean TagLib#. I just tried, and there are a few minor issues which were fixable in 15min. (You'll need to define ICloneable, remove a bunch of unnecessary Serialization constructors for exceptions, remove the last parameter on string.Split(char[],int) calls, that's about it.)
Note that unless someone else has fixed it, there's a minor bug in Taglib#'s Id3v2 unsynchronization code. You can ignore it and fail to parse a few id3v2 tags, or you can use the same workaround I did: https://bugzilla.gnome.org/show_bug.cgi?id=593138#c4 - I know, I should submit a patch, but time and all...