Walter Bright wrote:

>>While C# isn't identical to D, it is more "translatable" than C++ is...
>>But those translation tools are more like "Perl hacks" than tools. :-)
> 
> Perl hacks can seduce you by getting you 25% there quickly, but then you run into a brick wall. Writing a real lexer and parser is much simpler. 

It was "good enough" to help out with the initial translation of wxD...

Now that it has been done, upgrading between new versions and so on are
just small patches and can be done manually. So it's not needed anymore.


Just meant if you were looking for tools like SWIG, they weren't used.
And you are right, a "real tool" for the job would have been better...

Maybe Next Time :-)
--anders

Walter Bright wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:1ohbygoysxj15.1fzj523pfiokn$.dlg@40tude.net...
>> e.g. A clean up of the phobos code: correct all the 'module' statements
>> (including missing ones) and get it to compile with "-w" turned on. Should
>> take about an afternoon to complete and makes me feel like Walter actually
>> cares about it.
> 
> The -w switch is there to support a different philosophy of programming than is used in Phobos. So it's not that I don't care about it, it's that I don't agree with it. Not everything in D I agree with <g>. 
> 
> 

Whoa, am I reading this right? I didn't know this. Somebody should have told me this sooner, as, although very disturbing, it explains a whole lot. I was wondering myself why the hell didn't Phobos compile with -w, so now I know. It also explains why the -w feature is pretty much *broken*.

As for whether or not one should use warnings, I pretty much agree with Derek in his Explicit/Obvious vs Implicit/Ambiguous comment. I mean, how can sloth be a programming philosophy?
I don't know what more I can say about the use of warnings, I have the feeling it wont make a difference. I can only note that warnings have been present in the development philosophies of C-languages since the older days, to the present, ubiquitous even in modern languages like Java and C#, so how about it? Are *all* these people wrong??

As for whether how the warnings features should work, now here's the critical, poignant thing: how can you Walter, since you don't agree with the use of the warnings feature, be entitled to say _how_ should the warnings feature work at all?? It doesn't make sense. You are entitled to argue why you don't think warnings should exist or be used, no more.
If I had known this beforehand I wouldn't have written a point about why warnings should not halt compilation, or why warnings scrolling off the console is not a problem.
It's like, for example, a person who intrinsically doesn't agree with vi's editing model (or with LISP languages, or whatever.), trying to argue how it (they) should work. It makes no sense such arguing.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Anders F Björklund" <afb@algonet.se> wrote in message news:dscebv$15oj$1@digitaldaemon.com...
> Walter Bright wrote:
>
>>>While C# isn't identical to D, it is more "translatable" than C++ is... But those translation tools are more like "Perl hacks" than tools. :-)
>>
>> Perl hacks can seduce you by getting you 25% there quickly, but then you run into a brick wall. Writing a real lexer and parser is much simpler.
>
> It was "good enough" to help out with the initial translation of wxD...

If it's producing usable results, I'm not going to diss it <g>.

Walter Bright wrote:

>>>Perl hacks can seduce you by getting you 25% there quickly, but then you run into a brick wall. Writing a real lexer and parser is much simpler.
>>
>>It was "good enough" to help out with the initial translation of wxD...
> 
> If it's producing usable results, I'm not going to diss it <g>. 

I think the results it has produced are very usable, even if it did
take some big effort with the initial cleanup (mostly done by wx.NET)

Will split the next wxD release into two, just to get it out in time...

--anders

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dscmct$1ck3$1@digitaldaemon.com...
> As for whether how the warnings features should work, now here's the critical, poignant thing: how can you Walter, since you don't agree with the use of the warnings feature, be entitled to say _how_ should the warnings feature work at all??

It's inescapable, because I do the work to implement it. Inevitably, decisions must be made, documentation must be written, etc.

But you're right. I believe warnings are a mistake, which makes me the wrong person to go about implementing them. There's no reason you have to put up with this. Ben Hinkle has written a D front end toolkit, from which you can take the D front end sources that come with DMD and build the front end. With it, you can build any tool you like based on it with little effort. You are free to make a Dlint, and have it analyze the source code in any way you wish. You are entitled to make all the decisions as to its behavior, because you'll be the one doing the work.

I believe I've stated more than once my full endorsement for such a project (even though you don't need my approval). It's a good idea. Allowing people the freedom to make their own D source code analyzing tools was one of the motivating reasons for releasing the D front end as open source.

Bruno Medeiros wrote:
> Andrew Fedoniouk wrote:
>>
>> I thought about something different.
>>
>> Typical implementation is:
>>
>> Two classes:
>> Graphics and GraphicsEx : Graphics
>> and interface ISurface.
>>
>> Graphics is a set of basic functions to draw on some
>> surface. GraphicsEx is a set of extended functions,
>> in Java it is known as Graphics2D - extended set for
>> vector drawings - antialiasing and extended line styles,
>> transformations etc.
>>
>> Graphics in Windows is a pretty much wrapper of
>> HDC functions, ISurface is a HDC handler provider:
>> Objects like Window, Image and Printer implement
>> ISurface.
>>
>> GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
>> Quartz2D, AGG or DirectX derived gfx subsystem of Vista.
>>
>> The idea is simple: for UI implementation
>> you need only Graphics (like in Harmonia I use only 10 or so
>> graphic functions). For various vector graphic tasks you will
>> need GraphicsEx.
>>
>> Having them both will allow to use only what is needed.
>> As GraphicsEx is a Graphics too thus you can draw your
>> UI on e.g. OpenGL surfaces if needed.
>>
>> Graphics has concrete implementations
>> for each platform : on windows it is Graphics:Win32Graphics
>> or even Graphics:GC on DWT if DWT will need to use some
>> components knowing only about Graphics.
>>
>> Even on the same platform there are multiple rendering
>> engines available. Graphics[Ex] will alow to cover them.
>> I don't think that we need to implement low level drawing.
>> It would be too much for most of practical cases.
>> For sure we shall cover at least official OS
>> drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.
>>
>> Andrew Fedoniouk.
>> http://terrainformatica.com
>>
> 
> Let the first say I find quite good this idea of having a common (i.e. standard) primitive graphics library in D. Not only because it is more readily available, but especially because it can later be used upon to build higher level libraries like the advanced graphics lib or a GUI lib, with a higher degree of unification. (For instance there could be several GUI libs, but nonetheless they would share the same graphic primitives).
> 
> As for this primitive graphics library, there already exists one, (made in C), and it not only exists, but it is *The* library. I hope you know which one I'm talking about, and I hope too that you realize that your work should be to make a D layer/version of this lib. Not a direct C wrapper, as that already exists, but one to make use of the relevant D's prime features (OO and structured namespacing)
> 
> 

No, I wasn't thinking about GTK (which is a GUI library), nor Cairo (which is a vector library, still not primitive), nor OpenGL (related though)

I was thinking of SDL (Simple DirectMedia Layer, www.libsdl.org).
For those who don't know, SDL is a cross-platform multimedia library designed to provide low level access to 2D video surfaces(framebuffers) and 3D hardware via OpenGL (as well as audio, keyboard, mouse, joystick). In terms of graphics, it only provides the means to open a surface/framebuffer that you can write to, plus related functionality, like datatypes and conversions related to color encondings/channels etc.) It is available in many platforms, more than D is.

There are other libraries who provide similar functionality (like GLUT f.e.), but SDL is *the* library. It was used in entirety in some commercial games like Civilization, or (more recently), in the Linux ports of the Unreal Tournament games. The maintainer of the library (Sam Latinga) works for Blizzard Entertainment in World of Warcraft.
It is used in the ABA games made in D (those japanese arcade style games). I reckon this may have been one of the first libraries (together with OpenGL) that a import header was made.

So, using SDL as a rendering backend (and adapting it's design to D) might be interesting for whatever higher-level graphics libraries one wants to implement. There are some disadvantages though. There is no access to native widgets (naturally) and SDL only allows one window to be created (they're considering changing that in a future version).

Still, it *might* (depending on how it's done) be interesting to have a D framework for all those concepts (like color, surface/canvas, etc.) that are common to all graphics libraries, high-level or not, native-widgets or not.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:dsg9rh$2ce6$1@digitaldaemon.com...
> Bruno Medeiros wrote:
>> Andrew Fedoniouk wrote:
>>>
>>> I thought about something different.
>>>
>>> Typical implementation is:
>>>
>>> Two classes:
>>> Graphics and GraphicsEx : Graphics
>>> and interface ISurface.
>>>
>>> Graphics is a set of basic functions to draw on some
>>> surface. GraphicsEx is a set of extended functions,
>>> in Java it is known as Graphics2D - extended set for
>>> vector drawings - antialiasing and extended line styles,
>>> transformations etc.
>>>
>>> Graphics in Windows is a pretty much wrapper of
>>> HDC functions, ISurface is a HDC handler provider:
>>> Objects like Window, Image and Printer implement
>>> ISurface.
>>>
>>> GraphicsEx (2D) could be a wrapper of GDI+, OpenGL, Quartz2D, AGG or DirectX derived gfx subsystem of Vista.
>>>
>>> The idea is simple: for UI implementation
>>> you need only Graphics (like in Harmonia I use only 10 or so
>>> graphic functions). For various vector graphic tasks you will
>>> need GraphicsEx.
>>>
>>> Having them both will allow to use only what is needed.
>>> As GraphicsEx is a Graphics too thus you can draw your
>>> UI on e.g. OpenGL surfaces if needed.
>>>
>>> Graphics has concrete implementations
>>> for each platform : on windows it is Graphics:Win32Graphics
>>> or even Graphics:GC on DWT if DWT will need to use some
>>> components knowing only about Graphics.
>>>
>>> Even on the same platform there are multiple rendering
>>> engines available. Graphics[Ex] will alow to cover them.
>>> I don't think that we need to implement low level drawing.
>>> It would be too much for most of practical cases.
>>> For sure we shall cover at least official OS
>>> drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.
>>>
>>> Andrew Fedoniouk.
>>> http://terrainformatica.com
>>>
>>
>> Let the first say I find quite good this idea of having a common (i.e. standard) primitive graphics library in D. Not only because it is more readily available, but especially because it can later be used upon to build higher level libraries like the advanced graphics lib or a GUI lib, with a higher degree of unification. (For instance there could be several GUI libs, but nonetheless they would share the same graphic primitives).
>>
>> As for this primitive graphics library, there already exists one, (made in C), and it not only exists, but it is *The* library. I hope you know which one I'm talking about, and I hope too that you realize that your work should be to make a D layer/version of this lib. Not a direct C wrapper, as that already exists, but one to make use of the relevant D's prime features (OO and structured namespacing)
>>
>>
>
> No, I wasn't thinking about GTK (which is a GUI library), nor Cairo (which is a vector library, still not primitive), nor OpenGL (related though)
>
> I was thinking of SDL (Simple DirectMedia Layer, www.libsdl.org).
> For those who don't know, SDL is a cross-platform multimedia library
> designed to provide low level access to 2D video surfaces(framebuffers)
> and 3D hardware via OpenGL (as well as audio, keyboard, mouse, joystick).
> In terms of graphics, it only provides the means to open a
> surface/framebuffer that you can write to, plus related functionality,
> like datatypes and conversions related to color encondings/channels etc.)
> It is available in many platforms, more than D is.
>
> There are other libraries who provide similar functionality (like GLUT
> f.e.), but SDL is *the* library. It was used in entirety in some
> commercial games like Civilization, or (more recently), in the Linux ports
> of the Unreal Tournament games. The maintainer of the library (Sam
> Latinga) works for Blizzard Entertainment in World of Warcraft.
> It is used in the ABA games made in D (those japanese arcade style games).
> I reckon this may have been one of the first libraries (together with
> OpenGL) that a import header was made.
>
> So, using SDL as a rendering backend (and adapting it's design to D) might be interesting for whatever higher-level graphics libraries one wants to implement. There are some disadvantages though. There is no access to native widgets (naturally) and SDL only allows one window to be created (they're considering changing that in a future version).
>
> Still, it *might* (depending on how it's done) be interesting to have a D framework for all those concepts (like color, surface/canvas, etc.) that are common to all graphics libraries, high-level or not, native-widgets or not.

class Graphics
{
    IGraphicsImpl impl; // GDI, GDI+, OpenGL(SDL), etc.
};

is the only way to have *standard* Graphics package used
in many toolkits and toolkit-less apllications so why is "might"?

Andrew.

>
> -- 
> Bruno Medeiros - CS/E student
> "Certain aspects of D are a pathway to many abilities some consider to
> be... unnatural."

Because I am writing something like GUI in OpenGL I decided to use SDL to make it easy to port. The problems were:

- Slower than OpenGL directly in Win32
- Deletes all textures on window resize
- Handles messages too slow
- Not enough control over the shell window

It is very good library but not for GUI I believe....


Bruno Medeiros wrote:
> Bruno Medeiros wrote:
>> Andrew Fedoniouk wrote:
>>>
>>> I thought about something different.
>>>
>>> Typical implementation is:
>>>
>>> Two classes:
>>> Graphics and GraphicsEx : Graphics
>>> and interface ISurface.
>>>
>>> Graphics is a set of basic functions to draw on some
>>> surface. GraphicsEx is a set of extended functions,
>>> in Java it is known as Graphics2D - extended set for
>>> vector drawings - antialiasing and extended line styles,
>>> transformations etc.
>>>
>>> Graphics in Windows is a pretty much wrapper of
>>> HDC functions, ISurface is a HDC handler provider:
>>> Objects like Window, Image and Printer implement
>>> ISurface.
>>>
>>> GraphicsEx (2D) could be a wrapper of GDI+, OpenGL,
>>> Quartz2D, AGG or DirectX derived gfx subsystem of Vista.
>>>
>>> The idea is simple: for UI implementation
>>> you need only Graphics (like in Harmonia I use only 10 or so
>>> graphic functions). For various vector graphic tasks you will
>>> need GraphicsEx.
>>>
>>> Having them both will allow to use only what is needed.
>>> As GraphicsEx is a Graphics too thus you can draw your
>>> UI on e.g. OpenGL surfaces if needed.
>>>
>>> Graphics has concrete implementations
>>> for each platform : on windows it is Graphics:Win32Graphics
>>> or even Graphics:GC on DWT if DWT will need to use some
>>> components knowing only about Graphics.
>>>
>>> Even on the same platform there are multiple rendering
>>> engines available. Graphics[Ex] will alow to cover them.
>>> I don't think that we need to implement low level drawing.
>>> It would be too much for most of practical cases.
>>> For sure we shall cover at least official OS
>>> drawing primitives GDI/GDI+  and DirectDraw/Quarts2D.
>>>
>>> Andrew Fedoniouk.
>>> http://terrainformatica.com
>>>
>>
>> Let the first say I find quite good this idea of having a common (i.e. standard) primitive graphics library in D. Not only because it is more readily available, but especially because it can later be used upon to build higher level libraries like the advanced graphics lib or a GUI lib, with a higher degree of unification. (For instance there could be several GUI libs, but nonetheless they would share the same graphic primitives).
>>
>> As for this primitive graphics library, there already exists one, (made in C), and it not only exists, but it is *The* library. I hope you know which one I'm talking about, and I hope too that you realize that your work should be to make a D layer/version of this lib. Not a direct C wrapper, as that already exists, but one to make use of the relevant D's prime features (OO and structured namespacing)
>>
>>
> 
> No, I wasn't thinking about GTK (which is a GUI library), nor Cairo (which is a vector library, still not primitive), nor OpenGL (related though)
> 
> I was thinking of SDL (Simple DirectMedia Layer, www.libsdl.org).
> For those who don't know, SDL is a cross-platform multimedia library designed to provide low level access to 2D video surfaces(framebuffers) and 3D hardware via OpenGL (as well as audio, keyboard, mouse, joystick). In terms of graphics, it only provides the means to open a surface/framebuffer that you can write to, plus related functionality, like datatypes and conversions related to color encondings/channels etc.) It is available in many platforms, more than D is.
> 
> There are other libraries who provide similar functionality (like GLUT f.e.), but SDL is *the* library. It was used in entirety in some commercial games like Civilization, or (more recently), in the Linux ports of the Unreal Tournament games. The maintainer of the library (Sam Latinga) works for Blizzard Entertainment in World of Warcraft.
> It is used in the ABA games made in D (those japanese arcade style games). I reckon this may have been one of the first libraries (together with OpenGL) that a import header was made.
> 
> So, using SDL as a rendering backend (and adapting it's design to D) might be interesting for whatever higher-level graphics libraries one wants to implement. There are some disadvantages though. There is no access to native widgets (naturally) and SDL only allows one window to be created (they're considering changing that in a future version).
> 
> Still, it *might* (depending on how it's done) be interesting to have a D framework for all those concepts (like color, surface/canvas, etc.) that are common to all graphics libraries, high-level or not, native-widgets or not.
> 

In article <ds18hc$18sm$1@digitaldaemon.com>, Dave says...
>I'm still stumped as to how exactly the EPL would apply to using D/SWT in proprietary projects, so I sent away to the Eclipse folks for an answer. Some of the answers in the FAQ seem potentially ambiguous to me - instead of summarizing what the license actually says on a matter, they refer back to the license! They do make it clear what you can and can't do with Eclipse and Plugin source code, but not with something like SWT.

IBM-Rational and boat load of others are selling Eclipse based products (not just plug-ins) and they don't have to give anyone their value-adding code. It is not the GPL.

In article <drv9kc$2er2$1@digitaldaemon.com>, kris says...
>
>>> Where can I find the translator?
>> 
>> Zz
>
>I'm afraid you can't right now. It's not packaged in any form suitable for redistribution, and it is not turn-key. Was originally written explicitly for converting SWT (last April or May I think?), but there's an intermediate/simpler front-end (J2D) that might perhaps be used for almost any Java if you accept some occasional known artifacts (it will sometimes add an import for a module that's not actually used in the code, and there's certain extensive array-inits that it fails to format correctly. It catches most C-style casts, but there are one or two edge cases that slip through, or are mistaken).
>
>The truth is, the whole effort was abandoned right after Shawn got stuck into DWT ~ I saw no point in a duplication of effort, and already had enough on my plate at the time. Shawn and I discussed it back then, and it was clear he was going to be successful without the help of that tool.
>
>So while it can happily work on further ports of SWT, it wasn't constructed or considered for external usage at all ~ way too much of a hack! A couple of months back, I did seriously consider building another one using a much more robust approach ~ but haven't found the time.

Maybe you could publish what you did so others could volunteer to work on it. I'm sure that there is considerable interest in a Java to D translator.

Is it written in D?