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.