One of my Simulink SLX files has stopped opening as a model. Apparently it was corrupted. Are there any means to repair such a files or extract some information of them? File looks like being a MZ executable. Where is the block schema stored?
SLX is a compressed file which contains XML files with model information. You can try opening the SLX file in winzip and check. See http://www.mathworks.com/help/simulink/ug/saving-a-model.html#btbr7kx-1 for SLX format. I do not think there is any utility to repair corrupted SLX files.
DiffPlug's Simulink Viewer has an .slx parser that was developed independent of The Mathworks, and it's a little more "lenient" than The Mathworks' implementation. You might want to try opening your model in DiffPlug's viewer (it's free, so you don't have much to lose I guess...).
That way you'll at least be able to scout around the model so you can see what piece has been corrupted.
Disclaimer: I work for DiffPlug.
If there's a lot of time invested in the model, I'd be happy to open your model up and poke around inside it using our internal API. It'd only take me a few minutes, and it might be an easy fix like a mis-matched Stateflow id.
Remove the extension 'original' from the file name 'X.slx.original'. This worked for me.
You can actually still load the system using load_system(), use bdroot to see if it loaded, then use save_system() to save what is returned by bdroot, using a new filename. The new model should open correctly.
Related
I have implemented a backup per workspace functionality in my extension using workspaceState. Since the data can be sensitive - I'd like to clear all workspaceStates on extension deactivation/uninstall.
The ExtensionContext provides no ability to clear all extension related data across different workspaces with their workspaceStates.
So I've considered saving data on the ExtensionContext globalState, tagging each entry with a workspace id. Problem is that the workspace namespace doesn't provide a way to uniquely identify the current workspace. I thought about hashing workspace name and path but both of these things are changeable and any change will destroy the pointer to the data. This is exactly why I cant just write files to internal folders. The only other solution I have is to write the backup data directly to the workspace and I'd like to avoid that.
How does VSCode maintain the knowledge of which workspaceState belongs to which workspace? How can I tie data to the workspace but have access from anywhere else in VSCode?
Side note: You should avoid saving sensitive data in general. And if necessary, try to encrypt it.
Anyway:
I don't have the full answers but i was researching something similar (An extension I use crashes due to now invalid settings in the WorkspaceState).
I found the Storage for the Workspace state in this folder (windows):
%appdata%\Code\User\workspaceStorage\
In there, you find a lot of folders with hex-based names. Inside those folders, I always found 2 Files named state.vscdb and state.vscdb.backup.
There usually is a 3rd file called workspace.json which helps you figure out if you are in the correct workspace. (but you'd have to iterate through all the folders - maybe there is a way to figure out the folder name coming from the extension API?)
If you open the state.vscdb-file you find something that looks quite like a serialized object set in my eyes. It does have some Seperator chars of unknown function. But you also find full paths or names in there that clearly origin from different modules of VSC - Including the extensions.
I don't need to worry about the other cached stuff i'm just gonna delete the whole folder to fix my current issue. But I'm pretty sure, one can figure out the way the file is built and edit out your sensitive data if one has to.
The state.vscdb.backup-file looks pretty much like what the name is telling you: they probably just make a copy of the other file every few minutes so you have a fallback position.
To add to the conversation, there are two SQLite state databases:
<user-data-dir>\User\globalStorage\state.vscdb
<user-data-dir>\User\workspaceStorage\<workspace.id>\state.vscdb
Depending on how VS Code was launched you could have a Single Folder Workspace or a Multi-Folder Workspace that is global or local. Globally, the data lives here:
Linux: $HOME/.config/Code/
OS X: $HOME/Library/Application Support/Code/
Windows: %APPDATA%\Code\
Locally, the data will be in the .vscode folder of the current workspace.
In my situation:
I open a new workspace.
Set it up as I want it to start every time.
Makes copies of the two SQLite databases.
Copy over the databases before launching VS Code.
This leads to a clean VS Code state.
To see how workspace.id is generated check this link.
I have created a model in Anylogic 8.3. Now I want to open this model on a different computer that contains an older version, Anylogic 8.2.3. This, however, does not work, as I am prompted with the fact that the model is created in a newer Anylogic version.
Is there a way to circumvent this issue?
I am not a system admin on the computer with the older Anylogic, nor does our license cover updating to a newer version of Anylogic (expired in december 2018).
You can easily do that by opening the .alp file of your model with Notepad or a similar text editor. Then:
Get your actual AnyLogic build version (open AnyLogic, click "Help" and then "About". You can find your build-version as in the image below
replace AnyLogicVersion and AlpVersion with your required values, e.g. something like AnyLogicVersion="8.2.3.xxxxxxxx" and AlpVersion="8.2.3"
save the file and open with AnyLogic 8.2.3
(Note that if you want to open a model in AnyLogic 7 that was developed in AnyLogic 8, you would also need to remove the entire <RunConfiguration> section. But this is not relevant in your case.)
I think it's only possible to go back to an earlier AnyLogicVersion by hacking the .alp if the AlpVersion is the same, because it denotes the structure of the XML. I don't have an 8.4 file handy, but I have, for example, an 8.5.1 and an 8.2.4, and the AlpVersion is 8.4.9 for AnyLogicVersion 8.5.1, but 8.0.4 for AnyLogicVersion 8.2.4.
If the XML structure is different, the newer version of AnyLogic will likely be unable to load the file. Looking at the two examples of essentially the same model that I've detailed above, there are readily apparent structural differences in the ActiveObjectClass, for example. If there are not too many structural differences, you could try replicating them. I've succeeded in doing that manually at least once, that I can recall.
There are a variety of online tools that allow you to compare the XML schemas of two XML documents, from which you will be able to judge whether a manual hack is feasible.
I have an .m file which I wish to share with my friends but I am not interested in giving .m file. Could someone help me with best possible ways to convert it to a file that is not decodable?
I tried converting it to .p file by simply typing pcode example.m
however I don't believe it is really protecting it. I was able to convert my .p file back to .m file with the following link. https://sites.google.com/site/sippeyfunlabs/matlab-hacks/please-do-not-secure-your-password-in-matlab-p-code
This actually confirms that my code is not protected.
It'll be nice if someone shares the best methodology to protect .m file and sharing.
Thanks
The link you provided yourself already indicates that it is very difficult to obfuscate MATLAB code:
In fact, MATLAB language is very difficult to be secured or even obfuscated.
This is due to the late binding (or dynamic binding) feature of
MATLAB. [...] The amount of meta information associated with this
feature basically forbid any attempt of adding code level security.
Simply put, if there is a MATLAB file, and it calls a function foo
inside it. Until the runtime, the MATLAB interpreter do not even know
if foo is a function stored in M file or a built-in function or a mex
function or even a workspace function handle. Thus, it must store foo
as is somewhere inside the generated P-code.
Also to best solution is already mentioned on that page:
If there is really a need to do this, using the good old binary is a
much better solution. Or you can put critical code on a server, away
from the user.
Create a binary, i.e. mex file (see the answer of Wolfie): Note that to some extent also binary code can be decompiled especially small ones.
Host your code on a server (and run the code server-side): This is the best method to protect your code. You should let the user upload the input for your script and return the result. You can also automatize this process using a matlab script to make this process transparent to the user.
You could build a mex file.
This will completely obfuscate your actual MATLAB code, since it will be written in C/C++/FORTRAN, but the algorithms will still be there if your friends are determined enough to look for them.
Can anyone share his experience on workflow for R peject development under ESS? I tried several times to learn emacs but I have not get it yet. I can understand ESS as an editor, but is there a project view in ESS? what's the efficient ways to set up/view R project directory, coding, and testing, and how's ESS has an edge to facilitate the whole process?
Do you use ESS as a good R editor only or tend to emulate a R IDE environment within ESS?
Thanks for any advices.
It sounds like you're asking two separate questions.
One question concerns workflow and the other concerns using ESS.
As I use StatET and Eclipse, I'll just share my experience regarding the workflow aspect of your question.
As with Vincent I also follow something like the workflow set out by Josh Reich here (also see Hadley's useful comments):
Workflow for statistical analysis and report writing
Although it can vary between projects, I tend to have a couple of main R files
import.R: this imports data files and does any necessary cleaning and manipulation
analyse.R: This generates the output that I need for any final report
main.R: This calls import.R and analyse.R
The aim is for import.R and analyse.R to represent the complete and final workflow for producing the final results of any analyses.
In terms of a directory structure for an analysis project, I'll often also have the following folders
data: for storing any raw data files
meta: for storing meta data, such as variable labels, scoring systems for tests, recoding information, etc.
output: for storing any graphics, tables, or text generated by my analyses that I might want to incorporate into an external program
temp: When exploring the data and brainstorming analyses, I like to type code into files instead of using the console. I tend to label these temp1.R, temp2.R, temp3.R. I store these in a temp folder. That way I have a permanent record that's easily accessible. If the analyses become final they get incorporated into one of the main R files (i.e., import.R or analysis.R)
functions: If I think that a function will be needed across a couple of projects, I often place it one function per file or a set of related functions in a file in a folder called functions. This makes it relatively easy to reuse functions across projects, when the formal requirements of package development are more than needed.
library: If I want to create some general functions that I think will be project specific, I'll place them in this folder
save: A folder to store any saved R objects
StatET and Eclipse make it easy to interact with such a file system.
Of course, given all the R gurus that use ESS and Emacs, I'm sure it also handles interactions with the file system well.
I'm not exactly sure what you expect as an answer on this one. I, for one, have stolen (and adapted) a system that was suggested here a little while ago (by Josh Reich):
Create a folder for every project, and split up your work in a bunch of different .R files:
Load.R for getting your raw data into R;
Prep.R for cleaning the data, recoding variables, etc.;
Func.R for coding any custom functions you will need for evaluation; and
Eval.R for running your final stuff.
If that doesn't fit your style, just change it.
Then, you can either have a master file to call each of the parts one after each other (good for reproducibility), or save at different stages and have the individual scripts load the appropriate data (good if some of the prep work is very computationally/time intensive).
**
On a different note, the trick that is posted at the link really helped me get into ESS. It turns Shift-Enter into a one-stop-ESS-shop: http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/
Others have given you some good ideas about how to setup your directory/file structure for a project.
You also asked about "project views," in which case you might want to look into the Emacs Code Browser (ECB).
You can find some screen shots of it in action on its site, here:
http://ecb.sourceforge.net/screenshots/index.html
I would like to know about open source libraries that could be used to perform some simple tasks on MIDI files:
reading a file one note - or chord - at a time;
extracting a given instrument to re-encode it separately in a new file;
allow to produce a "customizable" score -- by that I mean that I should be able to alter the way the sheet music is produced from the midi using the libraries ... I assume this will require an interaction with Lilypond or Musixtex.
I don't really have a preferred language, as long as it is not too painful to make the app cross-platform. Other advice is welcome -- better to learn it now rather than when I've already written a lot of code. So far, I've been trying to dig in MuseScore's (C++) source code, but it seems that GUI code permeates most files and although spotting relevant files was easy, it is difficult for me to extract just what I need (I'm only aiming for a command line application right now, I'll see about interfaces later).
Any ideas?
Thanks!
Well, I'm just getting started, but this (in Python) seems promising.
If you're still working on the project and language isn't a problem, you might try Python's cross-platform music21 which can parse midi files into Note, Chord, Instrument, etc., objects, lets you manipulate the scores, and then R/T back to MIDI or output to Lilypond, etc. (full disclosure, I'm the author of the toolkit; but I don't know of many others in any language that will take MIDI in and put Lilypond out while giving you a chance to treat the MIDI elements as objects to manipulate in the meantime.).
Sample code to screw up all the instrument sounds in a MIDI file and then play it and make a lilypond.pdf from it:
import music21
mf = music21.converter.parse('pathToMidiFile.mid')
for x in mf.recurse():
if 'Instrument' in x.classes:
x.midiProgram = (x.midiProgram * 2) % 128
mf.show('midi')
mf.show('lily.pdf')
Hope that helps.