Say I have a file structure like so
a
|
+-- x
|
+-- y
b
and I wish to move x from a to b, what would be the best way of achieving this in Rust? I am working on Windows, but would optimally like to add cross platform support.
I am not particularly experienced with Rust at the moment, and haven't been able to find an answer on the web.
EDIT
The cross platform support is unimportant at the moment :)
Use std::fs::rename() to move a file.
Related
This isn't exactly the best stack overflow question because it's opinion-based, but I'm going to try to ask it in a way that will lend itself relatively to an answer with some degree of factuality (as opposed to opinion).
I know you can switch projects (https://docassemble.org/docs/playground.html#projects), which is of course very useful. What I'm thinking about in particular is that I have seen some tutorials that abstract code out of interviews in .py files -- this seems reasonably useful to me, not the least of all because of linting (tangent: is there a docassemble linter?).
Because of the way docassemble does inheritance, I think I would rather have my entire playground be one big directory with subdirectories for projects (rather than starting from scratch with new projects ... some of the .yml file, .py files, static files, etc. are probably able to be written in a way that they can be re-used across interviews and I'd love to do that in a way that's less clunky than re-importing them into a new project when I need them.
Can we organize the playground in docassemble, or are we stuck with a one-level directory?
If the playground can be organized (eg. into directories, subdirectories, etc.), are there any community-accepted or JHPyle-reccomended best-practices around that? (i.e. although I assume less formal, I'm thinking something like PEP) I know it's probably easy-enough to come up with a file naming convention with similar effect, but that's a bit hacky.
Is in possible, as an alternative, to simply directly edit the packages?
The main thing I'd like to accomplish, and the main impetus for this question, is keeping my code DRY by using helper functions / helper .yml files.
The Playground is a simplified interface for people who are new to programming. It supports "projects" but does not support subdirectories. Advanced programmers can write their code in Python packages using a text editor and can use subdirectories under the data directory if they want to.
Is there is a standard fashion for organizing a Rust project? I have been working with C-family programming languages for over nine years, but Rust seems different in some aspects.
Is one supposed to organize their projects in a similar manner to C-family languages, especially object-oriented such?
project
|->src
|->main.rs
|->structs.rs
Or perhaps in this way?
project
|->src
|->main.rs
|->struct0.rs
|->struct1.rs
|->struct2.rs
|->struct3.rs
That is, one file per struct?
Or does one create new binary projects every time they make a new part of their program? I am currently using Cargo to generate my projects, but to be fair do not know too much about it. Eventually, there will come a point when I read through the entire Cargo documentation, although I would like to get a little more acquainted with Rust prior to that.
Kindly explain in both trees and text, as well as possibly some pieces of code.
Try to plan how your program will be organized in terms of logic rather than objects. Split your logic into separate modules.
If a you have a small module make it a single file modname.rs or if it is a bigger module (consisting of submodules) create a folder with at least a mod.rs file in it: modname/mod.rs.
If your project gets really huge you could also split it into several crates (libraries) which you then depend on in your main project.
You can read more about Rusts crates and module system in the official rust book: https://doc.rust-lang.org/book/crates-and-modules.html
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Common GNU makefile directory path
After reading Recursive Make Considered Harmful I decided to use "include makefile" to my next project. I got a main Makefile that include two sub-makefiles that are in diffrent dirs. the problem is that the paths that inside the sub-makefile is relative to his dir so when I include it from the main Makefile he can't find the files. is there a way to solve this problem without changing the paths?
Although the article is right about recursive make and DAG tree, I read the article about half a year ago and tried to use the approach described in it and found the "classic" approach to recursive make much more convenient. Consider this:
big_project
|--Makefile
|
|--sub_project_1
| |--...
| |--Makefile
|
|--sub_project_2
|--...
|--Makefile
It's wonderful when you're running make from big_project project directory, but well, if you do things as it's recommended in the article, there would be no Makefiles in sub_project_x directories, thus you won't be able to treat each sub-project separately.
Summary: Want help to figure out how to setup the depot and my development environment so that I can support multiple, related projects.
Details:
Until now I've had a depot which had in it only one project - ProjectA - robot version A.
I am starting to work on a new version (ProjectB) which has some differences in HW - I/O port mappings and timers have changed. I would like to continue to develop code for both projects.
This means that ProjectB will share some files with the ProjectA and some files will be different.
Since the differences are HW related items what I'm thinking of doing is creating a common area and then project specific areas where the common area is for device independent code and project specific area is for device dependent code.
The differences are big enough that I don't want to do #ifdef within files. Some differences are simple - different I/O port mapping and some are completely new modules.
To make maintainance easier, I would like to be able to compare differences between device dependent code and propagate selected changes.
Finally, to minimize my burden during comparisons, I would like to mark differences that I know are okay so that in future comparisons they don't show up.
Help!
Your instincts are good -- you're trying to Not Duplicate Code. This is the core of good design & engineering.
As for the file layout, it's always annoying to have your directories too deep, but that's MUCH better than too shallow. Maybe:
<root>
main/
projects/
robot1/...
robot2/...
shared1/
shared2/
(Big repositories are much deeper than that, even.)
As for how you make shared code -- you could have different setup.h or constants.h that drive what the various shared libraries do. Alternatively, build your shared libraries so they are parameterized at runtime.
SetupDrivers(0x80020); // address of PIO registers
And lastly -- if the projects really are different, decide if sharing the code really is the right thing. Usually yes, but everything is a choice. If you hope to manually "diff" your files to look for differences, it's really up to you to keep the structures close enough to diff. The "different config.h file for each project" idea mentioned above would help.
If you roll your own diff tool (in python or whatever) you could use special comments to flag "expected different lines".
I am trying to understand how a language interpreter works. Can you guys point me the general lines on how an interpreter works?
I mean, suppose I have some lines written like this
10 x = 200;
20 for r = x to 1000 step 1
25 z = r + 32;
30 print z;
40 next r;
50 end;
what's the best way to build an interpreter that could run something like that?
Having a large matrix containing all functions allowed and searching for a match? The first line, for example: it is assigning 200 to a variable x, but these are symbols that does not exist.
If you guys can give me the direction...
Thanks for any help.
Compiler creation is a complex topic (an interpreter can be seen as a special compiler).
You have to first parse it - try to understand the syntax and then create some internal representation (abstract syntax tree) and then create some execution logic.
Wikpedia suggests http://mcs.une.edu.au/~comp319/
I know this is an old thread but most of the related questions are marked as duplicate or closed. So, here are my two cents.
I am surprised no one has mentioned xtext yet. It is available as Eclipse plugin and IntelliJ plugin. It provides not just the parser like ANTLR but the whole pipeline (including parser, linker, typechecker, compiler) needed for a DSL. You can check it's source code on Github for understanding how, an interpreter/compiler works.
Perhaps you are talking about creating a DSL.
You might find this helpful (if you are ok with spending $$)
http://gilesbowkett.blogspot.com/2010/03/create-your-own-programming-language.html
I'm interested in learning more about this as well. I found Douglas Crockford's JavaScript parser interesting, though from what I understand he's using a different method than is typical for parsing languages. It's not the full picture for interpreting and compiling, but I found it helpful to see some actual parsing implementation and the resulting restructuring of the code.
you can find an open source 'Gold Parsing System' at http://goldparser.org. :)
there are some explained concepts on their site too where you can learn some rudimentary basics of the process.
Learn about tools such as lex/flex and yacc/bison. These are most popular tools for building compilers in open software world. Many well known open source programs are written using them (including PHP, gcc, doxygen). You'll find a lot of free books and tutorials. They not only show how to use lex and yacc tools, but also explain general ideas behind compilers.