date:20110406


On 2011-04-05 22:58, Andrej Mitrovic wrote:

On 4/5/11, Jacob Carlborg  wrote:

On 2011-04-05 20:57, Andrej Mitrovic wrote:

On 4/5/11, Jacob Carlborg   wrote:

It's handy if you have a common directory with lib files.


Well I've always wanted to do that, but how eactly do you set a
library search directory with Optlink/DMD?


Don't know about Optlink but on Posix systems it's: -L-L/path/to/libraires


Oh well that's an LD trick then. :)

I have figured out a way to do it with Optlink, but I have to use the
LIB environment variable. So in a batch file I could have:
set LIB=C:\PathToMyLib\;%LIB%
dmd test.d myLib.lib

This will work. I should update the dwiki entry and add this information there.


Have a look at the lib section: 
http://www.digitalmars.com/ctg/optlink.html#operational


"The lib entry may be either a single file name or a pathname (with 
trailing "\") to a directory containing the libraries. "


--
/Jacob Carlborg

Re: DGui

2011-04-06 Thread AntonioDavide

On Wed, 6 Apr 2011 04:04:50 +0200, Andrej Mitrovic 
 wrote:
What the funk. I was trying to contact the author but google just 

gave
me an invalid email address. If I try to expand his email by 

clicking
on "troguant...@gmail.com", I get username "troguantoniodavide", 

but I

can't email him at this address.
:/


Hi, I don't read newsgroups very often.
I saw this discussion today, the valid mail is trogu [dot] davide 
[at] gmail [dot] com


The mail in the project page doesn't exist...(I don't know why)

Oh, I'm the DGui developer :)

Re: GUI library for D


On 2011-04-05 23:15, Alvaro wrote:

El 05/04/2011 15:32, Jacob Carlborg escribió:

On 2011-04-05 15:25, Matthias Pleh wrote:

Am 05.04.2011 15:06, schrieb Jacob Carlborg:

On 2011-04-05 13:08, Matthias Pleh wrote:

So I think for short or middle term such solution like gtkD, QtD, DWT
are good, but for the long term the D community needs a D GUI library
completly written in D.

Just my thoughts
°Matthias



You do know that DWT is completely written in D? Don't you think we can
create an environment for creating D GUI applications using DWT?



Yes, that would be an option. I have thought several times about that.
But I think, to get really acceptet by a wide range of developers, the
library must be adjusted, to suit better the D coding style. This way we
could get the whole power of D. But this also means that you get more
and more away from the java path and sometime you are not able any more
to merge changes in the java path to D.
So this means, this would really be a fork, not just a port.
(I hope, I have explained it correctly in my broken english, and I hope
it sound not rude :|


°Matthias


I see what you mean and I'm not seeing it as rude. It's hard to find a
balance where it's still possible to merge future versions and taking
full advantage of D.



DWT is an impressive achievement (as are gtkD and QtD), really. It's
great what it can do without needing other languages. Nevertheless DWT
might be in D and compile with D compilers, but looks more like "Dava"
(Java-like D) :-)

I was expecting a real D system (kind of forgetting its SWT origin) and
got a bit surprised when I browsed the code. Its very Java-ish (even
contains D ports of String, Integer, Runnable, File, InputStream, etc.).
What I mean is that I find it hard cosidering DWT "the One D GUI
library". It would not do D justice.

But, ugh, I understand that it's more practical this way, so
improvements in SWT can be adapted easily.

What would be the best solution? to D-ify more QtD? to D-ify DWT? gtkD?
Would it be worth? Just keep them as they are?


I think gtkD is out of the question since it's not using native 
controls. Don't know about QtD, if I recall correctly it, at least, 
looks quite native. But I would guess it would too hard to find whole 
int that, specially on Mac OS X.


--
/Jacob Carlborg

Re: GUI library for D


On 2011-04-06 09:00, Jacob Carlborg wrote:

On 2011-04-05 23:15, Alvaro wrote:

El 05/04/2011 15:32, Jacob Carlborg escribió:

On 2011-04-05 15:25, Matthias Pleh wrote:

Am 05.04.2011 15:06, schrieb Jacob Carlborg:

On 2011-04-05 13:08, Matthias Pleh wrote:

So I think for short or middle term such solution like gtkD, QtD, DWT
are good, but for the long term the D community needs a D GUI library
completly written in D.

Just my thoughts
°Matthias



You do know that DWT is completely written in D? Don't you think we
can
create an environment for creating D GUI applications using DWT?



Yes, that would be an option. I have thought several times about that.
But I think, to get really acceptet by a wide range of developers, the
library must be adjusted, to suit better the D coding style. This
way we
could get the whole power of D. But this also means that you get more
and more away from the java path and sometime you are not able any more
to merge changes in the java path to D.
So this means, this would really be a fork, not just a port.
(I hope, I have explained it correctly in my broken english, and I hope
it sound not rude :|


°Matthias


I see what you mean and I'm not seeing it as rude. It's hard to find a
balance where it's still possible to merge future versions and taking
full advantage of D.



DWT is an impressive achievement (as are gtkD and QtD), really. It's
great what it can do without needing other languages. Nevertheless DWT
might be in D and compile with D compilers, but looks more like "Dava"
(Java-like D) :-)

I was expecting a real D system (kind of forgetting its SWT origin) and
got a bit surprised when I browsed the code. Its very Java-ish (even
contains D ports of String, Integer, Runnable, File, InputStream, etc.).
What I mean is that I find it hard cosidering DWT "the One D GUI
library". It would not do D justice.

But, ugh, I understand that it's more practical this way, so
improvements in SWT can be adapted easily.

What would be the best solution? to D-ify more QtD? to D-ify DWT? gtkD?
Would it be worth? Just keep them as they are?


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



That would be "find a hole in that" not "find whole int that".

--
/Jacob Carlborg

Re: DWT2


On 2011-04-06 01:35, Andrej Mitrovic wrote:

Could you tell me what switches I need to build a simple example from scratch?

So far I know I probably need these:
libs dir: \dwt2\lib
libs dir: \dwt2\org.eclipse.swt.win32.win32.x86\lib
imports: \dwt2\base\src
imports: \dwt2\org.eclipse.swt.win32.win32.x86\src
-J switch: \dwt2\org.eclipse.swt.win32.win32.x86\res
lib: org.eclipse.swt.win32.win32.x86.lib

I still have linker errors for missing symbols referenced by
eclipse.swt.win32.win32.x86.lib, e.g.:
missing symbol: _D4java4lang6String7indexOfFAxaaZi


Are you linking with the base library?


Is there a basic set of switches needed that are mentioned somewhere,
e.g. how do you build new projects?

Btw, are the long names necessary to ease porting of Java to D?


Yes, that's the reason. "org.eclipse.swt" was previously "dwt" but it 
required an extra step in the porting process.


--
/Jacob Carlborg

Re: New look & feel for std.algorithm

2011-04-06 Thread MIURA Masahiro


Looks clean and professional.  I like it.

A typo:  In Cheat Sheet / Iteration / group,
tuple(5, 1) is written twice.

Re: DWT2


On 2011-04-06 01:35, Andrej Mitrovic wrote:

Could you tell me what switches I need to build a simple example from scratch?

So far I know I probably need these:
libs dir: \dwt2\lib
libs dir: \dwt2\org.eclipse.swt.win32.win32.x86\lib
imports: \dwt2\base\src
imports: \dwt2\org.eclipse.swt.win32.win32.x86\src
-J switch: \dwt2\org.eclipse.swt.win32.win32.x86\res
lib: org.eclipse.swt.win32.win32.x86.lib

I still have linker errors for missing symbols referenced by
eclipse.swt.win32.win32.x86.lib, e.g.:
missing symbol: _D4java4lang6String7indexOfFAxaaZi

Is there a basic set of switches needed that are mentioned somewhere,
e.g. how do you build new projects?


I've not access to my developer computer now but I think you need to do 
the following:


* link to the base library
* link to the swt library
* "link" the resource folder, i.e. use the -J switch

So I'm guessing you missed: link to the base library.


Btw, are the long names necessary to ease porting of Java to D?



--
/Jacob Carlborg

Re: Settings in CodeBlocks -- D Language

2011-04-06 Thread Anders F Björklund


David Wang wrote:

==
My understanding is that Code::Blocks only supports code
completion for D because their fuzzy C++ parser can sometimes
parse D successfully, and that they don't plan to support D
directly. Has this changed?
==

Acturally everytime when CodeBlocks parses D will be failed.  :(

And for there is no code developer of CodeBlocks using and familar
with D Language, so the support for D will stop here and there's
no further plan in a time.


This was discussed earlier on the Code::Blocks forum, too:
http://forums.codeblocks.org/index.php/topic,12246.0.html
It should still "work" with D and GDC, but will need to be
developed and extended further to better support D2 and DMD.


So, if someone be kindly and have the ability to modify the
CodeBlocks source code (svn checkout
http://svn.berlios.de/svnroot/repos/codeblocks/trunk), will be a
great help in extending D's IDE for cross-platform area.
(CodeBlocks supports Linux, Windows, OS X, FreeBSD, etc.)


Basically the first step is to introduce a "D" language,
since it currently only knows C/C++... (The D support is
treating itself like a "strange variant of a C++ compiler")
Then write lexing/codecompletion/wizard code to handle it.

--anders

Re: DWT2


On 2011-04-06 03:22, Sam Hu wrote:

Jacob Carlborg Wrote:


On 2011-04-05 05:54, Andrej Mitrovic wrote:

You have to be kidding me. Who writes code like this?

http://i.imgur.com/BBQde.png


Is that from a DWT snippet?

--
/Jacob Carlborg

Sorry for my stepping in...
@jacob:May I ask how to build DWT2 for DMD 2.052?I downloaded the zip file from 
here:
http://hg.dsource.org/projects/dwt2/log/112
In the readme file I only saw it need rake to build.Except rake,can I build it 
also,say from .bat file?


Yes you should be able to do that. For D1 I'm usually using DSSS and 
just building from source, never building the whole library. It's easier 
that way, I haven't excluded the browser package from the Linux port. 
Don't know if it works with D2 or at all and it requires both extra 
compile time and run time dependencies.



Thanks  in advance.
Regards,
Sam



--
/Jacob Carlborg

Re: GUI library for D

Hi, all,

For the GUI library for D, Why don't consider the GTK+ 3.0?

It is a very very good GUI library and has been formally released
(now version maybe is 3.0.7), and it introduced a "GObject
Introspection" which can widely enlarge the programming languages'
bundling using (of course includes D Language).

"GObject Introspection" implements calling GObject easily and
fluently. It means that every Language just need to build
a 'GObject Introspection' bundle, then the Language can easily and
fluently call every API of GTK+ 3.0 through this bundle;
It is excited! you know, GTK+ is a very very good GUI level
library which was written in C Language.


Please consider to produce a 'GObject Introspection' bundle for D,
then through the bundle, D language can access every API in GTK+
3.0. By this way, we will get cost down and can achieve a very
good GUI library.

GTK+ can be used in Linux & OS X & Windows & FreeBST & Unix & 

You can see that by this way, D can produce inestimably GUI Apps
for different platforms and do not need to change the code very
much.


Best regards.
David.

Re: Settings in CodeBlocks -- D Language


Am 06.04.2011 06:47, schrieb David Wang:

Dear all,

The CodeBlocks IDE supports DMD compiler and I've described the proper
settings for Codeblocks using in D Language.

Please visit the WiKi page here:

http://wiki.codeblocks.org/index.php?title=Installing_a_supported_compiler


BTW, the "Code Completion for D" isn't quite good now, and in future it will
be improved.



Best regards.
David.



Really cool, if someone could improve CodeBlocks in this direction.
We would have a good crossplatform IDE.

BTW:
Would be good, if you also can keep our wiki for CodeBlocks up to date.


http://prowiki.org/wiki4d/wiki.cgi?EditorSupport
http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/CodeBlocks


°Matthias

Re: GUI library for D

"Adam D. Ruppe"  wrote in message 
news:ingldk$1r9$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> The width is statically-known, so the compiler can optimize the
>> index calculation from multiplication to shifts when appropriate.
>
> One concern I have here is will it be an incompatible type with
> dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
> cleaning up my png and bmp loaders in the near future to use with
> this.)
>
> Maybe it could use an interface to smooth that over.
>

Anything that provides an abstraction for manipulating individual pixels 
needs to be *ultra* fast, zero overhead. So I don't think it would be a good 
idea to let any vtable overhead get into there. In fact, even the overhead 
of a function call is a big problem and the pixel-access routines really 
need to be inlined. I *think* with the class being final, calls to the 
pixel-access routines can have their vtable indirection optimized away and 
*should* be inline-able (if not, then they really should be turned into 
string mixins to force the inlining - although maybe not if it's *just* for 
toying around). But my understanding is that making the functions part of an 
interface will force the vtable overhead and definitely inhibit inlining.

My thought is this: Functions which take an Image should be templated on the 
image's type. Then, the image types can work the way ranges work: by using 
what's essentially compile-time duck-typing. Except, I hate the laxness of a 
duck's structural typing, so all the image types would include a static 
dummy variable named something like "_this_is_a_type_Image_", and the 
isImage template would check for that.

Then, some sort of adapter or converter could be created to go back and 
forth between static-sized and dynamic-sized images for any cases where you 
might really need to skip the templating (possibly at the cost of some 
speed, though). And that should take care of everything.

Actually, that pretty much describes the gist of an article I'm planning to 
write for that D article competition. Of course, if you see any fundamental 
problems with this, feel free to let me know :)

>
> But, I'm getting off the point. Indexed images can be played with
> later.
>

I'm nostalgic for palette-cycling effects :) VGA was great. (And I get 
downright excited over EGA.)

>> A major improvement, of course, would be to replace the GDI
>> stuff with Direct3D 7 or 8 (there's no real need to require
>> anything beyond those versions).
>
> Now, I don't want to get too fancy.. especially since I've never
> used directx, not even for hello world, and I don't think
> performance will be too big of a deal.
>

GDI is notoriously bad for performance. It's good enough for desktop 
applications, and it's fine if you're just going to draw something once and 
display it. But for anything that's continuously drawing new frames GDI has 
never really cut it. That's what DirectX was made for in the first place. 
(Actually, that's what WinG was made for but even that *still* wasn't quite 
good enough and it was quickly replaced by the "Game SDK" which was renamed 
to DirectX at version 2. Now I feel old.) Although that said, I did once 
make a pretty nifty GDI PacMan in C#: 
http://www.semitwist.com/download/GDIPac.zip

I have used DirectX, although it's been awhile (way back in my C/C++ days), 
and it was back when DirectDraw was still relevant. Direct3D is now the way 
to do high-performance 2D and 3D (unless you're requiring a new enough 
version of DirectX that you'd have access to Direct2D, but I don't remember 
which version introduced Direct2D.) Of course, OpenGL can be used too, but 
AIUI the average-Joe's Windows computer isn't likely to have reasonably good 
OpenGL drivers (unless my info's just out-of-date).

> But, I did do something similar with my D1 game lib. It uses
> SDL for most its stuff, but I found that to be dreadfully slow
> with anything beyond the simple, so I changed the output to
> use OpenGL, set up to do 2d output. Only difference client code
> wise was I had was I had to stop using putPixel - it was even
> slower!

Yea, any individual-pixel-access function is going to be overly slow unless 
it's completely inlined and highly optimized. And even then, things like 
line drawing, fills and image blitting are still better off skipping the 
individual-pixel-access routines (unless optimizing compilers have gotten 
far better than I'd even thought).

If you haven't already, any of the old books by Andre' LaMothe or Michael 
Abrash are fantastic resources for high-performance graphics processing in 
software. Oldies, but goodies.

But anyway, I don't know exactly how you were going about it, but the way to 
do this in OpenGL or DirectX would be to do all your drawing to a texture 
buffer (using the same pixel-format as the current screen mode), and attach 
that texture to couple of hardware-drawn triangles arranged in a rectangle. 
Then optionally wait for the VSync, a

Re: Settings in CodeBlocks -- D Language

===
BTW:
Would be good, if you also can keep our wiki for CodeBlocks up to
date.


http://prowiki.org/wiki4d/wiki.cgi?EditorSupport
http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/CodeBlocks

===

Because I have a user ID in codeblocks.forum, so I can add the
settings for D into codeblocks's WiKi page.

I don't have a wiki4d ID, so I think the better way is to copy the
corresponding sections os codeblocks's WiKi page into the wiki4d
page by yourself or someone whom has an ID of wiki4d.


Best regards.
David.

GUI library for D ---- Why do not consider to use GTK+ 3.0 ??

please view:

http://www.digitalmars.com/pnews/read.php?
server=news.digitalmars.com&group=digitalmars.D&artnum=134026

Re: GUI library for D

"David Wang"  wrote in message 
news:inh3v8$u5q$1...@digitalmars.com...
> Hi, all,
>
> For the GUI library for D, Why don't consider the GTK+ 3.0?
>


GTK+ apps are crap on Windows. And not real great on KDE either, AIUI. It 
only barely qualifies as "cross-platform".

Re: Settings in CodeBlocks -- D Language


Am 06.04.2011 09:32, schrieb David Wang:

===
BTW:
Would be good, if you also can keep our wiki for CodeBlocks up to
date.


http://prowiki.org/wiki4d/wiki.cgi?EditorSupport
http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/CodeBlocks

===

Because I have a user ID in codeblocks.forum, so I can add the
settings for D into codeblocks's WiKi page.

I don't have a wiki4d ID, so I think the better way is to copy the
corresponding sections os codeblocks's WiKi page into the wiki4d
page by yourself or someone whom has an ID of wiki4d.


Best regards.
David.


There is no ID needed for wiki4d. Just enter your name as CamelCase 
(e.g.: DavidWang) without any password.




°Matthias

Re: GUI library for D


On 2011-04-06 09:35, Nick Sabalausky wrote:

"David Wang"  wrote in message
news:inh3v8$u5q$1...@digitalmars.com...

Hi, all,

For the GUI library for D, Why don't consider the GTK+ 3.0?




GTK+ apps are crap on Windows. And not real great on KDE either, AIUI. It
only barely qualifies as "cross-platform".




Same for Mac OS X. Then there's also the extra runtime dependencies.

--
/Jacob Carlborg

Re: GUI library for D

=
Nick Sabalausky (a@a.a)

GTK+ apps are crap on Windows. And not real great on KDE either,
AIUI. It
only barely qualifies as "cross-platform".
=

Well, if that so, I think if someone want to build a 'real good'
GUI library which be good on Windows, KDE or other places will
need to build from the very LOW level of the machine code or
something like this.

BTW, KDE (it was built based on Qt, and now Qt seems encounters
problems) is not so good, it ture not for argument.

Before, apps based on GTK+ 2.xx is really not so good on Windows
or other platforms (except Linux). But, please pay attention to
new changed features of GTK+ 3.0.

such as:
totally use Cairo to draw;
support X Input 2;
use CSS style themes;
multiple backend support of GDK (on X or Wayland or W32api, even
HTML5, or something else.);
added GtkApplication class;



And GTK+ 3 introduced a "GObject Introspection" which can widely
enlarge the programming languages' bundling using.

"GObject Introspection" implements calling GObject easily and
fluently. It means that every Language just need to build
a 'GObject Introspection' bundle, then the Language can easily and
fluently call every API of GTK+ 3.0 through this bundle;


What about the Qt now?
Do you think NOKIA or the company who has bought Qt from NOKIA
will still truely do theirs efforts on it?


Please consider this carefully and detailly. Not for arguments.


Best regards.
David.

Re: GUI library for D


Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker, 
colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt 
make really good job in imitating the native Theme. (except OSX, which 
is a little bit special)

Re: GUI library for D

"Matthias Pleh"  wrote in message 
news:inh91t$1854$1...@digitalmars.com...
> Am 06.04.2011 09:00, schrieb Jacob Carlborg:
>>
>> I think gtkD is out of the question since it's not using native
>> controls. Don't know about QtD, if I recall correctly it, at least,
>> looks quite native. But I would guess it would too hard to find whole
>> int that, specially on Mac OS X.
>
>
> Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker, 
> colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt 
> make really good job in imitating the native Theme. (except OSX, which is 
> a little bit special)
>

My understanding is that Qt also has a compile-time flag that will make it 
actually use the real Win32 controls.

Re: DWT2

2011-04-06 Thread Sam Hu

Jacob Carlborg Wrote:

> On 2011-04-06 03:22, Sam Hu wrote:
> > Jacob Carlborg Wrote:
> >
> >> On 2011-04-05 05:54, Andrej Mitrovic wrote:
> >>> You have to be kidding me. Who writes code like this?
> >>>
> >>> http://i.imgur.com/BBQde.png
> >>
> >> Is that from a DWT snippet?
> >>
> >> --
> >> /Jacob Carlborg
> > Sorry for my stepping in...
> > @jacob:May I ask how to build DWT2 for DMD 2.052?I downloaded the zip file 
> > from here:
> > http://hg.dsource.org/projects/dwt2/log/112
> > In the readme file I only saw it need rake to build.Except rake,can I build 
> > it also,say from .bat file?
> 
> Yes you should be able to do that. For D1 I'm usually using DSSS and 
> just building from source, never building the whole library. It's easier 
> that way, I haven't excluded the browser package from the Linux port. 
> Don't know if it works with D2 or at all and it requires both extra 
> compile time and run time dependencies.
> 
> > Thanks  in advance.
> > Regards,
> > Sam
> 
> 
> -- 
> /Jacob Carlborg
Sorry for my stupid.May I ask what the batch file should be like to build the 
whole lib?

Thanks again for your great help!

Re: [GSOC] Database API draft proposal

2011-04-06 Thread Piotr Szturmaj

Masahiro Nakagawa wrote:
>> [1] https://github.com/pszturmaj/ddb 
>> http://pszturmaj.github.com/ddb/db.html
>>
> 
> Hmm.. In what way is your new module different from DDBI?
> What's the new features?

I should state here that work on DDB is in progress, so it's subject to
change. However, notable differences from DDBI are typed rows, where one
can map structs/tuples/arrays or base types directly to the result. For
example:

enum Axis { x, y, z }
struct SubRow1 { string s; int[] nums; int num; }
alias Tuple!(int, "num", string, "s") SubRow2;
struct Row { SubRow1 left; SubRow2[] right; Axis axis; string text; }

auto cmd = new PGCommand(conn, "SELECT ROW('text', ARRAY[1, 2, 3], 100),
ARRAY[ROW(1, 'str'), ROW(2, 'aab')],
'x', 'anotherText'");

auto row = cmd.executeRow!Row; // map result to Row struct

assert(row.left.s == "text");
assert(row.left.nums == [1, 2, 3]);
assert(row.left.num == 100);
assert(row.right[0].num == 1 && row.right[0].s == "str");
assert(row.right[1].num == 2 && row.right[1].s == "aab");
assert(row.axis == Axis.x);
assert(row.s == "anotherText");

This is done without intermediate state, such as Variant. In case of
PostgreSQL binary encoding, values are directly read into struct fields.
Also, typed rows form the basis of the ORM.

Dynamic rows are also first class citizens:

cmd = new PGCommand(conn, "SELECT * FROM table");
auto result = cmd.executeQuery; // range of DBRow!(Variant[])

foreach (row; result)
{
writeln(row["column"]);
}

result.close;

Some parts of the Connection/Command classes are currently modeled after
ADO.NET.

Re: DWT2


On 2011-04-06 11:50, Sam Hu wrote:

Jacob Carlborg Wrote:


On 2011-04-06 03:22, Sam Hu wrote:

Jacob Carlborg Wrote:


On 2011-04-05 05:54, Andrej Mitrovic wrote:

You have to be kidding me. Who writes code like this?

http://i.imgur.com/BBQde.png


Is that from a DWT snippet?

--
/Jacob Carlborg

Sorry for my stepping in...
@jacob:May I ask how to build DWT2 for DMD 2.052?I downloaded the zip file from 
here:
http://hg.dsource.org/projects/dwt2/log/112
In the readme file I only saw it need rake to build.Except rake,can I build it 
also,say from .bat file?


Yes you should be able to do that. For D1 I'm usually using DSSS and
just building from source, never building the whole library. It's easier
that way, I haven't excluded the browser package from the Linux port.
Don't know if it works with D2 or at all and it requires both extra
compile time and run time dependencies.


Thanks  in advance.
Regards,
Sam



--
/Jacob Carlborg

Sorry for my stupid.May I ask what the batch file should be like to build the 
whole lib?


No, you may not. I hate batch files and shell scripts :)

Ok, seriously, I think you only need to collect all files in the base 
directory and in the SWT directory and compile them. Don't forget the -J 
switch for the resource folder. Also remember to link to the necessary 
libraries, you can find those in the rake script, in the LIBNAMES_BASIC 
variable.



Thanks again for your great help!



--
/Jacob Carlborg

Re: GUI library for D


On 2011-04-06 10:39, Matthias Pleh wrote:

Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
make really good job in imitating the native Theme. (except OSX, which
is a little bit special)



As expected. I'm not sure but it seems that Mac OS X Lion has a new 
style on the regular push buttons. Then Qt needs to start all over (almost).


--
/Jacob Carlborg

Re: GUI library for D


Am 06.04.2011 11:40, schrieb Nick Sabalausky:

"Matthias Pleh"  wrote in message
news:inh91t$1854$1...@digitalmars.com...

Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
make really good job in imitating the native Theme. (except OSX, which is
a little bit special)



My understanding is that Qt also has a compile-time flag that will make it
actually use the real Win32 controls.




No! When compiling the Qt-library, you can specify a flag for the theme 
to build. The controls appears then with this theme.


On windows you can easaly test this, with Spy++.
I've just created a simple window with 
QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.

But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other platforms?

The problem with OSX is, as I know, that some controls not only look 
different, but are also different arranged, and this make it more 
difficult to emulate.


°Matthias

Re: GUI library for D

2011-04-06 Thread Michel Fortin


On 2011-04-05 23:07:33 -0400, Adam D. Ruppe  said:


Note: I just updated my simpledisplay.d. My color constructor
said b = c when I meant this.b = c... hence everything was yellow!
You can download again from the same place.


I played with it yesterday and never found why the blue channel didn't work!

By the way it works well with X11 on Mac OS X (if I change the "version 
(linux)" to "version (OSX)").


I also made a working OS X implementation (Cocoa).



Nick Sabalausky wrote:

I haven't benchmarked or even tested this, and heck, maybe I'm just
a dinosaur, but for better speed and flexibility I'd recommend
something more like what I've attached.


Yea, that does sound better. Though I have a few comments...


The width is statically-known, so the compiler can optimize the
index calculation from multiplication to shifts when appropriate.


One concern I have here is will it be an incompatible type with
dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
cleaning up my png and bmp loaders in the near future to use with
this.)


I don't think having fixed-size image will be a useful optimization, 
except perhaps if you manipulate a lot of tiny images of the same size.




Maybe it could use an interface to smooth that over.

I actually had a similar fight with myself over Indexed vs TrueColor
when writing the original thing. They really don't have compatible
interfaces. Sure, you could do some kind of putpixel(uint data)
for each of them, but it's not really the same.

So I think they should be separate types, with functions to convert
back and forth. (both conversions being lossy in their own way..
just because two palette entries have the same rgb values doesn't
mean the two colors are semantically the same.)


Don't forget that there's actually much more colorspaces than indexed 
and RGB. There's RGBA (when you need semi-transparency), there's CYMB 
(for print), there's grayscale. And in some cases HSV or XYZ could be 
useful too. And for each of these someone might want different bit 
depth. Can't we make things flexible enough for that by using a 
template?


final class Bitmap(Color) : Image {
void opIndexAssign(int x, int y, Color color) {
pixels[y * width + x] = Color(color);
}

size_t width, height;
Color[] pixels;
}

This way, you can have a bitmap of RGBColor, or RGBAColor (with an 
alpha mask), GrayColor, IndexedColor, or whatever color type you can 
come with, and algorithms can be reused.




Wow, I'm off topic again. Anyway, for the event loop here, I'm
thinking something similar to how std.concurrency does it might
be a good approach: a bunch of delegates, matched to events by
their signature. Simple signatures could be accepted as well
as fancier ones.

// need to make a simple window separately here so it is persistent
auto win = new DrawableWindow(width, height);

// still use an image the same way. Alternatively, DrawableWindow
// could implement the same interface as Image, probably double
// buffering internally anyway, so pretty much same implementation.
auto image = new Image(width, height);

window.eventLoop(
   50, // first parameter is the timeout. can be 0 to only react
   // to events, but putting one in gives you an easy to use
   // frame pulse for drawing
   (int keyPressed) { // might be a struct KeyEvent rather than int
// react to the key
   },
   (int x, int y, int mouseButton) {
// react to a mouse click
   },
   () { // no params means your timeout happened, time to draw
// draw your frame...

image.display(win); // this overload uses the existing
// window and returns immediately
// rather than making and waiting
   }
   // might also offer a platform specific msg, wParam, lParam
   // so you could in theory do all of Win32 based on this same
   // framework
);


Overall, I really like this concept. I'd like it better if 
image.display(win) was replaced with "window.image = image" however.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: GUI library for D

2011-04-06 Thread Michel Fortin


On 2011-04-06 07:38:30 -0400, Matthias Pleh  said:

The problem with OSX is, as I know, that some controls not only look 
different, but are also different arranged, and this make it more 
difficult to emulate.


And it'll only become harder and harder. Have you seen in Mac OS X Lion 
the new tab control or the button groups (segmented controls in OS X 
parlance) which are now using an animated "slider" knob? And the new 
iOS-style scrollbars with a bounce effect? Nothing is impossible, but 
it'll take time for Qt to catch up with those changes.




Meanwhile, Cocoa apps will get all this for free.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: GUI library for D

2011-04-06 Thread Lutger Blijdestijn

Nick Sabalausky wrote:

> "Andrej Mitrovic"  wrote in message
> news:mailman.3178.1301970383.4748.digitalmar...@puremagic.com...
>> On 4/5/11, Nick Sabalausky  wrote:
>>> After all, I
>>> *really* want to get around to making my own web browser (based off
>>> either
>>> Mozilla or Chromium) - I'm getting really fed up with the current state
>>> of
>>> available web browsers. Well, and the web as a whole (god I fucking hate
>>> the
>>> web), but one step at a time, I guess).
>>
>> I'll be the first to install it.
>>
>> Btw, there's a full web browser example in the QtD sources. But it has
>> to be ported to D2. And then you have to deal with any eventual bugs
>> along the way. :]
> 
> Ha! I may not need to do much after all: I was just looking through
> Wikipedia's giant list of browsers, found a few that looked potentially
> promising, tried them all and...well, was mostly disappointed. But the
> *last* one I had left to try I've been really impressed with so far:
> 
> Arora (Qt/WebKit)
> http://code.google.com/p/arora/
> 
> I've only tried it breifly, but the UI is *actually nice*! Only modern
> browser out there with a UI that isn't absolutely horrid. I didn't even
> see *one* instance of invisible-text on my light-on-dark system, which is
> unbeleivavly rare among all software these days.
> 
> And it has a lot of essential stuff built in, like ad blocking,
> disableable JS, and a "ClickToFlash" which I haven't tried out yet.
> There's still a few things it seems like it might be missing, like
> equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and
> DownThemAll, but most of those are less important to me, and even as it is
> right now it's a damn good start. Maybe I could add some of that remaining
> stuff, or heck, maybe even port the whole thing to D ;)

Even it it would involve looking at C++ code?

Did you know Arora *is* the Qt webbrowser example that got out of control  
and became a real browser? (it uses webkit)

iirc QtD has a sizeable chunk of that example already ported to D.

Re: GUI library for D


On 2011-04-06 13:38, Matthias Pleh wrote:

Am 06.04.2011 11:40, schrieb Nick Sabalausky:

"Matthias Pleh" wrote in message
news:inh91t$1854$1...@digitalmars.com...

Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
colorPicker, ... but most controls are drawn by the PaintEnginge. But Qt
make really good job in imitating the native Theme. (except OSX,
which is
a little bit special)



My understanding is that Qt also has a compile-time flag that will
make it
actually use the real Win32 controls.




No! When compiling the Qt-library, you can specify a flag for the theme
to build. The controls appears then with this theme.

On windows you can easaly test this, with Spy++.
I've just created a simple window with
QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other
platforms?

The problem with OSX is, as I know, that some controls not only look
different, but are also different arranged, and this make it more
difficult to emulate.

°Matthias


DWT handles that fine.

--
/Jacob Carlborg

Re: New look & feel for std.algorithm


On 04/06/2011 02:06 AM, MIURA Masahiro wrote:

Looks clean and professional. I like it.

A typo: In Cheat Sheet / Iteration / group,
tuple(5, 1) is written twice.


Thanks! We got a fix already:

https://github.com/D-Programming-Language/phobos/pull/26


Andrei

Re: New look & feel for std.algorithm


On 04/05/2011 06:39 PM, user@domain.invalid wrote:

On 4-4-2011 7:58, Andrei Alexandrescu wrote:

There were also a number of bugs on www.d-programming-language.org,
which David Gileadi kindly took care of. Please take a look at
www.digitalmars.com and let me know if you find any issues. In
particular, we've discussed a while ago the new look and feel of
std.algorithm, which will serve as an example for later modules. This is
the current form:
http://d-programming-language.org/phobos-prerelease/std_algorithm.html


Great. Love the cheat sheet.

BTW

canFind find("hello world", "or") returns true.

Should that not be:

canFind canFind("hello world", "or") returns true.


Jos



Thanks. Got a fix for that, too, from klickverbot.

https://github.com/D-Programming-Language/phobos/pull/26


Andrei

Re: GUI library for D


Am 06.04.2011 14:49, schrieb Michel Fortin:

 final class Bitmap(Color) : Image {
 void opIndexAssign(int x, int y, Color color) {
 pixels[y * width + x] = Color(color);
 }

 size_t width, height;
 Color[] pixels;
 }



Yep, exactly. I would implement it as template.

About the render backend, Nick mentioned.
In the first step, I would just draw all objects (lines, boxes, circles) 
to the buffer and then render it as image per gdi/xlib.


this render should ideally be in a single file, so other backends can be 
implemented (gdi/direct2d/cairo/xcb/cocoa/..)



°Matthias

Re: GUI library for D


Am 06.04.2011 15:21, schrieb Jacob Carlborg:

On 2011-04-06 13:38, Matthias Pleh wrote:

Am 06.04.2011 11:40, schrieb Nick Sabalausky:

"Matthias Pleh" wrote in message
news:inh91t$1854$1...@digitalmars.com...

Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.: FilePicker,
colorPicker, ... but most controls are drawn by the PaintEnginge.
But Qt
make really good job in imitating the native Theme. (except OSX,
which is
a little bit special)



My understanding is that Qt also has a compile-time flag that will
make it
actually use the real Win32 controls.




No! When compiling the Qt-library, you can specify a flag for the theme
to build. The controls appears then with this theme.

On windows you can easaly test this, with Spy++.
I've just created a simple window with
QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other
platforms?

The problem with OSX is, as I know, that some controls not only look
different, but are also different arranged, and this make it more
difficult to emulate.

°Matthias


DWT handles that fine.




Yeah, that's true.
You will only get the real platform feeling, when you use the native 
controls. I was always irritated by the unusual widget of swing.

So such an approach like DWT looks always handier, but don't forget,
you have to maintain all that code for _all_ platforms.
You always get pro's and con's.

°Matthias

Re: New look & feel for std.algorithm

2011-04-06 Thread David Nadlinger


On 4/4/11 7:58 AM, Andrei Alexandrescu wrote:

There were also a number of bugs on www.d-programming-language.org,
which David Gileadi kindly took care of. Please take a look at
www.digitalmars.com and let me know if you find any issues. In
particular, we've discussed a while ago the new look and feel of
std.algorithm, which will serve as an example for later modules. This is
the current form:
http://d-programming-language.org/phobos-prerelease/std_algorithm.html


I just opened pull requests for Phobos and d-p-l.org, fixing the most 
obvious HTML errors and also a few issues mentioned in this thread.


However, there are still a few pieces of invalid HTML left, most of them 
because DDoc doesn't escape spaces in the »I'm feeling lucky« URLs – any 
ideas how to fix that?


David

Re: GUI library for D


On 2011-04-06 16:37, Matthias Pleh wrote:

Am 06.04.2011 15:21, schrieb Jacob Carlborg:

On 2011-04-06 13:38, Matthias Pleh wrote:

Am 06.04.2011 11:40, schrieb Nick Sabalausky:

"Matthias Pleh" wrote in message
news:inh91t$1854$1...@digitalmars.com...

Am 06.04.2011 09:00, schrieb Jacob Carlborg:


I think gtkD is out of the question since it's not using native
controls. Don't know about QtD, if I recall correctly it, at least,
looks quite native. But I would guess it would too hard to find whole
int that, specially on Mac OS X.



Qt (and so QtD) use some native controls for Dialogs, e.g.:
FilePicker,
colorPicker, ... but most controls are drawn by the PaintEnginge.
But Qt
make really good job in imitating the native Theme. (except OSX,
which is
a little bit special)



My understanding is that Qt also has a compile-time flag that will
make it
actually use the real Win32 controls.




No! When compiling the Qt-library, you can specify a flag for the theme
to build. The controls appears then with this theme.

On windows you can easaly test this, with Spy++.
I've just created a simple window with
QHBoxLayout,QGridLayout,QGroupbox,Qlabel,QLineEdit,QTextEdit.
But ther is only one win32-control and this is the main-window!
You can see this also on the traffic of the windowsmessages.
This is so on Windows, maybe Qt use more native controls on other
platforms?

The problem with OSX is, as I know, that some controls not only look
different, but are also different arranged, and this make it more
difficult to emulate.

°Matthias


DWT handles that fine.




Yeah, that's true.
You will only get the real platform feeling, when you use the native
controls. I was always irritated by the unusual widget of swing.
So such an approach like DWT looks always handier, but don't forget,
you have to maintain all that code for _all_ platforms.
You always get pro's and con's.

°Matthias


Yes that's true. I don't know how much different it would be compared to 
a non-native framework since there you have all the different themes to 
maintain.


--
/Jacob Carlborg

Re: Proposal for std.path replacement

2011-04-06 Thread Bruno Medeiros

On 03/03/2011 16:29, Lars T. Kyllingstad wrote:

As mentioned in the "std.path.getName(): Screwy by design?" thread, I
started working on a rewrite of std.path a long time ago, but I got
sidetracked by other things. The recent discussion got me working on it
again, and it turned out there wasn't that much left to be done.

So here it is, please comment:

http://kyllingen.net/code/ltk/doc/path.html
https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

Features:

- Most functions work with all string types, i.e. all permutations of
mutable/const/immutable(char/wchar/dchar)[]. Notable exceptions are
toAbsolute() and toCanonical, because they rely on std.file.getcwd()
which returns an immutable(char)[].

- Correct behaviour in corner cases that aren't covered by the current
std.path. See the other thread for some examples, or take a look at the
unittests for a more complete picture.

- Saner naming scheme. (Still not set in stone, of course.)

-Lars

I hope I'm not too late for the party, especially because I do have a
bit of criticism for this one...
Looking at the DDoc page, this module seem to have very
platform-dependent behavior. I find this detrimental, even unsavory. I
think it's best that programs work with internal data structures that
are as platform-independent as possible, and only convert to
platform-dependent data or API at the very last possible moment, when so
required (ie, when interfacing with the actual OS, or with the user).

So, with that in mind, there is a toCanonical function that converts to
a OS specific format, but there's no function to convert to an
OS/platform independent format?... :S

Also, what does dirName( "d:file") return on POSIX? Is it the same as on
Windows? I hope so, and that such behavior is explicitly part of the API
and not just accidental. (I don't a linux machine nearby to try it out
myself) Because, what if I want to refer to Windows paths from a POSIX
application? (I'm sure there are scenarios where that makes sense)

Or what if I just want my application to behave in a pedantically
platform-identical way, like having it to accept backlashes as path
separators not just on Windows but on POSIX as well? (This makes much
more sense than is immediately obvious... in many cases it can be argued
to be the Right Thing)

I'm sorry if I seem a bit agitated :P , it's just that due to some more
or less recent traumatizing events (a long story relating to Windows 7)
I have become a Crusader for cross-platformness.

The other suggestion I have (mentioned by others as well) is to
generalize the driver letter to a device symbol/string/identifier. But
this only makes sense if this device segment works in a
platform-independent way. This generalization might make the path module
useful in a few new contexts. Note, I'm not saying it should handle
URIs, in fact I want to explicitly say it should not handle URIs, as
URIs have additional semantics (query and fragment parts, the percent
encoding, etc.) which should not be of concern here.

BTW, I admit I take some inspiration from this API:
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/IPath.html
Note that here there is only *one* platform dependent function, the
aptly named toOSString() ...

--
Bruno Medeiros - Software Engineer

Re: Should all enums be immutable?

2011-04-06 Thread Don


Stewart Gordon wrote:

On 04/04/2011 10:32, Don wrote:

Yes. The ONLY reason those manifest constants exist at all, is so that 
they don't exist at
run time. They have no address. Any case where taking a reference to 
them works, is a

compiler bug.



Eh what?  In the case of simple value-type constants, this makes sense.  
But when they're reference types, many copies exist at run time, rather 
than only one.  This is certainly not an advantage on any level.


No. NONE exist at run time. That is the whole point. No enum should ever 
exist in the compiler. That's the only difference between immutable and 
enum.


A reasonable way of doing it is such that every instance of the same 
enum value has the same bit pattern.  For pure value types (primitive 
types, static arrays and structs/unions consisting only of pure value 
types) this is straightforward.  If a reference type is involved, put 
the contents in the static data segment and have the enum value 
referencing this one instance.  I presume this can be done...?


Stewart.

Re: Should all enums be immutable?

2011-04-06 Thread Don


Nick Sabalausky wrote:
"Rainer Schuetze"  wrote in message 
news:ind21j$1si5$1...@digitalmars.com...

Don wrote:

Jonathan M Davis wrote:
Enum values cannot be altered. It is an error to try and assign a value 
to an enum. However, the value of an enum isn't really const or 
immutable. It's copied every time that the enum is used. This is fine in 
cases where the enum is a value type, but it's problematic when the enum 
is a reference type. I believe that the classic example is if you have 
an AA which is an enum. You copy _the entire_ AA every time it's 
referenced. But it's not just AA's. Normal arrays have the problem too.


Given that the value of enum must be known at compile time and given 
that it cannot be changed, why aren't enums all immutable? What's gained 
by making so that every reference to an enum is replaced by its value 
rather than actually referencing an immutable value? In most cases, it 
could still be replaced by the value (since it's a constant) if that's 
more efficient. And in the case of reference types, it would actually 
act like a reference type.


So, I ask, should enums just all be made automatically immutable instead 
of having the current replace when referenced semantics? Is there a good 
reason _not_ to make all enums immutable?
Yes. The ONLY reason those manifest constants exist at all, is so that 
they don't exist at run time. They have no address. Any case where taking 
a reference to them works, is a compiler bug.


Almost all existing enum arrays or AAs are bugs.
For example, if you have a lookup table which should be used at runtime, 
it should ALWAYS be defined as const or immutable, not as an enum.
Unfortunately, you currently get the same performance penalty with const 
or immutable arrays as with enum: 
http://d.puremagic.com/issues/show_bug.cgi?id=4298


/me looks through all his D code for any enum/immutable/const arrays...

Even once it gets fixed for immutable/const, I hope it still gets fixed for 
enum, too. It'd be a real pain to have to think about "enum or immutable?" 
every time I need a fixed named value. And I can imagine that also causing 
problems for metaprogramming:


template foo(T, alias val)
{
// Oops!! Sometimes needs to be immutable!
// Gotta split this into two template overloads...
enum T foo = val;
}

My understanding was that the point of enum (the manifest constant enum) was 
to serve as *the* de facto way to do fixed named values because of a 
particular limitation of trying to do the same with immutable.


No. It's just a workaround for an optlink bug: manifest constants that 
are never used, still get put into the executable.


By default, you should use const, not enum. You should forget that enum 
manifest constants even exist.

Re: GUI library for D





Yes that's true. I don't know how much different it would be compared to
a non-native framework since there you have all the different themes to
maintain.



Maybe, the best aproach would be, when you implement the basic framework 
flexible. E.g. a default rendering engine, where you can

draw you own controls, but keep it possible to add native controls.
So you always choose the best way, if a platform bring out a new control 
or a new look. But I down't know, if such different approaches

cann merged together?


BTW: under what license is DWT?
Can part of it relicensed under boost? (e.g. if we would reuse part of it)


°Matthias

Re: GUI library for D

Nick Sabalausky wrote:
> Of course, if you see any fundamental
> problems with this, feel free to let me know :)

I'm pretty sure your plan would work and would provide a boost,
but I'm not sure if it's worth the extra time.

I think the best thing to do will be to partially implement it,
write a little program with both methods and run some speed tests.
See if it's still easy to use and how big the difference really is.

I'm actually already almost to the point where the simple event
loop / gdi implementation works, so won't take long to finish
that off. Then we'll go back and see what to do with speed with
the simple base to compare against.

> It's good enough for desktop applications, and it's fine if
> you're just going to draw something once and display it.

Heh, that /was/ my original intention! But now, I think we can
go so much further.

> And even then, things like line drawing, fills and image
> blitting are still better off skipping the
> individual-pixel-access routines

Aye, even my homegrown DOS would always write them separately.
Horrible waste of instructions doing another y << 8 + y << 6 when
a simple "inc ax" would suffice!

> But anyway, I don't know exactly how you were going about it, but
> the way to do this in OpenGL or DirectX would be to do all your
> drawing to a texture buffer

I at first just used a SetPixel function in opengl, but when it
was unacceptable, I simply abandoned the idea of drawing pixels
to the screen. Instead, I started focusing on polygons and textures -
a rectangle with a bitmap attached as a texture makes an excellent
sprite that draws very very quickly, even if rotated or misshapen.

Once I realized that works so well, pixels weren't important
anymore so I just stopped using the old functions entirely. They're
still in the code, still godawfully slow, but I don't care enough
to change it.

> I'd love to do some of this.

Excellent!

> You were using getch() in a game?

Not literally, no, but this was quicker to write up in a post
than to dig up the old assembly and keymaps to paste it all in,
while still hopefully showing the same basic idea behind it.
(specifically that it was a simple loop rather than a callback
or virtual function system like most events nowadays)

> BTW, this is something I'd use DirectInput for. The Win32 event
> system is about as suitable for game input as the GDI is for game
> graphics.

All right. If you have the time to write that up too, I'd
appreciate it. I'll keep it simple now due to my lack of experience
with it. The one rule though is it needs to remain easy to use. One
idea here is that newbies can run with it quickly.

> Don't want to join one of the established companies though.

Oh, hell no. Especially since my preferred style is more NES than
XBox - I like the simple 2d, low resolution look. I like the
relatively low frame rate. There's a lot less pressure to code
it perfectly too (meaning I can just whip stuff out and it's good
enough as long as its fun).

> Interesting. I've had a lot of thoughts about game loops flying
> around in the back of my mind too, but talking about any of it
> will have to wait for another time, gotta get back to some other
> stuff right now

Yea, me too... I did start that eventLoop function last night
though. So far just tied in WM_KEYDOWN to a delegate, but it works
and it's easy, so I figure I'll continue to flesh it out for the
basic operations. This way, we can play with it soon and can go
back and switch to a better system later.

Re: GUI library for D

2011-04-06 Thread Michel Fortin


On 2011-04-06 10:25:42 -0400, Matthias Pleh  said:


Am 06.04.2011 14:49, schrieb Michel Fortin:

 final class Bitmap(Color) : Image {
 void opIndexAssign(int x, int y, Color color) {
 pixels[y * width + x] = Color(color);
 }

 size_t width, height;
 Color[] pixels;
 }


Yep, exactly. I would implement it as template.

About the render backend, Nick mentioned.
In the first step, I would just draw all objects (lines, boxes, 
circles) to the buffer and then render it as image per gdi/xlib.


this render should ideally be in a single file, so other backends can 
be implemented (gdi/direct2d/cairo/xcb/cocoa/..)


Since you're at it, have you considered making the API flexible enough 
so it could support vector images too?


// return an object derived from image depending on the actual file type
Image im = loadImage("filename");

// creating a bitmap for on-screen rendering
auto bitmap = new Bitmap!RGBColor(im.width, im.height);

// base image class has a virtual function to draw itself on a bitmap at
// a given location, so it's easy to draw it on screen
im.draw(10, 10, bitmap);

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: i like cakes

2011-04-06 Thread Bruno Medeiros


On 04/04/2011 19:56, Andrei Alexandrescu wrote:

One thing that I find a bit odd is that Walter and I need to do most of
this all by ourselves, although there's significant pressure for us to
do many other things for D. For example, after having suggested that the
GTK+ news is shared on reddit and after having seen that not one soul
cares to do that, I posted the article myself, followed up with
moderators (twice) when it was manipulated into deletion, and made sure
the article was reinstated.

Speaking of GtkD, I have difficulty understanding someone who is
confident and persistent enough to carry through a major piece of work,
yet refuses to take a simple step towards letting others know about it.
Also, I get a good chuckle when seeing the occasional "I'm ready to do
anything, how can I help D?" thread on digitalmars.D. Such is human nature.



Speaking for myself, I wouldn't post a link to reddit, or any similar 
site, because I don't read/use one, thus I'm not even familiar with the 
specifics of how the site works, it's environment and culture. Actually 
the only generic (and technical) news website I follow is Slashdot. I 
haven't yet felt motivated to read Reddit (for D or otherwise) or any 
other similar site.
I'm not saying this is the best approach, even for me personally, nor 
that Reddit is not popular or important, I agree it likely is. But I 
just haven't found Reddit or some other site or site usage that works 
for me, that I feel interested in following. And thus I wouldn't be very 
comfortable participating in such a site as producer only (posting 
links), but not a consumer (following feeds?).


--
Bruno Medeiros - Software Engineer

Re: GUI library for D

Michel Fortin wrote:
> I played with it yesterday and never found why the blue channel
> didn't work!

Yeah, I noticed that too after posting it. Here's the problem:

this(int a, int b, int c) {
r = cast(ubyte) a;
g = cast(ubyte) b;
b = cast(ubyte) c;
}

Those quick one letter variable names in a barely necessary
constructor ended up shadowing each other - that last line
wrote to the local parameter instead of to the struct member
like I meant...

Stupid me. Make it this.b = ... and it works.

> I also made a working OS X implementation (Cocoa).

Cool!

> Can't we make things flexible enough for [different colorspaces]
> by using a template?

Yeah, probably.

> I'd like it better if image.display(win) was replaced with
> "window.image = image" however.

Hmm, maybe. I'm thinking image.display(win) could be some kind of
rendering function that then calls out to bitblt or whatever to
draw in any location though, offering some flexibility that the
property wouldn't provide.

So it's more like image.drawAt(drawable_surface, x, y);

Where the drawable_surface could be a window or another image, and
the image renders itself to that destination. Default parameters
would tell it to assume upper left of a new window, keeping the
simple display() call just working.

Re: GUI library for D


On 2011-04-06 17:34, Matthias Pleh wrote:




Yes that's true. I don't know how much different it would be compared to
a non-native framework since there you have all the different themes to
maintain.



Maybe, the best aproach would be, when you implement the basic framework
flexible. E.g. a default rendering engine, where you can
draw you own controls, but keep it possible to add native controls.
So you always choose the best way, if a platform bring out a new control
or a new look. But I down't know, if such different approaches
cann merged together?


I don't know. It sounds like it could get really complicated.


BTW: under what license is DWT?
Can part of it relicensed under boost? (e.g. if we would reuse part of it)


It's licensed under the EPL license since that's the license used by 
SWT. So no. I don't know if you could do some kind of deal with the 
Eclipse foundation.



°Matthias



--
/Jacob Carlborg

Re: Should all enums be immutable?

2011-04-06 Thread Trass3r


Am 06.04.2011, 17:27 Uhr, schrieb Don :
No. It's just a workaround for an optlink bug: manifest constants that  
are never used, still get put into the executable.


What?

By default, you should use const, not enum. You should forget that enum  
manifest constants even exist.


Don't you mean immutable in this case?

GSoC XML library proposal


Hello,


We have an XML library proposal. I know Tomek Sowinski was working on 
such. What is the status? Does Tomek or someone else want to apply as a 
mentor for this project?



Thanks,

Andrei

Re: GUI library for D


Am 06.04.2011 17:35, schrieb Michel Fortin:

On 2011-04-06 10:25:42 -0400, Matthias Pleh  said:


Am 06.04.2011 14:49, schrieb Michel Fortin:

final class Bitmap(Color) : Image {
void opIndexAssign(int x, int y, Color color) {
pixels[y * width + x] = Color(color);
}

size_t width, height;
Color[] pixels;
}


Yep, exactly. I would implement it as template.

About the render backend, Nick mentioned.
In the first step, I would just draw all objects (lines, boxes,
circles) to the buffer and then render it as image per gdi/xlib.

this render should ideally be in a single file, so other backends can
be implemented (gdi/direct2d/cairo/xcb/cocoa/..)


Since you're at it, have you considered making the API flexible enough
so it could support vector images too?

// return an object derived from image depending on the actual file type
Image im = loadImage("filename");

// creating a bitmap for on-screen rendering
auto bitmap = new Bitmap!RGBColor(im.width, im.height);

// base image class has a virtual function to draw itself on a bitmap at
// a given location, so it's easy to draw it on screen
im.draw(10, 10, bitmap);




Yep, definitley this would be an issue to place on the todo-list.
But let's just start with a basic implementation with simple raster 
graphics, but always in mind to extand it in the future.
BTW: to implement the whole SVG specification, that would be a huge 
project, but basic vector drawings would be definitive a nice thing to have.


°Matthias

Re: Complete D grammar

2011-04-06 Thread Ellery Newcomer


On 03/29/2011 07:53 AM, Bruno Medeiros wrote:

On 28/03/2011 18:19, Luca Boasso wrote:

You can find an ANTLR grammar for D v1 at
http://www.dsource.org/projects/antlrd/browser/toys/v3d/parsed.g (by
Ellery Newcomer)



I never should have uploaded that file.



Indeed, Ellery is (AFAIK) the only one who has worked on ANLTR-based D
parser recently and possibly got any significant work done in that. It's
definitely worth looking at his work and see if anything can be reused.
However, according to his most recent message on the subject:


...it may not provide much of head-start.



Been working on them for 3 years now. I should hope it would.

As it is, I think I'm done with D and I probably won't be continuing 
that project, so if anyone wants to do anything further with it, they're 
welcome to it.


https://bitbucket.org/ariovistus/d-jvm-cc

I also have some netbeans plugin code somewhere. If memory serves, it 
can do syntax highlighting. If anyone wants it.

Re: Complete D grammar

2011-04-06 Thread Luca Boasso

Great! It can be a good start for my Google Summer of Code Proposal
[ANTLR and Java based D parser for IDE usage].
I was looking for this code

Thank you

On 4/6/11, Ellery Newcomer  wrote:
> On 03/29/2011 07:53 AM, Bruno Medeiros wrote:
>> On 28/03/2011 18:19, Luca Boasso wrote:
>>> You can find an ANTLR grammar for D v1 at
>>> http://www.dsource.org/projects/antlrd/browser/toys/v3d/parsed.g (by
>>> Ellery Newcomer)
>>>
>
> I never should have uploaded that file.
>
>>
>> Indeed, Ellery is (AFAIK) the only one who has worked on ANLTR-based D
>> parser recently and possibly got any significant work done in that. It's
>> definitely worth looking at his work and see if anything can be reused.
>> However, according to his most recent message on the subject:
>>
>>
>> ...it may not provide much of head-start.
>>
>
> Been working on them for 3 years now. I should hope it would.
>
> As it is, I think I'm done with D and I probably won't be continuing
> that project, so if anyone wants to do anything further with it, they're
> welcome to it.
>
> https://bitbucket.org/ariovistus/d-jvm-cc
>
> I also have some netbeans plugin code somewhere. If memory serves, it
> can do syntax highlighting. If anyone wants it.
>

Re: Should all enums be immutable?

2011-04-06 Thread Simen kjaeraas


On Wed, 06 Apr 2011 18:30:43 +0200, Trass3r  wrote:


Am 06.04.2011, 17:27 Uhr, schrieb Don :
No. It's just a workaround for an optlink bug: manifest constants that  
are never used, still get put into the executable.


What?


Yup. In theory, any immutable Foo declared at module scope (and likely
also those at static class/struct scope) could be elided by the linker
if it not used anywhere, but Optlink does not do that.

That means of course, that pointer manipulation to get from one manifest
constant to another declared right after is not supported (nor should it
be *shudder*).

--
Simen

Re: GUI library for D

"Lutger Blijdestijn"  wrote in message 
news:inhp3g$25jq$1...@digitalmars.com...
> Nick Sabalausky wrote:
>
>>
>> Ha! I may not need to do much after all: I was just looking through
>> Wikipedia's giant list of browsers, found a few that looked potentially
>> promising, tried them all and...well, was mostly disappointed. But the
>> *last* one I had left to try I've been really impressed with so far:
>>
>> Arora (Qt/WebKit)
>> http://code.google.com/p/arora/
>>
>> I've only tried it breifly, but the UI is *actually nice*! Only modern
>> browser out there with a UI that isn't absolutely horrid. I didn't even
>> see *one* instance of invisible-text on my light-on-dark system, which is
>> unbeleivavly rare among all software these days.
>>
>> And it has a lot of essential stuff built in, like ad blocking,
>> disableable JS, and a "ClickToFlash" which I haven't tried out yet.
>> There's still a few things it seems like it might be missing, like
>> equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and
>> DownThemAll, but most of those are less important to me, and even as it 
>> is
>> right now it's a damn good start. Maybe I could add some of that 
>> remaining
>> stuff, or heck, maybe even port the whole thing to D ;)
>
> Even it it would involve looking at C++ code?
>

Heh :) Yea, well, versus coding a whole browser from scratch that included 
all the features I'd want... Even using premade rendering and JS engines 
(which I definitely would have done), that still leaves a lot of work.

> Did you know Arora *is* the Qt webbrowser example that got out of control
> and became a real browser? (it uses webkit)
>

Yea, I noticed that on Arora's project page. Pretty cool.

> iirc QtD has a sizeable chunk of that example already ported to D.

I'm really interestng in looking at that now. I wonder how much of a split 
there is between that and the current Arora.

Re: Should all enums be immutable?

2011-04-06 Thread Trass3r


Am 06.04.2011, 20:40 Uhr, schrieb Simen kjaeraas :

Yup. In theory, any immutable Foo declared at module scope (and likely
also those at static class/struct scope) could be elided by the linker
if it not used anywhere, but Optlink does not do that.


Ok, I guess the hack works by replacing every occurrence of the constant  
identifier in the AST with the initializer part of "enum foo =  
initializer;"?


So there would be no reason to keep enum manifest constants if this  
Optlink bug was fixed?

User-Defined Literals in the D Programming Language


http://drdobbs.com/blogs/tools/229401068

Could someone post this to reddit? Thanks.


Andrei

Re: GUI library for D

"Adam D. Ruppe"  wrote in message 
news:ini1jr$2lj3$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> Of course, if you see any fundamental
>> problems with this, feel free to let me know :)
>
> I'm pretty sure your plan would work and would provide a boost,
> but I'm not sure if it's worth the extra time.
>
> I think the best thing to do will be to partially implement it,
> write a little program with both methods and run some speed tests.
> See if it's still easy to use and how big the difference really is.
>

Yea, sounds like a good plan. Although, my design is heavily dependent on 
inlining working, so that may be a problem until DMD issue #5708 gets fixed: 
http://d.puremagic.com/issues/show_bug.cgi?id=5708

There another similar -inline related bug in there too, but I don't remember 
offhand what it is.

>> And even then, things like line drawing, fills and image
>> blitting are still better off skipping the
>> individual-pixel-access routines
>
> Aye, even my homegrown DOS would always write them separately.
> Horrible waste of instructions doing another y << 8 + y << 6 when
> a simple "inc ax" would suffice!
>

Yup, exactly. Which reminds me, I've always wanted to actually check to see 
if modern compilers (or at least DMD) would be smart enough to optimize 
something like:

for(i in 128...256)
arr[i] = ...;

Into something like:

auto ptr = arr.ptr + 128;
auto ptrEnd = arr.ptr + 256;
for(; ptr < ptrEnd; ptr++)
*ptr = ...;

My guess is no (and I'm fairly certain it was "no" back in my DOS days: that 
was the sort of manual optimization I remember doing all the time), but with 
all the improvements that optimizers keep making, I'm not really sure 
anymore.

Of course, even if the compiler can optimize that, I still doubt it would be 
able to automatically do an equivalent optimization to effectively create, 
for example, Bresenham's algorithm (ie, straight diagonal lines between two 
arbitrary points).

>> But anyway, I don't know exactly how you were going about it, but
>> the way to do this in OpenGL or DirectX would be to do all your
>> drawing to a texture buffer
>
> I at first just used a SetPixel function in opengl, but when it
> was unacceptable, I simply abandoned the idea of drawing pixels
> to the screen. Instead, I started focusing on polygons and textures -
> a rectangle with a bitmap attached as a texture makes an excellent
> sprite that draws very very quickly, even if rotated or misshapen.
>
> Once I realized that works so well, pixels weren't important
> anymore so I just stopped using the old functions entirely. They're
> still in the code, still godawfully slow, but I don't care enough
> to change it.
>

Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we 
could do better (as long as we had direct access to the texture's buffer).

>> You were using getch() in a game?
>
> Not literally, no, but this was quicker to write up in a post
> than to dig up the old assembly and keymaps to paste it all in,
> while still hopefully showing the same basic idea behind it.
> (specifically that it was a simple loop rather than a callback
> or virtual function system like most events nowadays)
>

Ahh, I see :)

>> BTW, this is something I'd use DirectInput for. The Win32 event
>> system is about as suitable for game input as the GDI is for game
>> graphics.
>
> All right. If you have the time to write that up too, I'd
> appreciate it. I'll keep it simple now due to my lack of experience
> with it. The one rule though is it needs to remain easy to use. One
> idea here is that newbies can run with it quickly.
>

Yea. Actually, I think I'll need to take look at Derelict again. I know that 
project already has a lot of these game-appropriate APIs wrapped for D (or 
at least bindings). I don't remember: Did you say this would ideally be 
something for Phobos? If so, I wonder if requiring Derelict would be a 
problem. If it is, then maybe I could just borrow the appropriate code from 
Derelict, depending on the licenses involved (I don't remember what 
Derelict's license is).

>> Don't want to join one of the established companies though.
>
> Oh, hell no. Especially since my preferred style is more NES than
> XBox - I like the simple 2d, low resolution look. I like the
> relatively low frame rate. There's a lot less pressure to code
> it perfectly too (meaning I can just whip stuff out and it's good
> enough as long as its fun).
>

Yea, same here for the most part. Although I have fallen completely in love 
with the first three Splinter Cell games :) And Pikmin. And Moonbase 
Commander (Although that one's more SNES-style). Actually, there's a fair 
amount in both gaming eras I'm really into (and in-between stuff, like Doom 
1/2/64 and the first two Quakes). But with the newer stuff it just seems to 
be getting harder and harder to find the gems, and even when you do, they're 
likely to have more problems than they used to (Like Sonic Unleashed: The 
daytime levels and puzz

Re: GUI library for D

"Nick Sabalausky"  wrote in message 
news:inihjp$hnp$1...@digitalmars.com...
> "Adam D. Ruppe"  wrote in message 
> news:ini1jr$2lj3$1...@digitalmars.com...
>>
>> Aye, even my homegrown DOS would always write them separately.
>> Horrible waste of instructions doing another y << 8 + y << 6 when
>> a simple "inc ax" would suffice!
>>
>
> Yup, exactly. Which reminds me, I've always wanted to actually check to 
> see if modern compilers (or at least DMD) would be smart enough to 
> optimize something like:
>
> for(i in 128...256)
>arr[i] = ...;
>
> Into something like:
>
> auto ptr = arr.ptr + 128;
> auto ptrEnd = arr.ptr + 256;
> for(; ptr < ptrEnd; ptr++)
>*ptr = ...;
>

Actually, I meant more like this:

enum width = 512;
int x = 10;
for(y in 128...256)
   arr[y * width + x] = ...;

to this:

enum width = 512;
int x = 10;
auto ptr = arr.ptr + 128*width + x;
auto ptrEnd = arr.ptr + 256*width + x;
for(; ptr < ptrEnd; ptr += width)
   *ptr = ...;

Re: [GSoC Proposal draft] High-Level Networking

2011-04-06 Thread Max Klyga


On 2011-04-06 02:30:44 +0300, Torarin said:


2011/4/4 Max Klyga :

Thanks to everyone who provided feedback!

I'll post my proposal update tomorrow.




I'm looking forward to it too! I've done a fair amount of research on
these topics and given networking in D a lot of thought. I'd prefer
the standard library's socket interface to be more low level than it
is today, and to have a socket type that provides non-blocking IO
transparently through fibers. This enables both generic protocol
implementations that can handle several types of concurrency, and
efficient parsers using buffered input ranges.

I also think the library should offer it's own event loop instead of
linking to libev or libevent, which have their weaknesses in such a
context. For instance, you can't simply hand over garbage collected
objects to them, which is unfortunate given the usefulness of closures
for handling events. I also think a lower-level API than Boost ASIO is
wise, because one may need to use novel and platform-specific
optimizations like linux splice, a must for efficient file servers.

As I mentioned, I have started implementing some of this. Would you be
interested in pairing up with me on some parts of the project?

Best regards, Torarin


I'll be glad to cooperate if this isn't explicitly forbidden by GSoC 
rules (which is highly implausible).

I too think that current socket interface could be improved.

Re: GUI library for D

"Michel Fortin"  wrote in message 
news:inhnnn$236n$1...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> I haven't benchmarked or even tested this, and heck, maybe I'm just
>>> a dinosaur, but for better speed and flexibility I'd recommend
>>> something more like what I've attached.
>>
>> Yea, that does sound better. Though I have a few comments...
>>
>>> The width is statically-known, so the compiler can optimize the
>>> index calculation from multiplication to shifts when appropriate.
>>
>> One concern I have here is will it be an incompatible type with
>> dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
>> cleaning up my png and bmp loaders in the near future to use with
>> this.)
>
> I don't think having fixed-size image will be a useful optimization, 
> except perhaps if you manipulate a lot of tiny images of the same size.
>

Manipulating images in software involves accessing a *lot* of pixels, so you 
have a very big "inner loop" situation. If the width isn't statically-known, 
then:

- Every arbitrary pixel access requires a multiply (instead of a shift or 
sum-of-shifts like you can do if the width is statically-known and a power 
of 2 or a sum of powers of 2).

- Every sequential non-horizontal pixel access requires an extra register to 
be used (to hold the pointer-increment value).

Over all the pixels in a scene, that can really add up. In fact, that's one 
of the reasons game engines traditionally have only supported very specific 
finite sets of fixed image sizes.

Of course, usually you'd avoid doing direct pixel access and use 
specially-optimized higher-level primitives instead (although even those can 
often benefit from a statically-known power-of-2 width). But since one of 
the goals behind this API is to be used as a "playground", we can expect 
that people are going to want to be doing a lot of direct pixel access.

Although, we'll certainly want to do some benchmarking to really know for 
sure.

>
> Don't forget that there's actually much more colorspaces than indexed and 
> RGB. There's RGBA (when you need semi-transparency), there's CYMB (for 
> print), there's grayscale. And in some cases HSV or XYZ could be useful 
> too. And for each of these someone might want different bit depth. Can't 
> we make things flexible enough for that by using a template?
>
> final class Bitmap(Color) : Image {
> void opIndexAssign(int x, int y, Color color) {
> pixels[y * width + x] = Color(color);
> }
>
> size_t width, height;
> Color[] pixels;
> }
>
> This way, you can have a bitmap of RGBColor, or RGBAColor (with an alpha 
> mask), GrayColor, IndexedColor, or whatever color type you can come with, 
> and algorithms can be reused.
>

Yea, that's probably a very good idea.

Re: User-Defined Literals in the D Programming Language

> Could someone post this to reddit? Thanks.

Looks like someone already did:
http://www.reddit.com/r/programming/comments/gk5ou/userdefined_literals_in_the_d_programming_language/

Re: GUI library for D

2011-04-06 Thread David Nadlinger


On 4/6/11 10:41 PM, Nick Sabalausky wrote:

I don't think having fixed-size image will be a useful optimization,
except perhaps if you manipulate a lot of tiny images of the same size.



Manipulating images in software involves accessing a *lot* of pixels, so you
have a very big "inner loop" situation. If the width isn't statically-known,
then:[…]


If you want to write something generic that actually performs well, the 
Adobe/Boost »Generic Image Library« might be an interesting example: 
www.boost.org/doc/libs/release/libs/gil/doc/index.html


David

Re: GUI library for D

2011-04-06 Thread Dmitry Olshansky


On 07.04.2011 0:11, Nick Sabalausky wrote:

"Adam D. Ruppe"  wrote in message
news:ini1jr$2lj3$1...@digitalmars.com...

Nick Sabalausky wrote:

Of course, if you see any fundamental
problems with this, feel free to let me know :)

I'm pretty sure your plan would work and would provide a boost,
but I'm not sure if it's worth the extra time.

I think the best thing to do will be to partially implement it,
write a little program with both methods and run some speed tests.
See if it's still easy to use and how big the difference really is.



Yea, sounds like a good plan. Although, my design is heavily dependent on
inlining working, so that may be a problem until DMD issue #5708 gets fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=5708

There another similar -inline related bug in there too, but I don't remember
offhand what it is.


And even then, things like line drawing, fills and image
blitting are still better off skipping the
individual-pixel-access routines

Aye, even my homegrown DOS would always write them separately.
Horrible waste of instructions doing another y<<  8 + y<<  6 when
a simple "inc ax" would suffice!


Yup, exactly. Which reminds me, I've always wanted to actually check to see
if modern compilers (or at least DMD) would be smart enough to optimize
something like:

for(i in 128...256)
 arr[i] = ...;

Into something like:

auto ptr = arr.ptr + 128;
auto ptrEnd = arr.ptr + 256;
for(; ptr<  ptrEnd; ptr++)
 *ptr = ...;

My guess is no (and I'm fairly certain it was "no" back in my DOS days: that
was the sort of manual optimization I remember doing all the time), but with
all the improvements that optimizers keep making, I'm not really sure
anymore.

Of course, even if the compiler can optimize that, I still doubt it would be
able to automatically do an equivalent optimization to effectively create,
for example, Bresenham's algorithm (ie, straight diagonal lines between two
arbitrary points).


But anyway, I don't know exactly how you were going about it, but
the way to do this in OpenGL or DirectX would be to do all your
drawing to a texture buffer

I at first just used a SetPixel function in opengl, but when it
was unacceptable, I simply abandoned the idea of drawing pixels
to the screen. Instead, I started focusing on polygons and textures -
a rectangle with a bitmap attached as a texture makes an excellent
sprite that draws very very quickly, even if rotated or misshapen.

Once I realized that works so well, pixels weren't important
anymore so I just stopped using the old functions entirely. They're
still in the code, still godawfully slow, but I don't care enough
to change it.


Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we
could do better (as long as we had direct access to the texture's buffer).



Mmm, am I the only one wondering where did you guys get SetPixel in 
OpenGL ?  It's must have been GDI.
At any rate OpenGL and DirectX is all about sending commands and data 
back and forth between  CPU and videocard (well, there is driver 
involved, doing some translation into specific chip's commands and such).
So no, SetPixel couldn't exactly get inlined just because you can't 
access video ram without jumping through some hoops:  OS -> HAL-> driver 
--->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX subsytems 
bypass some of these additional hoops, but still you have to send the 
data down this route. That's why it's usually used for massive 
asynchronous transfers.
E.g. every time you need GetPixel you send "read pixels command" and 
wait utill all the data already streamed in is processed and stored in 
the video RAM, then it reads framebuffer and sends you results 
(effectively stalling all it's processors).
So for "straight" setpixel/putpixel drawing, software render + blit to 
screen is the way
(but I  doubt you need only pixels, and going futher inevitably shows 
why software render sucks).


--
Dmitry Olshansky

Re: User-Defined Literals in the D Programming Language

2011-04-06 Thread Trass3r


http://drdobbs.com/blogs/tools/229401068


Nice article, but after reading the title I was actually expecting an  
article more about real user-defined literals (and its quirks as we  
recently discussed in  
http://www.digitalmars.com/d/archives/digitalmars/D/user_defined_literals_132779.html)
There even is a proposal to remove it from C++0x:  
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html


Maybe some more reasons for not having real user-defined literals could be  
given before explaining how to implement something like it in user code.

Re: GUI library for D


Am 06.04.2011 22:50, schrieb David Nadlinger:

On 4/6/11 10:41 PM, Nick Sabalausky wrote:

I don't think having fixed-size image will be a useful optimization,
except perhaps if you manipulate a lot of tiny images of the same size.



Manipulating images in software involves accessing a *lot* of pixels,
so you
have a very big "inner loop" situation. If the width isn't
statically-known,
then:[…]


If you want to write something generic that actually performs well, the
Adobe/Boost »Generic Image Library« might be an interesting example:
www.boost.org/doc/libs/release/libs/gil/doc/index.html

David



Thank's for sharing. Seems to be a cool project.
I will have a look at it.

°Matthias

Re: GUI library for D

Dmitry Olshansky wrote:
> Mmm, am I the only one wondering where did you guys get SetPixel in
> OpenGL ?  It's must have been GDI.

Oops, looks like you're right. SetPixel is GDI, and it's pretty
slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f
[...] glEnd() as the opengl putpixel. Looks like in an earlier
revision, I also used glDrawPixels at some point, but I didn't keep
it for some reason. Don't remember why (or even what it does.)

But yeah, it's been a while and my brain jumbled it all together...
sorry about that.

Re: GUI library for D

"Dmitry Olshansky"  wrote in message 
news:inik5u$n13$1...@digitalmars.com...
>
> Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL 
> ?  It's must have been GDI.
> At any rate OpenGL and DirectX is all about sending commands and data back 
> and forth between  CPU and videocard (well, there is driver involved, 
> doing some translation into specific chip's commands and such).
> So no, SetPixel couldn't exactly get inlined just because you can't access 
> video ram without jumping through some hoops:  OS -> HAL-> 
> driver --->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX 
> subsytems bypass some of these additional hoops, but still you have to 
> send the data down this route. That's why it's usually used for massive 
> asynchronous transfers.
> E.g. every time you need GetPixel you send "read pixels command" and wait 
> utill all the data already streamed in is processed and stored in the 
> video RAM, then it reads framebuffer and sends you results (effectively 
> stalling all it's processors).
> So for "straight" setpixel/putpixel drawing, software render + blit to 
> screen is the way
> (but I  doubt you need only pixels, and going futher inevitably shows why 
> software render sucks).
>

What I was thinking of was using some set/get pixel stuff to draw to 
system-ram and then use OpenGL/DirectX to transfer it to video-ram when done 
(I have no idea which way Adam was doing it).

And yea, you're right that software rendering sucks performance-wise. But 
the main orginal point was t have a way to just toy around with image 
drawing in an easy classic DOS-style. From there, my thoughts were "ok, how 
to make this approach as close to being efficient as it can realistically 
get?"

Re: GUI library for D

I'm snipping a bit since we're on the same page.

Nick Sabalausky wrote:
> Yea. I see. I wonder if OpenGL's SetPixel was inlined.

Note my mistake: SetPixel is GDI. I got it mixed up in my brain.

>  Did you say this would ideally be something for Phobos?

Yes, I hope so. It'll be nice for D if newbies can dive right into
this stuff out of the box.

> And along the NES/SNES lines, I've always been a huge sucker for
> DOS VGA/EGA gaming.

Another great thing was all you could do with the text mode, like
Walter's Empire DOS version.

That oem character set with the 80x25 cell display, 16 color
palette.. and, of course, the blink bit could go incredibly far
in making a nice little game board.

> You'd probably need DOSBox for all of them these days.

DOS programs are one reason why I was so reluctant to get into the
64 bit bandwagon. I eventually caved in a few months ago when
my old motherboard gave up the magic smoke, but I really didn't
want to lose native 16 bit ability!

DOSBox does the job, but I've always found it hard to use compared
to the "real" thing.

GSoC 2011

2011-04-06 Thread Mihir Patil

Hi,
I am Mihir. I am a Bachelors student of Computer Science. I am
interested in applying for the lexing and parsing project in D. I am
also interested in the garbage collection project. I am doing these
tasks as my term project this semester and would love if I get this
opportunity.
There are no mentors listed on the ideas page. So whom should I
contact or can anyone in the mailing list tell me some details about
the task?
Thank you.

-- 
Mihir Patil
3rd year, BE (Computer Science),
Joint Co-ordinator, Computer Science Association
Birla Institute of Technology and Science,Pilani
+91-9772974127

Re: GUI library for D

"David Nadlinger"  wrote in message 
news:inijsn$m9r$1...@digitalmars.com...
> On 4/6/11 10:41 PM, Nick Sabalausky wrote:
>>> I don't think having fixed-size image will be a useful optimization,
>>> except perhaps if you manipulate a lot of tiny images of the same size.
>>>
>>
>> Manipulating images in software involves accessing a *lot* of pixels, so 
>> you
>> have a very big "inner loop" situation. If the width isn't 
>> statically-known,
>> then:[.]
>
> If you want to write something generic that actually performs well, the 
> Adobe/Boost »Generic Image Library« might be an interesting example: 
> www.boost.org/doc/libs/release/libs/gil/doc/index.html
>

Just took a brief glance. Does seem potentially interesting. Appears to 
essentially be a C++ std.range/std.algorithm for images. I can imagine a 
similar approach might be fruitful for us.

Re: GUI library for D

"Adam D. Ruppe"  wrote in message 
news:inimg1$t0m$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> And along the NES/SNES lines, I've always been a huge sucker for
>> DOS VGA/EGA gaming.
>
> Another great thing was all you could do with the text mode, like
> Walter's Empire DOS version.
>

I admit I've never actually played any version of Empire. But then I've 
never really been particularly into resource-management strategies (I 
*think* that's what Empire is...something similar to Civilazation, right?)

> That oem character set with the 80x25 cell display, 16 color
> palette.. and, of course, the blink bit could go incredibly far
> in making a nice little game board.
>

Yea. Kroz and ZZT were great. And I made a few little text-mode games in 
QBASIC a lifetime ago (And posted them on AOL, way back at AOL v1.x :) 
Pre-web, heh). Still have those QBASIC games around here somewhere. The 
characters for the extended-ASCII range and control codes were really useful 
(the walls, the two "face" characters, etc). I totally forgot about the 
blink bit!

>> You'd probably need DOSBox for all of them these days.
>
> DOS programs are one reason why I was so reluctant to get into the
> 64 bit bandwagon. I eventually caved in a few months ago when
> my old motherboard gave up the magic smoke, but I really didn't
> want to lose native 16 bit ability!
>
> DOSBox does the job, but I've always found it hard to use compared
> to the "real" thing.

I had no idea the 64-bit chips couldn't do 16-bit!

I'm actually not real concerned about that though. I've found that a *lot* 
of the old DOS stuff I like is entirely broken on my modern(-ish) 32-bit XP 
system (and a lot of it never played well with Windows in the first place), 
so I usually have to use either DOXBox or my old 486 anyway. Not that DOSBox 
is perfect yet, unfortunately, but it seems to actually have much better 
compatibility than trying to run things "natively".

Re: GSoC 2011


On 4/6/11 3:21 PM, Mihir Patil wrote:

Hi,
I am Mihir. I am a Bachelors student of Computer Science. I am
interested in applying for the lexing and parsing project in D. I am
also interested in the garbage collection project. I am doing these
tasks as my term project this semester and would love if I get this
opportunity.
There are no mentors listed on the ideas page. So whom should I
contact or can anyone in the mailing list tell me some details about
the task?
Thank you.


This list is a good point of contact because most mentors and potential 
mentors are frequenting it.


We already have a strong candidature for a lexing and parsing project. 
Please look at discussions initiated by Luca Boasso in this forum.


That doesn't mean you can't define a complementary project. 
Alternatively, feel free to select another potential project or come up 
with your own.



Best regards,

Andrei

Re: GUI library for D

2011-04-06 Thread Dmitry Olshansky


On 07.04.2011 1:29, Adam D. Ruppe wrote:

Dmitry Olshansky wrote:

Mmm, am I the only one wondering where did you guys get SetPixel in
OpenGL ?  It's must have been GDI.

Oops, looks like you're right. SetPixel is GDI, and it's pretty
slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f
[...] glEnd() as the opengl putpixel. Looks like in an earlier
revision, I also used glDrawPixels at some point, but I didn't keep
it for some reason. Don't remember why (or even what it does.)

But yeah, it's been a while and my brain jumbled it all together...
sorry about that.
Ah,  I see. No problem, and, yes, fro me OpenGL never got drawing single 
pixels this way,
 and still not fast enough even when packed in single array. DrawPixels 
is for drawing block of pixel data (2D images), technically it can draw 
1x1 image.
As for the topic of messing old school DOS-like messing with image, I 
think there was some peculiar MMX-based
code for that buried somewhere in SDL, may be it can be revived in SSE2 
world :)
Long time ago I also sought out simplistic GUI system with direct 
framebuffer, I ended up with design
Windowing System <-> GL <- blit -> software renderer should be easily 
portable as far as the wrapper around windowing system is minimalistic 
(e.g. map repaint, keys and mouse events).


--
Dmitry Olshansky

Re: GUI library for D

Nick Sabalausky wrote:
> I admit I've never actually played any version of Empire. But then
> I've never really been particularly into resource-management
> strategies (I *think* that's what Empire is...something similar to
> Civilazation, right?)

I've never played Civilization! But, I wouldn't call it resource
management really. Every turn, you can make more units (more
or less depending on how many cities you've captured), and while
that's an important part of the game, I'd say more of it is
positioning your guys and advancing without leaving your own cities
open to be conquered.

Resource management makes me think of something like Warcraft
where controlling the gold mines is more important than army
positioning. Holding cities is vital to victory in Empire, but
positioning your army is at least as important too.

> I had no idea the 64-bit chips couldn't do 16-bit!

Then can, but not when they are in 64 bit mode.

In 32 bit mode, it's the same as the old chips. You can run 32 bit
code and 16 bit code side by side, but no 64 bit.

In 64 bit mode, you can now run 64 and 32 bit code together, but
no 16 bit.

The mode it runs in depends on your operating system. Put a 32 bit
OS on the 64 bit chip and everything works the same as the old
processors. But, if you want to actually use the new capabilities,
you've gotta go with a 64 bit OS, which means losing native 16 bit
(at least until you reboot into 32 or 16 bit OS)

Re: [GSoC Proposal draft] High-Level Networking

2011-04-06 Thread Max Klyga

OK, I've absorbed enough informtion to transform my thoughts in the 
second proposal draft.

I'll be posting it direcltly to GSoC website and correct it, if necessary.

Proposal is situated here: 
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/neku42/1


Comments 


are welcome.

Re: GUI library for D

2011-04-06 Thread Daniel Gibson

Am 07.04.2011 00:33, schrieb Adam D. Ruppe:
> Nick Sabalausky wrote:
>> I admit I've never actually played any version of Empire. But then
>> I've never really been particularly into resource-management
>> strategies (I *think* that's what Empire is...something similar to
>> Civilazation, right?)
> 
> I've never played Civilization! But, I wouldn't call it resource
> management really. Every turn, you can make more units (more
> or less depending on how many cities you've captured), and while
> that's an important part of the game, I'd say more of it is
> positioning your guys and advancing without leaving your own cities
> open to be conquered.
> 
> Resource management makes me think of something like Warcraft
> where controlling the gold mines is more important than army
> positioning. Holding cities is vital to victory in Empire, but
> positioning your army is at least as important too.
> 
>> I had no idea the 64-bit chips couldn't do 16-bit!
> 
> Then can, but not when they are in 64 bit mode.
> 
> In 32 bit mode, it's the same as the old chips. You can run 32 bit
> code and 16 bit code side by side, but no 64 bit.
> 
> In 64 bit mode, you can now run 64 and 32 bit code together, but
> no 16 bit.
> 
> The mode it runs in depends on your operating system. Put a 32 bit
> OS on the 64 bit chip and everything works the same as the old
> processors. But, if you want to actually use the new capabilities,
> you've gotta go with a 64 bit OS, which means losing native 16 bit
> (at least until you reboot into 32 or 16 bit OS)

You can probably just run a 32bit VM with DOS (or Win9x or something) in
it (via VirtualBox or similar).
Maybe in some cases this runs better than DosBox (Or at least as good as
a native 32bit Windows).

Cheers,
- Daniel

Re: GUI library for D

"Adam D. Ruppe"  wrote in message 
news:inipn4$14rq$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> I admit I've never actually played any version of Empire. But then
>> I've never really been particularly into resource-management
>> strategies (I *think* that's what Empire is...something similar to
>> Civilazation, right?)
>
> I've never played Civilization! But, I wouldn't call it resource
> management really. Every turn, you can make more units (more
> or less depending on how many cities you've captured), and while
> that's an important part of the game, I'd say more of it is
> positioning your guys and advancing without leaving your own cities
> open to be conquered.
>
> Resource management makes me think of something like Warcraft
> where controlling the gold mines is more important than army
> positioning. Holding cities is vital to victory in Empire, but
> positioning your army is at least as important too.
>

Ah, so it's really more a straight strategy game, maybe with a slight 
tactical leaning. Maybe I should give it a try sometime then. Is it 
turn-based or realtime? I'm usually more a turn-based fan, although Pikmin 
was a damn good realtime strategy.

Re: GUI library for D

Nick Sabalausky wrote:
> Is [Empire] turn-based or realtime?

Turn based.

Here's the site: http://www.classicempire.com/

I like the old version - the text mode graphics are nice.

Don't blame me if it gets you fired and divorced :) Easy to lose
track of time once you get into it!

Re: GUI library for D ---- Why do not consider to use GTK+ 3.0 ??

2011-04-06 Thread nedbrek

Hi David,

"David Wang"  wrote in message 
news:inh53n$10fn$1...@digitalmars.com...
> please view:
>
> http://www.digitalmars.com/pnews/read.php?
> server=news.digitalmars.com&group=digitalmars.D&artnum=134026

Do you do a lot of gtk GUI development?  How do avoid the grind of 
edit-compile-test?

Ned

Re: GUI library for D ---- Why do not consider to use GTK+ 3.0 ??

2011-04-06 Thread Jesse Phillips

On Wed, 06 Apr 2011 07:35:19 +, David Wang wrote:

> please view:
> 
> http://www.digitalmars.com/pnews/read.php?
> server=news.digitalmars.com&group=digitalmars.D&artnum=134026

The reason this is not getting a lot of attention is the same reason any 
one GUI project isn't getting a lot of attention, everyone has their own 
desire for which toolkit to build from and everyone is busy. On top of 
that GtkD exists, while it currently uses an older version of Gtk it is 
there and will likely move to Gtk 3.0 when the author has some more time. 
The benefits of 'GObject Introspection' are of no consequence since it 
already works without them.

I do not speak for the author or his plans, but at this time moving it up 
to 3.0 is just more work and time the author doesn't have.

Re: [RFC] CSV parser

2011-04-06 Thread Jesse Phillips

On Wed, 06 Apr 2011 01:53:19 -0400, Robert Jacques wrote:

> The library should work with both and be efficient with both. i.e.
> detect at compile-time whether you have a string or an input range, and
> act accordingly.

I'm actually considering trying to benchmark my two implementations. 
However I really don't know a good setup for testing memory usage. At 
this time it is not a priority as specialization can be added without 
changing the interface or capabilities.

>> auto records  = csvText(str);
>> auto heading = records.heading;
>>
>> or shouldn't it be passed in as an empty array:
>>
>> string[] heading;
>> auto records = csvText(str, heading);
> 
> Hmm... The latter makes it explicit that there should be headers, while
> with the former, you'd need to call heading before parsing the records,
> which could be a source of bugs. Then again, records.heading is more
> natural. Alternative syntax ideas:
> 
> auto records = csvText(str, null);
> auto heading = records.heading;
> 
> or
> 
> auto records = csvText!(csvOptions.headers)(str); auto heading =
> records.heading;

I'm not fond of the csvOptions approach, but the combined explicit and 
ability to retrieve seems reasonable.

>>> * Regarding buffering, it's okay for the tokenizer to expose buffering
>>> in
>>> it's API (and users should be able to supply their own buffers), but I
>>> don't think an unbuffered version of csvText itself is correct;
>>
>> As I'm thinking of using an output range I believe it has the job of
>> allowing a user specified buffer or not. I'm not sure if the interface
>> for csvText or RecordList should allow for custom buffers.
> 
> An output range is not a buffer. A buffer requires a clear method and a
> data retrieval method. All output ranges provide is put.

Except for the exceptions thrown the tokenizer only needs an output range 
of char.

csvText is buffered by using Appender internally. However the default is 
to make a copy of the data in the buffer, which is safer.
 
>>> csvByRecord or csvText!(T).byRecord would be more appropriate.
>>
>> You always iterate CSV by record, what other option is there? If you
>> desire an array for the record:
>>
>> auto records = csvText(str);
>>
>> foreach(record: records)
>> auto arr = array(record); // ...
> 
> Well, some of your example code included
> csvText!MyStruct(str,["my","headers"]); or possibly just
> csvText!MyStruct(str). Which would have either provide a forward range
> of MyStructs or an array of MyStruct. In either case, duplication of
> strings where appropriate should occur. Also, remember that records
> might not be manually processed; the user might forward it to
> map,filter,etc and therefore should be safe by default. A user should
> have to manually state that they are going to want a lazy buffered
> version.

The behavior when using string is to do a duplication, but char[] will 
not. I believe this provides access to both a safe and memory efficient 
iteration. But it is confusing and probably doesn't need to be provided. 

> Why do you need to do any modification? Part of the advantage of csv is
> that it's just text: you don't have to deal with escape characters, etc.

This is wrong. CSV does have escape characters, or more precisely an 
escaped quote.

> By tuple I meant the tuple(5,7) kind, not the TypeTuple!(int,char) kind.
> Basically,
> 
> auto records = csvText!(string,real)(str); string[] names   =
> records._0;
> real[]   grades  = records._1;
> 
> vs
> 
> auto records = csvText!(Tuple!(string,"name",real,"grade"))(str);
> foreach(record; records) {
>   writeln(record.name," got ",record.grade);
> }

I'm not sure the second example would work with the current 
implementation. But thinking on this part, it might be better to wait for 
the DB API to be worked out and then it could use this module to provide 
such database queries.

Empire (Was: GUI library for D)