Re: yield iteration

[Christophe Travert]

"bearophile" , dans le message (digitalmars.D:173647), a écrit :
> Turning that in D code that uses opApply is not hard, but the 
> code inflates 3X, and you can't use most std.algorithm on it.

I believe most std.algorithm that work on input range could be made to 
work with opApply, or opApply-like delegates. It just wouldn't be 
particularly efficient unless agressive inlining is used.

For example, filter could work like this for opApply-like delegates:

template filter(pred)
{
  auto filter(T)(int delegate(int delegate(ref T)) apply)
  {
return (int delegate(ref T) dg)
{
  return apply( (ref T t) { return pred(t)? dg(t): 1; });
}
  }
}

-- 
Christophe

Re: yield iteration

[Christophe Travert]

Christophe Travert, dans le message (digitalmars.D:173787), a écrit :
> "bearophile" , dans le message (digitalmars.D:173647), a écrit :
>> Turning that in D code that uses opApply is not hard, but the 
>> code inflates 3X, and you can't use most std.algorithm on it.
> 
> I believe most std.algorithm that work on input range could be made to 
> work with opApply, or opApply-like delegates. It just wouldn't be 
> particularly efficient unless agressive inlining is used.
> 
> For example, filter could work like this for opApply-like delegates:
> 
> template filter(pred)
> {
>   auto filter(T)(int delegate(int delegate(ref T)) apply)
>   {
> return (int delegate(ref T) dg)
> {
>   return apply( (ref T t) { return pred(t)? dg(t): 1; });
 ^should read 0
> }
>   }
> }
> 
> -- 
> Christophe

Re: UTF8 + SIMD = win

[Walter Bright]

On 7/30/2012 12:13 PM, deadalnix wrote:

http://woboq.com/blog/utf-8-processing-using-simd.html

All in the article. As D include Unicode as a language feature, I think it is
interesting to mention here.


If someone wants to fix std.utf

   http://dlang.org/phobos/std_utf.html

to use SIMD instructions, that would be cool!

Re: Incomprehensible compiler errors

[Jacob Carlborg]

On 2012-07-31 01:32, Stuart wrote:


It's not D itself I have a problem with. It's the complete lack of
reliable tools for it. No IDE. No GUI designer. No nothing. Coding a
real application in D is like using Cobra, or Nemerle - in short,
frustrating and slow.


We're well aware of these problems and doing our best to solve them. The 
main problem is the lack of time and manpower. I'm guessing most of us 
(D developers) are working on D in our free time.


--
/Jacob Carlborg

Re: Incomprehensible compiler errors

[Jakob Ovrum]

On Monday, 30 July 2012 at 22:54:59 UTC, Stuart wrote:
I'm about ready to give up here. I like the idea of D, but it's 
like using fucking Linux: Absolutely everything needs to be 
compiled before you can use it; and nothing will compile 
because you need to do fifty other goddamn things that aren't 
mentioned in the readme, so you have to post on dozens of 
sodding forums for a week hoping someone throws you a bone.


All I want is to be able to write a GUI application using 
phrases like "button1.dock = Fill". Is that so much to ask? 
Apparently it is.


DFL won't compile. D-IDE doesn't work at all. VisualD crashes 
all the time. The Eclipse IDE plugin doesn't work either. None 
of the IDEs have any kind of reliable intellisense. The 
optional "module" keywords aren't optional. The whole fucking 
thing's a shambles, just like everything else designed for 
Linux.


It's really getting on my tits. Even using MFC is easier than 
this.


You're expecting the same diversity and quality of the toolchain 
of a small, relatively new (D2 is from 2007) programming language 
as you do from giants like C++ and .NET languages. This is 
unreasonable. D is run by a couple of language designers and its 
community - there is no backing from massive corporations or 
anything like that.


That does not mean we can't have good things - the community is 
really pulling its weight, despite its relatively small size (but 
growing at a remarkable rate) we have all kinds of great tools, 
including three up to date compilers, several on-going IDE 
projects, a growing multitude of libraries and bindings, etc.


As for VisualD, a lot of people - including myself - use it 
without issue. It has never crashed for me. I recommend you 
report your problem to the developer, or join development 
yourself. If you just want a stable production environment, start 
by disabling the clearly marked *experimental* auto-complete 
feature if you have it enabled.


Your swipes at Linux are ignorant and non-constructive. Besides, 
D has its roots on Windows, it's not "designed for Linux" in any 
way.


Your issues with compiling DFL are rooted completely in your own 
ignorance of the C/C++/D compilation model. You have a lot to 
learn and you should know that by now. Maybe tone down the 
aggressiveness a little; you've been generating a lot of noise 
lately.

Re: Incomprehensible compiler errors

[Nick Sabalausky]

On Tue, 31 Jul 2012 01:48:04 +0200
"Stuart"  wrote:

> Let me be clear: I have no problem with the language of D. It 
> looks quite decent. It's just not feasible to actually write a 
> PROGRAM in it. Sure, if I want a quick-and-dirty commandline tool 
> or something, no problem; but a Windows application? Without an 
> IDE or GUI designer? No way. Even MFC has a dialog designer.
> 
> The language is fine: Now the developers need to turn their 
> attention to the TOTAL AND UTTER LACK OF RELIABLE DEVELOPMENT 
> TOOLS.

FWIW, I think this is the problem:

The people who have been using D so far are mostly those who are
perfectly happy, or prefer, command lines and lightweight code
editors. So they've never been particularly motivated to work on such
things since they don't need them and have plenty of more immediate
concerns.

Then the people who demand fullweight IDEs, GUI designers, zero command
line, etc., see that D doesn't have much in that regard, and they don't
improve the situation either, they just leave in disgust instead.

So neither side is doing it and we have a chicken and egg situation :/

Of course, that's not *entirely* true. Things like VisualD and Mono-D
*are* very actively maintained. They just don't have very many people
helping out (which of course is where the chicken and egg comes in).

As far as reliable dev tools, Programmer's Notepad 2 + DMD has been
*very* reliable for me. It's not "Trivial, a-baby-can-do-it, set
everything up with one-click", you have to understand the command line,
etc., but it's certainly been very reliable.

Re: Incomprehensible compiler errors

[David]

It's not D itself I have a problem with. It's the complete lack of
reliable tools for it. No IDE. No GUI designer. No nothing. Coding a
real application in D is like using Cobra, or Nemerle - in short,
frustrating and slow.


Mh, if this is *your* opinion, why are you using D then?

Re: UTF8 + SIMD = win

[bearophile]

Walter Bright:


to use SIMD instructions, that would be cool!


I think in D the most needed UTF operation is UTF8 -> UTF32.

Bye,
bearophile

Re: Incomprehensible compiler errors

[Don Clugston]

On 31/07/12 00:54, Stuart wrote:

On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote:


A ModuleInfo is generated for each compiled module and inserted into
its corresponding .obj file. If the linker cannot find it, then it is
likely that you need to specify that .obj on the link command.


Ah, it would seem that my problem is with DFL not compiling. Look guys,
I'm about ready to give up here. I like the idea of D, but it's like
using fucking Linux: Absolutely everything needs to be compiled before
you can use it; and nothing will compile because you need to do fifty
other goddamn things that aren't mentioned in the readme, so you have to
post on dozens of sodding forums for a week hoping someone throws you a
bone.




All I want is to be able to write a GUI application using phrases like
"button1.dock = Fill". Is that so much to ask? Apparently it is.

DFL won't compile. D-IDE doesn't work at all. VisualD crashes all the
time. The Eclipse IDE plugin doesn't work either. None of the IDEs have
any kind of reliable intellisense. The optional "module" keywords aren't
optional. The whole fucking thing's a shambles, just like everything
else designed for Linux.

It's really getting on my tits. Even using MFC is easier than this.


Yeah, we still have *miles* to go on the toolchain. As a community we've 
been putting most of our effort into getting the compiler stable, and to 
a lesser extent working on the the standard library. Most of the other 
things are one-man shows.

The Eclipse plugin and DFL have both been abandoned for years.
Mono-D and VisualD are progressing quite well but again they are only 
one-man shows.


We need more people.

Re: Incomprehensible compiler errors

[bearophile]

David:


Mh, if this is *your* opinion, why are you using D then?


Because its community is helpful and friendly :-)

Bye,
bearophile

Re: build Ldc2 for win xp 32 bit Error

[Don Clugston]

On 26/07/12 09:05, Jacob Carlborg wrote:

On 2012-07-25 22:39, Rainer Schuetze wrote:


What is the state of the missing exception handling for Windows?


I just read an old post on the Clang mailing list, it's not looking
good. It seems Microsoft (or someone else) has a patent on SEH,


I've heard this, but does anyone know what patent is being referred to? 
Several times I've heard mention of an old one by Borland, which 
Microsoft bought. The Borland patent is not a patent on SEH, it's 
basically a patent on using a thunk. I suspect it is extremely unlikely 
to be a valid patent, for sure there is prior art. And the only reason 
for implementing it with a thunk anyway, is as a workaround for the 
broken thread-local support in Windows prior to Vista.


It's not difficult to implement SEH without violating that patent (which 
is due to expire soon anyway). Is there some other patent that people 
are referring to?



which

basically means: never gonna happen. An alternative could be
setjmp/longjmp. On 64bit it looks a bit better, where the correct way
seems to be to use the Win64 exception ABI.


Win64 SEH is scarcely any different to Win32 SEH, it's just better 
documented. You can do the same thing on Win32.




http://clang-developers.42468.n3.nabble.com/LLVM-Clang-and-setjmp-longjmp-exception-handling-on-MinGW-td3407322.html


http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx


The situation makes no sense to me.

Re: UTF8 + SIMD = win

[Bernard Helyer]

On Tuesday, 31 July 2012 at 10:57:23 UTC, bearophile wrote:

Walter Bright:


to use SIMD instructions, that would be cool!


I think in D the most needed UTF operation is UTF8 -> UTF32.

Bye,
bearophile


Where is UTF-32 actually used?

Re: UTF8 + SIMD = win

[bearophile]

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, when 
you give them a string in input.


Bye,
bearophile

Re: UTF8 + SIMD = win

[Jakob Ovrum]

On Tuesday, 31 July 2012 at 12:11:25 UTC, bearophile wrote:

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, 
when you give them a string in input.


Bye,
bearophile


In addition, foreach over a string with a dchar loop variable 
does implicit UTF-8 decoding.

Re: build Ldc2 for win xp 32 bit Error

[David Nadlinger]

On Tuesday, 31 July 2012 at 11:21:21 UTC, Don Clugston wrote:
Win64 SEH is scarcely any different to Win32 SEH, it's just 
better documented. You can do the same thing on Win32.


Unless I'm mistaken, SEH on Win64 is quite a lot different to 
Win32, as it is based on tables, rather than keeping FS:[0] up to 
date in the function pro-/epilogues.


David

Re: Different results for uniform random number generation between D and Boost

[FeepingCreature]

Try comparing the mxcsr register. It controls rounding mode when using SSE ops 
(even the single-float ones).

Here's a good page that documents all the bits of the mxcsr: 
http://softpixel.com/~cwright/programming/simd/sse.php

The x87 equivalent is the control word; see 
http://www.website.masmforum.com/tutorials/fptute/fpuchap1.htm#cword 
(fstcw/fldcw).

Re: OT: phobos name

[akaz]

On Tuesday, 31 July 2012 at 13:16:57 UTC, akaz wrote:

I just discovered that. I find it surprisingly. Fear


surprisingly -> surprising. sorry.

OT: phobos name

[akaz]

According to Wikipedia:

"Phobos (Ancient Greek: Φόβος, pronounced [pʰóbos], 
meaning "fear" or "terror") is the personification of fear in 
Greek mythology."


http://en.wikipedia.org/wiki/Phobos_(mythology)

I just discovered that. I find it surprisingly. Fear 
Terror

Re: OT: phobos name

[Tobias Brandt]

On 31 July 2012 15:16, akaz  wrote:
> According to Wikipedia:
>
> "Phobos (Ancient Greek: Φόβος, pronounced [pʰóbos], meaning "fear" or
> "terror") is the personification of fear in Greek mythology."
>
> http://en.wikipedia.org/wiki/Phobos_(mythology)
>
> I just discovered that. I find it surprisingly. Fear Terror

Phobos and Deimos are the two moons of Mars, which was the original name of D.

Re: OT: phobos name

[Gor Gyolchanyan]

On Tue, Jul 31, 2012 at 5:18 PM, akaz  wrote:

> On Tuesday, 31 July 2012 at 13:16:57 UTC, akaz wrote:
>
>> I just discovered that. I find it surprisingly. Fear
>>
>
> surprisingly -> surprising. sorry.
>
>
>
http://en.wikipedia.org/wiki/Phobos_(moon)
It's the name of one of Mars's moons.
Why Mars? Because Digital Mars.
www.digitalmars.com

-- 
Bye,
Gor Gyolchanyan.

Re: OT: phobos name

[akaz]

On Tuesday, 31 July 2012 at 13:22:57 UTC, Tobias Brandt wrote:

On 31 July 2012 15:16, akaz  wrote:
Phobos and Deimos are the two moons of Mars, which was the 
original name of D.


That, on the other hand, was known to me. What I did not know, 
was the "fear" factor... Maybe the library should have been 
renamed to Deimos? :)


By the way, I live in the same city as this guy here. So you may 
say that I live with Phobos over my head:


http://davinci-marsdesign.blogspot.fr/2012/05/scale-of-phobos.html

Pretty... scary, isn't?

Re: OT: phobos name

[Gor Gyolchanyan]

On Tue, Jul 31, 2012 at 5:28 PM, akaz  wrote:

> On Tuesday, 31 July 2012 at 13:22:57 UTC, Tobias Brandt wrote:
>
>> On 31 July 2012 15:16, akaz  wrote:
>> Phobos and Deimos are the two moons of Mars, which was the original name
>> of D.
>>
>
> That, on the other hand, was known to me. What I did not know, was the
> "fear" factor... Maybe the library should have been renamed to Deimos? :)
>
> By the way, I live in the same city as this guy here. So you may say that
> I live with Phobos over my head:
>
> http://davinci-marsdesign.**blogspot.fr/2012/05/scale-of-**phobos.html
>
> Pretty... scary, isn't?
>
>
Deimos was mentioned because it's the name of C library bindings package.

-- 
Bye,
Gor Gyolchanyan.

Re: OT: phobos name

[akaz]

On Tuesday, 31 July 2012 at 13:28:35 UTC, akaz wrote:

On Tuesday, 31 July 2012 at 13:22:57 UTC, Tobias Brandt wrote:

On 31 July 2012 15:16, akaz  wrote:
Phobos and Deimos are the two moons of Mars, which was the 
original name of D.


That, on the other hand, was known to me. What I did not know, 
was the "fear" factor... Maybe the library should have been 
renamed to Deimos? :)


http://en.wikipedia.org/wiki/Deimos_(moon)

OMG: "It is named after Deimos, a figure representing dread in 
Greek Mythology."


C'mon, Mars was really the God of War... His moons really show it.

Fear&Dread

Re: OT: phobos name

[Dejan Lekic]

That, on the other hand, was known to me. What I did not know, 
was the "fear" factor... Maybe the library should have been 
renamed to Deimos? :)


What do you think where the term "PHOBia" came from??

Re: Incomprehensible compiler errors

[Jacob Carlborg]

On 2012-07-31 11:28, Nick Sabalausky wrote:


FWIW, I think this is the problem:

The people who have been using D so far are mostly those who are
perfectly happy, or prefer, command lines and lightweight code
editors. So they've never been particularly motivated to work on such
things since they don't need them and have plenty of more immediate
concerns.


I'm not happy with and don't prefer command line tools. I prefer using 
an IDE. I'm really jealous on Eclipse (JDT) and Xcode 4.


I'm trying to work on improving the development environment for D. But 
these things take time. Before starting with high level tools like an 
IDE we need proper tools at a lower level. I don't think we're there 
yet. No proper build tools, no package manager, no good way to run tests 
and so on.



Then the people who demand fullweight IDEs, GUI designers, zero command
line, etc., see that D doesn't have much in that regard, and they don't
improve the situation either, they just leave in disgust instead.

So neither side is doing it and we have a chicken and egg situation :/

Of course, that's not *entirely* true. Things like VisualD and Mono-D
*are* very actively maintained. They just don't have very many people
helping out (which of course is where the chicken and egg comes in).

As far as reliable dev tools, Programmer's Notepad 2 + DMD has been
*very* reliable for me. It's not "Trivial, a-baby-can-do-it, set
everything up with one-click", you have to understand the command line,
etc., but it's certainly been very reliable.


I'm quite happy with my setup using TextMate and DMD, RDMD and DVM. I've 
added commands to run a single file using RDMD. I also have another 
command for building a whole project. It can parse the output of the 
builds and create links, which points back to TextMate, of any compile 
errors or exceptions thrown at runtime.


--
/Jacob Carlborg

Re: OT: phobos name

[Andrei Alexandrescu]

On 7/31/12 10:31 AM, Dejan Lekic wrote:

That, on the other hand, was known to me. What I did not know, was the
"fear" factor... Maybe the library should have been renamed to Deimos? :)


What do you think where the term "PHOBia" came from??


Whoa! Good point. Now if we could tie all this with Pho soup...

Andrei

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: Different results for uniform random number generation between D and Boost

[Era Scarecrow]

On Tuesday, 31 July 2012 at 01:00:38 UTC, Nick Sabalausky wrote:

My (limited) understanding is that it's almost practically 
impossible to get consistency in x86 floating point unless 
you're using SSE:


http://www.yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

Maybe the effect you're observing could be related to what he 
describes?


 I don't suppose there's an emulated floating type (like is 
optionally available in the linux kernel) that could be used in 
place of normal floating point? I wonder if the C++ version is 
wrong; In walter's article regarding floating point he brought 
out that few applications in C++ set/reset the register for 
floating point between operations or between functions (when they 
change)... Or was that between applications as a whole (And an 
occasional OS issue)?


 Is the problem be even worse if you mixed MMX and FPU (Since 
they use the same registers, just a different mode)?

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 04:15:40 UTC, Bernard Helyer wrote:
If they won't learn the compilation model, they won't be good 
programmers.
I'm not saying that good messages are a bad thing, but if they 
don't
understand the basic concept of source -> object file -> linker 
-> exe or dll,
then they will have a very hard time with D, pretty error 
messages

or no.


I understand the basic concept. What I didn't understand was why
omitting the optional keyword "module" caused linker errors; nor
did I understand why I couldn't use DFL after installing it
normally. It wasn't obvious that the DFL compilation had failed,
because the installer said "success!"

Re: build Ldc2 for win xp 32 bit Error

[Jacob Carlborg]

On 2012-07-31 13:21, Don Clugston wrote:


I've heard this, but does anyone know what patent is being referred to?
Several times I've heard mention of an old one by Borland, which
Microsoft bought. The Borland patent is not a patent on SEH, it's
basically a patent on using a thunk. I suspect it is extremely unlikely
to be a valid patent, for sure there is prior art. And the only reason
for implementing it with a thunk anyway, is as a workaround for the
broken thread-local support in Windows prior to Vista.


I think it's this patent:

http://www.google.com/patents/about?id=21MgEBAJ&dq=5,628,016

Inventor: Peter Kukol
Original Assignee: Borland International, Inc.
Primary Examiner: Peter J. Corcoran, III
Current U.S. Classification: 717/140; 717/114
International Classification: G06F 945


It's not difficult to implement SEH without violating that patent (which
is due to expire soon anyway). Is there some other patent that people
are referring to?


It doesn't matter. The Clang/LLVM developers won't accept an 
implementation that has any chance of being covered by a patent.


--
/Jacob Carlborg

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 09:26:42 UTC, Jakob Ovrum wrote:
You're expecting the same diversity and quality of the 
toolchain of a small, relatively new (D2 is from 2007) 
programming language as you do from giants like C++ and .NET 
languages. This is unreasonable.


You have a point, and I have no business complaining about the 
inadequacies of a free project. But nevertheless, it's 
discouraging to try out a new language (D, Nemerle, Cobra, etc 
etc) only to find that I can't actually write any programs in it.


By which I mean there is no way to create a GUI short of using 
the API directly. Try getting a bunch of controls to resize when 
you maximise their parent window - in .NET, this is trivial. If 
DFL worked, it would still be trivial. In D (or any other 
language with no decent tools) it's mind-bogglingly difficult.


I'm really impressed with D, and was planning to start writing an 
application in it yesterday. And all I got was obscure compiler 
errors and a non-functional DFL. So I was a little disappointed.


As for VisualD, a lot of people - including myself - use it 
without issue. It has never crashed for me. I recommend you 
report your problem to the developer, or join development 
yourself. If you just want a stable production environment, 
start by disabling the clearly marked *experimental* 
auto-complete feature if you have it enabled.


It was disabled until very recently, when I was advised to enable 
it. The crash - which I have already reported - occurs when 
opening the solution. Any D solution. Every time. When 
double-clicking the .sln file in Explorer (or using Win7 jump 
lists).



Your swipes at Linux are ignorant and non-constructive.


Ignorant? I'm no expert, certainly, but ignorant? Hardly. I've 
used Linux. For example, I ran it on my server machine for a 
year. And one thing I learnt was that, until you start getting 
Linux driver discs when you buy hardware, it's useless. Who wants 
an operating system that doesn't work until you post on forums, 
hack config files, and recompile the kernel? No thank you.


Besides, D has its roots on Windows, it's not "designed for 
Linux" in any way.


I was talking about the general mindset. The mindset behind DFL, 
to be specific. The mindset of: "Don't give 'em an exe - give 'em 
source, an obscure makefile, and undocumented dependencies. Let 
them WORK for it." That's the Linux mentality, and it drives me 
up the wall.


I never said D was crap. I said its tools don't work. I was 
disappointed that I couldn't use D to write an application. Does 
that sound like someone who doesn't like the language?


Your issues with compiling DFL are rooted completely in your 
own ignorance of the C/C++/D compilation model.


Er, no. Before I used .NET, I used C++ almost exclusively for a 
number of years. I'm a little out of practice, but I understand 
the general principles involved. How about you stop making all 
these assumptions about my ignorance?



You have a lot to learn and you should know that by now.


Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc in 
Software Engineering, and I've been coding for 16 years. So let's 
have less of the condescension, hmm?


Maybe tone down the aggressiveness a little; you've been 
generating a lot of noise lately.


Lately? I've only recently discovered D. What are you comparing 
my current noise level to? Besides, most of my posts have been 
constructive, to my mind. Granted, I got a bit frustrated 
yesterday, but so what?

Allocating Executable Memory

[Maxime Chevalier]

New to the D language here. I'm working on a tracing JIT compiler 
and will need to allocate chunks of memory that are marked as 
executable.


Is there a standard way of doing this in D, or do I need to 
directly call into mprotect? If I'm going to be calling mprotect, 
what's the cleanest way to do that, do I need to declare my own 
prototype for the function and its flags, or should I write some 
C code that does the call?


Thanks for your help.

Re: Let's stop parser Hell

[Tobias Pankrath]

On Tuesday, 31 July 2012 at 16:10:14 UTC, Kai Meyer wrote:

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.


Every helping hand is appreciated :-)

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.


Yes. To make this statement more precise: We need a lexer that 
provides
a range of tokens and we need a parser which makes it possible to 
build
an AST. Pegged combines both approaches but imposes an overhead 
if you

just need a token list. However I'm not sure if this is a problem.

There are already some working D-Parsers buried in this thread.

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've only glimpsed at your code. For most languages lexing is far 
more expensive then parsing and thus the lexer has to be very 
fast and I wouldn't pursue your approach and instead use 
something like ragel. It already has D output but needs a 
separate build step.

Re: Allocating Executable Memory

[Alex Rønne Petersen]

On 31-07-2012 19:23, Maxime Chevalier wrote:

New to the D language here. I'm working on a tracing JIT compiler and
will need to allocate chunks of memory that are marked as executable.

Is there a standard way of doing this in D, or do I need to directly
call into mprotect? If I'm going to be calling mprotect, what's the
cleanest way to do that, do I need to declare my own prototype for the
function and its flags, or should I write some C code that does the call?

Thanks for your help.


There's no standard way to do it. You'll have to either use mprotect or 
just pass the relevant flags when you call mmap.


The functions and constants related to this are all in core.sys.posix.mman.

See also:

* https://github.com/lycus/mci/blob/master/src/mci/core/memory.d#L71 
(and further down)

* https://github.com/lycus/mci/blob/master/src/mci/vm/code.d

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 09:33:57 UTC, David wrote:
It's not D itself I have a problem with. It's the complete 
lack of reliable tools for it. No IDE. No GUI designer. No 
nothing. Coding a real application in D is like using Cobra, 
or Nemerle - in short, frustrating and slow.


Mh, if this is *your* opinion, why are you using D then?


Of course it's *my* opinion. Whose else opinion would it be?

And that's just the point. I'm *not* using D. I *want* to be 
using D, and I've been *trying* to use D, but I keep hitting 
strange compiler errors and libraries that won't compile (i.e. 
DFL).


I like D. It's been well-thought-out. But without tools, how can 
it be used? Yeah, I know, many of you don't use IDEs - but tell 
me this. How can I write a GUI? Whether you like GUIs is beside 
the point: Applications need them. There's no point writing a 
decent-sized program without one. And yet (without DFL) you have 
no library support for them whatsoever. To create a window or a 
button, I must use CreateWindow(). To handle events, I must use 
GetMessageA(). To resize controls when the parent window changes 
size, I have to do it all by hand, in code.


DFL and intellisense. Those are the areas this project is lacking.

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 10:59:49 UTC, Don Clugston wrote:


Yeah, we still have *miles* to go on the toolchain. As a 
community we've been putting most of our effort into getting 
the compiler stable, and to a lesser extent working on the the 
standard library. Most of the other things are one-man shows.

The Eclipse plugin and DFL have both been abandoned for years.
Mono-D and VisualD are progressing quite well but again they 
are only one-man shows.


We need more people.


Agreed. I don't know if I can help much - I'm not an expert on 
low-level things like compilers and such, and I do my best work 
in .NET; but there may be something I can do. Maybe write a 
better IDE, with intellisense, I dunno. It'd have to be .NET 
based.


Or maybe I could work with you guys on devising a new DFL. I've 
had loads of experience with the .NET standard library for GUIs 
(System.Windows.Forms). I don't have much experience in the D 
language, but if it was a joint effort, that wouldn't matter so 
much. What does everyone think? (Except Jakob, who thinks I'm 
ignorant)

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 11:20:53 UTC, bearophile wrote:



Mh, if this is *your* opinion, why are you using D then?


Because its community is helpful and friendly :-)


lol ;)

Re: Allocating Executable Memory

[Maxime Chevalier]

The functions and constants related to this are all in 
core.sys.posix.mman.


See also:

* 
https://github.com/lycus/mci/blob/master/src/mci/core/memory.d#L71 
(and further down)

* https://github.com/lycus/mci/blob/master/src/mci/vm/code.d


Thanks. Forgive my ignorance though, but does 
core.sys.posix.sys.mman ship standard with D compilers?

Re: Incomprehensible compiler errors

[Mirko Pilger]

How can I write a GUI?


as i understand gtkD is actively maintained and even already prepared 
for the next dmd release version 2.060.


https://github.com/gtkd-developers/GtkD

Re: Allocating Executable Memory

[Gor Gyolchanyan]

On Tue, Jul 31, 2012 at 9:36 PM, Maxime Chevalier <
maximechevali...@gmail.com> wrote:

> The functions and constants related to this are all in core.sys.posix.mman.
>>
>> See also:
>>
>> * 
>> https://github.com/lycus/mci/**blob/master/src/mci/core/**memory.d#L71(and
>>  further down)
>> * 
>> https://github.com/lycus/mci/**blob/master/src/mci/vm/code.d
>>
>
> Thanks. Forgive my ignorance though, but does core.sys.posix.sys.mman ship
> standard with D compilers?
>

It's part of druntime. Druntime is D's runtime library, without which D
code above version 2.0 can't work.

-- 
Bye,
Gor Gyolchanyan.

Re: Allocating Executable Memory

[Alex Rønne Petersen]

On 31-07-2012 19:36, Maxime Chevalier wrote:

The functions and constants related to this are all in
core.sys.posix.mman.

See also:

* https://github.com/lycus/mci/blob/master/src/mci/core/memory.d#L71
(and further down)
* https://github.com/lycus/mci/blob/master/src/mci/vm/code.d


Thanks. Forgive my ignorance though, but does core.sys.posix.sys.mman
ship standard with D compilers?


Yep. Anything core.* and std.* is part of druntime and phobos which both 
ship with any D 2.0 compiler.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Allocating Executable Memory

[Maxime Chevalier]

Yep. Anything core.* and std.* is part of druntime and phobos 
which both ship with any D 2.0 compiler.


Thanks very much for the quick responses.

My tracing JIT will likely need to have the compiled code write 
into data structures of the host VM. This will mean the compiled 
code holds pointers to host data.


How well does the D GC deal with immovable objects. Would it be a 
problem if I allocated many chunks of immovable data?


Would it be preferable to minimize immovable data by having 
compiled code refer to an (immovable) table with pointers to 
(movable) host data?


Also, if you don't mind me asking, which D compiler do you guys 
prefer? Which one is most widely supported, most up to date?

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 00:30:50 UTC, Bernard Helyer wrote:
Oh, and if there are complaints of LoadLibraryA or whatever not 
being nothrow, remove any trace of nothrow from those modules.


Yeah, that didn't work.

bash.exe"-3.1$ dmd -lib -ofdfl *.d internal/*.d -I..
DFL: dfl.com is deprecated, please import dfl.internal.com; 
dfl.com is provided

for compatibility only
folderdialog.d(33): Error: cannot implicitly convert expression 
(& fbdHookProc)
of type extern (Windows) int function(void* hwnd, uint msg, int 
lparam, int lpDa
ta) to extern (Windows) int function(void* hwnd, uint uMsg, int 
lParam, int lpDa

ta) nothrow
fontdialog.d(30): Error: cannot implicitly convert expression (& 
fondHookProc) o
f type extern (Windows) uint function(void*, uint, uint, int) to 
extern (Windows
) uint function(void* hdlg, uint uiMsg, uint wParam, int lParam) 
nothrow


Sigh.

Re: Allocating Executable Memory

[Alex Rønne Petersen]

On 31-07-2012 20:06, Maxime Chevalier wrote:

Yep. Anything core.* and std.* is part of druntime and phobos which
both ship with any D 2.0 compiler.


Thanks very much for the quick responses.

My tracing JIT will likely need to have the compiled code write into
data structures of the host VM. This will mean the compiled code holds
pointers to host data.

How well does the D GC deal with immovable objects. Would it be a
problem if I allocated many chunks of immovable data?


Can you clarify what you mean by immovable data? I don't think I follow.

In any case, if the compiled code's executable memory regions aren't 
added as root ranges to D's GC (which is entirely reasonable to not do), 
then you can keep the data alive by simply keeping pointers to the D 
GC-managed data in the host environment. D doesn't use a moving collector.




Would it be preferable to minimize immovable data by having compiled
code refer to an (immovable) table with pointers to (movable) host data?

Also, if you don't mind me asking, which D compiler do you guys prefer?
Which one is most widely supported, most up to date?


DMD: Latest updates, fixes, and enhancements. Very fast compilation. Not 
that great optimization.
GDC: Best optimization and fantastic debug info generation. Somewhat 
slow at compilation.
LDC: Fast compilation and good optimization. Sits somewhere between DMD 
and GDC.


Note that DMD can only target x86 while LDC and GDC (due to using LLVM 
and GCC respectively) can target many other 32-bit and 64-bit architectures.


Also, LDC and GDC tend to lag one release behind DMD sometimes, since 
they rely on the DMD front end code.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Allocating Executable Memory

[Timon Gehr]

On 07/31/2012 08:06 PM, Maxime Chevalier wrote:


How well does the D GC deal with immovable objects. Would it be a
problem if I allocated many chunks of immovable data?



The current GC in druntime never moves data.

Re: Allocating Executable Memory

[Era Scarecrow]

On Tuesday, 31 July 2012 at 17:23:08 UTC, Maxime Chevalier wrote:
New to the D language here. I'm working on a tracing JIT 
compiler and will need to allocate chunks of memory that are 
marked as executable.


Is there a standard way of doing this in D, or do I need to 
directly call into mprotect? If I'm going to be calling 
mprotect, what's the cleanest way to do that, do I need to 
declare my own prototype for the function and its flags, or 
should I write some C code that does the call?


 The x86 chip it's a simple flag that the OS can set. For use 
with like UPX, the whole section is marked read, write & execute 
I believe (since it has to expand it first before it can execute 
the code; That is of course for loaded memory, not 
allocating...). I would say check their sources, may prove 
interesting.

Re: Allocating Executable Memory

[bearophile]

Maxime Chevalier:

How well does the D GC deal with immovable objects. Would it be 
a problem if I allocated many chunks of immovable data?


The GC supports flags to define memory as movable or immovable,
but I think at the moment it performs no memory movements.


Also, if you don't mind me asking, which D compiler do you guys 
prefer? Which one is most widely supported, most up to date?


DMD has a back-end that produces less efficient binaries compared
to GDC and LDC. But DMD is more up to date (but not a lot), and
it's the most supported, it's the reference implementation. DMD
works well on Windows too, GDC works on Windows too. I think LDC
doesn't work well on Windows.

Bye,
bearophile

Re: Allocating Executable Memory

[Alex Rønne Petersen]

On 31-07-2012 20:30, Era Scarecrow wrote:

On Tuesday, 31 July 2012 at 17:23:08 UTC, Maxime Chevalier wrote:

New to the D language here. I'm working on a tracing JIT compiler and
will need to allocate chunks of memory that are marked as executable.

Is there a standard way of doing this in D, or do I need to directly
call into mprotect? If I'm going to be calling mprotect, what's the
cleanest way to do that, do I need to declare my own prototype for the
function and its flags, or should I write some C code that does the call?


  The x86 chip it's a simple flag that the OS can set. For use with like
UPX, the whole section is marked read, write & execute I believe (since
it has to expand it first before it can execute the code; That is of
course for loaded memory, not allocating...). I would say check their
sources, may prove interesting.


UPX simply uses VirtualProtect/mprotect. It's the only way you _can_ do 
this in ring 3 on any OS with sane security.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Allocating Executable Memory

[bearophile]

bearophile:

DMD has a back-end that produces less efficient binaries 
compared

to GDC and LDC. But DMD is more up to date (but not a lot), and
it's the most supported, it's the reference implementation. DMD
works well on Windows too, GDC works on Windows too. I think LDC
doesn't work well on Windows.


An DMD doesn't support 64 bit on Windows.

Bye,
bearophile

Re: Incomprehensible compiler errors

[Bernard Helyer]

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:



Your swipes at Linux are ignorant and non-constructive.


Ignorant? I'm no expert, certainly, but ignorant?


Yes, ignorant. You're an ignorant fool. Worst part is you don't
even know it.



I never said D was crap. I said its tools don't work. I was 
disappointed that I couldn't use D to write an application. 
Does that sound like someone who doesn't like the language?


Your issues with compiling DFL are rooted completely in your 
own ignorance of the C/C++/D compilation model.


Er, no. Before I used .NET, I used C++ almost exclusively for a 
number of years. I'm a little out of practice, but I understand 
the general principles involved.


No you don't, or you wouldn't have asked the question in the first
place.




You have a lot to learn and you should know that by now.


Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc in 
Software Engineering, and I've been coding for 16 years.


Well jesus, a BSc, aren't you just a fucking genius.


Fuck off. Stop wasting our time.

Re: Incomprehensible compiler errors

[Andrej Mitrovic]

On 7/31/12, Stuart  wrote:
> On Tuesday, 31 July 2012 at 00:30:50 UTC, Bernard Helyer wrote:
>> Oh, and if there are complaints of LoadLibraryA or whatever not
>> being nothrow, remove any trace of nothrow from those modules.
>
> Yeah, that didn't work.

I've had some success with using DGui, which seems to be loosely based
on DFL. http://code.google.com/p/dgui/

It seems to compile with DMD 2.059, although it needs fixing for the
upcoming 2.060.

Personally if I maintained DFL I'd make a simpler build script because
there were many posts about failing to build DFL over the last years..

Re: Incomprehensible compiler errors

[q66]

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc in 
Software Engineering, and I've been coding for 16 years. So 
let's have less of the condescension, hmm?


errr I meant this :)

Re: Incomprehensible compiler errors

[q66]

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Lately? I've only recently discovered D. What are you comparing 
my current noise level to? Besides, most of my posts have been 
constructive, to my mind. Granted, I got a bit frustrated 
yesterday, but so what?



There's only one answer I could imagine: 
http://i0.kym-cdn.com/entries/icons/original/000/007/508/watch-out-we-got-a-badass-over-here-meme.png

Re: UTF8 + SIMD = win

[Walter Bright]

On 7/31/2012 5:24 AM, Jakob Ovrum wrote:

On Tuesday, 31 July 2012 at 12:11:25 UTC, bearophile wrote:

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, when you give
them a string in input.

Bye,
bearophile


In addition, foreach over a string with a dchar loop variable does implicit
UTF-8 decoding.



SIMD isn't going to speed things up at all for decoding one character. It is for 
transcoding a large array.

Re: UTF8 + SIMD = win

[Jakob Ovrum]

On Tuesday, 31 July 2012 at 19:28:03 UTC, Walter Bright wrote:

On 7/31/2012 5:24 AM, Jakob Ovrum wrote:

On Tuesday, 31 July 2012 at 12:11:25 UTC, bearophile wrote:

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, 
when you give

them a string in input.

Bye,
bearophile


In addition, foreach over a string with a dchar loop variable 
does implicit

UTF-8 decoding.



SIMD isn't going to speed things up at all for decoding one 
character. It is for transcoding a large array.


Duh, good point, I totally forgot the context.

Re: Allocating Executable Memory

[David Nadlinger]

On Tuesday, 31 July 2012 at 18:06:28 UTC, Maxime Chevalier wrote:
How well does the D GC deal with immovable objects. Would it be 
a problem if I allocated many chunks of immovable data?


D's GC currently doesn't move memory at all, so this should not 
be a problem. If there is a chance that all references to the 
object in question in D-managed memory (i.e. stack, GC heap) go 
away, but the memory is still used, you might need to manually 
mark the object as live, though (see core.memory.GC.addRoot).


Also, if you don't mind me asking, which D compiler do you guys 
prefer? Which one is most widely supported, most up to date?


DMD is the official reference compiler and compiles faster than 
the others, but is x86-only (32 bit only on Windows), and the 
performance of the generated code is sometimes significantly 
worse than with the other compilers. GDC and LDC also use the 
same frontend as DMD, but it usually takes them a few weeks to 
catch up after a new version of it is released. LDC currently 
doesn't work on Windows if your application uses exception 
handling (which most applications do).


I personally use LDC as my default compiler, but I might be 
biased… ;)


David

Re: UTF8 + SIMD = win

[Tobias Pankrath]

On Tuesday, 31 July 2012 at 19:28:03 UTC, Walter Bright wrote:

On 7/31/2012 5:24 AM, Jakob Ovrum wrote:

On Tuesday, 31 July 2012 at 12:11:25 UTC, bearophile wrote:

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, 
when you give

them a string in input.

Bye,
bearophile


In addition, foreach over a string with a dchar loop variable 
does implicit

UTF-8 decoding.



SIMD isn't going to speed things up at all for decoding one 
character. It is for transcoding a large array.


You could decode them in advance.

Re: Incomprehensible compiler errors

[Dmitry Olshansky]

On 31-Jul-12 21:35, Stuart wrote:

On Tuesday, 31 July 2012 at 10:59:49 UTC, Don Clugston wrote:


Yeah, we still have *miles* to go on the toolchain. As a community
we've been putting most of our effort into getting the compiler
stable, and to a lesser extent working on the the standard library.
Most of the other things are one-man shows.
The Eclipse plugin and DFL have both been abandoned for years.
Mono-D and VisualD are progressing quite well but again they are only
one-man shows.

We need more people.


Agreed. I don't know if I can help much - I'm not an expert on low-level
things like compilers and such, and I do my best work in .NET; but there
may be something I can do. Maybe write a better IDE, with intellisense,
I dunno. It'd have to be .NET based.



Mono-D is .NET based. You can provide some help for its developer  since 
it's not working for you, a good first step would be to identify problem 
and fix it.



--
Dmitry Olshansky

Re: UTF8 + SIMD = win

[bearophile]

Walter Bright:

SIMD isn't going to speed things up at all for decoding one 
character. It is for transcoding a large array.


Right.
Maybe you remember my two or three posts about vectorized 
lazynesss and related matters (that later was a bit implemented 
in the half-eager map of std.parallelism). Introducing some 
vectorized lazyness in std.algorithm when the iterable is a UTF-8 
(or rarely UTF-16) string allows to use SIMD and probably leads 
to higher performance.


Bye,
bearophile

Re: Incomprehensible compiler errors

[Minas]

I'm currently using Mono-D in Monodevelop and it's working really 
well. Just make sure you install Monodevelop 3.0+

Re: Incomprehensible compiler errors

[Minas]

On Tuesday, 31 July 2012 at 20:26:06 UTC, Minas wrote:
I'm currently using Mono-D in Monodevelop and it's working 
really well. Just make sure you install Monodevelop 3.0+


And intellisense is working really well!

Re: Incomprehensible compiler errors

[Jacob Carlborg]

On 2012-07-31 19:30, Stuart wrote:


Of course it's *my* opinion. Whose else opinion would it be?

And that's just the point. I'm *not* using D. I *want* to be using D,
and I've been *trying* to use D, but I keep hitting strange compiler
errors and libraries that won't compile (i.e. DFL).

I like D. It's been well-thought-out. But without tools, how can it be
used? Yeah, I know, many of you don't use IDEs - but tell me this. How
can I write a GUI? Whether you like GUIs is beside the point:
Applications need them. There's no point writing a decent-sized program
without one. And yet (without DFL) you have no library support for them
whatsoever. To create a window or a button, I must use CreateWindow().
To handle events, I must use GetMessageA(). To resize controls when the
parent window changes size, I have to do it all by hand, in code.

DFL and intellisense. Those are the areas this project is lacking.


Have a look at DWT, I think it should work with DMD 2.059.

http://dsource.org/projects/dwt
https://github.com/d-widget-toolkit/dwt

--
/Jacob Carlborg

Re: Incomprehensible compiler errors

[Ettienne]

On Monday, 30 July 2012 at 22:54:59 UTC, Stuart wrote:

On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote:


A ModuleInfo is generated for each compiled module and 
inserted into its corresponding .obj file. If the linker 
cannot find it, then it is likely that you need to specify 
that .obj on the link command.


Ah, it would seem that my problem is with DFL not compiling. 
Look guys, I'm about ready to give up here. I like the idea of 
D, but it's like using fucking Linux: Absolutely everything 
needs to be compiled before you can use it; and nothing will 
compile because you need to do fifty other goddamn things that 
aren't mentioned in the readme, so you have to post on dozens 
of sodding forums for a week hoping someone throws you a bone.


I really empathize with you - I went through similar pains when I 
started using DFL some years ago (along with VisualD). In the end 
it wasn't too bad, but there are some "catcha"s to be aware of. 
So I figure the best I can do for you (and to avoid one extremely 
long message) is to do a blog posting on this - see 
http://objectmonkey.wordpress.com/2012/07/31/using-dfl-with-visuald/.


Hope it helps!

All I want is to be able to write a GUI application using 
phrases like "button1.dock = Fill". Is that so much to ask? 
Apparently it is.


DFL won't compile. D-IDE doesn't work at all. VisualD crashes 
all the time. The Eclipse IDE plugin doesn't work either. None 
of the IDEs have any kind of reliable intellisense. The 
optional "module" keywords aren't optional. The whole fucking 
thing's a shambles, just like everything else designed for 
Linux.


It's really getting on my tits. Even using MFC is easier than 
this.


Actually, if you are stuck in Windows land and really need to use 
VS for whatever reason (and don't need portability to other OS's) 
I found the DFL+VisualD combo to be acceptable for doing GUI 
development. It isn't as polished as C#/Delphi/C++ Builder as far 
as all the RAD Form stuff goes, but it is useable - so hang in 
there!


Ettienne

Re: Let's stop parser Hell

[Philippe Sigaud]

On Tue, Jul 31, 2012 at 7:29 PM, Tobias Pankrath  wrote:
> On Tuesday, 31 July 2012 at 16:10:14 UTC, Kai Meyer wrote:
>
>> 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.
>
>
> Every helping hand is appreciated :-)

Hi Kai, welcome here!

>> 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.
>
>
> Yes. To make this statement more precise: We need a lexer that provides
> a range of tokens and we need a parser which makes it possible to build
> an AST. Pegged combines both approaches but imposes an overhead if you
> just need a token list. However I'm not sure if this is a problem.

I think we need a tokenizer generator and a parser generator. They can
be grouped or not, but we need both, in Phobos.

We also need to define what's needed in a token. Kai's approach is OK,
but what's the _type field for an operator or and identifier?
Also, a lexer can fill a symbol table and produce identifier tokens
that refer to a particular entry in the symbol table.

I guess creating a tree of symbol tables according to scope visibility
is then more the job of the parser, but I'm not sure.


> There are already some working D-Parsers buried in this thread.

Yes. We also need a D parser (not generic), but no one pushed one for
Phobos inclusion right now.
Anyway, we can put generic parsers in Phobos too (LALR, LL(*), etc),
but I'd say the first priority would be to have a D lexer (producing a
range of tokens) and a D parser (consuming a range of tokens, and
executing semantic actions, like the building of an AST). Generic
parsers can come later on. Having a D parser in the standard
distribution would create much goodwill. Many people want that.


> I've only glimpsed at your code. For most languages lexing is far more
> expensive then parsing

Is that so?

> and thus the lexer has to be very fast and I wouldn't
> pursue your approach and instead use something like ragel. It already has D
> output but needs a separate build step.

Having std.lexer in Phobos would be quite good. With a pre-compiled lexer for D.

The only problem I see in Kai's approach (which is the standard one, a
prioritized list of regexes) is how to recognize tokens that are not
regular (I mean, that cannot be encoded as a regex), like nesting
comments? How does the lexer know when to stop producing a 'comment'
token?

Philippe

Re: Let's stop parser Hell

[Jonathan M Davis]

On Tuesday, July 31, 2012 23:10:37 Philippe Sigaud wrote:
> Having std.lexer in Phobos would be quite good. With a pre-compiled lexer
> for D.

I'm actually quite far along with one now - one which is specifically written 
and optimized for lexing D. I'll probably be done with it not too long after 
the 2.060 release (though we'll see). Writing it has been going surprisingly 
quickly actually, and I've already found some bugs in the spec as a result 
(some of which have been fixed, some of which I still need to create pull 
requests for). So, regardless of what happens with my lexer, at least the spec 
will be more accurate.

- Jonathan M Davis

Re: Let's stop parser Hell

[Dmitry Olshansky]

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!


--
Dmitry Olshansky

Re: Let's stop parser Hell

[Tobias Pankrath]

On Tuesday, 31 July 2012 at 21:10:52 UTC, Philippe Sigaud wrote:
I've only glimpsed at your code. For most languages lexing is 
far more

expensive then parsing


Is that so?


I have no numbers. It's a statement that I found in some (1-3) 
sources about parsing. I'll share if I can find them.



and thus the lexer has to be very fast and I wouldn't
pursue your approach and instead use something like ragel. It 
already has D

output but needs a separate build step.


Having std.lexer in Phobos would be quite good. With a 
pre-compiled lexer for D.


Yeah.

Re: Let's stop parser Hell

[Philippe Sigaud]

On Tue, Jul 31, 2012 at 11:20 PM, Jonathan M Davis  wrote:
> On Tuesday, July 31, 2012 23:10:37 Philippe Sigaud wrote:
>> Having std.lexer in Phobos would be quite good. With a pre-compiled lexer
>> for D.
>
> I'm actually quite far along with one now - one which is specifically written
> and optimized for lexing D. I'll probably be done with it not too long after
> the 2.060 release (though we'll see).

That was quick! Cool!

>Writing it has been going surprisingly
> quickly actually, and I've already found some bugs in the spec as a result
> (some of which have been fixed, some of which I still need to create pull
> requests for). So, regardless of what happens with my lexer, at least the spec
> will be more accurate.

Could you please describe the kind of token it produces?
Can it build a symbol table?
Does it recognize all kind of strings (including q{ } ones)?
How does it deal with comments, particularly nested ones?
Does it automatically discard whitespaces or produce them as a token?
I'd favor this approach, if only because wrapping the lexer in a
filter!noWS(tokenRange) is easy.
Does it produce a lazy range btw?

Re: Let's stop parser Hell

[Dmitry Olshansky]

On 01-Aug-12 01:10, Philippe Sigaud wrote:

On Tue, Jul 31, 2012 at 7:29 PM, Tobias Pankrath  wrote:

On Tuesday, 31 July 2012 at 16:10:14 UTC, Kai Meyer wrote:


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.



Every helping hand is appreciated :-)


Hi Kai, welcome here!


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.



Yes. To make this statement more precise: We need a lexer that provides
a range of tokens and we need a parser which makes it possible to build
an AST. Pegged combines both approaches but imposes an overhead if you
just need a token list. However I'm not sure if this is a problem.


I think we need a tokenizer generator and a parser generator. They can
be grouped or not, but we need both, in Phobos.

We also need to define what's needed in a token. Kai's approach is OK,
but what's the _type field for an operator or and identifier?
Also, a lexer can fill a symbol table and produce identifier tokens
that refer to a particular entry in the symbol table.


Yeah.


I guess creating a tree of symbol tables according to scope visibility
is then more the job of the parser, but I'm not sure.


Parser can use constant IDs for nested tables, IDs point to string table.
String table is populated by lexer.



I've only glimpsed at your code. For most languages lexing is far more
expensive then parsing


Is that so?


It usually is. Unless parser is overly generic as GLL/GLR (not to claim 
that it's very slow but GLL/GLR are slower for obvious reasons).





and thus the lexer has to be very fast and I wouldn't
pursue your approach and instead use something like ragel. It already has D
output but needs a separate build step.


Have to agree here if anything a better DFA generator is needed, current 
std.regex can't get as good in this field because of:


a) irregularities like lookahed/lookbehind/etc. in patterns (avoided in 
ctRegex via codegen)
b) full unicode features commitment (again expect some improvement here 
in near future)

c) designed to take multiple captures from matched piece of text.

I'm not sure when (or even if) std.regex will ever special case all of 
the above.




Having std.lexer in Phobos would be quite good. With a pre-compiled lexer for D.

The only problem I see in Kai's approach (which is the standard one, a
prioritized list of regexes) is how to recognize tokens that are not
regular (I mean, that cannot be encoded as a regex), like nesting
comments?


See below.


How does the lexer know when to stop producing a 'comment'
token?


Call special function skipComment when lexer hits comment_start pseudotoken.

Typically lexeres are regular as it allows them to be fast.


--
Dmitry Olshansky

Re: OT: phobos name

[akaz]

On Tuesday, 31 July 2012 at 14:32:01 UTC, Dejan Lekic wrote:
That, on the other hand, was known to me. What I did not know, 
was the "fear" factor... Maybe the library should have been 
renamed to Deimos? :)


What do you think where the term "PHOBia" came from??


That, for one, I missed it! Thanks!

Re: OT: phobos name

[akaz]

On Tuesday, 31 July 2012 at 14:32:01 UTC, Dejan Lekic wrote:
That, on the other hand, was known to me. What I did not know, 
was the "fear" factor... Maybe the library should have been 
renamed to Deimos? :)


What do you think where the term "PHOBia" came from??


And what about PHOBos? (PHOB Operating System)

Just kidding. I stop here.

Re: UTF8 + SIMD = win

[jerro]

On Tuesday, 31 July 2012 at 19:41:02 UTC, Tobias Pankrath wrote:

On Tuesday, 31 July 2012 at 19:28:03 UTC, Walter Bright wrote:

On 7/31/2012 5:24 AM, Jakob Ovrum wrote:

On Tuesday, 31 July 2012 at 12:11:25 UTC, bearophile wrote:

Bernard Helyer:


Where is UTF-32 actually used?


I think all std.algorithm and std.range yield UTF-32 dchars, 
when you give

them a string in input.

Bye,
bearophile


In addition, foreach over a string with a dchar loop variable 
does implicit

UTF-8 decoding.



SIMD isn't going to speed things up at all for decoding one 
character. It is for transcoding a large array.


You could decode them in advance.


The problem is you don't know how much you are going to need.
This would actually hurt performance in some cases.

Re: Let's stop parser Hell

[Philippe Sigaud]

On Tue, Jul 31, 2012 at 11:38 PM, Dmitry Olshansky
 wrote:

>> I guess creating a tree of symbol tables according to scope visibility
>> is then more the job of the parser, but I'm not sure.
>>
> Parser can use constant IDs for nested tables, IDs point to string table.
> String table is populated by lexer.

The latter, I get. The former, not so much.


>>> I've only glimpsed at your code. For most languages lexing is far more
>>> expensive then parsing
>>
>>
>> Is that so?
>
>
> It usually is. Unless parser is overly generic as GLL/GLR (not to claim that
> it's very slow but GLL/GLR are slower for obvious reasons).

I'd have thought that, seeing as 'the end result' is more complicated
(richer, if I may say so) for parsing, then parsing is more expensive.
I'm reading on GLR, and was wondering what the practical limits are.
Do people use GLR to parse thousands of pages of text?


> Have to agree here if anything a better DFA generator is needed, current
> std.regex can't get as good in this field because of:
>
> a) irregularities like lookahed/lookbehind/etc. in patterns (avoided in
> ctRegex via codegen)
> b) full unicode features commitment (again expect some improvement here in
> near future)
> c) designed to take multiple captures from matched piece of text.
>
> I'm not sure when (or even if) std.regex will ever special case all of the
> above.

Well,

- for a lexer lookahead is sometimes useful (the Dragon book cite the
FORTRAN grammar, for which keywords are not reserved and so when you
encounter IF, you don't know if (!) it's a function call or a 'real'
if)
- Unicode is needed to lex D correctly, no?
- multiple captures doesn't seem necessary *for a lexer*


>> How does the lexer know when to stop producing a 'comment'
>> token?
>
>
> Call special function skipComment when lexer hits comment_start pseudotoken.

Ah, and this special function must somehow maintain a stack, to
'count' the comment_start and comment_end pseudotokens. So in a way,
it quits the regular world to become temporarily more powerful.

> Typically lexeres are regular as it allows them to be fast.

Hmm, but then it has to treat comments a one token. So no Ddoc love?

Re: Let's stop parser Hell

[Jonathan M Davis]

On Tuesday, July 31, 2012 23:39:38 Philippe Sigaud wrote:
> On Tue, Jul 31, 2012 at 11:20 PM, Jonathan M Davis  
wrote:
> > On Tuesday, July 31, 2012 23:10:37 Philippe Sigaud wrote:
> >> Having std.lexer in Phobos would be quite good. With a pre-compiled lexer
> >> for D.
> > 
> > I'm actually quite far along with one now - one which is specifically
> > written and optimized for lexing D. I'll probably be done with it not too
> > long after the 2.060 release (though we'll see).
> 
> That was quick! Cool!

Yeah. Once I started on it, I made a lot of progress really quickly. There's 
still a fair bit to do (primarily having to do with literals), but it probably 
won't take all that much longer. Certainly, I'd expect to have it done within 
a couple of weeks if not sooner, unless something goes wrong.

> >Writing it has been going surprisingly
> >
> > quickly actually, and I've already found some bugs in the spec as a result
> > (some of which have been fixed, some of which I still need to create pull
> > requests for). So, regardless of what happens with my lexer, at least the
> > spec will be more accurate.
> 
> Could you please describe the kind of token it produces?
> Can it build a symbol table?
> Does it recognize all kind of strings (including q{ } ones)?
> How does it deal with comments, particularly nested ones?
> Does it automatically discard whitespaces or produce them as a token?
> I'd favor this approach, if only because wrapping the lexer in a
> filter!noWS(tokenRange) is easy.
> Does it produce a lazy range btw?

Well, it's still a work in progress, so it certainly can be adjusted as 
necessary. I intend it to fully implement the spec (and make sure that both it 
and the spec match what dmd is doing) as far as lexing goes. The idea is that 
you should be able to build a fully compliant D parser on top of it and build 
a fully compliant D compiler on top of that.

It already supports all of the comment types and several of the string literal 
types. I haven't sorted out q{} yet, but I will before I'm done, and that may 
or may not affect how some things work, since I'm not quite sure how to handle 
q{} yet (it may end up being done with tokens marking the beginning and end of 
the token sequence encompassed by q{}, but we'll see). I'm in the middle of 
dealing with the named entity stuff at the moment, which unfortunately has 
revealed a rather nasty compiler bug with regards to template compile times, 
which I still need to report (I intend to do that this evening). The file 
generating the table of named entities currently takes over 6 minutes to 
compile on my Phenom II thanks to that bug, so I'm not quite sure how that's 
going to affect things. Regardless, the lexer should support _everything_ as 
far as what's required for fully lexing D goes by the time that I'm done.

I don't have the code with me at the moment, but I believe that the token type 
looks something like

struct Token
{
 TokenType type;
 string str;
 LiteralValue value;
 SourcePos pos;
}

struct SourcePos
{
 size_t line;
 size_ col;
 size_t tabWidth = 8;
}

The type is an enum which gives the type of the token (obviously) which 
includes the various comment types and an error type (so errors are reported 
by getting a token that was an error token rather than throwing or anything 
like that, which should make lexing passed malformed stuff easy).

str holds the exact text which was lexed (this includes the entire comment for 
the various comment token types), which in the case of lexing string rather 
than another range type would normally (always? - I don't remember) be a slice 
of the string being lexed, which should help make lexing string very efficient. 
It may or may not make sense to change that to the range type used rather than 
string. For nesting block comments, the whole comment is one token (with the 
token type which is specifically for nested comments), regardless of whether 
there's any nesting going on. But that could be changed if there were a need 
to get separate tokens for the comments inside.

LiteralValue is a VariantN of the types that a literal can be (long, ulong, 
real, and string IIRC) and is empty unless the token is a literal type (the 
various string postfixes - c,w, and d - are treated as different token types 
rather than giving the literal value different string types - the same with the 
integral and floating point literals).

And pos holds the position in the text where the token started, which should 
make it easy to use for syntax highlighting and the like (as well as 
indicating where an error occurred). The initial position is passed as an 
optional argument to the lexing function, so it doesn't have to be 1:1 (though 
that's the default), and it allows you to select the tabwidth.

So, you'll pass a range and an optional starting position to the lexing 
function, and it'll return a lazy range of Tokens. Whitespace is stripped as 
part of the lexing process, but if you take the pos prope

Re: OT: phobos name

[Joseph Rushton Wakeling]

On 31/07/12 14:32, akaz wrote:

Fear&Dread


D: striking fear and dread into all other programming languages since 1893. ;-)

Re: Let's stop parser Hell

[Timon Gehr]

On 08/01/2012 12:01 AM, Philippe Sigaud wrote:

On Tue, Jul 31, 2012 at 11:38 PM, Dmitry Olshansky
 wrote:

Typically lexeres are regular as it allows them to be fast.


Regularity of the language is not required for speed.



Hmm, but then it has to treat comments a one token. So no Ddoc love?


Ddoc is typically not required. By default it should be treated as
whitespace. If it is required, one token seems reasonable: The
post-processing of the doc comment is best done as a separate step.

Re: Let's stop parser Hell

[Jonathan M Davis]

On Wednesday, August 01, 2012 00:54:56 Timon Gehr wrote:
> Ddoc is typically not required. By default it should be treated as
> whitespace. If it is required, one token seems reasonable: The
> post-processing of the doc comment is best done as a separate step.

That was how I was intending to deal with ddoc. It's just a nested block 
comment token. The whole comment string is there, so the ddoc processor can 
use that to do whatever it does. ddoc isn't part of lexing really. It's a 
separate thing.

- Jonathan M Davis

Re: OT: phobos name

[Nick Sabalausky]

On Tue, 31 Jul 2012 15:16:56 +0200
"akaz"  wrote:

> According to Wikipedia:
> 
> "Phobos (Ancient Greek: Φόβος, pronounced [pʰóbos], 
> meaning "fear" or "terror") is the personification of fear in 
> Greek mythology."
> 
> http://en.wikipedia.org/wiki/Phobos_(mythology)
> 
> I just discovered that. I find it surprisingly. Fear 
> Terror
> 

"Phobos and Deimos ("fear" and "dread")"

That's really awesome, actually. C++/Java/Python and the like should
PHear us :)

So does that make one of the Deimos maintainers Judge Dredd?

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 19:07:52 UTC, q66 wrote:

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc 
in Software Engineering, and I've been coding for 16 years. So 
let's have less of the condescension, hmm?


errr I meant this :)


If I don't point out that I know something, I'm ignorant. And 
when I do, I'm a showoff. I can't win.


Maybe I should just give up on this "friendly and helpful 
community" I've heard so much about.

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 18:53:43 UTC, Bernard Helyer wrote:

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:


Er, no. Before I used .NET, I used C++ almost exclusively for 
a number of years. I'm a little out of practice, but I 
understand the general principles involved.


No you don't, or you wouldn't have asked the question in the 
first

place.


Ah, so I'm a liar. Right.


You have a lot to learn and you should know that by now.


Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc 
in Software Engineering, and I've been coding for 16 years.


Well jesus, a BSc, aren't you just a fucking genius.


Fuck off. Stop wasting our time.


If this is what you guys on here consider a friendly and helpful 
attitude, I'm not impressed. You in particular, Bernard, can suck 
my rosy red arse, you rude objectionable scrote.


I notice nobody else at all has objected to my being told to fuck 
off and stop wasting people's time. I guess it's okay for people 
to talk to me like that, yes?


I can just fuck off if everyone would rather. After this blatant 
abuse - which has gone unremarked, it seems - I'm seriously 
considering leaving.

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 19:05:07 UTC, Andrej Mitrovic wrote:


I've had some success with using DGui, which seems to be 
loosely based

on DFL. http://code.google.com/p/dgui/


I can't find any trace of documentation on that site.

Re: Incomprehensible compiler errors

[Jonathan M Davis]

On Wednesday, August 01, 2012 02:44:55 Stuart wrote:
> On Tuesday, 31 July 2012 at 19:07:52 UTC, q66 wrote:
> > On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
> >> Oh, now, that's going too far. Do you think I'm some kind of
> >> programming newbie? A college student, perhaps? I have a BSc
> >> in Software Engineering, and I've been coding for 16 years. So
> >> let's have less of the condescension, hmm?
> > 
> > errr I meant this :)
> 
> If I don't point out that I know something, I'm ignorant. And
> when I do, I'm a showoff. I can't win.
> 
> Maybe I should just give up on this "friendly and helpful
> community" I've heard so much about.

Well, I think that on a whole, the community is friendly and helpful, but 
that's not always the case, and there _have_ been some rather rude responses 
in this thread unfortunately.

- Jonathan M Davis

Re: Incomprehensible compiler errors

[Jonathan M Davis]

On Wednesday, August 01, 2012 02:48:43 Stuart wrote:
> I notice nobody else at all has objected to my being told to fuck
> off and stop wasting people's time. I guess it's okay for people
> to talk to me like that, yes?

I don't agree with Bernard at all (and for the most, I don't think that anyone 
else does either). It's just that I generally ignore nasty comments and 
trolls. I also suspect that given the length of this thread, there are plenty 
of people who never read his response, which would at least partially explain 
why no one has spoken up about it. Bernard has said some good things on this 
list before, so he's not a complete troll, but he _does_ seem to get very 
rude, very quickly, which is a detriment to the community as evidenced by your 
response. And his response in this case was particularly rude. If he doesn't 
want to help you, he doesn't need to respond. Rudeness helps no one.

- Jonathan M Davis

Re: Incomprehensible compiler errors

[Timon Gehr]

On 08/01/2012 02:44 AM, Stuart wrote:

On Tuesday, 31 July 2012 at 19:07:52 UTC, q66 wrote:

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:

Oh, now, that's going too far. Do you think I'm some kind of
programming newbie? A college student, perhaps? I have a BSc in
Software Engineering, and I've been coding for 16 years. So let's
have less of the condescension, hmm?


errr I meant this :)


If I don't point out that I know something, I'm ignorant.
And when I do, I'm a showoff. I can't win.



- Why would it be interesting to talk about whether someone 'knows
  something' or not? This is d.D.

- Why is it important whether or not some random guy on
  the internet thinks some statements are ignorant?

- Besides, the statement does not even make sense. Who would respond to
  something that was not posted?


Maybe I should just give up on this "friendly and helpful community"
I've heard so much about.


Why? It is friendly and helpful. Even more so if it is treated as such.

Re: Incomprehensible compiler errors

[Andrei Alexandrescu]

On 7/31/12 8:48 PM, Stuart wrote:

I notice nobody else at all has objected to my being told to fuck off
and stop wasting people's time. I guess it's okay for people to talk to
me like that, yes?


I've also been surprised by Bernard's exaggerated reaction. Your vent 
was not the most unreasonable out there. This is an unmoderated 
newsgroup and although personal attacks do happen, they are very rare.



I can just fuck off if everyone would rather. After this blatant abuse -
which has gone unremarked, it seems - I'm seriously considering leaving.


Are you threatening to leave an online forum? Now this is exactly the 
kind of immature thing that won't help any. No, personal attacks are not 
welcome here, but you needn't have an emotional answer to a head hotter 
than yours.



Andrei

Re: Incomprehensible compiler errors

[Stuart]

On Wednesday, 1 August 2012 at 01:10:30 UTC, Andrei Alexandrescu 
wrote:
I've also been surprised by Bernard's exaggerated reaction. 
Your vent was not the most unreasonable out there.


Mm. I just got really frustrated at not being able to use this 
interesting new language.


(Which, incidentally, I still cannot do because the (helpful, 
constructive) suggestions for compiling DFL or finding 
alternatives have not, in fact, worked.)


I can just fuck off if everyone would rather. After this 
blatant abuse -
which has gone unremarked, it seems - I'm seriously 
considering leaving.


Are you threatening to leave an online forum? Now this is 
exactly the kind of immature thing that won't help any.


Threatening? No. I was simply being honest. After that entirely 
undeserved attack, I was considering leaving the forum and giving 
up on D. Some people are trying to help me and are being 
constructive; but some have been complete pricks, and that's 
really not helping my enthusiasm for the project.

Re: Incomprehensible compiler errors

[Stuart]

On Wednesday, 1 August 2012 at 01:12:37 UTC, Timon Gehr wrote:

On 08/01/2012 02:44 AM, Stuart wrote:

If I don't point out that I know something, I'm ignorant.
And when I do, I'm a showoff. I can't win.



- Why would it be interesting to talk about whether someone 
'knows something' or not? This is d.D.


I didn't say it was interesting. I was called ignorant, and it 
was implied that I was a programming newbie. So I pointed out 
that I was not. And then got a bunch of flak for that too.



- Why is it important whether or not some random guy on
  the internet thinks some statements are ignorant?


I assumed that most people who posted on this forum were relevant 
to the project. I mean, it's hardly a subject that should attract 
random trolls, I would've thought.


Maybe I should just give up on this "friendly and helpful 
community" I've heard so much about.


Why? It is friendly and helpful. Even more so if it is treated 
as such.


Some of it is, yes. But the ones who aren't are spoiling it 
somewhat. And as I say, I assumed everyone on this forum was 
either a dev or a user. I wasn't expecting drive-by trolling.


And yes, I may have been a little negative in this thread, but 
it's because I really found D interesting and wanted to use it; 
and discovered that I couldn't.

Re: Incomprehensible compiler errors

[q66]

On Wednesday, 1 August 2012 at 00:44:56 UTC, Stuart wrote:

On Tuesday, 31 July 2012 at 19:07:52 UTC, q66 wrote:

On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Oh, now, that's going too far. Do you think I'm some kind of 
programming newbie? A college student, perhaps? I have a BSc 
in Software Engineering, and I've been coding for 16 years. 
So let's have less of the condescension, hmm?


errr I meant this :)


If I don't point out that I know something, I'm ignorant. And 
when I do, I'm a showoff. I can't win.


Maybe I should just give up on this "friendly and helpful 
community" I've heard so much about.


You are ignorant, no matter whether you have a BSc in software 
engineering or not; you've had enough chances to prove that you 
are. Also, maybe you should - I don't think anybody really gives 
a fuck.

Re: Incomprehensible compiler errors

[q66]

Bernard's reaction was entirely reasonable, spewing ignorant 
bullshit all around and then being like "hurr durr i have a bsc 
from software engineering, no wai" deserves no better.


By the way, he's only proving what I said with these "hurrr I'm 
gonna leave" responses (not that it wasn't apparent before). With 
this attitude, I can say only one thing: "fuck off faggot"

Re: Incomprehensible compiler errors

[q66]

On Wednesday, 1 August 2012 at 01:10:30 UTC, Andrei Alexandrescu 
wrote:

On 7/31/12 8:48 PM, Stuart wrote:
I notice nobody else at all has objected to my being told to 
fuck off
and stop wasting people's time. I guess it's okay for people 
to talk to

me like that, yes?


I've also been surprised by Bernard's exaggerated reaction. 
Your vent was not the most unreasonable out there. This is an 
unmoderated newsgroup and although personal attacks do happen, 
they are very rare.


I can just fuck off if everyone would rather. After this 
blatant abuse -
which has gone unremarked, it seems - I'm seriously 
considering leaving.


Are you threatening to leave an online forum? Now this is 
exactly the kind of immature thing that won't help any. No, 
personal attacks are not welcome here, but you needn't have an 
emotional answer to a head hotter than yours.



Andrei


Bernard's reaction was entirely reasonable, spewing ignorant 
bullshit all around and then being like "hurr durr i have a bsc 
from software engineering, no wai" deserves no better.

Re: Incomprehensible compiler errors

[Andrej Mitrovic]

On 8/1/12, Stuart  wrote:
> On Tuesday, 31 July 2012 at 19:05:07 UTC, Andrej Mitrovic wrote:
>>
>> I've had some success with using DGui, which seems to be
>> loosely based
>> on DFL. http://code.google.com/p/dgui/
>
> I can't find any trace of documentation on that site.
>

The docs can be generated via the compiler (it comes with a batch
script that does that). But if you want a stable GUI library GtkD is
probably your best bet.

Re: Incomprehensible compiler errors

[Andrei Alexandrescu]

On 7/31/12 9:39 PM, q66 wrote:

Bernard's reaction was entirely reasonable, spewing ignorant bullshit
all around and then being like "hurr durr i have a bsc from software
engineering, no wai" deserves no better.


By the way, he's only proving what I said with these "hurrr I'm gonna
leave" responses (not that it wasn't apparent before). With this
attitude, I can say only one thing: "fuck off faggot"


No reaction that strong is reasonable, regardless of context. It's not a 
civilized response to anything. Probably this meta-talk has long run its 
course. We're one Hitler mention away from complete mayhem :o).


All - please, let's stay civil. It's obvious this is helping no one and 
nothing. Let's keep this forum focused on interesting technical topics 
as it's always been. Freedom of word is most liberating when used 
judiciously.



Thanks much,

Andrei

Re: Incomprehensible compiler errors

[Walter Bright]

On 7/31/2012 10:35 AM, Stuart wrote:

Agreed. I don't know if I can help much - I'm not an expert on low-level things
like compilers and such, and I do my best work in .NET; but there may be
something I can do. Maybe write a better IDE, with intellisense, I dunno. It'd
have to be .NET based.


Any help you can give will be most appreciated by the D community.

Re: Allocating Executable Memory

[Vladimir Panteleev]

On Tuesday, 31 July 2012 at 17:23:08 UTC, Maxime Chevalier wrote:
New to the D language here. I'm working on a tracing JIT 
compiler and will need to allocate chunks of memory that are 
marked as executable.


Is there a standard way of doing this in D, or do I need to 
directly call into mprotect? If I'm going to be calling 
mprotect, what's the cleanest way to do that, do I need to 
declare my own prototype for the function and its flags, or 
should I write some C code that does the call?


Thanks for your help.


Hope this helps:
http://stackoverflow.com/a/8656294/21501

Re: Incomprehensible compiler errors

[Timon Gehr]

On 08/01/2012 03:27 AM, Stuart wrote:

On Wednesday, 1 August 2012 at 01:12:37 UTC, Timon Gehr wrote:

On 08/01/2012 02:44 AM, Stuart wrote:

If I don't point out that I know something, I'm ignorant.
And when I do, I'm a showoff. I can't win.



- Why would it be interesting to talk about whether someone 'knows
something' or not? This is d.D.


I didn't say it was interesting. I was called ignorant,


Some of your statements were called like that. Those certainly were
irrelevant to the topic.


and it was implied that I was a programming newbie.


A D newcomer.


...

Maybe I should just give up on this "friendly and helpful community"
I've heard so much about.


Why? It is friendly and helpful. Even more so if it is treated as such.


Some of it is, yes.  But the ones who aren't are spoiling it somewhat.


Joining the former group would be a good start to making the latter
group significantly smaller.


And as I say, I assumed everyone on this forum was either a dev or a
user. I wasn't expecting drive-by trolling.

And yes, I may have been a little negative in this thread,


That is an understatement.


but it's  because I really found D interesting and wanted to use it; and
discovered that I couldn't.



Your best bet is to ask politely and to keep the question short and to 
the point. Also, pushing the blame away is inflammatory and irrelevant,

so discussing whom is to blame can be omitted. Meta-discussions like
this one can be omitted just as well. They serve no purpose other than
avoiding meta-discussions in the future.

Re: Incomprehensible compiler errors

[Walter Bright]

On 7/31/2012 5:48 PM, Stuart wrote:

I notice nobody else at all has objected to my being told to fuck off and stop
wasting people's time. I guess it's okay for people to talk to me like that, 
yes?


Not many of us read all the posts. Is it ok for people to level such insults in 
this forum? I certainly think it is inappropriate.


But I do try and allow people to say whatever they want as much as possible. If 
you look hard enough in this forum, you'll find the occasional similar insult 
directed at me.


Such language, and attempts at trolling and baiting others tend to just be 
ignored.



I can just fuck off if everyone would rather. After this blatant abuse - which
has gone unremarked, it seems - I'm seriously considering leaving.


I certainly wish you'd stay. I don't believe Bernard is representative of our 
community.

Re: Incomprehensible compiler errors

[Bernard Helyer]

On Wednesday, 1 August 2012 at 02:00:05 UTC, Andrei Alexandrescu 
wrote:

On 7/31/12 9:39 PM, q66 wrote:
No reaction that strong is reasonable, regardless of context.


Perhaps not.

It's not a civilized response to anything. Probably this 
meta-talk has long run its course. We're one Hitler mention 
away from complete mayhem :o).


Appeasement, eh? JUST LIKE CHAMBERLAIN


All - please, let's stay civil.


I'll admit, I came on a bit strong. Still, if I think someone's
being an arse, I'm going to call it like I see it. New comer or
not. I'm not being a paid support rep here, I'll give back snark
in return.

Now Stuart, I'll apologise if I have caused offense, and offer
a question -- where are you getting your DFL sources from?

Re: Incomprehensible compiler errors

[Walter Bright]

On 7/31/2012 6:27 PM, Stuart wrote:

I wasn't expecting drive-by trolling.


Well, there is one guy we all know & love who changes his pseudonym weekly and 
posts some incomprehensible drunken rants & insults late Saturday nights :-)

Re: Incomprehensible compiler errors

[Stuart]

On Wednesday, 1 August 2012 at 02:35:13 UTC, Bernard Helyer wrote:

Now Stuart, I'll apologise if I have caused offense, and offer
a question -- where are you getting your DFL sources from?


You'll apologise if telling me to fuck off and stop wasting 
everyone's time caused offence? Oooh, I dunno how likely that 
might be. I want no help from an unreasonable twat like you.


Incidentally, I was getting the DFL sources from the official 
repository.


On Wednesday, 1 August 2012 at 01:30:07 UTC, q66 wrote:
You are ignorant, no matter whether you have a BSc in software 
engineering or not; you've had enough chances to prove that you 
are. Also, maybe you should - I don't think anybody really 
gives a fuck.


Bernard's reaction was entirely reasonable, spewing ignorant 
bullshit all around and then being like "hurr durr i have a bsc 
from software engineering, no wai" deserves no better.


"fuck off faggot"


Uhuh. Another cock.

Any help you can give will be most appreciated by the D 
community.


If this kind of abuse is indicative of the "D community", I'll 
keep my help to myself.


I certainly wish you'd stay. I don't believe Bernard is 
representative of our community.


Perhaps not, but he's certainly lowering my opinion of this forum 
and its members. I would like to point out AGAIN that my claim of 
a BSc in Software Engineering was not bragging; but simply a 
statement that I was not "ignorant" of the general principles of 
coding and of C/C++. I fail to see why it has immediately earned 
me large amounts of abuse.


While I appreciate the help of some people on here, it seems this 
forum is populated at least 50% by complete cocks. Also, as it 
stands, D is NOT USABLE for any serious purpose (such as writing 
an application); and I'm not prepared to put up with the level of 
abuse and trolling that's coming my way. You may notice I 
insulted nobody who didn't insult me first.


I don't mind a bit of banter and bad language, but I draw the 
line at personal attacks. Either they stop or I do.

Re: Incomprehensible compiler errors

[Chris Cain]

Stuart, I highly recommend you reread the first 4 pages of this 
topic. You should notice everyone trying to help you and give you 
information on what was going on. You should also notice (if you 
make any attempt at all to pay attention) that your posts were 
fairly confrontational and could be interpreted to be insulting 
(by "could be", I mean "has", at this point, of course).


You responded to peoples' escalations with more escalations. 
Obviously, that almost never works and has simply fanned the 
flames.


Even now there are people trying to extend olive branches to you 
even though you continue to be insulting. If you continue this, 
you can only expect more people to join in on the conversation to 
give you a piece of their minds.


I recommend a break from this topic (permanently, ideally) and 
relax for awhile. You seem to be wound tight and there's no sense 
in taking your frustrations out on your fellow programmers like 
this.