Normally I use Chemspider webservice client (WSDL) with the help of Knime generic web service clients to convert a list of molecule names into a table containing molecular properties (physicochemical prperties,...). Now, Chemspider has suspended its WSDL function and I don't know how to get these data.
I've tried using ChemBL, but the Get request function of uploaded workflows don't work.
Are there any remaining ways (free)?
I myself use pubchempy module for this purpose. It's really easy to handle, and I find it more flexible and easier than chem spider for general use.
Related
I am trying to find a clean way to access the regmap that is used with *RegisterNode for creating documentation and testing files. The TLRegisterNode has methods for generating the json through some Annotations. These are done in the regmap method by adding them to the ElaborationArtefacts object. Other protocols don't seem to have these annotations.
Is there anyway to iterate over the "regmap" Register Fields post elaboration or during?
I cannot just access the regmap as it's not really a val/var since it's a method. I can't quite figure out where this information is being stored. I don't really believe it's actually "storing" any information as much as it is simply creating the hardware to attach the specified logic to the RegisterNode based logic.
The JSON output is actually fine for me as I could just write a post processing script to convert JSON to my required formats, but I'm wondering if I can access this information OR if I could add a custom function call at the end. I cannot extend the case class *RegisterNode, but I'm not sure if it's possible to add custom functions to run at the end of the regmap method.
Here is something I threw together quickly:
//in *RegisterRouter.scala
def customregmap(customFunc: (RegField.Map*) => Unit, mapping: RegField.Map*) = {
regmap(mapping:_*)
customFunc(mapping:_*)
}
def regmap(mapping: RegField.Map*) = {
//normal stuff
}
A user could then create a custom function to run and pass it to the regmap or to the RegisterRouter
def myFunc(mapping: RegField.Map*): Unit = {
println("I'm doing my custom function for regmap!")
}
// ...
node.customregmap(myFunc,
0x0 -> coreControlRegFields,
0x4 -> fdControlRegFields,
0x8 -> fdControl2RegFields,
)
This is just a quick example I have. I believe what would be better, if something like this was possible, would be to have a Seq of functions that could be added to the RegisterNode that are ran at the end of the regmap method, similar to how TLRegisterNode currently works. So a user could add an arbitrary number and you still use the regmap call.
Background (not directly part of question):
I have a unified register script that I have built over the years in which I describe the registers for a particular IP. It works very similar to the RegField/node.regmap, except it obviously doesn't know about diplomacy and the like. It will generate the Verilog, but also a variety of files for DV (basic `defines for simple verilog simulations and more complex uvm_reg_block defines also with the ability to describe multiple of the IPs for a subsystem all the way up to an SoC level). It will also print out C Header files for SW and Sphinx reStructuredText for documentation.
Diplomacy actually solves one of the main issues I've been dealing with so I'm obviously trying to push most of my newer designs to Chisel/Diplo.
I ended up solving this by creating my own RegisterNode which is the same as the rocketchip RegisterNodes except that I use a different Elaboration Artifact to grab the info and store it for later.
I have been trying to break down the differences between the Open Closed Principal and Liskov's Substitution Principal. And the best and most common examples of either use the exact same problem. Finding the Area of a shape class.
They use slightly different means, but effectively solve the same problem with the same solution.
As these are both parts of SOLID, I'm really trying to find a reason to support why both are called out.
I'm looking for an explanation that doesn't work for both.
Thanks.
LSP:
Consumers target an abstraction (e.g. interface) and should not need to know which concrete implementation stands behind the interface. For example, a client (e.g. a DocumentProcessor class) holds a dependency on IDocumentStore. If in V1, you gave it a SqlSeverDocumentStore instance, and then in V2 you gave it a FileSystemDocumentStore, the client (DocumentProcessor) should work without modification. This can be achieved by making sure the contract of IDocumentStore is well defined and that DocumentProcessor, SqlSeverDocumentStore and FileSystemDocumentStore abide by this contract.
The contract means much more than an interface. Having two classes implement the same interface does not mean they abide by the same contract (although they should).
For example, does both implementations support saving documents which are smaller or equal to 20MB? Or does one of them support documents that are at most 10MB? If it is part of the contract that an implementation should support 20MB documents, then all implementations should support this.
OCP:
We should avoid modifying a unit of composition (e.g. a class or a function) after we release it. One way to achieve this is to make the units parameterized. For example, if you have a function (say, ProcessImages) that reads images from the file system, compresses them and then sends them to some web service, you can parameterize this function to accept other functions that are responsible for (1) reading images, (2) compressing them, (3) sending them.
E.g. (in C#):
public static void ProcessImages(
Func<Image[]> getImages,
Func<Image, CompressedImage> compressImage,
Action<CompressedImage> sendImage)
{
//... Orchestrate the operation here
}
And, in the Composition Root:
Action processImages = () => ProcessImages(ReadImages, CompressImage, SendImage);
Where ReadImages, CompressImage, SendImage are themselves functions.
This way, if you want to change how the images are compressed, you will not modify the ProcessImages function. Instead you will create a new compression function (say CompressImageInADifferentWay) and then compose the ProcessImages function in the Composition Root like this:
Action processImages =
() => ProcessImages(ReadImages, CompressImageInADifferentWay, SendImage);
If you apply the OCP in a perfect way, only the Composition Root itself will change.
LSP allows us to achieve OCP. For example, because CompressImage and CompressImageInADifferentWay abide by some contract that ProcessImages knows about, we can replace CompressImage with CompressImageInADifferentWay without modifying ProcessImages.
I'm After several days learning angularJS through converting my standart JS app to a ng one.
I was wondering about this simple scenario:
I have a global function called fb_connect(),
it can be used from any page (or any controller if you like) to make a facebook-based login.
This function makes a simple http call and receives a JSON object contain data to move on (display a pop up, login, etc...)
I read that I can define a Factory or a Service for my app and use it in any controller, which works fine.
So, I created a fb_connect factory function.
The problem is that now, in every page (every controller), I have to define that fb_connect in the constructor of every controller - for example :
function welcome($scope,fb_connect){});
What is the proper way to do this kind of actions using Angular without having to define these functions each and every time in every controller?
Thanks
Setting up factories and services is all part of the dependency injection system of Angular. Using that system is great when you need to create things that depend on other injected things. It's a big tree of dependencies. It's also nice for creating singletons, such that everywhere in your code end up using the same instance of some object.
It sounds to me like neither of these benefits apply in your case. I'd suggest just not using Angular's DI for it. You have some function defined globally, just call it directly and skip the DI. There's nothing wrong with that.
Of course you say it makes an Ajax call, so doesn't depend on the Angular $http service?
Your two options are:
Declare the function on the $rootScope
Inject it as a service
My advice is to go with making it a service. The whole purpose of services is explained in the Angular.js docs, just like this quote:
Angular services are singletons that carry out specific tasks common to web apps... To use an Angular service, you identify it as a dependency for the dependent (a controller, or another service) that depends on the service.
As you mentioned in your question, you'd prefer to not define the service in every controller you wish to use it in. With $rootScope you'll be injecting that also in every controller. So really it's a question of which you prefer, although to answer your question, the proper way of using a factory or service is to inject it into the controller you wish to use it in.
You can always put it in the $rootScope
myApp.run(function($rootScope, fb_connect){
$rootScope.welcome = function(){
};
});
I'm creating a flash campaign which will be loaded into a client's framework, which I have no control over. The framework will already have loaded a few things such as locale, fonts and copy, and will pass these things to my swf upon initialization.
Since the size of my swf (let's call it the shell) is restricted it will in turn display a campaign-specific preloader and then load another swf (let's call this the campaign) with the rest of the site.
The shell and the campaign will both be PureMVC modules. The shell will create a few proxies and populate these with data passed from the framework (locale constants, fonts etc), before loading in the campaign.
When the campaign is loaded it too will need locale and fonts etc. so my question is, what is the best way to pass this data along to the campaign module from the shell module?
I could create the same proxies in the campaign module and load the data again, which will be cached, but this obviously feels like the wrong way to go.
I've investigated the use of the pipes utility but this seems like a bit of an overkill in my case since the communication will be one-way and will just happen once during the initialization of the campaign.
Would it be "ok" from a design pattern point of view to pass the proxies to an init method of the campaign module and then register these proxies in the campaign module startup command? This seems wrong since these proxies have references to my shell application facade through notification names. Would it be ok if I move the notification names to some "NotificationConstants" class which both modules can use?
I could create similar proxies in the campaign module but this time populate them with the data objects from my old proxies passed to the previously mentioned init method? Spontaneously this feels like the best way to do it since the data objects don't have any references to my shell module but the "old" proxies do..
The solution I usually use is to create an interface:
interface Campaign {
function set campaignDetails(value:CampaignDetails):void;
//...
}
The campaign-module should implement this interface - in the implementation I recommend you to use a different proxy in the module, so that you would avoid having duplicated notifications and references.
When the shell is ready with the loading of the module it just has to:
if (module is Campaign)
{
(module as Campaign).campaignDetails = ...;
}
I'm sure I'm telling you nothing new. You just need to make sure to keep the acquaintance between the shell and the module only on an interface level. Then you just pass the data and leave the module MVC core to deal with it independently from the shell.
I have been trying out Service Factory and have run into some problems in regards to long filenames - surpassing the limit in Vista/XP. The problem is that when generating code from the models service factory prefixes everything with the namespace specified. Making the folder structure huge. For example starting in
c:\work\sftest\MyWebService
I create each of the models with moderate length of names in data contracts and service interface. I set the namespace to be MyCompany.SFTest.MyWebservice
After generating code I end up with
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Business Logic
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Resource Access
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.DataContracts
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.FaultContracts
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.MessageContracts
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.ServiceContracts
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.ServiceImplementation
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Tests
Under each of the folders is a project file with the same prefix
c:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.ServiceImplementation\MyCompany.SFTest.MyWebService.ServiceImplementation.proj
This blows up the recipe as windows can't accept filenames exceeding a specific length.
Is it necessary to explicitly include the namespace in each of the foldernames?
Obviously at some point I might want to branch a service to another location but for the same reason as above might be unable to.
Is there a workaround for this?
I don't know Service Factory so i am not sure if this will help. Anyway: maybe the article Naming a File or Directory from MSDN can help.
Windows API has a maximum length for paths (MAX_PATH = 260). If you want to use longer pathnames you will have to use the Unicode versions of the API by prefixing your paths with "\\?\", i. e. use
"\\?\C:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.ServiceImplementation\MyCompany.SFTest.MyWebService.ServiceImplementation.proj"
instead of
"C:\work\sftest\MyWebService\MyCompany.SFTest.MyWebService\Source\Service Interface\MyCompany.SFTest.MyWebService.ServiceImplementation\MyCompany.SFTest.MyWebService.ServiceImplementation.proj"
Does Service Factory allow that notation?
We had exactly this problem and we got around it by making our service factory a very thin wrapper around a normal library (that has been marked up with the WCF stuff). This gave us a normally deep project (the factory) and then a stunningly deep wrapper factory (without all that extract interface and logic and what not).
We still have some problems - but mainly in the client side - our servers are for the most part trouble free.