I'm new to Julia.
I'm seeking the best practice of structuring directories, packages, and projects.
Compared with Python, the most annoying parts in Julia are as follows:
The path for e.g. include seems depend on the path of executed file. I'd like to keep a specific reference path so that I can load some files easily.
I asked similar questions here, and someone told me that creating packages and using using will be easy to manage my projects.
However, It's really confusing when loading files and modules. For example,
MyProject
├── MyPkg1
│ ├── src
│ │ └── MyPkg1.jl
│ └── test
│ └── runtests.jl
└── MyPkg2
├── src
│ └── MyPkg1.jl
└── test
└── runtests.jl
6 directories, 4 files
a) MyPkg1/src/MyPkg1.jl
module MyPkg1
export func_export
function func_export
println("hi")
end
end
b) MyPkg1/test/runtests.jl
using MyPkg1
using Test
#testset "MyPkg1.jl" begin
func_export() # raise error: func_export not defined
end
c) MyPkg2/test/runtests.jl
using MyPkg2
using Test
using MyPkg1 # other Pkg
#testset "MyPkg2.jl" begin
func_export() # raise error
end
As written in the above codes, some errors are raised (see b), c)).
So my questions are...
If I did something wrong in the above example, please explain why errors occur in detail.
What's the best practice in developing Julia projects in the sense of directory structure?
Related
I have a project with a proto files in a:
$ tree proto/
proto/
├── common
│ └── request.proto
├── file
│ ├── file.proto
│ └── file_service.proto
├── job
│ ├── job.proto
│ └── job_service.proto
├── pool
│ ├── pool.proto
│ └── pool_service.proto
└── worker
├── worker.proto
└── worker_service.proto
5 directories, 9 files
I want to generate a one single file from worker_service.proto but these file has imports from common.
Is there a option in grpc_tools.protoc to generate one single python file?
Or is there a tool to generate one proto file?
Based on the information, I guess by generate one Python file means: instead of generate one Python file for messages (*_pb2.py) and one Python file for services (*_pb2_grpc.py), you hope to concatenate both of them into one Python file. To take a look at the generated file content, here is the Helloworld example.
Combining the two output file is currently not supported by the gRPC Python ProtoBuf plugin (unlike Java/Go). You can post a feature request and add more detail about your use case: https://github.com/grpc/grpc/issues
I'm working on a program that generates simple text files to save the state of users.
To keep things organized, I have a folder for users. Nested inside, I create a folder for each user with their ID, like this:
[Program Name]\currentusers\36a7781b
Inside of these folders I save a text file with the state of the user. At the moment I'm calling the file simply "appstate."
I have three questions:
Is there a convention for naming folders? E.g. currentusers, currentUsers, CurrentUsers, current_users.
Is there a convention for naming files? E.g. appstate, appState, AppState, app_state.
These are text files —should they include the .txt extension, or are they fine without it?
In order:
1) Yes, there is a convention to name folders. End the foldername with .d like foldername.d. This is used a lot in /etc/, but isn't too common to use. I never use it, and I barely see it except in old "things"
2) File basenames (that's the name of the file without an extension or path) are usually minorcase, and are often separated with - or _. There are no rules. Just avoid spaces or weird symbols. Keep it alphanumerical, for your own and others' sake.
3) POSIX doesn't understand extensions, but also doesn't care if you add them. Users do, and makes it easier for users (and editors/viewers) to know how to handle files.
You said your files are text files (and if it's raw text, end them with .txt), but I believe what you mean is that the files are not binary files (aka readable by a human). I believe your files have some sort of data structure that is parsed by your program, forming some sort of database with folders and users... thus your files are data files (ending with .dat as a convention).
So... all in all:
MyProgram/
├── anna
│ ├── birthday.dat
│ └── name.dat
├── dog
│ ├── birthday.dat
│ └── name.dat
├── john-smith
│ ├── birthday.dat
│ └── name.dat
├── mike
│ ├── birthday.dat
│ └── name.dat
└── rachel
├── birthday.dat
└── name.dat
5 directories, 10 files
I was having a look at the KeepassXC's source code, with Clion as my IDE of choice. After a bit of digging and navigating through the source code, I noticed that one of the source file has the following #include directive:
#include "ui_MainWindow.h"
with a red underline. Hovering over it with my mouse, it says "'ui_MainWindow.h' not found".
The project's CMakeLists.txt file provides three build types:
Debug
Release
Release With Debug Info
and, once all three build types are successfully built, the file CLion should look for is in the following location:
cmake-build-(debug|release|relwithdebuginfo)
└── src
└── keepassx_core_autogen
└── include
├── moc_KMessageWidget.cpp
├── ui_AboutDialog.h
├── ui_CategoryListWidget.h
├── ui_ChangeMasterKeyWidget.h
├── ui_CloneDialog.h
├── ui_CsvImportWidget.h
├── ui_DatabaseOpenWidget.h
├── ui_DatabaseSettingsWidgetEncryption.h
├── ui_DatabaseSettingsWidgetGeneral.h
├── ui_DatabaseSettingsWidget.h
├── ui_DetailsWidget.h
├── ui_EditEntryWidgetAdvanced.h
├── ui_EditEntryWidgetAutoType.h
├── ui_EditEntryWidgetHistory.h
├── ui_EditEntryWidgetMain.h
├── ui_EditEntryWidgetSSHAgent.h
├── ui_EditGroupWidgetMain.h
├── ui_EditWidget.h
├── ui_EditWidgetIcons.h
├── ui_EditWidgetProperties.h
├── ui_EntryAttachmentsWidget.h
├── ui_MainWindow.h
├── ui_PasswordGeneratorWidget.h
├── ui_SearchWidget.h
├── ui_SettingsWidgetGeneral.h
├── ui_SettingsWidgetSecurity.h
├── ui_SetupTotpDialog.h
├── ui_TotpDialog.h
└── ui_WelcomeWidget.h
After a couple hours trying to make it work, I've noticed something weird. The red underline will go away (and the code navigation will work too) only if I build the project in Debug mode (i.e. it'll only pick the file from the cmake-build-debug).
If I clean the debug build and use the release build, there's no way I can get CLion to pick the file from cmake-build-release. Same applies for cmake-build-relwithdebinfo.
The code compiles and runs just fine, meaning that the CMake configuration is correct.
You can solve this problem by changing Clion environment under Build, Execution, Deployment > Toolchains to use compilers installed with Qt instead.
For MinGW 64bit you'll find it under C:\Qt\Qt5.x.x\Tools\mingwxxx_64.
this answer https://stackoverflow.com/a/31293158/192798 helped me find the solution for my case. i also had the same issue for you where it used to work and then suddenly couldn't find the header file. for me, i used target_include_directories so i had to tell clion to choose the configuration corresponding to the target. (i was choosing one of the target's dependents.) then i build, then i can switch to any configuration.
for your case, after switching the configuration, you may need to build to get clion to pick up the file.
Just manually reload cmake project after build.
It works fine for me.
Reference: https://youtrack.jetbrains.com/issue/CPP-22534
I want to generate a simple figure (something like this) with sub directory names, file names in a directory. Is there any easiest way in *nix to do this?
I often need to submit all my analysis results to core biologists, I feel that it would be easy for them to navigate to the files & figures they need, if I provide this kind of figure also.
Thank you very much.
You could use the tree command.
It will display a tree like structure for a directory.
tree
.
└── foo
├── bar
│ └── test
├── bar2
│ └── test
└── test
I am using Sprockets with Sinatra, as suggested in Sinatra's page docs, but I can't make it work.
When I go to localhost:4567, the page loads correctly but with no styles. If I go to localhost:4567/assets/app.css, I get a not found error. I wonder what I am missing or what is wrong in the way I am using Sprockets?
This is my folder structure:
├── assets
│ ├── css
│ │ ├── app.css
│ │ ├── base.css
│ │ └── normalize.css
├── bin
│ └── app
├── lib
│ ├── app_assets.rb
│ └── main.rb
├── spec
│ ├── spec_helper.rb
│ └── main_spec.rb
├── views
│ └── index.erb
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── .rspec
└── .ruby-version
The contents of app.css are:
//= require normalize
//= require base
The contents of app_assets.rb are:
module AppAssets
def self.environment root_path
environment = Sprockets::Environment.new root_path
environment.append_path './assets/css/'
environment
# get assets
get '/assets/*' do
env['PATH_INFO'].sub!('/assets', '')
settings.environment.call(env)
end
end
end
The contents of lib/main.rb are:
require 'sinatra'
require 'sprockets'
require 'app_assets'
class Main < Sinatra::Base
set :views, "#{settings.root}/../views"
get '/' do
erb :index
end
end
The file views/index.erb contains the line:
<link rel="stylesheet" href="assets/app.css">
And the contents of bin/app are:
#!/usr/bin/env ruby
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), '..', 'lib')
require 'sinatra'
require 'sprockets'
require 'app_assets'
require 'main'
Main.run!
Which I run typing:
$ bin/app
Any help would be appreciated, I'm sure I made something wrong but I can't see what. Can anybody spot it?
The app_assets.rb file is the problem here. When you require this file inside another file, the methods you define inside this module are not automatically included. You need to explicitly include AppAssets wherever you need the self.environment method to exist.
The second issue here is that self.environment is not equivalent to settings.environment. If I understand correctly, what you're trying to do is define the asset routing whenever the module gets included. To achieve this one way is to use the included hook for modules. This hook gets run every time you include a module inside a context. If you use that, the code in app_assets.rb turns to:
module AppAssets
def self.included(klass)
environment = Sprockets::Environment.new klass.settings.root
# note the change to path. Since the file where this gets included
# is inside a sub-folder, we need to traverse to one level above.
environment.append_path '../assets/css/'
klass.set :environment, environment
klass.get '/assets/*' do
env['PATH_INFO'].sub!('/assets', '')
klass.settings.environment.call(env)
end
end
end
The klass argument to this hook is the class into which this module is included. In our case this is the Sinatra class you've described in main.rb. That file looks like:
class Main < Sinatra::Base
include AppAssets
# Same as what you have
end
There's a Sinatra Recipes article about using Sprockets with Sinatra: http://recipes.sinatrarb.com/p/asset_management/sprockets?#article