Re: How do I iteratively replace lines in a file?
On 03/19/2011 04:51 PM, Andrej Mitrovic wrote:
> I'm trying to do something like the following:
>
> File inputfile;
> foreach (string name; dirEntries(r".\subdir\", SpanMode.shallow))
> {
> if (!(isFile(name)&& getExt(name) == "d"))
> {
> continue;
> }
>
> inputfile = File(name, "a+");
>
> foreach (line; inputfile.byLine)
> {
> if (line == "import foo.d")
> {
> inputfile.write("import bar.d"); // or ideally `line =
"import bar.d"`
> }
> }
> }
>
> That obviously won't work. I think I might need to use the `fseek`
function to keep track of where I am in the file, or something like that.
That's not a good idea with text files.
Even for binary files, the file must have a well defined format. It is
not possible to insert or remove bytes from a file due to low level
reasons. The file systems that I am aware of don't provide such interfaces.
And writing after fseek would overwrite existing data.
Like Jonathan M Davis said, the best is to read from the source and
write to the destination.
Ali
Re: Want to help DMD bugfixing? Write a simple utility.
> Jonathan M Davis wrote:
> > On Saturday 19 March 2011 18:04:57 Don wrote:
> >> Jonathan M Davis wrote:
> >>> On Saturday 19 March 2011 17:11:56 Don wrote:
> Here's the task:
> Given a .d source file, strip out all of the unittest {} blocks,
> including everything inside them.
> Strip out all comments as well.
> Print out the resulting file.
>
> Motivation: Bug reports frequently come with very large test cases.
> Even ones which look small often import from Phobos.
> Reducing the test case is the first step in fixing the bug, and it's
> frequently ~30% of the total time required. Stripping out the unit
> tests is the most time-consuming and error-prone part of reducing the
> test case.
>
> This should be a good task if you're relatively new to D but would
> like to do something really useful.
> >>>
> >>> Unfortunately, to do that 100% correctly, you need to actually have a
> >>> working D lexer (and possibly parser). You might be able to get
> >>> something close enough to work in most cases, but it doesn't take all
> >>> that much to throw off a basic implementation of this sort of thing if
> >>> you don't lex/parse it with something which properly understands D.
> >>>
> >>> - Jonathan M Davis
> >>
> >> I didn't say it needs 100% accuracy. You can assume, for example, that
> >> "unittest" always occurs at the start of a line. The only other things
> >> you need to lex are {}, string literals, and comments.
> >>
> >> BTW, the immediate motivation for this is std.datetime in Phobos. The
> >> sheer number of unittests in there is an absolute catastrophe for
> >> tracking down bugs. It makes a tool like this MANDATORY.
> >
> > I tried to create a similar tool before and gave up because I couldn't
> > make it 100% accurate and was running into problems with it. If someone
> > wants to take a shot at it though, that's fine.
> >
> > As for the unit tests in std.datetime making it hard to track down bugs,
> > that only makes sense to me if you're trying to look at the whole thing
> > at once and track down a compiler bug which happens _somewhere_ in the
> > code, but you don't know where. Other than a problem like that, I don't
> > really see how the unit tests get in the way of tracking down bugs. Is
> > it that you need to compile in a version of std.datetime which doesn't
> > have any unit tests compiled in but you still need to compile with
> > -unittest for other stuff?
>
> No. All you know there's a bug that's being triggered somewhere in
> Phobos (with -unittest). It's probably not in std.datetime.
> But Phobos is a horrible ball of mud where everything imports everything
> else, and std.datetime is near the centre of that ball. What you have to
> do is reduce the amount of code, and especially the number of modules,
> as rapidly as possible; this means getting rid of imports.
>
> To do this, you need to remove large chunks of code from the files. This
> is pretty simple; comment out half of the file, if it still works, then
> delete it. Normally this works well because typically only about a dozen
> lines are actually being used. After doing this about three or four
> times it's small enough that you can usually get rid of most of the
> imports. Unittests foul this up because they use functions/classes from
> inside the file.
>
> In the case of std.datetime it's even worse because the signal-to-noise
> ratio is so incredibly poor; it's really difficult to find the few lines
> of code that are actually being used by other Phobos modules.
>
> My experience (obviously only over the last month or so) has been that
> if the reduction of a bug is non-obvious, more than 10% of the total
> time taken to fix that bug is the time taken to cut down std.datetime.
Hmmm. I really don't know what could be done to fix that (other than making it
easier to rip out the unittest blocks). And enough of std.datetime depends on
other parts of std.datetime that trimming it down isn't (and can't be) exactly
easy. In general, SysTime is the most likely type to be used, and it depends
on Date, TimeOfDay, and DateTime, and all 4 of those depend on most of the
free functions in the module. It's not exactly designed in a manner which
allows you to cut out large chunks and still have it compile. And I don't
think that it _could_ be designed that way and still have the functionality
that it has.
I guess that this sort of problem is one that would pop up mainly when dealing
with compiler bugs. I have a hard time seeing it popping up with your typical
bug in Phobos itself. So, I guess that this is the sort of thing that you'd
run into and I likely wouldn't.
I really don't know how the situation could be improved though other than
making it easier to cut out the unit tests.
- Jonathan M Davis
Re: Want to help DMD bugfixing? Write a simple utility.
Jonathan M Davis wrote:
Jonathan M Davis wrote:
On Saturday 19 March 2011 18:04:57 Don wrote:
Jonathan M Davis wrote:
On Saturday 19 March 2011 17:11:56 Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with very large test cases.
Even ones which look small often import from Phobos.
Reducing the test case is the first step in fixing the bug, and it's
frequently ~30% of the total time required. Stripping out the unit
tests is the most time-consuming and error-prone part of reducing the
test case.
This should be a good task if you're relatively new to D but would
like to do something really useful.
Unfortunately, to do that 100% correctly, you need to actually have a
working D lexer (and possibly parser). You might be able to get
something close enough to work in most cases, but it doesn't take all
that much to throw off a basic implementation of this sort of thing if
you don't lex/parse it with something which properly understands D.
- Jonathan M Davis
I didn't say it needs 100% accuracy. You can assume, for example, that
"unittest" always occurs at the start of a line. The only other things
you need to lex are {}, string literals, and comments.
BTW, the immediate motivation for this is std.datetime in Phobos. The
sheer number of unittests in there is an absolute catastrophe for
tracking down bugs. It makes a tool like this MANDATORY.
I tried to create a similar tool before and gave up because I couldn't
make it 100% accurate and was running into problems with it. If someone
wants to take a shot at it though, that's fine.
As for the unit tests in std.datetime making it hard to track down bugs,
that only makes sense to me if you're trying to look at the whole thing
at once and track down a compiler bug which happens _somewhere_ in the
code, but you don't know where. Other than a problem like that, I don't
really see how the unit tests get in the way of tracking down bugs. Is
it that you need to compile in a version of std.datetime which doesn't
have any unit tests compiled in but you still need to compile with
-unittest for other stuff?
No. All you know there's a bug that's being triggered somewhere in
Phobos (with -unittest). It's probably not in std.datetime.
But Phobos is a horrible ball of mud where everything imports everything
else, and std.datetime is near the centre of that ball. What you have to
do is reduce the amount of code, and especially the number of modules,
as rapidly as possible; this means getting rid of imports.
To do this, you need to remove large chunks of code from the files. This
is pretty simple; comment out half of the file, if it still works, then
delete it. Normally this works well because typically only about a dozen
lines are actually being used. After doing this about three or four
times it's small enough that you can usually get rid of most of the
imports. Unittests foul this up because they use functions/classes from
inside the file.
In the case of std.datetime it's even worse because the signal-to-noise
ratio is so incredibly poor; it's really difficult to find the few lines
of code that are actually being used by other Phobos modules.
My experience (obviously only over the last month or so) has been that
if the reduction of a bug is non-obvious, more than 10% of the total
time taken to fix that bug is the time taken to cut down std.datetime.
Hmmm. I really don't know what could be done to fix that (other than making it
easier to rip out the unittest blocks). And enough of std.datetime depends on
other parts of std.datetime that trimming it down isn't (and can't be) exactly
easy. In general, SysTime is the most likely type to be used, and it depends
on Date, TimeOfDay, and DateTime, and all 4 of those depend on most of the
free functions in the module. It's not exactly designed in a manner which
allows you to cut out large chunks and still have it compile. And I don't
think that it _could_ be designed that way and still have the functionality
that it has.
The problem is purely the large fraction of the module which is devoted
to unit tests. That's all.
I guess that this sort of problem is one that would pop up mainly when dealing
with compiler bugs. I have a hard time seeing it popping up with your typical
bug in Phobos itself. So, I guess that this is the sort of thing that you'd
run into and I likely wouldn't.
Yes.
I really don't know how the situation could be improved though other than
making it easier to cut out the unit tests.
- Jonathan M Davis
Hence the motivation for this utility. The problem exists in all
modules, but in std.datetime it's such an obvious time-waster that I
can't keep ignoring it.
Re: Want to help DMD bugfixing? Write a simple utility.
> Jonathan M Davis wrote:
> >> Jonathan M Davis wrote:
> >>> On Saturday 19 March 2011 18:04:57 Don wrote:
> Jonathan M Davis wrote:
> > On Saturday 19 March 2011 17:11:56 Don wrote:
> >> Here's the task:
> >> Given a .d source file, strip out all of the unittest {} blocks,
> >> including everything inside them.
> >> Strip out all comments as well.
> >> Print out the resulting file.
> >>
> >> Motivation: Bug reports frequently come with very large test cases.
> >> Even ones which look small often import from Phobos.
> >> Reducing the test case is the first step in fixing the bug, and it's
> >> frequently ~30% of the total time required. Stripping out the unit
> >> tests is the most time-consuming and error-prone part of reducing
> >> the test case.
> >>
> >> This should be a good task if you're relatively new to D but would
> >> like to do something really useful.
> >
> > Unfortunately, to do that 100% correctly, you need to actually have a
> > working D lexer (and possibly parser). You might be able to get
> > something close enough to work in most cases, but it doesn't take all
> > that much to throw off a basic implementation of this sort of thing
> > if you don't lex/parse it with something which properly understands
> > D.
> >
> > - Jonathan M Davis
>
> I didn't say it needs 100% accuracy. You can assume, for example, that
> "unittest" always occurs at the start of a line. The only other things
> you need to lex are {}, string literals, and comments.
>
> BTW, the immediate motivation for this is std.datetime in Phobos. The
> sheer number of unittests in there is an absolute catastrophe for
> tracking down bugs. It makes a tool like this MANDATORY.
> >>>
> >>> I tried to create a similar tool before and gave up because I couldn't
> >>> make it 100% accurate and was running into problems with it. If someone
> >>> wants to take a shot at it though, that's fine.
> >>>
> >>> As for the unit tests in std.datetime making it hard to track down
> >>> bugs, that only makes sense to me if you're trying to look at the
> >>> whole thing at once and track down a compiler bug which happens
> >>> _somewhere_ in the code, but you don't know where. Other than a
> >>> problem like that, I don't really see how the unit tests get in the
> >>> way of tracking down bugs. Is it that you need to compile in a version
> >>> of std.datetime which doesn't have any unit tests compiled in but you
> >>> still need to compile with -unittest for other stuff?
> >>
> >> No. All you know there's a bug that's being triggered somewhere in
> >> Phobos (with -unittest). It's probably not in std.datetime.
> >> But Phobos is a horrible ball of mud where everything imports everything
> >> else, and std.datetime is near the centre of that ball. What you have to
> >> do is reduce the amount of code, and especially the number of modules,
> >> as rapidly as possible; this means getting rid of imports.
> >>
> >> To do this, you need to remove large chunks of code from the files. This
> >> is pretty simple; comment out half of the file, if it still works, then
> >> delete it. Normally this works well because typically only about a dozen
> >> lines are actually being used. After doing this about three or four
> >> times it's small enough that you can usually get rid of most of the
> >> imports. Unittests foul this up because they use functions/classes from
> >> inside the file.
> >>
> >> In the case of std.datetime it's even worse because the signal-to-noise
> >> ratio is so incredibly poor; it's really difficult to find the few lines
> >> of code that are actually being used by other Phobos modules.
> >>
> >> My experience (obviously only over the last month or so) has been that
> >> if the reduction of a bug is non-obvious, more than 10% of the total
> >> time taken to fix that bug is the time taken to cut down std.datetime.
> >
> > Hmmm. I really don't know what could be done to fix that (other than
> > making it easier to rip out the unittest blocks). And enough of
> > std.datetime depends on other parts of std.datetime that trimming it
> > down isn't (and can't be) exactly easy. In general, SysTime is the most
> > likely type to be used, and it depends on Date, TimeOfDay, and DateTime,
> > and all 4 of those depend on most of the free functions in the module.
> > It's not exactly designed in a manner which allows you to cut out large
> > chunks and still have it compile. And I don't think that it _could_ be
> > designed that way and still have the functionality that it has.
>
> The problem is purely the large fraction of the module which is devoted
> to unit tests. That's all.
>
> > I guess that this sort of problem is one that would pop up mainly when
> > dealing with compiler bugs. I have a hard time seeing it popping up with
> > your typical bug in Phobos itself. So, I guess that this i
Re: How do I iteratively replace lines in a file?
On 03/19/2011 05:51 PM, Andrej Mitrovic wrote:
I'm trying to do something like the following:
File inputfile;
foreach (string name; dirEntries(r".\subdir\", SpanMode.shallow))
{
if (!(isFile(name)&& getExt(name) == "d"))
{
continue;
}
inputfile = File(name, "a+");
foreach (line; inputfile.byLine)
{
if (line == "import foo.d")
{
inputfile.write("import bar.d"); // or ideally `line = "import
bar.d"`
}
}
}
That obviously won't work. I think I might need to use the `fseek` function to
keep track of where I am in the file, or something like that. File I/O in D is
no fun..
The only problem with your approach that a "line" is an abstract
concept. In a filesystem, there are only blocks of bytes. When you write
(flush) a byte to a file, the file transaction is actually an entire
block at a time (ext3 defaults to a 4k block, for example.) Lines are
just an array of bytes. When dealing with (relatively) fast memory,
modifying a line is pretty transparent. If you open a 1GB file and add
bytes at the very beginning, the filesystem is quite likely to write out
the entire file again.
I would suggest you write out to a temporary file, and then move the
file on top of the original file.
foreach(name ...)
{
inputfile = File(name, "r");
outputfile = File("/tmp/" ~ name, "a");
foreach(line ...)
{
do something to line
outputfile.write(line);
}
outputfile.close();
rename("/tmp" ~ name, name);
}
This will allow you to manipulate line by line, but it won't be
in-place. This is the type of approach that a lot of text editors take,
and a very common work around. If you were to encounter a language that
allows you to read and write lines iteratively and in-place like this in
a file, I'll bet you they are writing your changes to a temp file, and
moving the file over the top of the original at the end (perhaps when
you close()).
Other integral literals?
Do you ever desire literals for byte, ubyte, short and ushort integrals (beside the currently present for int, uint, long, ulong that are 10, 10U, 10L, 10UL)? Because of the more strict typing of templates in some situations I have had to write things like: cast(ubyte)100 Possible literals for byte, ubyte, short and ushort integrals (the byte ones aren't great): 10Y 10UY 10S 10US Are similar suffixes useful enough to have? Bye, bearophile
Re: How do I iteratively replace lines in a file?
Yeah, I've already done exactly as you guys proposed. Note however
that `inputfile` and `outputfile` should be declared inside the
foreach loop. Either that or you have to call `close()` explicitly. If
you don't do that, file handles don't get released, and you'll
eventually get back a stdio error such as "too many file handles
opened". You could loose files this way. I know this because it just
happened yesterday while testing. :p
Anywho, I needed a quick script to append a semicolon to import lines
because I managed to screw up some files when using sed to replace
some lines. It's a quick hack but worked for me:
import std.stdio;
import std.file;
import std.stdio;
import std.path;
import std.string;
void main()
{
File inputfile;
File outputfile;
string newname;
foreach (string name; dirEntries(r".", SpanMode.breadth))
{
if (!(isFile(name) && getExt(name) == "d"))
{
continue;
}
newname = name.idup ~ "backup";
if (exists(newname))
{
remove(newname);
}
rename(name, newname);
inputfile = File(newname, "r");
outputfile = File(name, "w");
foreach (line; inputfile.byLine)
{
if ((line.startsWith("private import") ||
line.startsWith("import")) &&
!line.endsWith(",") &&
!line.endsWith(";"))
{
outputfile.writeln(line ~ ";");
}
else
{
outputfile.writeln(line);
}
}
inputfile.close();
outputfile.close();
}
foreach (string name; dirEntries(r".", SpanMode.breadth))
{
if (getExt(name) == "dbackup")
{
remove(name);
}
}
}
Re: Problem with associative arrays
Jesse Phillips wrote:
Piotr Szturmaj Wrote:
Thank you for your very complete answers :)
I was trying to avoid multiple AA key lookups while appending many
elements to dynamic array. It's clear now, that with D2 semantics it's
better to first build an array and then assign it to AA.
What everyone else said, but you can get a pointer with 'in'
void main() {
uint[][uint] aa;
aa[5] = new uint[0];
auto temp = 5 in aa; // copy uint[] reference
*temp ~= 1;
assert(temp.length == 1 && (*temp)[0] == 1); // pass
assert(aa[5].length == 1 && aa[5][0] == 1); // pass
}
Yes, I already used pointers but in other way:
uint[]* temp = &aa[5]; // copy uint[] reference
and it worked the same as using 'in'. However, I wasn't sure it's
completely safe.
Re: Want to help DMD bugfixing? Write a simple utility.
Not very elegant but this should get the job done:
000 module strip;
001 import std.algoritm : countUntil;
002 import std.array: strip;
003 import std.file : read;
004 import std.string : splitlines;
005 import std.stdio: writeln;
006
007 void main(string[] args)
008 {
009 bool start = false;
010 bool end = false;
011
012 bool comment = false;
013 bool nested = false;
014
015 int lBrace, rBrace;
016
017 auto f = cast(char[]) read(args[1]);
018 auto file = splitlines(f);
019
020 foreach(ref ndx, line; file)
021 {
022 if(countUntil(strip(line), "//") == 0)
023 {
024 continue;
025 }
026
027 if(!comment && countUntil(line, "/+", != -1)
028 {
029 nested = true;
030
031 if(countUntil(line, "+/") != -1)
032 nested = false;
033
034 continue;
035 }
036
037 while(nested)
038 {
039 if(countUntil(file[ndx], "+/") != -1)
040 {
041 nested = false;
042 end = true;
043 goto endTest;
044 }
045 ndx++;
046 }
047
048 if(!nested && countUntil(line, "/*", != -1)
049 {
050 comment = true;
051
052 if(countUntil(line, "*/") != -1)
053 comment = false;
054
055 continue;
056 }
057
058 while(comment)
059 {
060 if(countUntil(file[ndx], "*/") != -1)
061 {
062 comment = false;
063 end = true;
064 goto endTest;
065 }
066 ndx++;
067 }
068
069 if(!end && countUntil(line, "unittest") != -1)
070 {
071 start = true;
072 }
073
074 if(!nested && start)
075 {
076 if(countUntil(line, "{") != -1)
077 {
078 lBrace++;
079 }
080
081 if(countUntil(line, "}") != -1)
082 {
083 rBrace++;
084 if(rBrace > 0 && lBrace == rBrace)
085 {
086 end = true;
087 lBrace = rBrace = 0;
088 }
089 }
090 }
091
092 if(!start)
093 writeln(line);
094
095 endTest:;
096 if(end)
097 {
098 start = false;
099 end = false;
100 }
101 }
102 }
cheers.
Re: Problem with associative arrays
Piotr Szturmaj Wrote: > Yes, I already used pointers but in other way: > > uint[]* temp = &aa[5]; // copy uint[] reference > > and it worked the same as using 'in'. However, I wasn't sure it's > completely safe. Depends on what you mean by "safe." In your example if 5 is not a key then a Range violation will be thrown. In mine null will be returned. Generally safety refers to not corrupting memory, and under that definition both of these are safe. Under the definition of "will not crash" no solution is safe.
Re: Other integral literals?
http://d.puremagic.com/issues/show_bug.cgi?id=4870
Re: Other integral literals?
On 03/20/2011 04:40 PM, bearophile wrote: Do you ever desire literals for byte, ubyte, short and ushort integrals (beside the currently present for int, uint, long, ulong that are 10, 10U, 10L, 10UL)? Because of the more strict typing of templates in some situations I have had to write things like: cast(ubyte)100 Possible literals for byte, ubyte, short and ushort integrals (the byte ones aren't great): 10Y 10UY 10S 10US Are similar suffixes useful enough to have? I would support this gratefully. I find it a big weakness of D that its literals do not map to a type. As for precise morphology, I'd prefere * instead of cryptic suffixes like 'Y' or 'S', numerous languages simply write the size : 8, 16, 32, 64: much nicer! A better idea would be to count the size in bytes: 1, 2, 4, 8. * else, use lowercase suffixes in std, because digits are full height (so that the suffix is more clearly told apart) * for the same reason, hex literals should use uppercase digits in std and '0x' prefix * ideally, I would use the sign to tell signed types apart (1 is unsigned, +1 is signed) * get rid of "1." and ".1" horrors! * get rif of 01 octal bug! Denis -- _ vita es estrany spir.wikidot.com
Re: Want to help DMD bugfixing? Write a simple utility.
The following patch addresses the following issues:
1) fixed improper handling of nested and multiline comments that
do not take up a complete line.
2) eliminate extra blank lines where unit tests and comments are
removed.
Replace lines 31 & 32 with:
# auto n = countUntil(line, "+/");
# if(n != -1 && n < line.lenght - 2)
# {
# nested = false;
# goto output;
# }
Replace lines 52 & 53 with:
# auto n = countUntil(line, "*/");
# if(n != -1 && n < line.lenght - 2)
# {
# comment = false;
# goto output;
# }
Replace lines 92 - 100 with;
# output:;
# if(!start)
# {
# if(line.length == 0 && !blankLine)
# {
# blankLine = true;
# writeln(line);
# }
# else if(line.length == 0 && blankLine)
# {
# goto endTest;
# }
#
# endTest:;
# if(end)
# {
# start = false;
# end = false;
# blankLine = true;
# }
# }
Re: Want to help DMD bugfixing? Write a simple utility.
Messed that up again: see embeded change. Wish I could just copy
and pase but that's not possible with my current setup.
== Quote from Tyro[a.c.edwards] (nos...@home.com)'s article
> The following patch addresses the following issues:
> 1) fixed improper handling of nested and multiline comments that
> do not take up a complete line.
> 2) eliminate extra blank lines where unit tests and comments are
> removed.
> Replace lines 31 & 32 with:
> # auto n = countUntil(line, "+/");
> # if(n != -1 && n < line.lenght - 2)
> # {
> # nested = false;
> # goto output;
> # }
> Replace lines 52 & 53 with:
> # auto n = countUntil(line, "*/");
> # if(n != -1 && n < line.lenght - 2)
> # {
> # comment = false;
> # goto output;
> # }
> Replace lines 92 - 100 with;
> # output:;
> # if(!start)
> # {
> # if(line.length == 0 && !blankLine)
> # {
> # blankLine = true;
> # writeln(line);
> # }
> # else if(line.length == 0 && blankLine)
> # {
> # goto endTest;
> # }
#else
#{
#writeln(line);
#}
> #
> # endTest:;
> # if(end)
> # {
> # start = false;
> # end = false;
> # blankLine = true;
> # }
> # }
Re: Other integral literals?
On Sun, 20 Mar 2011 19:37:45 +0100, spir wrote: * ideally, I would use the sign to tell signed types apart (1 is unsigned, +1 is signed) I hope you messed that one up. An unadorned int literal should be signed. Period. * get rid of 01 octal bug! Oh gods, yes. -- Simen
Re: How do I iteratively replace lines in a file?
On 03/20/2011 09:46 AM, Andrej Mitrovic wrote:
Yeah, I've already done exactly as you guys proposed. Note however
that `inputfile` and `outputfile` should be declared inside the
foreach loop. Either that or you have to call `close()` explicitly. If
you don't do that, file handles don't get released, and you'll
eventually get back a stdio error such as "too many file handles
opened". You could loose files this way. I know this because it just
happened yesterday while testing. :p
Anywho, I needed a quick script to append a semicolon to import lines
because I managed to screw up some files when using sed to replace
some lines. It's a quick hack but worked for me:
import std.stdio;
import std.file;
import std.stdio;
import std.path;
import std.string;
void main()
{
File inputfile;
File outputfile;
string newname;
foreach (string name; dirEntries(r".", SpanMode.breadth))
{
if (!(isFile(name)&& getExt(name) == "d"))
{
continue;
}
newname = name.idup ~ "backup";
if (exists(newname))
{
remove(newname);
}
rename(name, newname);
inputfile = File(newname, "r");
outputfile = File(name, "w");
foreach (line; inputfile.byLine)
{
if ((line.startsWith("private import") ||
line.startsWith("import"))&&
!line.endsWith(",")&&
!line.endsWith(";"))
{
outputfile.writeln(line ~ ";");
}
else
{
outputfile.writeln(line);
}
}
inputfile.close();
outputfile.close();
}
foreach (string name; dirEntries(r".", SpanMode.breadth))
{
if (getExt(name) == "dbackup")
{
remove(name);
}
}
}
Funny, I would have just fixed it with sed.
sed -ir 's/^(import.*)/\1;' *.d
Infact, I think sed is actually a great example of an application that
you apply a search and replace on a per-line basis. I'd be curious if
somebody knows how their '-i' flag (for in-place) works. Based on the
man page, I'll bet it opens the source read-only, and opens the
destination write-only like Andrej's example.
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
The SUFFIX option just renames the original instead of deleting at the end.
Re: Using D libs in C
Now I'm trying to do something more complicated, and it seems that while
importing works (it compiles and links fine), actually using the imported
things or pretty much anything that D offers makes the program crash. For
instance, in the D part:
---
module dpart;
import std.stdio;
version(linux)
{
int main()
{
return 0;
}
}
extern(C):
shared int ResultD;
int Process(int Value)
{
writeln("hai"); //<- Hangs here
printf("You have sent the value %d to the D library.\n", Value);
ResultD = (Value % 5);
string a; //Doesn't hang
a = "10";//Doesn't hang
printf("String %s", a); //<- Hangs here
return ResultD;
}
---
There is no readable error, just your ordinary program crash "report this to
Microsoft"... Any idea why it's like that?
Re: Want to help DMD bugfixing? Write a simple utility.
On 03/19/2011 06:11 PM, Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with very large test cases.
Even ones which look small often import from Phobos.
Reducing the test case is the first step in fixing the bug, and it's
frequently ~30% of the total time required. Stripping out the unit tests
is the most time-consuming and error-prone part of reducing the test case.
This should be a good task if you're relatively new to D but would like
to do something really useful.
-Don
Is there a copy of the official D grammar somewhere online? I wrote a
lexer for my Compiler class and would love to try and apply it to
another grammar.
-Kai Meyer
Re: Want to help DMD bugfixing? Write a simple utility.
On 20/03/2011 19:55, Kai Meyer wrote:
On 03/19/2011 06:11 PM, Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with very large test cases.
Even ones which look small often import from Phobos.
Reducing the test case is the first step in fixing the bug, and it's
frequently ~30% of the total time required. Stripping out the unit tests
is the most time-consuming and error-prone part of reducing the test
case.
This should be a good task if you're relatively new to D but would like
to do something really useful.
-Don
Is there a copy of the official D grammar somewhere online? I wrote a
lexer for my Compiler class and would love to try and apply it to
another grammar.
-Kai Meyer
As far as I know the documentation /is/ the official grammar
http://digitalmars.com/d/2.0/lex.html
Re: Want to help DMD bugfixing? Write a simple utility.
On 3/19/11 9:11 PM, Don wrote:
Here's the task:
Given a .d source file, strip out all of the unittest {} blocks,
including everything inside them.
Strip out all comments as well.
Print out the resulting file.
Motivation: Bug reports frequently come with very large test cases.
Even ones which look small often import from Phobos.
Reducing the test case is the first step in fixing the bug, and it's
frequently ~30% of the total time required. Stripping out the unit tests
is the most time-consuming and error-prone part of reducing the test case.
This should be a good task if you're relatively new to D but would like
to do something really useful.
-Don
Can it be done in Ruby? Or you need it in D?
