It is actually a credit to the strength of PyDev/ Eclipse that the debugger also steps through the corresponding parts of the imported numpy/pandas, at the places their functionalities are used by my script e.g. df = pandas.dataframe({...
But if I am confident that the imports work OK: Is there a way for the debugger to step only through my own 10 lines of script and not its imports? It would save a lot of inspection time.
(Eclipse for C/C++ on Windows 10 64bit)
Thank you!
There's actually such functionality available in the debugger, but it currently doesn't have an UI (still didn't have time to implement it).
Still, you can set an environment variable to use it.
I.e.: add an environment variable named PYDEVD_FILTERS (you can add it in the interpreter configuration or by editing your launch) and set it to be a list of paths which match the directories you want to ignore separated by ; (fnmatch style) -- those matches will be skipped by the debugger.
See: https://github.com/fabioz/PyDev.Debugger/blob/master/_pydevd_bundle/pydevd_utils.py#L191 as a reference for this (i.e.: pydevd_utils.is_ignored_by_filter).
Related
So I noticed, while answering this question, that the one who asked the question appears to be a javascript developer. And as the code I wrote in haskell is easy enough, I thought I give haste a try and try to compile it to javascript.
So, I downloaded the Windows binary package of haste (why does the .msi require a reboot?!!?), added it to my path, issued haste-cabal update and haste-cabal install split and after a bit of reading the output of hastec --help, I issued:
PS E:\h\stackoverflow> hastec -o hexagon.js --pretty-print hexagon.hs
as my best guess on how to get the output I am looking for.
Opposite to my expectation, haste output was this:
hastec.exe: user error (shell expression failed in readModule: Data.Binary.Get.runGet at position 8: not enough bytes)
So, my question: What do I have to do to get a java script source file?
Is it possible that you have an old version of Haste lying around, or have intermediate files (.jsmod, for instance) from a different version of the compiler in your source directory? This sounds like the (quite unhelpful) error message Haste produces when it runs into a corrupted intermediate file.
Check that the version of the binary you're calling is what you expect (hastec --version). Then, try getting rid of all intermediate files in the directory as well as any files in %USERPROFILE%\AppData\Roaming\haste, reinstalling split, and recompiling with the -fforce-recomp flag. You should also add a main function, so that Haste has an entry point to your program from which to start linking. If all you want to do is to make some Haskell function available to external JavaScript, you can use the export foreign function interface:
{-# LANGUAGE OverloadedStrings #-}
module Main where
import Haste.Foreign
import Hexagon
main = export "picture" Hexagon.picture
You will probably also want to compile your program with the --onexec flag, to make sure that main runs and exports picture immediately when loaded, and not on page load which is the default:
> hastec -o hexagon.js --pretty-print --onexec hexagon.hs
After doing this, any code included after hexagon.js will be able to call e.g. Haste.picture(5); in order to produce a picture of size 5.
(Re: MSI installer requiring a reboot, this is required since it adds the Haste binaries to your %PATH%, which does not take effect immediately. I assume that a re-login would be enough to make it take effect, however.)
So for various "boring" reasons, I'm stuck using VC++ 2008.
Now, I have a custom build rule that parses a ".h" file and produces a .cpp.
The build rule works fine when I can get the setting in the .vcproj (it appears as a <Tool Name="my rule"/> element as a child of the <FileConfiguration> elements for each <File> element).
In the ".rule" file, the FileExtension attribute I've specified is "*.hxx" and not "*.h" as I don't want the custom rule running on every .h, only the ones I want it to. Changing the extension of the files to run the rule on to something other than .h is not an option for reasons that are beyond my control.
The rule works fine, the generated .cpp gets compiled, the dependencies etc are all working - i.e. VC++ only does the custom step when the .h changes etc.
Manually hacking the xml in the .vcproj gets thing working, the issue is the Visual Studio GUI keeps messing with the tool setting and deleting it from the ".vcproj". I haven't definitively determined exactly under what conditions Visual Studio mucks up the setting, as it's somewhat random, but mostly when any change to the project needs to be saved is my observation.
Sometimes (not always) I can manually change the tool in the properties page in the visual studio GUI and it will save it for the active configuration (e.g. "Debug"), but when I try to add it to other configurations (e.g. "Release" or "All configurations") the GUI gets confused and deletes the tool setting for all configurations instead of adding it for the other configuration.
This seems to happen also if I first change the active configuration -> when you go to set the custom tool it gets confused and deletes the setting from all configurations.
I've been able to get similar rules working fine when the input file for the custom rule has a unique extension, it seems to be related to the input name matching ".h" and the default rule for .h's and that my ".rule" file doesn't specify a corresponding matching pattern.
Note this setup with the non matching FileExtension pattern is what was recommended on MSDN for VC++ 2008, which is why I did it that way.
Anybody had any similar issues ? Any clues at all on what a robust solution and/or workaround might be ?
I just need to preserve the setting in the context that NOOBS might be using the VS GUI so you can't trust them to not do "certain things".
OK, so after much searching here, and anywhere else I could think of, and trying a bunch of dastardly incantations I've still got no joy on an actual solution to the problem of preventing the IDE deleting the custom build tool setting when the extension pattern doesn't match the file.
So the work around was I changed the rule to use "*.h" pattern and do a test to see if the custom command needs to be run. The following is my "FunkyRule.rules" file in case anybody needs to see what I did:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="Funky code generator"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="Funky"
DisplayName="Funky code generator"
CommandLine="IF NOT EXIST $(InputFileName) goto :notFound
NeedsFunky $(InputFileName) 1>nul || goto :notFound
echo Generating Funky things for $(InputFileName)
FunkyCodeGenerator $(InputFileName) -o ".\GeneratedFiles\funky_$(InputName).cpp "
goto :done
:notFound
exit 0
:done
"
Outputs=".\GeneratedFiles\funky_$(InputName).cpp"
AdditionalDependencies="$(InputFileName)"
FileExtensions="*.h"
ShowOnlyRuleProperties="false"
>
<Properties>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
This CustomBuildRule needs two external commands "NeedsFunky" and "FunkyCodeGenerator".
"NeedsFunky" is a command that returns 0 if the input .h is a valid input for "FunkyCodeGenerator" and non-zero otherwise.
"FunkyCodeGenerator" is the command that does the "funky-ness" taking the input .h as a parameter and requiring a -o option to specify the output file.
In this context (i.e. whatever environmemt Visual Studio calls the resulting temporary .bat file), I had some trouble making an IF statement work using the usual "IF errorlevel" syntax, so hence the unusual "cmd || goto :failLabel" construct.
If you add this rules file to the custom build rules for a project you'll automatically get "some funkiness" on all your ".h" files :-)
My team has been using Notepad for translation purposes so far. Recently, we decided to use one of the CAT tools available on the Internet - OmegaT.
We've got source and manually translated files, and only values were ever touched.
Is it possible to import both to the same project, so that source phrases stay source, and our phrases become their translated counterparts?
Note: I don't know if it matters, but files are formatted as INI (key=value).
What you need is an alignment. It takes source and target files and creates a translation memory.
In your specific case (INI files), you can use OmegaT to do an automatic alignment with a command line:
http://omegat.sourceforge.net/manual-standard/en/chapter.installing.and.running.html#omegat.command.arguments
Sample command line:
java -jar OmegaT.jar "C:\OmegaTProject" --mode=console-align --alignDir="C:\OmegaTProject\align"
For more general purposes, and with a GUI, there's a prototype version of OmegaT with an aligner:
https://omegat.ci.cloudbees.com/job/omegat-prototype/26/
See the OmegaT development mailing list for information about this.
Didier
With currently Beta version of 4.* releases (currently 4.1.5), you can use nice visual aligner - https://www.proz.com/forum/omegat_support/306343-new_interactive_aligner_in_omegat.html
I have a custom package that I find myself reusing repeatedly in Dymola models, and I'd like to put this package in a common directory that is automatically loaded whenever I start Dymola. My current strategy is to load the custom package when a model I'm working on is loaded and then save total. This is not elegant because the contents of the custom package end up saved in multiple locations across my hard drive, and if I change one of them, the changes are not reflected everywhere. I would like a more robust way of distributing this custom package to all of my models. Is there a way to tell Dymola to automatically load my custom packaged every time?
The trick is to add the following lines to settings.mos in c:/Users/USERNAME/AppData/Roaming/Dynasim:
Utilities.setenv("MODELICAPATH", "C:\Users\USERNAME\Documents\Dymola");
openModel("c:\Users\USERNAME\Documents\Dymola\UserDefined\package.mo")
The first line adds the directory to the path that Dymola uses to search for packages that have not been loaded prior to the first run of a model, and the second line loads the specified package. These two commands may be somewhat redundant, but I am doing both because I want to make sure my custom packages are on the path in addition to loading the UserDefined package.
Two suggestions. First, you need to add your package to the MODELICAPATH. You'll have to consult the Dymola documentation to figure out exactly what you need to do. But normally, what this means is that you have to set an environment variable that gives a list of directories (; separated) to be searched for your package. Now that will put it in your path so it can find it automatically, but it won't load it until it needs it.
If you want it to always appear in the package browser, you'll probably need to set up a .mos file (script) to load it. Dymola has that capability, but you'll have to read the manual to figure out what that script has to be called and where Dymola expects to find it.
I hope that helps.
In the instalation folder of Dymola 2018 -> insert -> dymola.mos
I've added the lines:
Utilities.setenv("MODELICAPATH", "C:\Users\XXXX\Documents\Dymola");
openModel("C:\Users\XXXX\Documents\Dymola\DCOL\package.mo");
openModel(“C:\Users\XXXX\Documents\Dymola\Annex60 1.0.0\package.mo”);
Now I don't get the utilities sentence, as the DCOL package loads fine without it and the added 'utilities' package in the package menu is useless.
But it does not open the Annex60 package.
I've tried a lot of different combinations and can't get multiple packages to load. I doubt that "cd" and "Advanced.ParallelizeCode", which are also added in the text work.
The accepted answer does not work since Dymola 2017 FD01, as the file settings.mos is not used anymore. User settings are stored in the setup.dymx file instead, located in
C:\Users\USERNAME\AppData\Roaming\DassaultSystemes\Dymola
In contrast to the setup.mos file you can not include custom lines with modelica script in setup.dymx.
The answer using dymola.mos still works, but you need admin privileges to modify this file.
Here is a simple solution which works with all Dyomola versions:
You can pass a .mos-script as first parameter to the dymola.exe.
This can e.g. be done like this:
Create a .mos script somewhere with commands like openModel(), etc.
Create a desktop shortcut to Dymola.exe
Open the properties of the shortcut and add the path to the .mos script in the Target text field. It will then look something like this:
"C:\Program Files\Dymola 2018 FD01\bin64\Dymola.exe" "C:\<some-path>\startup.mos"
Start Dymola with the desktop shortcut. The script will be executed and eventual errors or messages are displayed in the Commands window
Another suggestion where you don't need to hardcode your package into an environment variable of your operating system (and maybe more safe for inexperienced programmers):
Go to the folder where Dymola is installed (e.g. C:\Program Files\Dymola 2020).
Search for the Dymola.mos file in the insert-folder. 'insert' folder
Open the script (e.g., in notepad++)
Add the link(s) to your Dymola-library-package.mo file(s) here with the openModel statement
e.g., openModel("C:/IDEAS/package.mo"); Dymola.mos script
Save the script. Now, every time you open Dymola, your libraries will be loaded automatically.
Is it possible to exclude files from debugging in Eclipse?
There are my files which I have written and I am interesting in going through these files using debugger Step Over command.
But there are also many imported library files and Step Over goes into these files, which I'd like to avoid. So is there an option eother to specify which files to debug or which files to exclude?
If you're using a JVM based language (as you didn't specify), under Preferences, filter for Step Filtering.
You will see a list of packages. Add your packages to the list, and ensure Use Step Filters is selected.
Assuming it's an entire package you want filtered out, and you're using Java, this should do what you want.