RejectedSoftware Forums

On Thu, 24 Apr 2014 04:27:48 GMT, Rikki Cattermole wrote:

So I'm currently exploring the idea of auto reloading of routes/models/templates ext. for Cmsed using dub.
I'm at the point of I've gotten the basic structure for directories.

tree of directory
build-deps.sh
compile.sh

The idea is that the dependencies are built as a shared library once. With it also a host runner is built.
The compile action is essentially setting up to run.

So as a summary of what I need:

• A shared library of every major dependency with (hopefully) no overlapping code. As well as its map file.
• A host application that will be used to run with.
• The ability to say here is the template of the entire software (for creation purposes like dub init).
• For all dependency sources like templates to be copied and available under lib (not possible quite yet).

The actual auto reloading capabilities will be handled by the host application.

I know this is designed for linux mostly right now, but I don't see why it cannot be done on Windows given the shared library support.

I don't believe this should be Cmsed specific hence why I'm asking what you guys think of this.
Which means there would need to be a way to specify the host app package/subpackage, dependencies like Cmsed/Dakka and that it is a web application. Which in theory would mean it is possible to use this for Vibe directly. Given the appropriate host application.

Unfortunately I can't really invest time for this at this point (although it's an interesting topic), but for the specific case of dynamically reloading Diet templates there has been a short thread a while ago. But one thing that will always be an issue is of course when data types get changed and thus existing memory structures get invalidated. For this reason I'm not entirely sure if this should be endorsed as a standard tool for the average library/framework user who may not be aware of such traps.

Am 24.04.2014 16:33, schrieb Rikki Cattermole:

On Thu, 24 Apr 2014 14:06:29 GMT, Sönke Ludwig wrote:

Unfortunately I can't really invest time for this at this point (although it's an interesting topic), but for the specific case of dynamically reloading Diet templates there has been a short thread a while ago. But one thing that will always be an issue is of course when data types get changed and thus existing memory structures get invalidated. For this reason I'm not entirely sure if this should be endorsed as a standard tool for the average library/framework user who may not be aware of such traps.

I'm okay in the case of Cmsed as I can make sure what data is registered will be deregistered. But I see your point in the general case.
As far as getting what I need to do this, how would you feel about a copyDirectories option? Its far from what I could use, but atleast I wouldn't have to write a new build manager.

I'll implement a way to access the directory of individual packages with
$variables in "postBuildCommands" and similar fields, which can then
be used with cp -r to achieve this. Instead of a simple
"copyDirectories", I'd like to implement something more powerful and
with better semantics at some point, but that still needs some thought.