Matlab editor issue, a bug? - matlab

I am having this problem that when I run the below written code in the main screen matlab does'nt give me a problem.
However if i write it in the editor then it complains that it is invalid syntax.
Can you tell me what am i doing wrong or is it a bug?
Ques1 = { #(data) mean(data) #(data) std(data) };
mean = Ques1 {1} (data(:,1)) # runs perfectly on the main compiler screen
On my editor page the compilers complains on the = sign that a possible bracket is missing. However I do not understand why it works on the matlab line by line compiler !!

Those two lines of code are absolutely correct. Somewhere in you code you have forgotten an open left bracket e.g. [ , { , (

EDIT Now I understand what g24l was saying! Yes, that is likely the culprit of your problem.
Not sure what version of matlab you're using but when I run a very simple script:
data = kron(1:25,transpose(1:25)); % very simple 2D matrix of data;
Ques1 = { #(data) mean(data) #(data) std(data) };
mean1 = Ques1 {1} (data(:,1)) % runs perfectly on the main compiler screen
It works perfectly on R2007B and R2009B, are you using an older or newer version? I suspect there is some other issue creeping up in your script. Also, as a matter of following Mathworks recommended programming procedures, I would encourage you not to name a variable or function the same name as another variable or function. In this instance I'm referring to mean = .... It's easy to get this stuff mixed up and then have nasty problems. If you need more help, please feel free to post more of your script. Hope this helps!

I don't have access to Matlab at the moment so I can't test this out, but your syntax doesn't look right to me. Try this:
Ques1 = {#(data)mean, #(data)std};
mean = Ques1{1}(data(:,1))
If you run it your way in your debugger, how many elements does it say are in your cell array?

Related

Emmet abbreviation for Pug "input" is inserting an unneeded #

I'm working on a Pug template in VS Code and whenever I try to use the emmet abbreviation input:text (or any input for that matter), it resolves to input#(type="text", name="").
It's not the end of the world, but it's driving me crazy, and I can't figure out why it's doing so or how to change it.
I guess my question is: is there any way to change this behavior or any place that I can draw attention to this?
The problem is the treatment of the attributes id and class for indent-based syntaxes (Slim, Pug, etc.).
For some reason it removes the attribute from its current position and pushes to the front the strings # for id and . for class.
This is controlled with 2 regex statements near line 3297 in
C:\Program Files\Microsoft.VS.Code\resources\app\extensions\emmet\node_modules\vscode-emmet-helper\out\expand\expand-full.js
Change
const reId = /^id$/i;
const reClass = /^class$/i;
to
const reId = /^Xid$/i;
const reClass = /^Xclass$/i;
You must also remove the cached version of this file in the directory
C:\Users\__username__\AppData\Roaming\Code\CachedData\__some_hex_value__
Restart VSC and it should work.
For linux systems you have to find the location of these files.
I finally understand why this is happening, and that my confusion was basically a misunderstanding of proper form creation.
All text inputs should have an id associated with them, so Emmet is expecting an ID in the shorthand. So this:
input:text#user
resolves to
input#user(type="text", name="")
Which works great! Too bad it took me months of confusion to I realized how daft I am!

How can I make sure that Matlab mcc doesn't build incomplete stand-alone executables?

we use a scripting environment to automatically build, run and verify a stand-alone executable. We are working with Matlab R2010a x64. The Matlab compiler mcc is called from the Windows command line building a stand-alone application:
mcc -m -v -w enable -I source_folder -I common_folder -a specific_files_we_need our_program
The program consists of about 25 modules (.m files) and is using about 5 toolboxes. This is working fine as long as the correct license is available. mcc checks for a compiler license available, resolves dependencies, packs everything in the executable.
However if the license does not include the required toolboxes, mcc does not issue any warning or error. It builds the executable without the toolboxes. So the executable starts, seems to run at a first glance but crashes if a line of code requiring a toolbox is reached.
I am expecting from a compiler that it informs me about missing components. What can I do to get informed about missing components? How can I make sure that mcc does not put together incomplete executables? Am I missing something in the call to mcc?
Preferably I would like to setup the compiling in a way that it stops if things are missing.
\Zweikeks
The simplest way is in your compilation script you can checkout the licenses required, i.e.
license('checkout','Compiler')
license('checkout','control_toolbox')
You just add the 5 toolboxes that need to be checked out -> if the license function cant checkout the license it returns false which you can then use to abort the compilation.
This is what I finally came up with:
I can check before compilation which toolboxes are needed and call license() accordingly. Or I can implement a built-in check into the executable itself. (Called with a special parameter after compilation triggers a self-check for available toolboxes.) In either case I need the names of the required toolboxes.
I tried several ways to generate a list of toolboxes. In short: Running the program in Matlab and then entering license('inuse') is not very reliable. depfun() descends way to much. mydepfun() and fdep() do not descend enough.
I think the problem with mydepfun() and fdep() is that they do not descend into the \toolbox\shared folder. So I took mydepfun() from Tobias Kienzler (link to the original sources) and modified it:
function [list,callers,tboxes_found] = i_scan(f)
func = i_function_name(f);
[list,~,~,~,~,~,callers,~] = depfun(func,'-toponly','-quiet');
toolboxroot = fullfile(matlabroot,'toolbox');
sharedroot = strcat(toolboxroot, filesep, 'shared');
intoolbox = strncmpi(list,toolboxroot,numel(toolboxroot));
inshared = strncmpi(list,sharedroot, numel(sharedroot));
tboxes_found = list(intoolbox & ~inshared);
tboxes_found = regexpi(tboxes_found, '[\\/]toolbox[\\/](.+?)[\\/]', 'tokens');
tboxes_found = cellfun(#(cfun) cfun{1}, tboxes_found);
list = list(~intoolbox | inshared);
callers = callers(~intoolbox | inshared);
for jj = 1:numel(list)
c = callers{jj};
cs = cell(numel(c),1);
for kk = 1:numel(c)
cs{kk} = list{c(kk)};
end;
callers{jj} = cs;
end;
This way i_scan(f) is returning the toolboxes and also descends into \toolbox\shared. The main function of mydepfun() just collects the toolboxes:
function [filelist,callers,toolboxes] = mydepfun(fn,recursive)
.
.
toolboxes = {};
[filelist,callers,tboxes_found] = i_scan(foundfile);
toolboxes = [toolboxes; tboxes_found];
.
.
[newlist,newcallers,tboxes_found] = i_scan(toscan{1});
toolboxes = [toolboxes; tboxes_found];
.
.
toolboxes = unique(toolboxes);
The toolboxes listed are the ones our source code uses. The modified mydepfun() seems to work fine. (Apart from the typical problems caused by elements only resolved during run time like eval(), function handles, callbacks etc.)
And: The dependeny walkers I have seen - like mydepfun() - are using depfun() inside. depfun() is not reliable since it silently ignores all source code not on the path (also its return prob_files is empty in this case). So care has to be taken that the Matlab path is set correctly. (Also any additional pathes are problematic since Matlab may take unexpectedly functions with the same name from other locations.)
After all, I think, this is a good way to make my build process more reliable.
/Zweikeks
I just got another hint from the Mathworks forum. The compiler writes out mccExludedFiles.log. This is listing missing toolboxes.
For example
mccExludedFiles.log:
C:\Program Files\MATLAB\R2010a\toolbox\shared\optimlib\fmincon.m
called by ...c:\temp\whatever\source\code.m
(because the required licenses are not available.)
(Other missing files in the source code do not get listed, though.)
/Zweikeks

MATLAB TODO: Fill in Description

I was trying to find something about LegendEntry in MATLAB, so I clicked it to open the help window, and this is what I saw:
If you want to see it yourself run this code:
h = plot(1:10,1:10);
legend('a')
h.Annotation.LegendInformation
Then you will see at the command window:
ans =
LegendEntry with properties:
IconDisplayStyle: 'on'
LegendEntry is a link to the help file for matlab.graphics.eventdata.LegendEntry which pops up the window in the picture above.
Are you familiar with this? Is this some kind of a problem with my installation?
I use MATLAB 2015a.
What's happened here is that a developer has left a TODO note to him or herself in the comments for matlab.graphics.eventdata.LegendEntry, and has forgotten to remove it before release.
If you'd noticed this in the most recent release, it would probably be worth bringing it to the notice of MathWorks with a bug report: but in fact I've just tried this on 16a and it looks like it's been removed already.
It's not a problem with your installation.

Ignore java comments with JFlex

Hi I am trying to ignore java comments using JFlex but I can't manage to make it working, I always have an error in execution. I used these two lines:
commentary = "//"[\r\n]*(\r|\n|\r\n)
<YYINITIAL> {commentary} {}
I also tried different things like commentary = [/][/].* but without success.
commentary = (/*([^]|[\r\n]|(*+([^/]|[\r\n])))*+/)|(//.)
Please try this

Selenium WebDriver with Perl

I am trying to run the Selenium driver with Perl bindings, and due to the lack of examples and documentation, I am running into some roadblocks. I have figured out how to do some basic things, but I seem to be running into some issues with other simple things like validating the text on a page using Remote::Driver package.
If I try to do something like this:
$sel->get("https://www.yahoo.com/" );
$ret = $sel->find_element("//div[contains( text(),'Thursday, April 26, 2012')]");
I get a message back that the element couldn't be found. I am using xpath because the driver package doesn't appear to have a sub specific for finding text.. at least not that I've found.
If my xpath setup is wrong or if someone knows a better way, that would be extremely helpful. I'm having problems with some button clicking too.. but this seems like it should be easier and is bugging me.
Finding text on a web page and comparing that text to some "known good value" using Selenium::Remote::Driver can be implemented as follows:
File: SomeWebApp.pm
package SomeWebApp;
sub get_text_present {
my $self = shift;
my $target = shift;
my $locator = shift;
my $text = $self->{driver}->find_element($target, $locator)->get_text();
return $text;
}
Somewhere in your test script: test.pl
my $text = $some_web_app->get_text_present("MainContent_RequiredFieldValidator6", "id");
The above finds the element identified by $target using the locating scheme identified by $locator and stores it in the variable $text. You can then use that to compare / validate as required / needed.
https is a tad slower loading than http. Although WebDriver is pretty good about waiting until it's figured out that the requested page is fully loaded, maybe you need to give it a little help here. Add a sleep(2); after the get() call and see if it works. If it does, try cutting down to 1 second. You can also do a get_title call to see if you've loaded the page you think you have.
The other possibility is that your text target isn't quite exactly the same as what's on the page. You could try looking first for one word, such as "April", and see if you get a hit, and then expand until you find the mismatch (e.g., does this string actually have a newline or break within it? How about an HTML entity such as a non-breaking space?). Also, you are looking for that bit of text anywhere under a div (all child text supposedly is concatenated, and then the search done). That would more likely cast too wide a net than not get anything at all, but it's worth knowing.