RejectedSoftware Forums

Sign up

Proposal: Allow projectName.d along with "app.d"

first off, vibe.d is awesome, and one of the many key projects D
needs to thrive.

The specification calls for every project to have a 'app.d' file,
and thus if you run 'vibe build' the resulting binary is 'app'.

So I propose that an alternative be allowed: ProjectName.d
Easy to implement, Easy to check for.

I'll even fix the vibe script to do it, and submit a pull request.

PS-
Also to whomever runs the vpm registry,
http://registry.vibed.org/register
does not parse email addresses correctly. It claims that
"An email user name must not begin with a number."

My email begins with a number, my username does not. I think
it's checking both when it should not be.

It also claims that usernames must be at least 3 characters
when the username is 3 characters.

I'd offer to at least play with that, but it's not included in
the vibed.org github repo...

Re: Proposal: Allow projectName.d along with "app.d"

Am 19.08.2012 08:35, schrieb 1100110:

first off, vibe.d is awesome, and one of the many key projects D
needs to thrive.

Thanks!

The specification calls for every project to have a 'app.d' file,
and thus if you run 'vibe build' the resulting binary is 'app'.

So I propose that an alternative be allowed: ProjectName.d
Easy to implement, Easy to check for.

I'll even fix the vibe script to do it, and submit a pull request.

Sounds like a good idea. I think it would also make sense to support
passing the file name to the script explicitly to be able to support
multiple applications in one directory. If you want to do a pull request
for anything in this area, I'll be happy to merge it in.

PS-
Also to whomever runs the vpm registry, http://registry.vibed.org/register
does not parse email addresses correctly. It claims that
"An email user name must not begin with a number."

My email begins with a number, my username does not. I think it's
checking both when it should not be.

It also claims that usernames must be at least 3 characters when the
username is 3 characters.

It's currently using an ad-hoc check in vibe.utils.validation, that was
not given to much attention because the std.net.isemail module was not
working for DMD 2.059. So if DMD 2.060 is fixed in that regard, it'll be
a matter of commenting in some lines to hopefully have it fully
standards compliant. I'll look into that.

It's also planned to put the whole thing on github but some code
restructuring is necessary, because it currently uses a library that is
not supposed to be public. So the relevant code needs to be extracted
beforehand.

Re: Proposal: Allow projectName.d along with "app.d"

On Sunday, 19 August 2012 at 07:34:21 UTC, Sönke Ludwig wrote:

Am 19.08.2012 08:35, schrieb 1100110:

first off, vibe.d is awesome, and one of the many key projects
D
needs to thrive.

Thanks!

The specification calls for every project to have a 'app.d'
file,
and thus if you run 'vibe build' the resulting binary is 'app'.

So I propose that an alternative be allowed: ProjectName.d
Easy to implement, Easy to check for.

I'll even fix the vibe script to do it, and submit a pull
request.

Sounds like a good idea. I think it would also make sense to
support passing the file name to the script explicitly to be
able to support multiple applications in one directory. If you
want to do a pull request for anything in this area, I'll be
happy to merge it in.

Awesome, I'll see what I can do.
I actually came very close to suggesting that it accept passing a
filename.
But right now it does not appear that vibe.d is capable of simply
running the program. It would be really nice to support
caching the executable in ./bin/ or similar. But it seems vibe
is recompiled each time it is run.

Which definitely is not a problem, since dmd compiles so fast.
I just caught myself waiting for a few seconds and thought "come
on, its not like your compiling or any.... well, then nevermind."
=P

what exactly is the point of cp'ing and rm'ing vpm.d?

copy vpm.d to /tmp and make it deletable by anyone

cp -p "$VIBEPATH"/vpm.d /tmp/vpm.d
chmod 666 /tmp/vpm.d

run VPM and delete the vpm.d file again, VPM will output the

compile/run script
rdmd -g -w -property -I"$VIBEPATH"/../source $LIBS -Jviews
-Isource /tmp/vpm.d "$VIBEPATH" "$START_SCRIPT" $1 $2 $3 $4 $5 $6
$7 $8 $9
rm /tmp/vpm.d

would it not make more sense to simply rdmd "$VIBEPATH"/vpm.d &&
rdmd "$START_SCRIPT"? (pretend I typed all that out...)

I removed "rm /tmp/vibe.d" on my local machine and observed no
differences other than -2 seconds from the start time. A quick
once-through and I see no static enum mixins or anything strange
like that. I can't figure out a reason for not allowing rdmd to
cache that executable. Or the specific project executable for
that matter.

PS-
Also to whomever runs the vpm registry,
http://registry.vibed.org/register
does not parse email addresses correctly. It claims that
"An email user name must not begin with a number."

My email begins with a number, my username does not. I think
it's
checking both when it should not be.

It also claims that usernames must be at least 3 characters
when the
username is 3 characters.

It's currently using an ad-hoc check in vibe.utils.validation,
that was not given to much attention because the
std.net.isemail module was not working for DMD 2.059. So if DMD
2.060 is fixed in that regard, it'll be a matter of commenting
in some lines to hopefully have it fully standards compliant.
I'll look into that.

It's also planned to put the whole thing on github but some
code restructuring is necessary, because it currently uses a
library that is not supposed to be public. So the relevant code
needs to be extracted beforehand.

Yeah, I looked for it, but I figured it was something like that.

Re: Proposal: Allow projectName.d along with "app.d"

Am 19.08.2012 10:23, schrieb 1100110:

On Sunday, 19 August 2012 at 07:34:21 UTC, Sönke Ludwig wrote:

Am 19.08.2012 08:35, schrieb 1100110:

first off, vibe.d is awesome, and one of the many key projects D
needs to thrive.

Thanks!

The specification calls for every project to have a 'app.d' file,
and thus if you run 'vibe build' the resulting binary is 'app'.

So I propose that an alternative be allowed: ProjectName.d
Easy to implement, Easy to check for.

I'll even fix the vibe script to do it, and submit a pull request.

Sounds like a good idea. I think it would also make sense to support
passing the file name to the script explicitly to be able to support
multiple applications in one directory. If you want to do a pull
request for anything in this area, I'll be happy to merge it in.

Awesome, I'll see what I can do.
I actually came very close to suggesting that it accept passing a
filename.
But right now it does not appear that vibe.d is capable of simply
running the program. It would be really nice to support
caching the executable in ./bin/ or similar. But it seems vibe
is recompiled each time it is run.

Which definitely is not a problem, since dmd compiles so fast.
I just caught myself waiting for a few seconds and thought "come
on, its not like your compiling or any.... well, then nevermind."
=P

what exactly is the point of cp'ing and rm'ing vpm.d?

copy vpm.d to /tmp and make it deletable by anyone

cp -p "$VIBEPATH"/vpm.d /tmp/vpm.d
chmod 666 /tmp/vpm.d

run VPM and delete the vpm.d file again, VPM will output the

compile/run script
rdmd -g -w -property -I"$VIBEPATH"/../source $LIBS -Jviews
-Isource /tmp/vpm.d "$VIBEPATH" "$START_SCRIPT" $1 $2 $3 $4 $5 $6
$7 $8 $9
rm /tmp/vpm.d

would it not make more sense to simply rdmd "$VIBEPATH"/vpm.d &&
rdmd "$START_SCRIPT"? (pretend I typed all that out...)

I removed "rm /tmp/vibe.d" on my local machine and observed no
differences other than -2 seconds from the start time. A quick
once-through and I see no static enum mixins or anything strange
like that. I can't figure out a reason for not allowing rdmd to
cache that executable. Or the specific project executable for
that matter.

The problem is that rdmd will create temporary files within the same
directory as the .d file it compiles. On a *nix system, where vibe.d
might be installed in a read-only directory, this would cause rdmd to
fail. rdmd is also the reason why it currencly always compiles the
application - rdmd (or rather dmd -deps=...) does not detect function
local imports and string imports as dependencies. So the alternative to
spend some seconds vs. missing changes was considered the preferable
one. (The bug is partially mentioned in
http://d.puremagic.com/issues/show_bug.cgi?id=767#c3)

Workaround is to run "vibe build" and then only the generated ./app(.exe).

Because of these issues and also to improve compatibility with gdc and
ldc, I'm thinking about implementing a build script that does not rely
on rdmd.

PS-
Also to whomever runs the vpm registry,
http://registry.vibed.org/register
does not parse email addresses correctly. It claims that
"An email user name must not begin with a number."

My email begins with a number, my username does not. I think it's
checking both when it should not be.

It also claims that usernames must be at least 3 characters when the
username is 3 characters.

It's currently using an ad-hoc check in vibe.utils.validation, that
was not given to much attention because the std.net.isemail module was
not working for DMD 2.059. So if DMD 2.060 is fixed in that regard,
it'll be a matter of commenting in some lines to hopefully have it
fully standards compliant. I'll look into that.

It's also planned to put the whole thing on github but some code
restructuring is necessary, because it currently uses a library that
is not supposed to be public. So the relevant code needs to be
extracted beforehand.

Yeah, I looked for it, but I figured it was something like that.

Re: Proposal: Allow projectName.d along with "app.d"

Awesome, I'll see what I can do.
I actually came very close to suggesting that it accept
passing a
filename.
But right now it does not appear that vibe.d is capable of
simply
running the program. It would be really nice to support
caching the executable in ./bin/ or similar. But it seems vibe
is recompiled each time it is run.

Which definitely is not a problem, since dmd compiles so fast.
I just caught myself waiting for a few seconds and thought
"come
on, its not like your compiling or any.... well, then
nevermind."
=P

what exactly is the point of cp'ing and rm'ing vpm.d?

copy vpm.d to /tmp and make it deletable by anyone

cp -p "$VIBEPATH"/vpm.d /tmp/vpm.d
chmod 666 /tmp/vpm.d

run VPM and delete the vpm.d file again, VPM will output the

compile/run script
rdmd -g -w -property -I"$VIBEPATH"/../source $LIBS -Jviews
-Isource /tmp/vpm.d "$VIBEPATH" "$START_SCRIPT" $1 $2 $3 $4 $5
$6
$7 $8 $9
rm /tmp/vpm.d

would it not make more sense to simply rdmd "$VIBEPATH"/vpm.d
&&
rdmd "$START_SCRIPT"? (pretend I typed all that out...)

I removed "rm /tmp/vibe.d" on my local machine and observed no
differences other than -2 seconds from the start time. A quick
once-through and I see no static enum mixins or anything
strange
like that. I can't figure out a reason for not allowing rdmd
to
cache that executable. Or the specific project executable for
that matter.

The problem is that rdmd will create temporary files within the
same directory as the .d file it compiles. On a *nix system,
where vibe.d might be installed in a read-only directory, this
would cause rdmd to fail. rdmd is also the reason why it
currencly always compiles the application - rdmd (or rather dmd
-deps=...) does not detect function local imports and string
imports as dependencies. So the alternative to spend some
seconds vs. missing changes was considered the preferable one.
(The bug is partially mentioned in
http://d.puremagic.com/issues/show_bug.cgi?id=767#c3)

Workaround is to run "vibe build" and then only the generated
./app(.exe).

Because of these issues and also to improve compatibility with
gdc and ldc, I'm thinking about implementing a build script
that does not rely on rdmd.

Really? rdmd creates files in /tmp on my Arch machine...
I'll look into it.

I have a version that outputs the applicationName upon vibe build.
Needs cleaning, then I'll pull.$VIBEPATH

Re: Proposal: Allow projectName.d along with "app.d"

The problem is that rdmd will create temporary files within the same
directory as the .d file it compiles. On a *nix system, where vibe.d
might be installed in a read-only directory, this would cause rdmd to
fail. rdmd is also the reason why it currencly always compiles the
application - rdmd (or rather dmd -deps=...) does not detect function
local imports and string imports as dependencies. So the alternative to
spend some seconds vs. missing changes was considered the preferable
one. (The bug is partially mentioned in
http://d.puremagic.com/issues/show_bug.cgi?id=767#c3)

Workaround is to run "vibe build" and then only the generated
./app(.exe).

Because of these issues and also to improve compatibility with gdc and
ldc, I'm thinking about implementing a build script that does not rely
on rdmd.

Really? rdmd creates files in /tmp on my Arch machine...
I'll look into it.

I have a version that outputs the applicationName upon vibe build.
Needs cleaning, then I'll pull.$VIBEPATH <- why is that there?

Looking at the source for rdmd, I see:

private @property string myOwnTmpDir()
{

 version (Posix)
 {
     import core.sys.posix.unistd;
     auto tmpRoot = format("/tmp/.rdmd-%d", getuid());
 }

...
}

which is used literally everywhere that the tmpfile is mentioned.
/tmp/.rdmd-userid is literally hardcoded into rdmd.

I've been tracing rdmd for a few minutes, and it appears that the version
on github
does write anything to the current directory unless you specifically ask
it to(deps, etc).
I can submit a pull request for rdmd to check the current directory and
default to myOwnTmpDir if it is readonly.
Or we could always fork rdmd. It should be using the boost license and
it'd be an excellent starting point.

The executable and the object are both written to myOwnTmpDir afaict.

I do not know if it is still true, but since rdmd claims that it 'may get
folded into dmd',
It might be a good idea to support it 'officially' as long as it does what
is needed...
But that is your call to make.

rdmd also supports the --compiler=[anything] and gdc builds and installs
gdmd by default.
my version of ldc also includes a ldmd2 wrapper by default, although I do
not know if it is built with ldc like gdc.

It looks like everything includes a "map dmd opts to our opts" mode, so
that's a very good thing for us at least.

Re: Proposal: Allow projectName.d along with "app.d"

Am 19.08.2012 12:08, schrieb 1100110:

The problem is that rdmd will create temporary files within the same
directory as the .d file it compiles. On a *nix system, where vibe.d
might be installed in a read-only directory, this would cause rdmd to
fail. rdmd is also the reason why it currencly always compiles the
application - rdmd (or rather dmd -deps=...) does not detect function
local imports and string imports as dependencies. So the alternative
to spend some seconds vs. missing changes was considered the
preferable one. (The bug is partially mentioned in
http://d.puremagic.com/issues/show_bug.cgi?id=767#c3)

Workaround is to run "vibe build" and then only the generated
./app(.exe).

Because of these issues and also to improve compatibility with gdc
and ldc, I'm thinking about implementing a build script that does not
rely on rdmd.

Really? rdmd creates files in /tmp on my Arch machine...
I'll look into it.

I have a version that outputs the applicationName upon vibe build.
Needs cleaning, then I'll pull.$VIBEPATH <- why is that there?

Looking at the source for rdmd, I see:

private @property string myOwnTmpDir()
{

 version (Posix)
 {
     import core.sys.posix.unistd;
     auto tmpRoot = format("/tmp/.rdmd-%d", getuid());
 }

..
}

which is used literally everywhere that the tmpfile is mentioned.
/tmp/.rdmd-userid is literally hardcoded into rdmd.

I've been tracing rdmd for a few minutes, and it appears that the
version on github
does write anything to the current directory unless you specifically ask
it to(deps, etc).
I can submit a pull request for rdmd to check the current directory and
default to myOwnTmpDir if it is readonly.
Or we could always fork rdmd. It should be using the boost license and
it'd be an excellent starting point.

The executable and the object are both written to myOwnTmpDir afaict.

I just tested and you are right. The version that ships with DMD 2.060
keeps the source directory clean if it has to (unfortunately in that
case dependency tracking seems to get disabled but that's acceptable).

path:
https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L394
ignoring the error when failing to create the deps file:
https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L466

But since 2.059 still has the full issue, that copy logic probably has
to stay for a bit longer to not throw someone off who is not living on
the cutting edge.

I do not know if it is still true, but since rdmd claims that it 'may
get folded into dmd',
It might be a good idea to support it 'officially' as long as it does
what is needed...
But that is your call to make.

I was about to write a reasoning why rdmd is bad right now.. but rdmd
was improved recently and now compiles only once instead of making a
separate compile just to get the dependencies, reducing the arguments
against it to one ;)

So the only issue remaining is that local/string imports are not
tracked. In this case, if there is time, a hybrid solution may work to
improve the situation. A possible approach could be to collect the time
stamps of all .dt files and only when one of them changes is rdmd
invoked with --force.

rdmd also supports the --compiler=[anything] and gdc builds and installs
gdmd by default.
my version of ldc also includes a ldmd2 wrapper by default, although I
do not know if it is built with ldc like gdc.

It looks like everything includes a "map dmd opts to our opts" mode, so
that's a very good thing for us at least.

This would just still mean that rdmd has to be distributed or at least
needs some instructions for gdc/ldc - but maybe thats OK for someone who
is probably used to such customizations. A setting for the compiler in
/etc/vibe/vibe.conf, defaulting to 'dmd', would be a good idea anyways.

Re: Proposal: Allow projectName.d along with "app.d"

(I hope you don't mind my truncation.)

Looking at the source for rdmd, I see:

private @property string myOwnTmpDir()
{

 version (Posix)
 {
     import core.sys.posix.unistd;
     auto tmpRoot = format("/tmp/.rdmd-%d", getuid());
 }

..
}

which is used literally everywhere that the tmpfile is mentioned.
/tmp/.rdmd-userid is literally hardcoded into rdmd.

I've been tracing rdmd for a few minutes, and it appears that the
version on github
does write anything to the current directory unless you specifically ask
it to(deps, etc).
I can submit a pull request for rdmd to check the current directory and
default to myOwnTmpDir if it is readonly.
Or we could always fork rdmd. It should be using the boost license and
it'd be an excellent starting point.

The executable and the object are both written to myOwnTmpDir afaict.

I just tested and you are right. The version that ships with DMD 2.060
keeps the source directory clean if it has to (unfortunately in that
case dependency tracking seems to get disabled but that's acceptable).

path:
https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L394
ignoring the error when failing to create the deps file:
https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L466

But since 2.059 still has the full issue, that copy logic probably has
to stay for a bit longer to not throw someone off who is not living on
the cutting edge.

I do not know if it is still true, but since rdmd claims that it 'may
get folded into dmd',
It might be a good idea to support it 'officially' as long as it does
what is needed...
But that is your call to make.

I was about to write a reasoning why rdmd is bad right now.. but rdmd
was improved recently and now compiles only once instead of making a
separate compile just to get the dependencies, reducing the arguments
against it to one ;)

So the only issue remaining is that local/string imports are not
tracked. In this case, if there is time, a hybrid solution may work to
improve the situation. A possible approach could be to collect the time
stamps of all .dt files and only when one of them changes is rdmd
invoked with --force.

rdmd also supports the --compiler=[anything] and gdc builds and installs
gdmd by default.
my version of ldc also includes a ldmd2 wrapper by default, although I
do not know if it is built with ldc like gdc.

It looks like everything includes a "map dmd opts to our opts" mode, so
that's a very good thing for us at least.

This would just still mean that rdmd has to be distributed or at least
needs some instructions for gdc/ldc - but maybe thats OK for someone who
is probably used to such customizations. A setting for the compiler in
/etc/vibe/vibe.conf, defaulting to 'dmd', would be a good idea anyways.

I submitted a pull request for the changes.
Also the DFeed server is not having a good time with it's database.
I cc'd info@rejectedsoftware just in case.

Whew! I was worried that I just wasn't understanding things. =P
I obviously missed it's teething phase.

I think right now most people who install ldc or gdc are like me:
You already have the reference implementation, you're just curious to see
how well the reference implementation compares to other backends. So far
it's pretty favorable. dmd has the fastest compilation times.

You could not recompile everything every time with gdc... I now must go
time the differences...
...And gdc does NOT like something here.
...And ldc likes it even LESS.

Shrugs, I know that neither of them are fully caught up with the
complexity of dmd, (scoped imports, etc..)
I might also have outdated versions since I like recompiling them by hand.

ldc did catch a import core.sys.windows that probably needs to be
version'd though.