Walter Bright a écrit :
> John A. De Goes wrote:
>> Without documentation on the format, the best I can do is to
>> experiment with the compiler and try to elicit all possible
>> errors/warnings. And hope they fall into a small number of consistent
>> patterns (which seems likely given that all the errors I encountered
>> so far matched the above patterns).
>>
>> Anyone having inside knowledge of the format care to save me some
>> time here? (Walter, you listening? :-)
> 
> No problem. dmd.zip comes with compiler source, just grep for calls to the function "error(". No need to experiment!

But some errors are reported in the closed-source part... :-(

Chris R. Miller wrote:
> Frank Benoit wrote:
>> Chris R. Miller schrieb:
>>
>>> Well there's your problem!  Come back later when you're educated.
>>
>> Why are you so unfriendly?
> 
> Editors made by people who don't use the language - rather, by people who don't even know the language at all - are as a general rule very bad.
> 
> I'm a firm believer in using the software you make, so people who toss in a few features to rope in a little more market share tend to tick me off.  Go big or go home, either do it right or not at all in my mind.
> 

The more competition the better I say.  If people decide they don't like  n-brain, they won't use it.  Let the people decide.  Having D in yet another editor gives people choice.  Its yet another marketing resource for D.  The more people that use D the better support D will get.

Also many languages share the same core mechanics so having a multi-language editor is not all bad.  Hell, VS was never designed for Lua or DSL but I need to switch to that sometimes and I want to use something I'm familiar with.

-Joel

"John A. De Goes" <john.withoutspam.@n-brain.net> wrote in message news:g2rt5g$28e3$1@digitalmars.com...
> Hi,
>
> We're adding support for the D language to UNA (http://www.n-brain.net). The Personal Edition has been released free of charge (down from $100).
>
> However, none of us have used D so we'd like a bit of help.
>
> We've added support (in dev version) to matching messages of the form:
>
> foo.d(5): Warning: silly variable name
> foo.d(5): Error: spelling error in variable name "foobir"
>
> Assuming this is correct, we'd like to proceed with adding commonly used source code constructs, D idioms, and so forth. We call this 'source snippets'. Each source snippet has a few letter textual key. Typing that key and invoking the source snippet button inserts the snippet.
>
> So I'm soliciting for everyone's favorite source snippet.

I know this isn't what you're asking for, and maybe it's already in there (I haven't looked), but *please* make sure the syntax hightlighting *properly* supports both C-style block comments *and* D's nested block comments. It's a minor issue of course, but a real pet peeve of mine. Most of the D editors I've tried either highlight D's nested comments (ie, "/+ +/") as if they behaved like the non-nestable "/* */" comments, or don't even recognize them as comments at all.

BTW, Are you the same John De Goes that wrote a software-3D book about ten or so years ago? I still have that around here somewhere. Good book.

Ary Borenszweig wrote:
> Walter Bright a écrit :
>> John A. De Goes wrote:
>>
>>> Without documentation on the format, the best I can do is to
>>> experiment with the compiler and try to elicit all possible
>>> errors/warnings. And hope they fall into a small number of consistent
>>> patterns (which seems likely given that all the errors I encountered
>>> so far matched the above patterns).
>>>
>>> Anyone having inside knowledge of the format care to save me some
>>> time here? (Walter, you listening? :-)
>>
>> No problem. dmd.zip comes with compiler source, just grep for calls to the function "error(". No need to experiment!
> 
> But some errors are reported in the closed-source part... :-(

What's their format?
Do they ever contain file/line numbers?

Nick Sabalausky Wrote:
> I know this isn't what you're asking for, and maybe it's already in there (I haven't looked), but *please* make sure the syntax hightlighting *properly* supports both C-style block comments *and* D's nested block comments. It's a minor issue of course, but a real pet peeve of mine. Most of the D editors I've tried either highlight D's nested comments (ie, "/+ +/") as if they behaved like the non-nestable "/* */" comments, or don't even recognize them as comments at all.

I'll confess right now that all comments are nestable, even C-style comments. It's something we'll be addressing in a later issue. Personally, I've always been annoyed that comments couldn't be nested. Clearly an artifact of early primitive parser technology.

> BTW, Are you the same John De Goes that wrote a software-3D book about ten or so years ago? I still have that around here somewhere. Good book.

Yep, one and the same. As far as I know, there's exactly one "John De Goes" in the whole world, and he's sitting right here talking to you. :-)

Glad you enjoyed the book. I haven't done anything in the gaming industry for years, but I'm looking to get back into the industry, at least in a hobbyist role, later this year.

Regards,

John

If the error reporting is done through inheritance of the class 'Lexer', then they should obey the same general convention. Though I have no idea if the private part has an dependencies on the public part.

Regards,

John

Georg Wrede Wrote:
> Ary Borenszweig wrote:
> > Walter Bright a écrit :
> >> John A. De Goes wrote:
> >>
> >>> Without documentation on the format, the best I can do is to experiment with the compiler and try to elicit all possible errors/warnings. And hope they fall into a small number of consistent patterns (which seems likely given that all the errors I encountered so far matched the above patterns).
> >>>
> >>> Anyone having inside knowledge of the format care to save me some time here? (Walter, you listening? :-)
> >>
> >> No problem. dmd.zip comes with compiler source, just grep for calls to the function "error(". No need to experiment!
> > 
> > But some errors are reported in the closed-source part... :-(
> 
> What's their format?
> Do they ever contain file/line numbers?

John A. De Goes wrote:
> Nick Sabalausky Wrote:
>> I know this isn't what you're asking for, and maybe it's already in there (I haven't looked), but *please* make sure the syntax hightlighting *properly* supports both C-style block comments *and* D's nested block comments. It's a minor issue of course, but a real pet peeve of mine. Most of the D editors I've tried either highlight D's nested comments (ie, "/+ +/") as if they behaved like the non-nestable "/* */" comments, or don't even recognize them as comments at all.
> 
> I'll confess right now that all comments are nestable, even C-style comments. It's something we'll be addressing in a later issue. Personally, I've always been annoyed that comments couldn't be nested. Clearly an artifact of early primitive parser technology.
> 
>> BTW, Are you the same John De Goes that wrote a software-3D book about ten or so years ago? I still have that around here somewhere. Good book. 
> 
> Yep, one and the same. As far as I know, there's exactly one "John De Goes" in the whole world, and he's sitting right here talking to you. :-)
> 
> Glad you enjoyed the book. I haven't done anything in the gaming industry for years, but I'm looking to get back into the industry, at least in a hobbyist role, later this year.
> 
> Regards,
> 
> John

Maybe you'll consider D when you decide on a language for your new game.

-Joel

I wish -- D is really what C++ should have been, and wasn't. But my next 'hobbyist' foray into games will probably involve the browser-based casual gaming market.

Regards,

John

janderson Wrote:

> John A. De Goes wrote:
> > Nick Sabalausky Wrote:
> >> I know this isn't what you're asking for, and maybe it's already in there (I haven't looked), but *please* make sure the syntax hightlighting *properly* supports both C-style block comments *and* D's nested block comments. It's a minor issue of course, but a real pet peeve of mine. Most of the D editors I've tried either highlight D's nested comments (ie, "/+ +/") as if they behaved like the non-nestable "/* */" comments, or don't even recognize them as comments at all.
> > 
> > I'll confess right now that all comments are nestable, even C-style comments. It's something we'll be addressing in a later issue. Personally, I've always been annoyed that comments couldn't be nested. Clearly an artifact of early primitive parser technology.
> > 
> >> BTW, Are you the same John De Goes that wrote a software-3D book about ten or so years ago? I still have that around here somewhere. Good book.
> > 
> > Yep, one and the same. As far as I know, there's exactly one "John De Goes" in the whole world, and he's sitting right here talking to you. :-)
> > 
> > Glad you enjoyed the book. I haven't done anything in the gaming industry for years, but I'm looking to get back into the industry, at least in a hobbyist role, later this year.
> > 
> > Regards,
> > 
> > John
> 
> Maybe you'll consider D when you decide on a language for your new game.
> 
> -Joel

John A. De Goes wrote:
> I wish -- D is really what C++ should have been, and wasn't. But my next 'hobbyist' foray into games will probably involve the browser-based casual gaming market.

That really is a shame.  D has some great libraries to help you get started!  There's Arclib, which handles input, graphics, as well as sound.  It's based on OpenGL, so it's fast (but it's 2D, just floating sprites on the top of the view frustum).  There's also Derelict, which gives SDL/OpenGL/OpenAL support.  The there's also DAllegro (which I'm using at the moment) which gives you the Allegro game library (http://www.allegro.cc/).

If you want to try some web-based games, DDBI can handle the database layer, and FastCGI4D (http://dsource.org/projects/fastcgi4d) can handle the serving web pages part.

If you use D for the browser based stuff, you'll have the great advantage of not needing to sink all the extra money into a server with extra RAM to support J2EE, which can consume a frightful amount of memory!

Just something to think about.

John A. De Goes wrote:
> If the error reporting is done through inheritance of the class
> 'Lexer', then they should obey the same general convention. Though I
> have no idea if the private part has an dependencies on the public
> part.
> 
> Georg Wrede Wrote:
>> Ary Borenszweig wrote:
>>> Walter Bright a écrit :
>>>> John A. De Goes wrote:
>>>> 
>>>>> Without documentation on the format, the best I can do is to experiment with the compiler and try to elicit all possible errors/warnings. And hope they fall into a small number of
>>>>> consistent patterns (which seems likely given that all the
>>>>> errors I encountered so far matched the above patterns).
>>>>> 
>>>>> Anyone having inside knowledge of the format care to save me
>>>>> some time here? (Walter, you listening? :-)
>>>> 
>>>> No problem. dmd.zip comes with compiler source, just grep for
>>>> calls to the function "error(". No need to experiment!
>>> 
>>> But some errors are reported in the closed-source part... :-(
>> 
>> What's their format? Do they ever contain file/line numbers?

Thanks, John, for the (attempt to) answer.

I may have been too sloppy with my post, actually I was implicitly soliciting Walter's answer to this.

The proprietary part of the compiler (AFAICT) is from the legacy(?, and still maintained) C++ compiler that Walter's written for years ago (and which still is one of the fastest around, and especially, it's THE first C++-direct compiler in existence (from what I've been told)).

Therefore any formats in the closed-source are (IIUC) definitely not related to the open-source D-front-end. And very _specifically_, not inherited _from_ the OS front-end.

Apologies for the diffuse target in my post, I was actually implicitly asking Walter, although it may have appearaed like I was asking you (an unreasonable question, if I ever saw one).