I know I'm being a bit too picky but I really want to know which approach is better performance-wise in ES6:
import A from 'blabla/A';
import B from 'blabla/B';
import C from 'blabla/C';
or
import {A, B, C} from 'blabla';
If you are using Webpack or another tree-shaking bundler, both are roughly equivalent.
Assuming there is some submodule D in blabla that you don't want or need, your first example explicitly tells Webpack that you only need A, B, and C. In the second example, Webpack pulls in them all, but then should throw away D because it isn't actually used.
There may be some MINOR efficiency gains one way or another, but it generally won't be a big deal.
Related
I am working on a port of some IDL code to Python (3.7). I have a translation working which uses whatever direct Python alternatives are available, and supplementing what I can with idlwrap. In an effort to eliminate legacy IDL functions from the code, I am looking for an alternative to ARRAY_INDICES(). Right now, I have simply translated the entire function directly and import it on its own. I've spent a good deal of time trying to understand exactly what it does, and even after translating it verbatim, it is still unclear to me, which makes coming up with a simple Python solution challenging.
The good news is I only need it to work with one specific set of arrays whose shapes wont change. An example of the code that will be run follows:
temp = np.sum(arr, axis=0)
goodval = idlwrap.where(temp > -10)
ngood = goodval.size
arr2 = np.zeros_like(arr)
for i in range(0, ngood - 1):
indices = array_indices(arr2, goodval[i])
#use indices for computation
Is it correct to say that expectSaga is for integration testing and testSaga is for general assertions?
In reality, I can actually use them interchangeably for all my tests, so I am a bit confused about when to use which.
I think the subheading line from the README under Unit Testing [1] is the most concise explanation of when you would use testSaga vs expectSaga:
If you want to ensure that your saga yields specific types of effects
in a particular order, then you can use the testSaga function.
If you don't care about this level of detail, especially the ordering bit, then expectSaga is less rigid and therefore less brittle to future changes in your sagas. But in some cases you need to be very specific about exactly which effects in which order, in which case you should use testSaga.
[1] https://github.com/jfairbank/redux-saga-test-plan#unit-testing
There's a feature in TypeScript which I like so much and that's external modules using RequireJs and that the fact that the compiler won't include imported modules unless they are actually needed in the code. Here's an example:
import A = require('./A');
import B = require('./B');
var a = new A();
When you compile the above code using tsc --module amd example.ts it will transcompile to:
define(["require", "exports", './A'], function(require, exports, A) {
var a = new A();
});
As you can see there's no sign of B in the generated code. That's because B was not actually used. As I said this feature is great but now I've got a scenario in which I need to include some of the external modules even though they are not actually used anywhere in the code.
Does anyone have any idea how to do that? To prevent any misunderstanding, I'm not looking for a way to disable this feature completely, just for some specific modules.
Another way to do it:
/// <amd-dependency path="./B" />
import A = require('./A');
No need to create fictitious code
There is a simply fiddle you can do to get the compiler to include both:
import A = require('./A');
import B = require('./B');
var a = new A();
var b = B;
The variable b becomes noise in your program, so I wouldn't use this technique too much, but if the B module is doing polyfills or something like that which means you'll never want to directly instantiate it, this gets it loaded for you.
I want to generate empty implementations of procedures defined in a header file. Ideally they should return NULL for pointers, 0 for integers, etc, and, in an ideal world, also print to stderr which function was called.
The motivation for this is the need to implement a wrapper that adapts a subset of a complex, existing API (the header file) to another library. Only a small number of the procedures in the API need to be delegated, but it's not clear which ones. So I hope to use an iterative approach, where I run against this auto-generated wrapper, see what is called, implement that with delegation, and repeat.
I've see Automatically generate C++ file from header? but the answers appear to be C++ specific.
So, for people that need the question spelled out in simple terms, how can I automate the generation of such an implementation given the header file? I would prefer an existing tool - my current best guess at a simple solution is using pycparser.
update Thanks guys. Both good answers. Also posted my current hack.
so, i'm going to mark the ea suggestion as the "answer" because i think it's probably the best idea in general. although i think that the cmock suggestion would work very well in tdd approach where the library development was driven by test failures, and i may end up trying that. but for now, i need a quicker + dirtier approach that works in an interactive way (the library in question is a dynamically loaded plugin for another, interactive, program, and i am trying to reverse engineer the sequence of api calls...)
so what i ended up doing was writing a python script that calls pycparse. i'll include it here in case it helps others, but it is not at all general (assumes all functions return int, for example, and has a hack to avoid func defs inside typedefs).
from pycparser import parse_file
from pycparser.c_ast import NodeVisitor
class AncestorVisitor(NodeVisitor):
def __init__(self):
self.current = None
self.ancestors = []
def visit(self, node):
if self.current:
self.ancestors.append(self.current)
self.current = node
try:
return super(AncestorVisitor, self).visit(node)
finally:
if self.ancestors:
self.ancestors.pop(-1)
class FunctionVisitor(AncestorVisitor):
def visit_FuncDecl(self, node):
if len(self.ancestors) < 3: # avoid typedefs
print node.type.type.names[0], node.type.declname, '(',
first = True
for param in node.args.params:
if first: first = False
else: print ',',
print param.type.type.names[0], param.type.declname,
print ')'
print '{fprintf(stderr, "%s\\n"); return 0;}' % node.type.declname
print '#include "myheader.h"'
print '#include <stdio.h>'
ast = parse_file('myheader.h', use_cpp=True)
FunctionVisitor().visit(ast)
UML modeling tools are capable of generating default implementation in the language of choice. Generally there is also a support for importing source code (including C headers). You can try to import your headers and generate source code from them. I personally have experience with Enterprise Architect and it supports both of these operations.
Caveat: this is an unresearched answer as I haven't had any experience with it myself.
I think you might have some luck with a mocking framework designed for unit testing. An example of such a framework is: cmock
The project page suggests it will generate code from a header. You could then take the code and tweak it.
I want to write a strategy to evaluate items in an array in parallel. The old strategies had parArr to do this (see here). But this is not found in the new Control.Parallel.Strategies module.
E.g.
parallel list evaluation: map f myList `using` parList rdeepseq
I would want to be able to do something like: amap f myArr `using` parArr rdeepseq, where amap is from Data.Array.Base and applies a function to each of the elements (sequentially).
The following seems to work but I wonder if it is doing it right, and want to know how I could define my own parArr.
This works: amap ((+1) `using` rpar) $ Array.array (0,4) [(0,10),(1,20),(2,30),(3,40),(4,50)]
For a previous question, I wrote a parallel evaluation strategy for the vector package. That should be a good place to start. You can see the code on hackage in the vector-strategies package.
I don't have time to give a full answer - perhaps I'll edit this later. Feel free to comment with extra questions and direction.
Apart from all the good advice given: The reason that there is no parArr anymore is simply that it has been replaced by the more general parTraversable. Just say:
amap f myArr `using` parTraversable rdeepseq
That should give you the behavior you asked for.