Re: Let's stop parser Hell

[Kai Meyer]

On 07/31/2012 03:27 PM, Dmitry Olshansky wrote:

On 31-Jul-12 20:10, Kai Meyer wrote:

On 07/05/2012 06:11 AM, Denis Shelomovskij wrote:

There are more and more projects requiring parsing D code (IDE plugins,
DCT and dfmt now).

We definitely need a _standard_ fast D parser (suitable as tokenizer).
We already have a good one at least in Visual D. Maybe dmd's parser is
faster. If so, it can be (easily?) rewritten in D. We also already have
some other parsers (in C# from Mono-D etc.).

What about to get one and call it standard?



I know I'm a little late coming into this conversation. This seems like
a nice thread to toss myself into. I've started working on a generic
lexer that is based off of a defined grammar.

As I read through the thread (I unfortunately don't have enough time to
read every post, but I skimmed through as many as I could, and read the
ones that seemed important), it seems like we need a parser in D that
can lex D, and provide a Range of tokens that could be consumed.

With some very minor tweaks, and a properly written Grammar class, I
basically have it already done. D was going to be one of the first
languages I would have written a definition for.

https://github.com/kai4785/firstfront

I haven't had time to look through Pegged, but there are some
differences in my approach that I can immediately see in Pegged's.

1) Pegged does compile-time or run-time code generation for your parser.
Mine is run-time only and regex based.
2) Pegged uses PEG format, which I have been introduced to through this
thread. One of my goals was to actually invent something like PEG. This
will save me time :)




I would love to receive some critical feedback on my approach as well as
the actual code base.


Okay. Critics go as follows:

First, as an author of std.regex I'm pleased that you find it suitable
to use it in lexer. :)

Still there is a BIG word of warning:

Lexer based on trying out an array of regexes until one will match is
NOT fast and not even close to fast ones. It is acceptable as proof of
concept/prototype kind of thing only.

To help this use case I though of making multi-regex matching a-la:
match(text, regex1, regex2, regex3...);
then lexing would be effectively a loop of form:

foreach(tok; match(text, regex1, regex2, regex3...)){
switch(tok[0]){//suppose match returns tuple - N of regex matched + the
usual piece of text
...
}
}
(with some glitches on /+ ... +/ and other non-regular stuff).

But until such time it's not to be used seriously in this context.

The reason is that each call to match does have some overhead to setup
regex engine, it's constant but it's huge compared to what usual lexers
typically do. The other thing is that you should use ctRegex for this
kind of job if you can (i.e. compiler doesn't explode on it).


(keep in mind I only glimpsed the source, will post more feedback later)



To build it, you'll need cmake, and cmaked2 from here:
http://code.google.com/p/cmaked2/wiki/GettingStarted

Or just dmd *.d :) I haven't tried to build it on Windows yet, but I
don't see anything that immediately jumps out as not cross-platform.
I've been working on it on both Fedora and CentOS.



rdmd for the win!




I cut my teeth on perl, so everything gets compared to perl in my mind.

In perl, I can 'precompile' a regular expression, so I can avoid some 
overhead. So something like this:


while(){
if($_ =~ m//){
some work;
}
}

Would end up re-compiling the regex on each line from STDIN. Perl uses 
the term "compiling" the regular expression, which may be different than 
what you call "setup regex engine".


Does/Can D's std.regex offer something like this? If not, I would be 
interested in why not.


-Kai Meyer

Re: Let's stop parser Hell

[Kai Meyer]

On 07/05/2012 06:11 AM, Denis Shelomovskij wrote:

There are more and more projects requiring parsing D code (IDE plugins,
DCT and dfmt now).

We definitely need a _standard_ fast D parser (suitable as tokenizer).
We already have a good one at least in Visual D. Maybe dmd's parser is
faster. If so, it can be (easily?) rewritten in D. We also already have
some other parsers (in C# from Mono-D etc.).

What about to get one and call it standard?



I know I'm a little late coming into this conversation. This seems like 
a nice thread to toss myself into. I've started working on a generic 
lexer that is based off of a defined grammar.


As I read through the thread (I unfortunately don't have enough time to 
read every post, but I skimmed through as many as I could, and read the 
ones that seemed important), it seems like we need a parser in D that 
can lex D, and provide a Range of tokens that could be consumed.


With some very minor tweaks, and a properly written Grammar class, I 
basically have it already done. D was going to be one of the first 
languages I would have written a definition for.


https://github.com/kai4785/firstfront

I haven't had time to look through Pegged, but there are some 
differences in my approach that I can immediately see in Pegged's.


1) Pegged does compile-time or run-time code generation for your parser. 
Mine is run-time only and regex based.
2) Pegged uses PEG format, which I have been introduced to through this 
thread. One of my goals was to actually invent something like PEG. This 
will save me time :)


I would love to receive some critical feedback on my approach as well as 
the actual code base.


To build it, you'll need cmake, and cmaked2 from here:
http://code.google.com/p/cmaked2/wiki/GettingStarted

Or just dmd *.d :) I haven't tried to build it on Windows yet, but I 
don't see anything that immediately jumps out as not cross-platform. 
I've been working on it on both Fedora and CentOS.


-Kai Meyer

Re: Damn C++ and damn D!

[Kai Meyer]

lambda instead of macro?

On 02/05/2012 07:57 AM, Timon Gehr wrote:

On 02/05/2012 03:53 PM, so wrote:

On Sunday, 5 February 2012 at 14:24:20 UTC, Timon Gehr wrote:


This should work:

#define DOTDOTDOT ...

template void fun(T a){
if(cond::value) {
auto var = make(a);
DOTDOTDOT;
}else{
auto tmp = make(a);
auto var = make_proxy(tmp);
DOTDOTDOT;
}
}


It won't work.
You now have two scopes and you have to repeat every line after "var"
for both scopes. Now you have to maintain both of them.


You just maintain the macro.


And this grows
exponentially for every new condition you have.



It certainly has limits. I completely agree that C++s generic
programming facilities are severely underpowered.

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Kai Meyer]

On 12/14/2011 09:51 AM, Alex Rønne Petersen wrote:

On 14-12-2011 14:11, Vladimir Panteleev wrote:

On Wednesday, 14 December 2011 at 11:07:22 UTC, Alex Rønne Petersen
wrote:

No point maintaining something that won't be used. I would also
imagine that it can't be long before Windows stops supporting 32-bit.


Windows still supports 16-bit apps (even 64-bit versions do, for some
rare exceptions)!


Hehe, fun fact. Though I doubt Microsoft actually cares enough to
maintain that support these days...

- Alex
I work for a company who has large enough contracts in Brazil who still 
run Windows NT to justify the continued use of Visual Studio 2005 to 
build software for NT and XP (though most of our Windows developers 
develop in VS2010 and then make sure it still works in VS2005). Apple 
has the opportunity to depreciate entire architectures because they 
aren't as ubiquitous as Microsoft products. They don't have billion 
dollar contracts that request they spend an extra 200 million a year to 
support their old stuff. At least that's the only justification I can 
think of to stay on older software.

Re: Why D const is annoying

[Kai Meyer]

On 12/10/2011 03:52 AM, Timon Gehr wrote:

On 12/10/2011 11:45 AM, bearophile wrote:

Timon Gehr:


Just slice the const array to get a range. The specialization for ranges
does not have the bug.

import std.algorithm;
void main() {
const arr = [1, 2, 3];
reduce!"a*b"(arr[]); // It works.
}


Wasn't arr a range already?

Bye,
bearophile


No, popFront is mutating and const(int[]) cannot be mutated.


Seems to me like popFront isn't the right tool for the job.

Re: std.json dynamic initialization of JSONValue

[Kai Meyer]

On 12/06/2011 02:42 PM, Adam D. Ruppe wrote:

I could swear I replied in the other group... must have gotten lost in the
series of tubes.

Anyway, I think std.json is easiest to use with a little template wrapper 
instead
of making JSONValues directly.

Try this on for size:

=

import std.json;
import std.conv;
import std.traits;

JSONValue toJsonValue(T)(T a) {
JSONValue val;
static if(is(T == typeof(null))) {
val.type = JSON_TYPE.NULL;
} else static if(is(T == JSONValue)) {
val = a;
} else static if(isIntegral!(T)) {
val.type = JSON_TYPE.INTEGER;
val.integer = to!long(a);
} else static if(isFloatingPoint!(T)) {
val.type = JSON_TYPE.FLOAT;
val.floating = to!real(a);
} else static if(is(T == bool)) {
if(a == true)
val.type = JSON_TYPE.TRUE;
if(a == false)
val.type = JSON_TYPE.FALSE;
} else static if(isSomeString!(T)) {
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
} else static if(isAssociativeArray!(T)) {
val.type = JSON_TYPE.OBJECT;
foreach(k, v; a) {
val.object[to!string(k)] = toJsonValue(v);
}
} else static if(isArray!(T)) {
val.type = JSON_TYPE.ARRAY;
val.array.length = a.length;
foreach(i, v; a) {
val.array[i] = toJsonValue(v);
}
} else static if(is(T == struct)) { // also can do all members of a 
struct...
val.type = JSON_TYPE.OBJECT;

foreach(i, member; a.tupleof) {
string name = a.tupleof[i].stringof[2..$];
static if(a.tupleof[i].stringof[2] != '_')
val.object[name] = toJsonValue!(typeof(member), 
R)(member, formatToStringAs, api);
}
} else { /* our catch all is to just do strings */
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
}

return val;
}

string toJson(T)(T a) {
auto v = toJsonValue(a);
return toJSON(&v);
}

/* usage example */
import std.stdio;
void main() {
writeln(toJson(["message": "Hello, world!"]));
}
==


Then, you can either use toJsonValue() to fill in an object similar
to what you were doing before, or use toJson() to skip right
to having a string from a struct, an associative array, or many
other D types.


I like it. Any reason something like this doesn't already exist in std.json?

-Kai Meyer

std.json dynamic initialization of JSONValue

[Kai Meyer]

I posted this on D.learn, but got no responses. I'm hoping it's because 
I'm asking the wrong crowd.


I'm finding std.json extremely well written, with one glaring exception.

I can't seem to figure out how to do this:

JSONValue root = JSONValue(null, JSON_TYPE.OBJECT);
root.object["first_object"] = JSONValue(null, JSON_TYPE.OBJECT);
root.object["first_string"] = JSONValue("first_string", JSON_TYPE.STRING);

which would decode to:

{"first_object":{},"first_string":"first_string"}

What I end up having to do is:
JSONValue root;
root.type = JSON_TYPE.OBJECT;
root.object["first_object"] = JSONValue();
root.object["first_object"].type = JSON_TYPE.OBJECT;
root.object["first_string"] = JSON_Value();
root.object["first_string"].type = JSON_TYPE.STRING;
root.object["first_string"].str = "first_string";

That just feels like I'm doing it wrong. Is there a way to dynamically 
initialize a JSONValue struct? If I try to intialize the JSONValue 
object with anything other than simply null, or empty string, I either 
get a compile error or a segfault at run-time.


root.object["first_object"] = JSONValue(null, JSON_TYPE.OBJECT);

compile error:
Error: overlapping initialization for integer

root.object["first_string"] = JSONValue("first_string");
run-time segfault.

Any ideas?

Re: A real Forum for D

[Kai Meyer]

On 11/29/2011 02:34 PM, Jonathan M Davis wrote:

On Tuesday, November 29, 2011 14:25:33 Kai Meyer wrote:

On 11/29/2011 01:08 PM, Walter Bright wrote:

On 11/29/2011 10:52 AM, Jonathan M Davis wrote:

On Tuesday, November 29, 2011 08:58:59 Sean Kelly wrote:

The iPhone news reader is passable but not great. I can't do usenet
from work though (firewall) so I've long since moved to using
Brad's email forwarder. With IMAP that keeps everything in sync
across machines too. Too
bad most email clients don't do the tree threaded view.


Kmail does (which is what I use), and I'm pretty sure that Thunderbird
does.


I can confirm that Thunderbird does.


Roundcube Webmail does it as well. Gmail does it too.


LOL. Not to be rude, but gmail doesn't even come close. Its idea of threads is
a joke as far as mailing lists go. It only works for conversations which are
between two people. It has no tree structure at all. Also, gmail never sends
you e-mails which were sent to the list by you, which further screws up the
tree even if you use a client which will show proper trees. gmail is horrible
for mailing lists IMHO.

- Jonathan M Davis
Well, just because it's horrible, doesn't mean it doesn't do it :) I 
have clients and co-workers that swear by the "threaded" nature of 
Gmail. I tend to agree with you, but that's because I've been using a 
"real" mail client for a decade. What you cut your teeth on is sometimes 
hard to get over :) Hence, my Thunderbird addiction.

Re: A real Forum for D

[Kai Meyer]

On 11/29/2011 01:08 PM, Walter Bright wrote:

On 11/29/2011 10:52 AM, Jonathan M Davis wrote:

On Tuesday, November 29, 2011 08:58:59 Sean Kelly wrote:

The iPhone news reader is passable but not great. I can't do usenet from
work though (firewall) so I've long since moved to using Brad's email
forwarder. With IMAP that keeps everything in sync across machines
too. Too
bad most email clients don't do the tree threaded view.


Kmail does (which is what I use), and I'm pretty sure that Thunderbird
does.


I can confirm that Thunderbird does.

Roundcube Webmail does it as well. Gmail does it too.

There's no reason why we can't use the email forwarder to get a 
web-based threaded view of the news group. But it seems a bit of a hoop 
to jump through for new users.


I think the major complaint is new recruits, and what they are 
comfortable with. It sounds more and more like the features Walter wants 
are not readily available to individuals stopping by for the first 10 
times, unless they are willing to but some time into figuring out (for 
themselves) which tools are best to use news groups with.


I think the new comer is becoming more and more web-centric, and wants 
to have everything run in the browser. I have a hard time convincing 
people to use Thunderbird over Gmail or RoundCube, because they may want 
to check their email on more than one computer, and that next computer 
may not have Thunderbird already setup.


If we want to make new comers more comfortable, there is an argument for 
having a Forum for them. New comers are often sent to D.learn to start, 
and D.learn seems to carry much different conversations than the D 
newsgroup. They tend to be question and answer, which a Forum is great 
for (dare I say created for.) While I sympathize with Walter's desire to 
not create a separate community, there is already a division between 
those who are comfortable posting on D, and those comfortable posting on 
D.learn. I think converting D.learn to a Forum could benefit the 
community by being more attractive to younger/newer programmers. When 
they want to get serious, they can spend the 10 minutes it takes to 
configure an NNTP client, and feel it was time worth spent.


-Kai Meyer

Re: A real Forum for D

[Kai Meyer]

On 11/27/2011 10:41 AM, alex wrote:

Hi folks,

I just wondered why there still is this uncomfortable and obviously outdated 
newsgroup software in use.

Perhaps it'd be more contemporary to have a 'real' browser-based forum to which 
everyone can register and post D-related questions&answers.

So, my recommendation would be to establish a forum based on phpBB or a similar 
framework software (btw, it's free and open source, so don't worry about 
possible
costs!) at forum.d-programming-language.org


To give D a further community 'push', I and a friend of mine really would like 
to set up all required things if wanted.

The reason I'm asking the newsgroup directly is to have the forum that can be 
reachedunder the official D internet URL, so that it won't be a 'third-party' 
driven one
or something like that.


Even if this idea should be a bit too 'large', please do fix the http interface 
for the D main newsgroup thread - it's not working for me and only gives back a
connection timeout.


Imagine sitting in a movie theatre after the movie is finished. Everyone 
wants to talk about the same movie. What if you had to look through each 
comment made in the theatre in chronological order, instead of just 
turning to the person you came with and talking to them?


To me, Forums are not meant for discussion. They are a means to 
broadcast an opinion or question, and ask for feedback.


Walter appears to be in favor of having a discussion medium. I think 
that the D.learn newsgroup could be easily (and probably more 
productivly) converted to a web-based Forum. Even though it may cause a 
small division between communities, it would provide a more comfortable 
entry point for new developers who are more accustomed to Forums. The 
Forum could have a read-only view into the news group to expose the 
Forum Users to the language developer community and lessen the gap 
between the two groups.


My 2 cents.

Re: Just starting out

[Kai Meyer]

On 10/13/2011 01:37 AM, J Arrizza wrote:

Thanks for all the replies. Seems straightforward enough:

1) Phobos is it.
2) DMD is the clear winner
3) Eclipse is a hog - knew that. I really only like a couple of things
in it. A big one for me is the source formatting. For some reason,
having to hit the space bar 4,000 times every hour just isn't my cup of
tea.

The formatter for java set a nice high standard for configurability that
I was hoping a D plug-in would also have. I had issues with installing
descent on Linux (worked ok in windows for some reason), but I'll give
it another shot on Indigo. If that doesn't play, I'll stick with
UltraEdit (great editor, got a life-time license for it).

John



On Wed, Oct 12, 2011 at 11:42 PM, Jacob Carlborg mailto:d...@me.com>> wrote:

On 2011-10-13 01:43, J Arrizza wrote:

Hi,

I'm just starting out in D, read the book, tried a Hello World, and
wrote a few unit tests. I'm ready for the next step.

I'd like to begin writing some more complex D code which I want
to use
not only as a test bed to investigate D itself to a deeper level
but if
it's successful to eventually use it as the beginnings of a
toolkit for
our internal use.

I'm looking for some recommendations from folks with lots of
experience
in D:

1) Which to use: Phobos, Tango, or Tangobos? It makes sense for
us to
use D2 so this seems to preclude Tango for now. Correct?


Most people will definitely say D2 and Phobos. I still think Tango
is better and for the time being that means D1. I also think that
some parts of D2 is not quite ready yet.


Are there plans to merge or standardize on one of these? Phobos and
Tango seem to be incompatible with each other at this point.


Yes, Tango and Phobos are incompatible. There are someone/a couple
of people working on porting Tango to D2. I think that port will use
druntime, meaning it will be compatible with Phobos.

My worry here is if we choose the wrong underlying library we end up
having to re-write a lot of code later on.

2) Which compiler? DMD, GDC or something else?  We use Ubuntu
10.04, 64
bit as our development platform. I'm assuming the gc is in all the D
compilers.


DMD is a good compiler for development. It's the fastest available D
compiler (as far as I know). It's always up to date, LDC and GDC can
be a release behind DMD. I don't know what's best for production. I
usually hear people saying that LDC and GDC is better than DMD but I
haven't done any benchmarking myself.


3) DDT (eclipse plugin) seems relatively green. Any other
suggestions
for an IDE. Not a big deal for us, but it's nice to have source
formatting. The DDT folks indicated that that feature is a long
way off
for them.


There's an older plugin for Eclipse called Descent. It has source
formatting and a couple of more nice and interesting features, like
compile time debugging. I also shows both syntax and semantic errors
(semantic errors are disable by default). I still uses this plugin
but I can be quite slow and unfortunate it's not maintained anymore.
I still recommend you take a look at it.

http://dsource.org/projects/__descent


Otherwise I use TextMate on Mac OS X. There's also a similar
application called E (text editor) available on Windows (in the
works for Linux too). It's compatible with TextMate's bundles.

Thanks,
John



--
/Jacob Carlborg




--
John
blog: http://arrizza.blogspot.com/
web: http://www.arrizza.com/


VIM + gnu make has done everything I've needed it to do so far, but the 
biggest project I've done so far was only ~10k lines long.

Re: D in the TIOBE top

[Kai Meyer]

On 09/14/2011 11:24 AM, Andrei Alexandrescu wrote:

On 09/14/2011 12:18 PM, Marco Leise wrote:

Am 14.09.2011, 15:02 Uhr, schrieb Andrei Alexandrescu
:


On 9/14/11 6:22 AM, bioinfornatics wrote:

It is a good news. This news appear in same time where fedora add D2
in Fedora 16:
https://fedoraproject.org/wiki/Features/D2_programming

:-)

next step create powerfull free and open source library, more
documentation and
tutorial on the web


I wonder whether it's okay to post this on reddit.

Andrei


You would definitely need a straw man to do this.


The thing about that piece is I'm not sure for how long D has been in
Fedora, so I wouldn't know whether it's really news, and how noteworthy
(e.g. is Fedora picky in adopting new packages etc).


Oh btw I hope to get a
recent DMD into Gentoo again soonish.


That would be great!


Andrei


Fedora will pick up just about any package that has a package maintainer 
committed to keep it up to date. It's pretty open. I think I remember 
LDC showing up in Fedora 15. With 9 month(ish) release cycles, I would 
guess that some interested party has been trying to get LDC into Fedora 
for at least a year at this point.

Re: Thoughts on std.system.OS

[Kai Meyer]

On 08/14/2011 01:20 PM, Jonathan M Davis wrote:

On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis

wrote:

Personally, I'm
inclined to drop the Os enum along with the os and os_major and os_minor
variables, because I just don't think that we can get them to be correct
enough of generally useful enough to be worth having. It's too
OS-specific to
be trying to handle it in an OS-generic manner like that.


Looking at the code again, I noticed there's a Family enum, which seems to
me closer to what the OS enum should really be. I think Family should just
replace OS.

I don't agree that we should just drop version numbers. As I said before,
they can be useful for users. They can also be useful for programs that
care only about a certain OS family.

What do you think about this?

https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


I'm not at all convinced that it makes any sense to try and handle OS version
numbers in a system-independent manner. You have to know what OS you're on for
them to mean anything, in which case, why try and handle them in an OS-
independent manner?

On Linux, the version number is probably pointless. It's the version number
for the kernel. Most programs won't care one whit about that. If they care
about a version number, odds are that it's the version number of some program
or library on the system that they're using, not the kernel. And in general,
if you care, you care when you compile, not when you run the program. I would
expect FreeBSD to be the same. I don't know about Mac OS X.


I would argue against using the kernel version as the "OS Version". It's 
as useless as the NTKernel version to most programmers. I would argue 
that there is a good case for determining if you are on a Debian or 
Redhat based system. I actually think this sort of system-independant OS 
version detection is very valuable. I'm on different linux systems all 
the time. Identifying which distro is running is both simple and 
necessary before doing any systems administration. I do and want to 
continue to use D for systems adminsitration. The most difficult 
programming tasks are making the same program work the same way on 
different platforms. The more tools D can provide that give the 
programmer this information in an easy to consume format, the more 
popular D will be for cross-platform programming.




However, the case of Windows is _completely_ different from the others. Windows
version numbers mean _nothing_ to most people. They want stuff like Windows XP
and Windows 7. They'd probably expect an enum with the primary versions of
Windows in it. But since there _are_ other stray versions of Windows, and the
actual version number could matter for some stuff, finding a clean way to deal
with Windows' GetVersion call and dealing with the full version number and at
the same time dealing with the more commonly useful enum needs to happen (as
part of that, the enum would probably use the version numbers for the values
of its enum members similar to what you did with you constants). It's all
_very_ different from Linux, FreeBSD, and Mac OS X. And I don't see _any_
reason to try and treat them the same.

If we're going to deal with operating system versions, it should be in a
system-specific manner and _not_ in std.system.

Endian is effectively a runtime enum for the versions which deal with
endianness. Family is effectively the runtime enum for the OS versions. As
such, I think that both have some value. I do think that you have a valid
point that OS would be a better name for Family, so I'll make that change in
my pull request. However, I do _not_ think that it makes sense to try and do
getOSVersion like you're doing.

We need to find a clean, simple and yet flexible way to deal with version
numbers for Windows and put that in std.windows or core.windows somewhere -
preferably in core IMHO (and actually I'd be kind of inclined to put
std.system  in core rather than std given what it's doing). If something
similar for the Mac makes sense, then we can add that somewhere. For Linux and
FreeBSD, I expect that there's no point - particularly since I'm not sure that
it's quite safe to trust uname to be consistent anyway. But I do not think
that putting that in std.system in an OS-independent way makes sense.

- Jonathan M Davis

Re: Thoughts on std.system.OS

[Kai Meyer]

On 08/13/2011 11:16 AM, Jonathan M Davis wrote:

On Saturday, August 13, 2011 14:49:13 Vladimir Panteleev wrote:

On Sat, 13 Aug 2011 14:23:35 +0300, Jonathan M Davis

wrote:

It does on at least some distros.


TIL...


Except that you need useful, understandable version numbers to make
sense. 2.6
and 3.0 are virtually meaningless on Linux (which would be the major and
minor
number). Maybe the minor number will mean something with the 3 series,
but
we've had 2.6 for years now, and there's an enormous difference between
2.6.3
and 2.6.33.


Perhaps make the version number a dynamic array?


Even worse, major and minor numbers don't mean _anything_ on Windows.
What are
you going to give? The NT kernel version?


By the way, the Windows versions in the OS enum are very incomplete - only
major client versions are listed.

A rather large variety of Windows versions and editions exists, see for
example:

http://msdn.microsoft.com/en-us/library/ms724429(v=vs.85).aspx
http://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Considering the large variety, I think it would be a mistake to try to
keep track of all Windows versions in an enum. I would like to suggest to
replace all Windows versions in the OS enum with a single "Windows"
entity, and add some constants or enums for common Windows versions to
allow comparisons. For example:

if (os_major>   OS_MAJOR_WINDOWS_XP ||
 (os_major == OS_MAJOR_WINDOWS_XP&&  os_minor>= OS_MINOR_WINDOWS_XP))
{
  // This is Windows XP or higher
}

Going even further, a version structure supporting comparison operators
would make the above simpler. (Or are regular dynamic arrays suitable for
this?)


There are a large variety of Linux distros as well, and we can't cover all of
them, so I'm not sure that the fact that there are lots of stray versions of
Windows depending on how you count them merits handling Windows like that.
However, it _is_ a bit odd to treat each version of Windows as a separate OS
in the enum when none of the other OSes have more than one version in the
list.



That's why you let the community keep the enum up to date. Offer support 
for the major distros (My list would include RedHat, Debian, SuSE, and 
their derivatives (Fedora, Ubuntu, openSuSE). Once you have those 6 
(that's not a big number), it's not hard to let the community add their 
favorite distro (like Arch).



As for doing something like you suggest with the os_major and os_minor
numbers, it does seem kind of messy. If all you want is comparison, you can do
that with the existing enum, and it covers all of the Windows versions that
most people will care about.

The situation definitely requires some consideration though. And it should
probably be redesigned a bit.

- Jonathan M Davis

Re: Thoughts on std.system.OS

[Kai Meyer]

On 08/13/2011 04:23 AM, Jonathan M Davis wrote:

On Saturday, August 13, 2011 13:18:29 Vladimir Panteleev wrote:

On Sat, 13 Aug 2011 08:08:09 +0300, Jonathan M Davis

wrote:

Thoughts on std.system.OS? Is there a good reason to leave it? In
principle, it's a nice idea, but I just don't see how it can deliver.
And if it can't deliver, it should be removed IMHO. What do you think?


Why not use uname on non-Windows systems, and report the kernel version?


That's certainly a thought, but that could get entertaining to get the enum
values from that. As long as the various distros are consistent in their
naming schemes between their releases though, that _should_ be possible. That
may be worth trying though.

- Jonathan M Davis


Yup, it's easy:


http://mattiasgeniar.be/2008/10/05/how-to-find-out-your-current-distribution-version/

Between Debian and RedHat and their derivatives (ie Ubuntu and Fedora 
respectively), you should hit nearly all distributions.


I think /etc/issue is the most reliable place to look for distribution 
information, and then fall back to the other files.

Re: DMD with older versions of Linux

[Kai Meyer]

On 08/03/2011 06:05 PM, Adam Davis wrote:

Dreamhost doesn't provide an updated glibc in my vps server. Is it possible to
run dmd on somewhat outdated linux distributions?

I tried running dmd from the distribution but got:

./dmd: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./dmd)

The instaled versions are:

$ ldd --version
ldd (GNU libc) 2.7

$ uname -a
Linux ps54363 2.6.33.7-vs2.3.0.36.30.4 #23 SMP Tue Sep 28 05:47:35 PDT 2010
x86_64 GNU/Linux


If it's not possible to run the standard DMD package, could I build it from
source using those versions?

Thank you


You're using the 32bit binary on a 64bit machine. It's possible they do 
not have 32bit glibc, or possibly 32bit glibc-compat installed. Try 
using the 64bit binary. (If you were using the 64bit library, it would 
have thrown an error on /lib64/libc.so.6 .)


Also, 2.6.33 is not really "old". 2.6.18 would be "old". :) RHEL 6, just 
released last November is 2.6.32.


-Kai Meyer

Re: D users on Google+

[Kai Meyer]

On 07/13/2011 02:52 AM, simendsjo wrote:

Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.


I'll take invites from anybody in the D community as well (except you'll 
probably find me @ gnukai.com). I should be the only non German author 
with my name :)

Broken link

[Kai Meyer]

On the main page:
http://www.d-programming-language.org/index.html

Click on "Howtos" in the left menu. That takes you to the first howto:
http://www.d-programming-language.org/windows.html

Then the Howto link called "Port­ing to 64 Bits" is broken:
http://www.d-programming-language.org/32-64-portability.html


Preliminary testing showed that the same "Porting to 64 Bits" is broken 
on all of the howto pages.


-Kai Meyer

Re: Best article vote tally - WE HAVE TWO WINNERS!

[Kai Meyer]

On 06/09/2011 01:21 PM, Steven Schveighoffer wrote:

On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright
 wrote:


On 6/9/2011 11:03 AM, Robert Clipsham wrote:

So there is going to be a next one?


Yes, maybe in 6 months or so. I'm very happy with how this one turned
out.

But next time we need to devise a tie-breaking rule. Any suggestions?
A runoff?


We're all developers here, I think people might be open to an instant
runoff:

http://en.wikipedia.org/wiki/Instant-runoff_voting

Essentially, you rank the articles 1 to x, and then the algorithm
figures out the winner. It's still possible to have a tie, but unlikely.

I think for the next time, someone should write a newsgroup-to-vote
program that automatically counts the votes (must be in D of course!)


BTW, there's nothing in the rules preventing an author from tooting
his own horn and doing a bit of marketing of their article(s) for votes!


We're developers, not politicians :) If you allow this, then we'll have
to start creating youtube ads showing the other articles' past records
of infidelity and such, and it just turns ugly.

-Steve


I second the vote for IRV.

Re: Building DMD on Linux with Windows Domain Logins

[Kai Meyer]

On 05/24/2011 12:34 AM, KennyTM~ wrote:

On May 24, 11 12:55, Walter Bright wrote:

On 5/23/2011 4:10 PM, KennyTM~ wrote:

On May 24, 11 06:37, Kai Meyer wrote:

Funny thing happened today. I tried building DMD from source, and got
this:

dmd: libelf.c:171: void OmToHeader(Header*, ObjModule*): Assertion `len
<= 6' failed.

Digging around, and it appears that my user ID can only be 6 characters
long. Doh! I happen to be on a RHEL 6 workstation that can authenticate
users via a Windows Domain Controller (using samba + winbind). My
smb.conf looks has these two lines:

idmap uid = 16777216-33554431
idmap gid = 16777216-33554431

Which is to say "If a uid or gid appears on the system, use winbind to
resolve to a name".

On my machine, my user looks like this:
[kai.meyer@kai-rhel6 BUILD]$ id
uid=16777216(kai.meyer) gid=16777221(domain users)
groups=16777221(domain
users),16777223(SENSORED),16777224(SENSORED),16777225(SENSORED),16777226(SENSORED)





That's right. My UID is 8 characters long.

Are we interested in accommodating UID and GID's that are this big?

-Kai Meyer


An old bug (e.g.
http://www.mail-archive.com/dmd-internals@puremagic.com/msg00402.html).
The

'uid' > 6 digit problem has been worked-around, but the 'gid' hasn't.



Post to bugzilla!


http://d.puremagic.com/issues/show_bug.cgi?id=6050


On the bright side, the rpm builds on RHEL6 with no problems if I build 
it with a UID/GID of 500 :)


-Kai Meyer

Building DMD on Linux with Windows Domain Logins

[Kai Meyer]

Funny thing happened today. I tried building DMD from source, and got this:

dmd: libelf.c:171: void OmToHeader(Header*, ObjModule*): Assertion `len 
<= 6' failed.


Digging around, and it appears that my user ID can only be 6 characters 
long. Doh! I happen to be on a RHEL 6 workstation that can authenticate 
users via a Windows Domain Controller (using samba + winbind). My 
smb.conf looks has these two lines:


   idmap uid = 16777216-33554431
   idmap gid = 16777216-33554431

Which is to say "If a uid or gid appears on the system, use winbind to 
resolve to a name".


On my machine, my user looks like this:
[kai.meyer@kai-rhel6 BUILD]$ id
uid=16777216(kai.meyer) gid=16777221(domain users) 
groups=16777221(domain 
users),16777223(SENSORED),16777224(SENSORED),16777225(SENSORED),16777226(SENSORED)


That's right. My UID is 8 characters long.

Are we interested in accommodating UID and GID's that are this big?

-Kai Meyer

Re: DSO with DMD 2.052 on Linux?

[Kai Meyer]

On 05/02/2011 03:10 PM, Jonathan M Davis wrote:

Is dynamic linking supported on Linux with DMD 2.052 (and D2 in general)?

I am not talking about Phobos, just modules which I want to compile as DSO.

There is -fPIC switch to DMD - does it work as intended?

PS: gdc is not an option...


The short answer: no.

As for the long answer, someone else could answer far better than I could.
IIRC, the main problem is the runtime. It has issues when you try and split
your D code with .so files (I believe that you end up with multiple instances
of the runtime). It _might_ work if you don't use the garbage collector at
all, but there could be other issues. I don't remember exactly what all of the
problems are. But regardless, don't expect shared libraries to work at the
moment.

Getting shared libraries to work is near the top of the TODO list, but it
hasn't been done yet.

- Jonathan M Davis


I thought I saw somewhere that you simply have to have the runtime 
initialized before calling into the shared library (which is done for 
you when dmd is supposed to produce an executable):


http://www.digitalmars.com/d/2.0/phobos/core_runtime.html

I may be incorrect too :)

-Kai Meyer

Re: How about a Hash template?

[Kai Meyer]

On 04/29/2011 07:13 AM, Jacob Carlborg wrote:

On 2011-04-28 21:46, Timon Gehr wrote:

Andrei Alexandrescu wrote:

On 4/28/11 11:00 AM, Alexander wrote:

On 28.04.2011 17:46, Andrej Mitrovic wrote:


It works, but it makes the if statement ugly again. :)


Well, just a bit - still much better than (var == "..." || var =
"...">||

var == "..." ...), don't you think so? ;)


If compiler would support special "in" usage, automatically expanding
values on the right to series of comparisons (like "var in
[1,2,3,4,5]"),>>it

would be really nice, of course :)


That was discussed, too. Walter and I support that although it's a
special case. We didn't get around to talk the purist police into
accepting it.

Andrei


Why is this a special case? The 'in' could be extended operator to
generally work
on arrays (using a simple linear search). The compiler could then
optimize the
given expression the way suggested (actually even to 1<=var&&var<=5).

Why is 'in' not currently defined on arrays? To me it seems like a
left-out that
should be fixed, because it has quite obvious and useful semantics.

Timon


This has been discussed many times before and the general argument
against it is that "in" is available for associative arrays and it tests
for keys. With arrays it would test for values.



The only thing I can compare this with is python's 'in' operator. It's 
purpose is different though. In python, 'in' returns a boolean, and the 
operator works for any sequence. Associative arrays can return a set of 
keys (hashed), or a list (array) of values, and the 'in' operator can be 
used on either, but defaults to keys.


Not only have I missed a 'set' data structure, but I have missed the 
'in' for arrays as well. It's value is suspect when we consider that 
currently the 'in' operator returns a pointer to the value in the 
associative array. What would we do for an array? You don't need the 
pointer to the value, because you have the value already that you're 
looking for. I see the value in returning the pointer in the associative 
array, so you don't have to do the look-up again.


My argument is that all sequences and containers should support some 
flavor of the "Do I contain this?" question. How many times are we asked 
to build a collection bucket, and then asked to retrieve something put 
in there? In the case of the OP, he has a static compile-time bucket 
that he wants to go poking around in.


If we had a built-in "set" data structure (you know, just the key 
portion of the Associative array), we would solve the OP's problem, and 
make some of my dreams come true.

Re: OOP, faster data layouts, compilers

[Kai Meyer]

On 04/22/2011 11:20 AM, Daniel Gibson wrote:

Am 22.04.2011 19:11, schrieb Kai Meyer:

On 04/22/2011 11:05 AM, Daniel Gibson wrote:

Am 22.04.2011 18:48, schrieb Kai Meyer:


I don't think C# is the next C++; it's impossible for C# to be what
C/C++ is. There is a purpose and a place for Interpreted languages like
C# and Java, just like there is for C/C++. What language do you think
the interpreters for Java and C# are written in? (Hint: It's not Java or
C#.) I also don't think that the core of Unity (or any decent game
engine) is written in an interpreted language either, which basically
means the guts are likely written in either C or C++. The point being
made is that Systems Programming Languages like C/C++ and D are picked
for their execution speed, and Interpreted Languages are picked for
their ease of programming (or development speed). Since D is picked for
execution speed, we should seriously consider every opportunity to
improve in that arena. The OP wasn't just for the game developers, but
for game framework developers as well.


IMHO D won't be successful for games as long as it only supports
Windows, Linux and OSX on PC (-like) hardware.
We'd need support for modern game consoles (XBOX360, PS3, maybe Wii) and
for mobile devices (Android, iOS, maybe Win7 phones and other stuff).
This means good PPC (maybe the PS3's Cell CPU would need special support
even though it's understands PPC code? I don't know.) and ARM support
and support for the operating systems and SDKs used on those platforms.

Of course execution speed is very important as well, but D in it's
current state is not *that* bad in this regard. Sure, the GC is a bit
slow, but in high performance games you shouldn't use it (or even
malloc/free) all the time, anyway, see
http://www.digitalmars.com/d/2.0/memory.html#realtime

Another point: I find Minecraft pretty impressive. It really changed my
view upon Games developed in Java.

Cheers,
- Daniel


Hah, Minecraft. Have you tried loading up a high resolution texture pack
yet? There's a reason why it looks like 8-bit graphics. It's not Java
that makes Minecraft awesome, imo :)


No I haven't.
What I find impressive is this (almost infinitely) big world that is
completely changeable, i.e. you can build new stuff everywhere, you can
dig tunnels everywhere (ok, somewhere really deep there's a limit) and
the game still runs smoothly. Haven't seen something like that in any
game before.


The random world generator is amazing, but it's not speed. The polygon 
count of the game is excruciatingly low because the client is smart 
enough to only draw the faces of blocks that are visible. The very 
bottom (bedrock) and they very top of the sky (as high as you can build 
blocks) is 256 blocks tall. The game is full of low-level bit-stuffing 
(like stacks of 64). The genius of the game is not in any special 
features of Java, it's in the data structure and data generator, which 
can be done much faster in other languages. But it begs the question, 
"why does it need to be faster?" It is "fast enough" in the JVM (unless 
you load up the high resolution textures, in which case the game becomes 
unbearably slow when viewing long distances.)


The purpose of the original post was to indicate that some low level 
research shows that underlying data structures (as applied to video game 
development) can have an impact on the performance of the application, 
which D (I think) cares very much about.

Re: OOP, faster data layouts, compilers

[Kai Meyer]

On 04/22/2011 11:05 AM, Daniel Gibson wrote:

Am 22.04.2011 18:48, schrieb Kai Meyer:


I don't think C# is the next C++; it's impossible for C# to be what
C/C++ is. There is a purpose and a place for Interpreted languages like
C# and Java, just like there is for C/C++. What language do you think
the interpreters for Java and C# are written in? (Hint: It's not Java or
C#.) I also don't think that the core of Unity (or any decent game
engine) is written in an interpreted language either, which basically
means the guts are likely written in either C or C++. The point being
made is that Systems Programming Languages like C/C++ and D are picked
for their execution speed, and Interpreted Languages are picked for
their ease of programming (or development speed). Since D is picked for
execution speed, we should seriously consider every opportunity to
improve in that arena. The OP wasn't just for the game developers, but
for game framework developers as well.


IMHO D won't be successful for games as long as it only supports
Windows, Linux and OSX on PC (-like) hardware.
We'd need support for modern game consoles (XBOX360, PS3, maybe Wii) and
for mobile devices (Android, iOS, maybe Win7 phones and other stuff).
This means good PPC (maybe the PS3's Cell CPU would need special support
even though it's understands PPC code? I don't know.) and ARM support
and support for the operating systems and SDKs used on those platforms.

Of course execution speed is very important as well, but D in it's
current state is not *that* bad in this regard. Sure, the GC is a bit
slow, but in high performance games you shouldn't use it (or even
malloc/free) all the time, anyway, see
http://www.digitalmars.com/d/2.0/memory.html#realtime

Another point: I find Minecraft pretty impressive. It really changed my
view upon Games developed in Java.

Cheers,
- Daniel


Hah, Minecraft. Have you tried loading up a high resolution texture pack 
yet? There's a reason why it looks like 8-bit graphics. It's not Java 
that makes Minecraft awesome, imo :)

Re: OOP, faster data layouts, compilers

[Kai Meyer]

On 04/22/2011 02:55 AM, Paulo Pinto wrote:

Many thanks for the links, they provide very nice discussions.

Specially the link below, that you can follow from your first link,
http://c0de517e.blogspot.com/2011/04/2011-current-and-future-programming.html

But in what concerns game development, D2 might already be too late.

I know a bit of it, since a live a bit on that part of the universe.

Due to XNA(Windows and XBox 360), Mono/Unity, and now WP7, many game studios
have started to move their tooling into C#. And some of them are nowadays
even using
it for the server side code.

Java used to have a foot there, specially due to the J2ME game development,
with a small
push thanks to Android. Which decreased since Google made the NDK available.

If one day Microsoft really lets C# free, the same way AT&T  somehow did
with C and C++, then C#
might actually be the next C++, at least in what game development is
concerned.

And the dependency on a JIT environment is an implementation issue. The
Bartok compiler in Singularity
compiles to native code, and Mono also provides a similar option.

So who knows?

--
Paulo





I don't think C# is the next C++; it's impossible for C# to be what 
C/C++ is. There is a purpose and a place for Interpreted languages like 
C# and Java, just like there is for C/C++. What language do you think 
the interpreters for Java and C# are written in? (Hint: It's not Java or 
C#.) I also don't think that the core of Unity (or any decent game 
engine) is written in an interpreted language either, which basically 
means the guts are likely written in either C or C++. The point being 
made is that Systems Programming Languages like C/C++ and D are picked 
for their execution speed, and Interpreted Languages are picked for 
their ease of programming (or development speed). Since D is picked for 
execution speed, we should seriously consider every opportunity to 
improve in that arena. The OP wasn't just for the game developers, but 
for game framework developers as well.

Re: Hidden argument kind antipattern

[Kai Meyer]

On 04/19/2011 05:18 PM, dsimcha wrote:

== Quote from Vladimir Panteleev (vladi...@thecybershadow.net)'s article

To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer knows
the function's signature. I've noticed a worrying adoption in D of this
"antipattern", which, frankly, I believe doesn't belong in a well-designed
programming language. One classic example of this is passing arguments by
reference, something D inherited from C++. For example:
int x, y;
// ...
someObject.updateCoords(x, y);
What can you say about this code? The unobvious and surprising
interpretation of it is that updateCoords will change the values of x and
y. C# solved this problem neatly by requiring to specify the "ref" keyword
before the function arguments:
someObject.updateCoords(ref x, ref y); // much clearer
This problem carries over to lazy parameters, as well. I'll quote a line
of code from a recent post by David Simcha:

auto connections = taskPool.workerLocalStorage(new MysqlConnection());

Anyone who is not familiar with std.parallelism and D's lazy parameter
feature is going to be very surprised to find out what this code really
does. This might be OK for us, experienced D users, but think about the
poor bloke who will someday, somewhere try to debug a D program written by
someone else, and tear his hair out trying to figure out why an expression
passed as an argument to some function isn't being evaluated before/during
the function call. (The solution I would suggest is simply having to
specify the "lazy" keyword before the expression of each lazy parameter,
same as C#'s "ref". This will require updating all usage of "enforce"
among other changes.)
I know that I should have brought this up during the module's review
phase, so take the following with a grain of salt: in my opinion,
std.parallelism's usage of lazy parameters overreaches their intended use
and borders into abuse of this language feature. For this reason (and
meaning no disrespect towards David and everyone who participated in
shaping the module), I am uncomfortable with the inclusion of
std.parallelism into the standard D library, as it would carry the message
that D's maintainers encourage abusing the language in such ways. (This
probably doesn't count as a vote.) For the moment, I would suggest
changing all lazy parameters which are evaluated in different contexts
(outside of the said function) into delegates, and replacing their usage
with delegate literals.


Interesting point.  I was questioning whether this was really a good idea 
myself.
  I did it because it seemed like things like this were kind of the point of 
lazy
parameters.  Let's have a good discussion on this now, and if we decide that my
idiom is an abuse of lazy parameters, then I'll switch it over to a delegate
literal.  My vote is weakly in favor of lazy parameters, since a maintenance
programmer would probably look at what such a function does and not be surprised
for very long.  However, I'm not dead-set against changing it if there's a 
strong
consensus that it should be changed.


I would agree with the "ref" and "lazy" modifiers to parameters. If they 
exist in the function signature, it seems potentially confusing to 
"silently" accept a built-in or other stack-based parameter as a 
reference with out an explicit "ref" in the call. For instance:


import std.stdio;
struct Bar { public int a; }
class Foo { public int a; }
void main()
{
int a;
Bar b = Bar();
Foo f = new Foo();
a   = 1;
b.a = 1;
f.a = 1;
writef("a=%d b.a=%d f.a=%d\n", a, b.a, f.a);
changeit(a);
changeit(b);
changeit(f);
writef("a=%d b.a=%d f.a=%d\n", a, b.a, f.a);
changeit_ref(a);
changeit_ref(b);
changeit_ref(f);
writef("a=%d b.a=%d f.a=%d\n", a, b.a, f.a);
}
void changeit(int baz) { baz =   2; }
void changeit(Bar bar) { bar.a = 2; }
void changeit(Foo foo) { foo.a = 2; }
void changeit_ref(ref int baz) { baz =   3; }
void changeit_ref(ref Bar bar) { bar.a = 3; }
void changeit_ref(Foo foo) { foo.a = 3; }
//Output:
//a=1 b.a=1 f.a=1
//a=1 b.a=1 f.a=2
//a=3 b.a=3 f.a=3


The call signatures for changeit and changeit_ref are exactly the same, 
but the function definition signatures are different. In the example 
above, I can see the value in forcing the caller to use 
"changeit_ref(ref a)" to match the function declaration.

Re: compile phobos into 64bit -- error!

[Kai Meyer]

On 04/17/2011 08:29 AM, Don wrote:

David Wang wrote:

Hi, all,

I've download the latest dmd & druntime & phobos from gitHub.com;
I copied them into a "32bit" folder and a "64bit" folder; I combined them
separately into 32bit version and 64bit.

1). 32bit for dmd & druntime & phobos -- passed.
2). 64bit for dmd & druntime -- passed; but phobos -- failed. Please
view the
info as follows:


A 'live' development checkout is not guaranteed to work. For one thing,
development on Phobos and on the compiler is independent, and changes
can be made simultaneously to both.
To maximize your chances of getting a functional build, look at the D
autotester before you download from github.
http://d.puremagic.com/test-results/index.ghtml
Additionally, any problems should be reported on the development mailing
lists, not here.
In this particular case, what's happened is that one of the largest
structural problems inside the compiler has been fixed. This fixed a
dozen of the nastiest bugs in Bugzilla, but also exposed some problems
in Phobos and in the test suite. It'll probably be another day or so
before everything is fully stable again.


What a wonderful resource. The test results are fascinating, and provide 
some insight I've been idly wondering about recently. Thanks :)


David, it appears should be able to simply go backwards ("Older") until 
you see a good compile and test, and check out that revision from git, 
like this one:

http://d.puremagic.com/test-results/index.ghtml?runmax=8413&runmin=8364

-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

Kai,


It would be indeed great to automate this once and for all.

We have an installer project at
https://github.com/D-Programming-Language/installer. If you create a
pull request for that project, I'd be glad to review and integrate it.

If you need help with creating a pull request on github, feel free to
ask here - several contributors are quite familiar with such.


Thanks,

Andrei



I created the pull request, but haven't heard back. I'm happy to be 
patient if you would confirm the pull request worked as designed. :)


-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

Kai,


It would be indeed great to automate this once and for all.

We have an installer project at
https://github.com/D-Programming-Language/installer. If you create a
pull request for that project, I'd be glad to review and integrate it.

If you need help with creating a pull request on github, feel free to
ask here - several contributors are quite familiar with such.


Thanks,

Andrei


The current project has a few features that I'm not sure are very 
desirable. I would like some feedback as I try to decide how to best


1) Repackage the .zip distribution from the website.
It hurts my brain to think that's the best way to approach this. I've 
already verified that a fairly stock CentOS 5.6 and Fedora 14 systems 
can compile dmd, phobos, and druntime all from source on git. I think 
this would be preferable.


2) Support arbitrary versions of DMD.
I think it would be better to create tags in the installer project that 
match the other tags/versions. I have something that works right now 
with 2.052 (as far as I can test). I would rather not have to worry 
about backwards compatibility as we move forward once it's finished.


3) Makefile creates a spec file and then tries to start the build.
Would we like to have a method that should work something like this?
git clone /installer.git
cd installer
./this-script-should-result-in-the-rpm
Or should we simply provide .patch files and a .spec file?


-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

On 04/13/2011 01:12 PM, Andrei Alexandrescu wrote:

On 4/13/11 2:04 PM, Kai Meyer wrote:

On 04/13/2011 12:46 PM, Jesse Phillips wrote:

Kai Meyer Wrote:


Ok, how should I go about this then?

-Kai Meyer


Send the updated RPMs to Walter after each release. If you have an
easy tool to build them you can ask Walter if he would like it. Note
he likes bash files because he can review what they are doing easily.


As in email them directly to him?

RPM spec files rely heavily on shell scripts. If he likes bash, he'll
love rpmbuild.

-Kai Meyer


Kai,


It would be indeed great to automate this once and for all.

We have an installer project at
https://github.com/D-Programming-Language/installer. If you create a
pull request for that project, I'd be glad to review and integrate it.

If you need help with creating a pull request on github, feel free to
ask here - several contributors are quite familiar with such.


Thanks,

Andrei


Great, I'll poke around in the installer project, and see how it goes. 
Thanks


-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

On 04/13/2011 12:46 PM, Jesse Phillips wrote:

Kai Meyer Wrote:


Ok, how should I go about this then?

-Kai Meyer


Send the updated RPMs to Walter after each release. If you have an easy tool to 
build them you can ask Walter if he would like it. Note he likes bash files 
because he can review what they are doing easily.


As in email them directly to him?

RPM spec files rely heavily on shell scripts. If he likes bash, he'll 
love rpmbuild.


-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

On 04/12/2011 07:00 PM, Jesse Phillips wrote:

Kai Meyer Wrote:


On 04/12/2011 05:22 PM, Kai Meyer wrote:

On 04/08/2011 10:47 AM, Kai Meyer wrote:

I've been waiting patiently for the Linux RPM to be updated (it's
currently 2.051). Do I need to continue to wait, or should I volunteer
some time to help maintain the RPM packaging? I would be happy to help
develop and maintain a DEB package as well.

-Kai Meyer


This source RPM uses the .zip source distributions from git.

http://kai.gnukai.com/rpms/dmd-2.052-0.i386.rpm
http://kai.gnukai.com/rpms/dmd-2.052-0.src.rpm

I've tested on my Fedora 14 box, and everything appears to be working
fine. With out the source rpm that built the one on that's available on
the website, I've tried to extrapolate what I could about where things
should go, and what should be included. I tried to error on the side of
including too much.

I have not tried to build on CentOS, and I have stripped out all the RPM
dependencies to make installation a little simpler. I hope you can
resolve the dependancies yourself.

I started with the spec file that's in the "installer" repo, but kept
very little of it. One portion was the alien stuff in the post commands.
I don't think that's the place it belongs, but it's just sitting there
commented out for interested individuals.

I'm interested in making this better, so feedback please :)



P.S.

When building on a x64 machine, please add --target i386 to the rpmbuild
command, ie:
rpmbuild --target i386 -ba dmd.spec

I'll fix that later.


Well you aren't supposed to distribute the RPMs yourself, license doesn't allow 
for that.


Ok, how should I go about this then?

-Kai Meyer

Re: Linux RPM out of date

[Kai Meyer]

On 04/12/2011 05:22 PM, Kai Meyer wrote:

On 04/08/2011 10:47 AM, Kai Meyer wrote:

I've been waiting patiently for the Linux RPM to be updated (it's
currently 2.051). Do I need to continue to wait, or should I volunteer
some time to help maintain the RPM packaging? I would be happy to help
develop and maintain a DEB package as well.

-Kai Meyer


This source RPM uses the .zip source distributions from git.

http://kai.gnukai.com/rpms/dmd-2.052-0.i386.rpm
http://kai.gnukai.com/rpms/dmd-2.052-0.src.rpm

I've tested on my Fedora 14 box, and everything appears to be working
fine. With out the source rpm that built the one on that's available on
the website, I've tried to extrapolate what I could about where things
should go, and what should be included. I tried to error on the side of
including too much.

I have not tried to build on CentOS, and I have stripped out all the RPM
dependencies to make installation a little simpler. I hope you can
resolve the dependancies yourself.

I started with the spec file that's in the "installer" repo, but kept
very little of it. One portion was the alien stuff in the post commands.
I don't think that's the place it belongs, but it's just sitting there
commented out for interested individuals.

I'm interested in making this better, so feedback please :)



P.S.

When building on a x64 machine, please add --target i386 to the rpmbuild 
command, ie:

rpmbuild --target i386 -ba dmd.spec

I'll fix that later.

Re: Linux RPM out of date

[Kai Meyer]

On 04/08/2011 10:47 AM, Kai Meyer wrote:

I've been waiting patiently for the Linux RPM to be updated (it's
currently 2.051). Do I need to continue to wait, or should I volunteer
some time to help maintain the RPM packaging? I would be happy to help
develop and maintain a DEB package as well.

-Kai Meyer


This source RPM uses the .zip source distributions from git.

http://kai.gnukai.com/rpms/dmd-2.052-0.i386.rpm
http://kai.gnukai.com/rpms/dmd-2.052-0.src.rpm

I've tested on my Fedora 14 box, and everything appears to be working 
fine. With out the source rpm that built the one on that's available on 
the website, I've tried to extrapolate what I could about where things 
should go, and what should be included. I tried to error on the side of 
including too much.


I have not tried to build on CentOS, and I have stripped out all the RPM 
dependencies to make installation a little simpler. I hope you can 
resolve the dependancies yourself.


I started with the spec file that's in the "installer" repo, but kept 
very little of it. One portion was the alien stuff in the post commands. 
I don't think that's the place it belongs, but it's just sitting there 
commented out for interested individuals.


I'm interested in making this better, so feedback please :)

Re: Linux RPM out of date

[Kai Meyer]

On 04/11/2011 11:22 AM, Kai Meyer wrote:

On 04/11/2011 10:10 AM, Denis Koroskin wrote:

On Mon, 11 Apr 2011 18:21:52 +0400, Kai Meyer  wrote:


Then I suppose I have two options. Do I start where somebody else left
off? Or should I start from scratch? If from scratch, should I be
re-packaging the .zip file distribution, or building from source?

I'm also interested in DDMD.

I don't know where I would find these resources. If somebody could
point me to at least where the resources are (ie: source repository).

-Kai Meyer

On 04/08/2011 03:57 PM, %u wrote:

please do




It's on dsource: http://dsource.org/projects/ddmd

Feel free to ask whatever questions you want!



Ok, so there's DDMD, what about the rpm distribution from the website?
Am I going to just repackage the .zip distribution? Or is there
somewhere I can download and build D from the "real" source?


Oh, here it is:


https://github.com/D-Programming-Language/dmd/tree/dmd-2.052

Thanks :)

If anybody has the 2.051 source rpm that was used, that would help a 
great deal. Otherwise, I'll see you when I've got something working.

Re: Linux RPM out of date

[Kai Meyer]

On 04/11/2011 10:10 AM, Denis Koroskin wrote:

On Mon, 11 Apr 2011 18:21:52 +0400, Kai Meyer  wrote:


Then I suppose I have two options. Do I start where somebody else left
off? Or should I start from scratch? If from scratch, should I be
re-packaging the .zip file distribution, or building from source?

I'm also interested in DDMD.

I don't know where I would find these resources. If somebody could
point me to at least where the resources are (ie: source repository).

-Kai Meyer

On 04/08/2011 03:57 PM, %u wrote:

please do




It's on dsource: http://dsource.org/projects/ddmd

Feel free to ask whatever questions you want!



Ok, so there's DDMD, what about the rpm distribution from the website? 
Am I going to just repackage the .zip distribution? Or is there 
somewhere I can download and build D from the "real" source?

Re: Linux RPM out of date

[Kai Meyer]

Then I suppose I have two options. Do I start where somebody else left 
off? Or should I start from scratch? If from scratch, should I be 
re-packaging the .zip file distribution, or building from source?


I'm also interested in DDMD.

I don't know where I would find these resources. If somebody could point 
me to at least where the resources are (ie: source repository).


-Kai Meyer

On 04/08/2011 03:57 PM, %u wrote:

please do

Linux RPM out of date

[Kai Meyer]

I've been waiting patiently for the Linux RPM to be updated (it's 
currently 2.051). Do I need to continue to wait, or should I volunteer 
some time to help maintain the RPM packaging? I would be happy to help 
develop and maintain a DEB package as well.


-Kai Meyer