BACKGROUND
One of the very useful tools for reproducible work in R is the "here" library.
https://malco.io/2018/11/05/why-should-i-use-the-here-package-when-i-m-already-using-projects/
http://jenrichmond.rbind.io/post/how-to-use-the-here-package/
https://here.r-lib.org/
https://here.r-lib.org/articles/rmarkdown.html
I was hooked by the part in the first link where they said this:
The "here" library is encoded in Anaconda as "r-here"
I'm not sure which came first, but Python has a "here" library as well.
https://pypi.org/project/pyhere/
https://github.com/wildland-creative/pyhere
"Here" makes relative paths a trivial matter, which is really useful for reproducible data-science and analysis work.
QUESTION
What is the Julia equivalent for clean handling of relative paths for files?
Is there a clean way to integrate that with project packaging, like RStudio does?
Based on the description, it sounds like DrWatson.jl does what you're looking for. From the website:
[DrWatson] is a Julia package created to help people increase the consistency of their scientific projects, navigate them and share them faster and easier, manage scripts, existing simulations as well as project source code. DrWatson helps establishing reproducibility, and in general it makes managing a scientific project a simple job.
Like the description implies, it's more ambitious than here seems to be, having functionality to also manage data, simulation runs, etc. But they're optional, and you can use only the directory handling part if you need.
The Navigating a Project describes the projectdir function which works similar to here. projectdir("foo", "bar") resolves to foo/bar under the current project's root directory, just like with here.
There's also datadir(), srcdir(), and others to directly handle common subdirectories under a project for eg. datadir("foo", "test.jld2") resolves to data/foo/test.jld2 under the project's root directory.
It doesn't exist, as far as I'm aware (Here.jl doesn't return any Google hits), but it seems like it would a simple enough for someone to implement. Maybe you!
Related
So, for an embedded project with external NOR flash and existing commercial RTOS.
Can I use the coffee filesystem in a form of a library, i.e. to compile it in? From what I've seen it seems possible, only the dependencies go quite deep in to Contiki. I'll surely dig in, but may be someone have done something of the kind already?
This does look very doable.
From a quick grep in core/cfs/ it looks like there are no Contiki-specific abstractions used in the implementation of CFS. And another very quick search on GitHub shows that swift-nav/piksi_firmware contains and uses CFS without Contiki.
I want to open libraries, because currently I want to see the algorithms used for drawing, modify them and implement them in my program. For example: I have tried to create an algorithm on my own for lines. But I failed. And even if I had succeeded, I fear that it might not give the same result as the algorithm in the libraries. And I don't want this to happen. That's why I want to copy the algorithms used for the methods in libraries. And I really hope that this will help me create the application I'm currently working on and with other applications in the future.
I tried to open the libraries with a code editor. But I had troubles finding the libraries- I don't really know where are they placed nor in what files are their codes stored.
How to open a Java library? Or is there a place in the Internet where the code is uploaded?
It sounds like what you want is to get inside the standard Java libraries (so you can see the code for methods like Graphics.drawLine()).
You can download the source files from the same place you got the JDK, if you are on Windows or Linux. For the Mac, see this question. You can even set up Eclipse so that you can debug into that source as if it were your own code.
However, you will probably not find line-drawing code in Java in these libraries - the Graphics implementation will almost certainly use native methods, and may just call existing methods in the OS.
If you are specifically looking for line drawing algorithms, another option would be to look at the Wikipedia page for the Bresenham (aliased) or Wu (antialiased) algorithm.
Edit:
The part of a Graphics2D call that actually puts pixels on the screen is probably inside a system call and therefore the source would not be available.
A java vector graphics library like Batik might have source for some of these algorithms, but probably relies on the Graphics2D calls for most of them. So, you might look for a comprehensive vector graphics library written in a language other than Java, where those graphics calls do not already exist by default.
Alternately, checking the table of contents for a computer graphics book might point you at a variety of algorithms that you could look up on Wikipedia.
For any given library:
Make sure to obey all licenses when using another's code
If you are referring to the Java SDK source code, you can find it here: http://grepcode.com/
If the project is open source, you can usually just get the source from the project website. No problem, though make sure to obey their license.
If the project is NOT open source, well, then you're in a pickle licensing wise, so I do NOT endorse this, however, you would need to use a Java Decompiler such as JD-Gui
As far as what drawing algorithms to use, there are so many different ones (obviously, people have been trying to draw quickly for many many years), your best bet is to figure out exactly what you need to do and then search for that specific need separately. There isn't really a good repository of ALL of them, except maybe wikipedia.
If you are using the libraries they are on your classpath. Check out how to figure out your classpath in whichever IDE you are using and you can find the JARs you depend on. If they are packaged with sources all you need to do it unjar them and look at the sources.
If you don't have access to the sources you can get the code using a Java Decompiler.
If you are trying to look at a standard Java library, see the other answers about getting the source to the JDK.
If you are interested in an open source library (such as something maintained by the Apache project), look on the site of the project for a 'source jar' which you can open with a standard zip utility.
If the library you want is not open source or you cannot find the source for it, you can try to decompile it. If you are using Eclipse, try this decompiler.
The team I work for manages a large collection of technical documentation which is written in LaTeX.
Currently all the documentation we have is manually built by the editors and then checked into a version control system. Sometimes people forget to compile their documents so we have a situation where the PDF and .tex files are often out of step. Unfortunately when this happens our users find themselves reading old versions of our document.
I've managed to hack a simple script to build PDFs using Make - it's rather clumsy.
I was wondering if there was a better way to do it? Most people in our department use Eclipse + Pydev for a Python project which means we are all very familiar with this IDE. I know that Ant plays nicely with Eclipse, so might we be able to use this tool for our doc building?
So what's the best way of doing this? I hope I will not have to learn everything there is to know about a new build-system in order to automate the building of some quite simple docs.
There is an external Ant task for LaTeX PDF generation, though the site is in German.
To use it, download the jar to a location on your machine, then define a taskdef as follows:
<taskdef name="latex" classname="de.dokutransdata.antlatex.LaTeX"
classpath="/path/to/ant/lib/ant_latex.jar"/>
Then to use it, define a target like this:
<target name="doLaTeX">
<latex
latexfile="${ltx2.file}"
verbose="on"
clean="on"
pdftex="off"
workingDir="${basedir}"
/>
</target>
Where ltx2.file is the file to process.
This is a link to the howto page listing the parameters. If you need any more options, my German is just about passable enough to explain, maybe.
There is also a maven plugin for LaTeX, but I can't find any documentation.
Haven't tried it, but I remember seeing a blog post about it.
If you know python, this blog post might be interesting
EDIT: Also, I would assume that you're using some kind of version control system, and I can't say for sure, but I use git to manage all my latex docs, and it might be possible to use some kind of post-commit hook to execute a script to rebuild the document. This would depend on how your repository is structured... just thinking out loud, so to speak.
I went into great detail on a large number of build systems for latex in this question, but its slightly different in your case. I think you want rubber or latexmk. The latex-makefile seems a good idea, but only supports building via postscript, which might not be your build process.
In general, its a good idea to keep generated files outside of version control for just this reason. A good exception is when specialist build tools are not widely available, and your situation sounds similar. You might do better with a commit-hook to build automatically upon commit.
I guess I should also point out that committing something without first building it and checking it is a deadly sin, so a better solution might be to stamp that out.
Maven is a better alternative as build system compared to Ant. So I would recommend a maven-plugin to generate PDF from LaTeX sources. Have a look at mathan-latex-maven-plugin
Looking at our codebase some code is included in a project explicitly and is pulled in from the search path. Does anyone have an opinion as to which is best practise and why?
Update:
I thought I would clarify my question. All our paths are relatives, so we can have multiple branches that all refer to code within their branches. So I'm not asking about relative paths, but whether units should be in the .dpr or picked up using the search path, which is why the previously asked questions don't quite answer my needs. Thanks to everyone
I have a very basic way of determining this... If the code is specific to the project (not used elsewhere) I include it explicitly. All shared code gets pulled from the library path.
best regards,
don
I don't think I can count the number of times I've helped someone who discovered that the compiler was finding a duplicate copy of a unit somewhere on their search path where they did not expect to find it. They couldn't understand why they were changing their code in the editor (on a copy of the units not found in the search path) and not seeing any change in the behavior of the application. Explicitly including the unit and not setting a search path means there can only be one copy of the unit found by the compiler.
This has been covered here before:
In Delphi, should I add shared units to my projects, to a shared package, or neither?
What is the best way to share Delphi source files among projects?
My answer to the first question is also my answer to your question.
my libraries are in SVN, and I usually check them out for (branch them into) a project at ../libraries relative to the project. This keeps the scope of the includes dirs small and to the point.
In the real source (.pas), paths are totally forbidden.
no project related paths in global delphi searchpath (only per project, or they are truly universally shared sources/components)
I hate poluting source with hardcoded paths, so I usually have only a few units in the project, always with relative paths. Not the VSS w:\ drive substitutes hack please! Typically these are the units that pull in framework parts or are needed due to visual inheritance or form initialization.
Unfortunately, relative paths can be dangerous with Delphi, because they are relative to the working directory, which can change according to Delphi dialogs (e.g. Open). The solution is simple, have an include file with an unique name in the main project.
The shared code vs specific code is a good rule.
I use VSSConnextion a lot, so files that I usually need to check out/in together, naturally belongs to the same project.
After upgrading Delphi twice and moving my project to new computers twice, I've learned that hard-coded paths are evil because root directories tend to change. Doubly so if you're working on a shared project.
I had the same problem. The blue-dots where not showing up in the gutter.
Simple solution (one of):
Menu > Project > Compiler > Build Configuration... set to DEBUG instead of release.
Delphi 2007
PS: well, I thought I was done coding. Someone had requested a new feature. :)
Is there a indexing plugin for GDS that allows for source code search? I see some for specific types (Java, C++, ...) and one for "any text". These are nice, but I would like one that allows for many/configurable extensions (HTML, CSS, JS, VB, C#, Java, Python, ...). A huge bonus would be to allow for syntax highlighting (http://pygments.org/) in the cache.
I just found Dropout and it seems to work great. Put Dropout in any folder and it will index all files in that folder. I put it in my Projects folder and it crawled all my code. Very fast and flexible search. Dropout
You could use OpenGrok or some other code-specific search engine instead.
I wrote a quick review of some of them some time ago.
It has been a long time, but the last time I tried to use Google Desktop Search for searching code, I found it quite inappropriate for that task, as I outlined at [http://perlmonks.org/?node_id=490310], the gist of which is that GDS (silently) only indexed a tiny fraction of many source code files (and made it quite a challenge to figure out why searching so often failed to find so much of what was in source code files).
I found Copernic Desktop Search worked better on code files (but I also had trouble with later versions of it being buggy in not finding all matches so I've been staying with version 2.1.1). But these days I don't use it much (mostly because I don't have permission to install such things on the laptop provided by my new employer).
You can try out Larry's Any Text File Indexer. You can specify a list of extensions at install time and it will do full text search on those file types.
Im just giving this a go:
http://desktop.google.com/plugins/i/java.html?hl=en
..also you can search for things in your Java tree using the following syntax in Google Desktop:
<YOUR SEARCH> filetype:java under:"C:\hft\trunk"
..where I keep my code in "C:\hft\trunk"
This is not a Google Desktop plugin, but works for what we need.
We have started using http://svnquery.tigris.org/ and it seems to work and is very fast. I wish it supported multiple repositories per site. We have a repository per project, so currently I have to create a virtual directory for each project we have. Not a show stopper, just something we need to automate in our project setup script.