Just interesting why is names lib. The Entry point is main.dart, so it's a little bit strange to see main.dart inside lib folder.
I think it is because when we code in Flutter, we're composing the widgets to make it functional & importable, thus we call it our lib (library).
Besides that, Dart is a new thing in this time, it surely unique from any other existing programming languages, so "little bit strange" is understatement. For example, we use echo to print text on the screen. Why "echo"? Isn't it supposed to outputting a voice? It was strange, but eventually people will adapt with it. Strange will not strange anymore.
It is not strange, lib is directory and this name is hardcoded and there is no way to change it. The whole pub package system depends on that directory name. There is also a convention that tools like the analyzer support code in lib/src being considered package-private when not exported by files in other directories in lib/.
The Entry point is main.dart but you can change main.dart(entry point) to some other page in Flutter.
I think it's the most anti-pattern thing i've seen in 24 years of development. It's nonintuitive, names and pattern is made for human... machines don't care if a directory name is src, lib, abc, xyz or 123.
Related
Tried searching for this a number of ways and have not yet found an answer ...
Background
I am working on a legacy Perl application that has a lot of hard-coded values in it which should be configurable depending on where the app is installed. So, obviously, I am looking to externalize these values into a configuration file that may be located in one of a few "expected" locations. That is, using a traditional approach of checking for the configuration file in:
the current working directory,
the user's home directory (or a sub-folder therein), and
the system configuration directory (or a sub-folder therein)
where the first one found wins.
Where I am at
Perused the CPAN site a bit and found the Config::Any package, which looks promising. I can give it a list of files to use:
use Config::Any;
my $config = Config::Any->load_files(
{
files => [qw(sample.conf /home/william/.config/sample.conf /etc/sample.conf)],
use_ext => 0,
});
This will check for the existence of each of these files, and, if found, load the contents into an array reference of hash references. Not bad, but I still have to hard-code the locations where I search for my sample.conf file. Here, I assume that I am working on a Linux system, and that the location for the configuration file for all users of the application is /etc/. I could always add /usr/local/etc/ as well, but regardless, this is not system agnostic.
I can locate the user home folder using File::HomeDir for searching there, and it works correctly regardless of the system on which the application is running. So is there a similar package that would provide the /etc/ folder (or its equivalent on other platforms)?
Questions
Is there a way to do this without having to know what particular OS I am on? (Perl package or code snippet)
What is the "Perl best practice" way of accomplishing this? I cannot imagine that no one else has run into this previously.
Unless you don't plan to run your code on non unix-based hosts, according to the conventional directory layout and filesystem hierarchy standard, you may rely on a quite large set of well known places.
Anyway, nothing prevents you to dynamically build the file search specification to take account of platform oddities and their specific ways to get them (eg. File::HomeDir::Win32 vs File::HomeDir).
I am developing a couple of packages for sublime text, and to avoid copy and pasting massive amounts of code I began to move my classes into separate files. I have been avoiding this so far, since, in my current workflow, changes to files that are not in the main plugin file won't get updated when saved and only go into effect when I restart sublime.
Is there a way to reload a package, including all it's files, without restarting Sublime Text?
You don't actually have to restart the editor. You will have to restructure your plugins though to take advantage of this. Essentially, you can load the plugin files from some top level file. As an example, take a look at Package Control. I also do it in PersistentRegexHighlight (though the package control solution is likely more robust (I did base it on that). Still not as good as simply saving a particular file, but better than restarting! In fact, you could probably tie into the on_post_save event to automatically save the top level file when you modify a child file.
I personally found the easiest solution was to install Package Reloader, and just put a new file in the top directory of my plugin named .build. Save your top-level plugin file and enjoy not having to restart.
Virtually no restructuring of code required.
From the unofficial docs:
Sublime Text will reload top-level Python modules from packages as they change (perhaps because you are editing a .py file). By contrast, Python subpackages won’t be reloaded automatically, and this can lead to confusion while you’re developing plugins. Generally speaking, it’s best to restart Sublime Text after you’ve made changes to plugin files, so all changes can take effect.
Unfortunately, plugins are not loaded into a scope visible from the console (Ctrl`), so you can't just reload() it. EDIT But, you can call reload() from within your top-level plugin file, as detailed in #skuroda's answer.
You'll have to make the decisions on when to break classes out into separate files vs. keeping them together in one monolithic collection. Having 50 files, each with only two or three function definitions is overkill in one direction, while having 20 classes each with 10 or 15 methods all in one file is going overboard in the other, so just do what feels best for the particular project. In my experience killing/restarting ST2 doesn't take too long in any of the supported operating systems (except on XP, for some reason...), so hopefully it's not too much of a delay on your workflow. One suggestion I'd give is to create a portable installation (if you're on Windows) with just the bare essentials in extra plugins if your startup time is too long.
Good luck!
I'm making a Lua game using the 2D framework 'LÖVE'.
I needed to know HOW to make a .exe file with it! I've done the command line, sucessfully zipped up my main.lua and the image, I've renamed the file extension to .exe!! When I run the .exe, I get a file extracting application coming up. This is not supposed to happen, right? I want it to be run as a game, not as a self-extracting application. Help?
From the sounds of it, you are trying to save your 'lovechive' with an .exe extension; your archiver is probably 'helpfully' assuming you meant to create a self extractor, which you didn't.
Okay, lets start by talking about how runable 'lovechives' work:
When love.exe starts up, it first checks its own name, if its called something other than love or love.exe it immediately checks to see if there is somethng stuck to its end. if there is, then it tries to interpret it as if it were a 'lovechive'.
So basically, we want to stick a zip-file to love's bottom (don't worry, it likes it).
Start by creating an ordinary zip archive of you game directory.
Remember to check for anything you don't actually mean to ship; plenty of love games have gone out containing backup copies of the source code, test artwork, and peoples' shopping lists. Don't be a statistic.
The filename is irrelevant for what were are doing here, so don't worry about the usual step of renaming it to a .love. just make sure that what you have is an plain-ol' ordinary zip.
The next step depends on your host platform, but basically you now need to do the whole "stick it to love's bottom' part now, generally this is done from the command-line:
On windows, the command is:
copy /b love.exe+YourGame.zip TheGame.exe
Where love.exe is the name of the main 'love' executable YourGame.zip is the name of zip file containing your game, and TheGame.exe is what you want the final game executable to be named.
On Linux or OSX, the command is:
cat love YourGame.zip > TheGame
Where love is the name of the main 'love' executable, YourGame.zip is the name of zip file containing your game, and TheGame is what you want the final game executable to be named.
These substituting the relevant filenames should let you produce versions for Linux, and Windows
(All I know about making 'merged' OSX Apps is that its more complicated.)
For the record, it is utterly trivial to extract files from the 'merged' game. Usually nothing more than changing the file extension, sometimes not even that.
And no, zip encryption doesn't help here; it won't run because love can't read the archive. (quite sensibly, really.)
Finally, If you are distributing to the Love community, they generally prefer that you just give them the 'lovechive.'
From https://love2d.org/wiki/Game_Distribution :
Here's how to do it on Windows. In a console, type this:
copy /b love.exe+game.love game.exe
Then, all you have to do is zip game.exe and required DLLs, and distribute them. Yes; this does mean that the game will have a private copy of LÖVE, but there's nothing wrong with that. It also means that you will have to create one package for each platform you would like to support, or simply offer the .love alone for the other platforms.
At first I want to say I'm a total beginner in Python so this question might be really stupid. I'm currently trying to learn something new and am developing a plugin for SublimeText2.
Can I get a list of files and folders in some directory in Packages folder of SublimeText2, what I basically want is a simple list. If yes, how can this be done?
I've searched the API for something like that, but the only thing that there is are commands that manipulate the currently open folders (the ones in the sidebar).
Ok, this was really stupid, I won't close the question as I think it may help others to start here. The reason I didn't find anything in SublimeText2 API is because this is the default Python functionality from the os library.
import sublime, sublime_plugin, os
#...
print(os.listdir(sublime.packages_path()))
Method sublime.packages_path() returns the path to packages folder.
OK, this is in the pet peeve department. Not terribly important but sometimes annoying.
I am creating a series of test projects to experiment with various ideas. The projects are named "Test 1" through whatever.
When the project is created by XCode I get file names like "Test_1AppDelegate.h" and "Test_1ViewController.h".
What I want is: "Test_1_AppDelegate.h" and "Test_1_ViewController.h", which is far more readable and "civilized", if you will.
Is there a way to make this happen?
What I've resorted to now is a really messy process:
I name the project with a trailing space: "Test 1 "
This gives me the file names I want within the project.
I then have to go and use Project>Rename to remove the trailing space from the project name
At this point, close the project and rename the directory to remove the trailing space.
OK, it works, but it is convoluted and hopefully not necessary. This also produces a couple of "casualties" with weird naming that I simply have to live with:
"Test_1__Prefix.pch" // Double underscores
"Test_1_-Info.plist" // Underscore prior to hyphen
Again, not a huge deal, but it'd sure be nice to clean-up the naming as a part of the automagic project creation process.
Like many things XCode, it's a love-hate relationship.
Thanks,
-Martin
While I haven't done it, you can define your own custom project template. I would start first by examining the supplied project templates at:
(Xcode folder)/Library/Xcode/Project Templates/
to see the overall structure. The most difficult part is finding documentation on this topic, because I could not find any documentation supplied by Apple. This likely means that it is subject to change at any time and the work you put into defining your own template may need to be tossed.
I was able to find some instructions with a simple google search: Xcode custom project template
For example:
Cocoa dev: Design your own Xcode
project templates
Xcode: How to customize the existing
project templates