Re: Reggae v0.0.5 super alpha: A build system in D
On Saturday, 4 April 2015 at 19:59:46 UTC, Dicebot wrote: We need solutions that can be reasonably implemented with existing resources, not perfect solutions. Storing IR in object files and using custom linker is correct approach for WPO but it is currently unaffordable. Works for me with llvm toolchain. Add compilation time problems and there seems to be no compelling reasons to go that route for now. A compelling reason is memory consumption and exhaustion. I am not aware of any solutions based on coding style. Not sure what you mean, reliance on attribute hell is a coding style. You can look at any language, which has no such problem.
Re: Standardpaths library
On Sunday, 5 April 2015 at 11:42:42 UTC, Marco Leise wrote: On another note when I ran your 'printdirs' it didn't list a user Fonts or Applications directory. The Applications directory is ok, but I do have a ~/.fonts/ directory and /etc/fonts/fonts.conf says: !-- the following element will be removed in the future -- dir~/.fonts/dir Fonts in ~/.fonts are listed in LibreOffice. It seems like you do parse /etc/fonts/fonts.conf. Maybe there is a bug in the parser? The whole Applications thing doesn't make much sense on Linux, right? Is that a directory where applications are installed to including their assets? Probably you don't have local $XDG_CONFIG_DIR/fontconfig/fonts.conf file. I've opened issue https://github.com/MyLittleRobo/standardpaths/issues/8 About Applications: on my Windows 7 it returns C:/Users/Username/Application Data/Microsoft/Windows/Start Menu/ProgramsC:/ProgramData/Microsoft/Windows/Start Menu/Programs where .lnk files are stored (I believe these are used in the start menu). Since freedesktop systems use .desktop files it would be sane to return paths which contain them (~/.local/share/applications, /usr/local/share/applications and /usr/share/applications). I just have not implemented it yet. Though not sure it the whole thing can be useful, since things are not the same on Windows and freedesktop: Windows uses directories to make menu hierarchy, while freedesktop for the same purpose use Categories field in .desktop files. Also .lnk and .desktop are different things themselves.
Re: Standardpaths library
On Sunday, 5 April 2015 at 09:08:14 UTC, FreeSlave wrote: And github repo https://github.com/MyLittleRobo/standardpaths If I understand meaning of PublicShare correctly, it's CSIDL_COMMON_APPDATA on Windows.
Re: Standardpaths library
On Sunday, 5 April 2015 at 11:42:42 UTC, Marco Leise wrote: is this Windows? return executable_path That depends on what do you understand by data. Are game's saves data too? Or content downloaded while playing (server-specific assets or new levels). In the past it was ok to write configs and data to the same path where the game (or application) originally installed. But starting with Vista or Windows 7 it's not the case since Program Files folder become write-protected by default.
Re: Reggae v0.0.5 super alpha: A build system in D
On Sunday, 5 April 2015 at 12:22:15 UTC, Dicebot wrote: Unless LDC does some D specific WPO magic I am not aware of this is not what your original statement was about. llvm does normal WPO in a sense that compiled code is not opaque. Erm. Either it is coding style issue or a language issue. Pick one. Only coding style for D I am aware of that deals with attribute hell is ignore most attributes which is hardly solution. The problem can't be solved for coding styles, which rely on attribute hell, I only said the problem depends on coding style.
Re: Standardpaths library
Am Sun, 05 Apr 2015 09:08:12 +
schrieb FreeSlave freeslav...@gmail.com:
I wrote small library for getting standard paths (like Pictures,
Music)
Here's dub package http://code.dlang.org/packages/standardpaths
And github repo https://github.com/MyLittleRobo/standardpaths
You can see open issues on github. Please, participate in
discussions if you're interested. The biggest problem now is OS X
support https://github.com/MyLittleRobo/standardpaths/issues/4
You can generate documentation with dub build --build=docs.
This is indeed useful. I once had a specific use case where I
needed the default location for where the assets of my
application is stored. On Windows applications come with an
installer and install the assets right into the installation
directory (usually current directory). On Linux applications
store their data in /usr/share/appname/. So with a
compile-time only template I accessed these as:
string asset1 = dirs!myapp.staticData ~ /image.png;
Now I realize this is a bit simplistic for several reasons:
* On Windows, one might still want to create a subdirectory to
separate assets from program code, e.g. data.
* On Linux, as your library shows, data directories are
layered like this:
~/.local/share, /usr/local/share, /usr/share
* The _actual_ data directory is often passed into the
configure script on Linux and no general algorithm could
guess it.
* An application name would typically become lower-case on
Linux while keeping its casing on Windows in e.g.
AppData/appname.
Unsure if that's it, but that could make data file lookup for
application SomeTool go like this:
was the data directory explicitly overridden (e.g.
through ./configure or by the programmer)?
return overridden_dir; // note: relative directories expand
as based on executable directory
is this Linux?
for (dir in
[${XDG_DATA_HOME}/sometool, /usr/local/share/sometool, /usr/share/sometool])
is the file in dir ?
return dir
is this Windows?
return executable_path
This goes a bit into heuristics and best practices, so it
probably doesn't fit with your library that provides
clearly defined standard paths from the desktop environment.
Aside from that I think it is a common enough use case to
lookup assets that ship with your program in the typical
installation directories.
On another note when I ran your 'printdirs' it didn't list a
user Fonts or Applications directory. The Applications
directory is ok, but I do have a ~/.fonts/ directory and
/etc/fonts/fonts.conf says:
!-- the following element will be removed in the future --
dir~/.fonts/dir
Fonts in ~/.fonts are listed in LibreOffice. It seems like you
do parse /etc/fonts/fonts.conf. Maybe there is a bug in the
parser?
The whole Applications thing doesn't make much sense on Linux,
right? Is that a directory where applications are installed to
including their assets?
--
Marco
Re: Reggae v0.0.5 super alpha: A build system in D
On Sunday, 5 April 2015 at 12:17:09 UTC, Kagamin wrote: On Saturday, 4 April 2015 at 19:59:46 UTC, Dicebot wrote: We need solutions that can be reasonably implemented with existing resources, not perfect solutions. Storing IR in object files and using custom linker is correct approach for WPO but it is currently unaffordable. Works for me with llvm toolchain. Unless LDC does some D specific WPO magic I am not aware of this is not what your original statement was about. I am not aware of any solutions based on coding style. Not sure what you mean, reliance on attribute hell is a coding style. You can look at any language, which has no such problem. Erm. Either it is coding style issue or a language issue. Pick one. Only coding style for D I am aware of that deals with attribute hell is ignore most attributes which is hardly solution. Please give any specific example to back your point.
Re: Standardpaths library
On Sunday, 5 April 2015 at 12:35:46 UTC, Kagamin wrote: On Sunday, 5 April 2015 at 09:08:14 UTC, FreeSlave wrote: And github repo https://github.com/MyLittleRobo/standardpaths If I understand meaning of PublicShare correctly, it's CSIDL_COMMON_APPDATA on Windows. Although I did not find if any spec mentions the purpose of Public folder on freedesktop, I think it should be used for data sharing in the local network. Common AppData on Windows serves different purpose: data available for all users on the same computer.
Dgame RC #2
Instead of opening a new post I announce here the release of the RC #2. Besides some minor bug fixes and some API changes (mostly to improve the Event handling) I've added also support for Joysticks and GameControllers. That should be the last big changes. If no more bugs appear (and the Derelict issue [https://github.com/DerelictOrg/DerelictSDL2/issues/44] is fixed) I will release the 0.5.0 version next sunday.
Standardpaths library
I wrote small library for getting standard paths (like Pictures, Music) Here's dub package http://code.dlang.org/packages/standardpaths And github repo https://github.com/MyLittleRobo/standardpaths You can see open issues on github. Please, participate in discussions if you're interested. The biggest problem now is OS X support https://github.com/MyLittleRobo/standardpaths/issues/4 You can generate documentation with dub build --build=docs.
Re: Dgame RC #2
On Sunday, 5 April 2015 at 16:39:34 UTC, Suliman wrote: Is it's possible to use Dgame for iOS game developing? AFAIK iOS LDC now support building iOS Apps. https://github.com/smolt/ldc-iphone-dev No. But because I also have no iOS device, I could not test well in this respect. My next step (version 0.5.1) would be to add touch events. Maybe (full) support for Android / iOS comes with 0.5.2
Re: Reggae v0.0.5 super alpha: A build system in D
On 4/4/15 12:56 PM, Dicebot wrote: Even if you consistently work with the same project it is incredibly rare to have a changeset contained in a single module. And if there are at least 5 changed modules (including inter-dependencies) it becomes long enough already. That's my experience as well. -- Andrei
Re: Dgame RC #2
Is it's possible to use Dgame for iOS game developing? AFAIK iOS LDC now support building iOS Apps. https://github.com/smolt/ldc-iphone-dev
