[Issue 3120] std.process.execv() pass arguments to programm incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=3120 --- Comment #1 from Alexey G golovanov_ale...@mail.ru 2009-07-01 04:28:48 PDT --- Created an attachment (id=408) -- (http://d.puremagic.com/issues/attachment.cgi?id=408) caller program using std.process.execv() -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3120] std.process.execv() pass arguments to programm incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=3120 --- Comment #2 from Alexey G golovanov_ale...@mail.ru 2009-07-01 04:29:33 PDT --- Created an attachment (id=409) -- (http://d.puremagic.com/issues/attachment.cgi?id=409) called programm, received parameters -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3121] New: recurrence does not generate the correct numbers
http://d.puremagic.com/issues/show_bug.cgi?id=3121
Summary: recurrence does not generate the correct numbers
Product: D
Version: 2.030
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch, wrong-code
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: k-fo...@onu.edu
Original:
1943struct Recurrence(alias fun, StateType, size_t stateSize)
1944{
1945StateType[stateSize] _state;
1946size_t _n;
1947
1948this(StateType[stateSize] initial) { _state = initial; }
1949
1950void popFront()
1951{
1952_state[_n % stateSize] = binaryFun!(fun, a, n)(
1953cycle(_state, _n), _n);
1954++_n;
1955}
1956
1957StateType front()
1958{
1959return _state[_n % stateSize];
1960}
1961
1962enum bool empty = false;
1963}
Line 1953 should be cycle(_state, _n), _n + stateSize);
Otherwise, the factorial example will print an initial 1, followed infinitely
by 0. Maybe the unittest should perform an assert rather than a print:
auto fact = recurrence!(n * a[n-1])(1);
assert( equal(take(10, fact), [1, 1, 2, 2*3, 2*3*4, 2*3*4*5, 2*3*4*5*6,
2*3*4*5*6*7, 2*3*4*5*6*7*8, 2*3*4*5*6*7*8*9][]) );
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3122] New: [patch] Adding support for fast and reliable build tools to the frontend
http://d.puremagic.com/issues/show_bug.cgi?id=3122
Summary: [patch] Adding support for fast and reliable build
tools to the frontend
Product: D
Version: 1.045
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: enhancement
Priority: P3
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: h3r3...@mat.uni.torun.pl
Created an attachment (id=410)
-- (http://d.puremagic.com/issues/attachment.cgi?id=410)
DMD frontend patch
Creating a reliable and fast build tool for D is a tricky business currently.
Bu[il]d gets away with partial parsing of D files and is reasonably fast, but
may miss some imports and doesn't guarantee proper incremental builds. ReBuild
parses the project's modules by using the DMD frontend on them, then figures
out which files to pass to the compiler. This approach may provide proper full
and partial builds, but is slow because of duplicating a lot of work.
Leonard Dahlmann and myself have been working on a build tool that achieves
both of these merits through a reasonable compromise. It requires a special
patch to the compiler so it emits dependencies between modules to a file during
the semantic analysis. This way it can track module dependencies and build
projects by usually only running the compiler once (twice in special cases).
Tracking module dependencies is critical, because when A imports B and its code
is conditionally generated upon some declarations in B, they both have to be
recompiled whenever B is changed.
The patch has already been included in LDC 0.9.1 and works great with the first
tool that can exploit the extra info the compiler provides thanks to it -
xfBuild ( http://wiki.team0xf.com/index.php?n=Tools.XfBuild ). Several people
have been testing it for more than a month with DMD as well on Linux and
Windows, using a custom-patched version of DMD. It's proving to be consistently
faster and more reliable than other build tools.
Summary of the diff:
The mars.c file is modified as to accept an additional switch -deps=filename.
This is to specify the file to which module dependencies are written in the
following format ( the real work is done in import.c ):
ImportDeclaration
::= BasicImportDeclaration [ : ImportBindList ] [ -
ModuleAliasIdentifier ] \n
BasicImportDeclaration
::= ModuleFullyQualifiedName ( FilePath ) : Protection [ static
] : ModuleFullyQualifiedName ( FilePath )
FilePath
- any string with '(', ')' and '\' escaped with the '\' character
The ImportBindList, ModuleAliasIdentifier, ModuleFullyQualifiedName
non-terminals are borrowed from
http://digitalmars.com/d/1.0/module.html#ImportDeclaration with the exception
of not allowing whitespace between substitution symbols
For example:
mod.ModA (mod\\ModA.d) : public : object
(c:\\prog\\dmd\\bin\\..\\import\\object.di)
mod.ModCommon (mod\\ModCommon.d) : public : object
(c:\\prog\\dmd\\bin\\..\\import\\object.di)
mod.ModA (mod\\ModA.d) : public : mod.ModCommon (mod\\ModCommon.d)
aliasedSelectiveImport (aliasedSelectiveImport.d) : public :
tango.text.convert.Integer
(c:\\prog\\dmd\\bin\\..\\import\\tango\\text\\convert\\Integer.d) :
parse,toString32 - Integer
The patch I've attached is Public Domain. It can be applied to DMD's source by
running:
patch -p0 -ui dmdDiff.patch
in the dmd/src directory, assuming DMD sources are in dmd/src/dmd. It's created
against DMD 1.045. It might be necessary to run 'dos2unix' on the files to be
patched (import.c, mars.c, mars.h) if doing it on a *nix.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2484] Templated classes have no moduleinfo
http://d.puremagic.com/issues/show_bug.cgi?id=2484
Justin mrjn...@gmail.com changed:
What|Removed |Added
CC||mrjn...@gmail.com
--- Comment #2 from Justin mrjn...@gmail.com 2009-07-01 10:56:19 PDT ---
Following Chris Wright's suggestion, I can confirm that this works (dmd.1.045):
import std.stdio,
std.moduleinit;
void main() {
auto foo = new Container!(int)();
foo.thingy = 3;
assert(foo.thingy == 3);
writefln(foo Classinfo.name : , foo.classinfo.name);
// Patch ModuleInfo
foreach (mod; ModuleInfo.modules)
{
if (mod.name == factory)
{
mod.localClasses ~= [foo.classinfo];
break;
}
}
auto bar = Object.factory(foo.classinfo.name);
assert(bar !is null);
writefln(bar Classinfo.name : , bar.classinfo.name);
}
class Container(T) { T thingy; }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2484] Templated classes have no moduleinfo
http://d.puremagic.com/issues/show_bug.cgi?id=2484
--- Comment #3 from Justin mrjn...@gmail.com 2009-07-01 11:31:25 PDT ---
Ok, with a bit of work, I thing I've improved on this technique a bit.
Here's factory.d:
module factory;
import std.stdio;
import container;
void main() {
auto foo = new Container!(int)();
foo.thingy = 3;
assert(foo.thingy == 3);
writefln(foo Classinfo.name : , foo.classinfo.name);
auto bar = Object.factory(foo.classinfo.name);
assert(bar !is null);
writefln(bar Classinfo.name : , bar.classinfo.name);
}
And container.d uses a template to insert the patching work:
module container;
import std.moduleinit;
const char[] CURRENT_MODULE = container;
class Container(T) {
T thingy;
mixin registerTemplatedClass;
}
public template registerTemplatedClass() {
static this() {
// Patch ModuleInfo
foreach (mod; ModuleInfo.modules)
{
if (mod.name == CURRENT_MODULE)
{
mod.localClasses ~= [this.classinfo];
break;
}
}
}
}
This could be improved if there's a way of getting the current module; I
couldn't find anything, so I created the constant CURRENT_MODULE which will
have to be placed in each module which uses the template.
Output is the expected:
foo Classinfo.name : container.Container!(int).Container
bar Classinfo.name : container.Container!(int).Container
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
