View mode: basic / threaded / horizontal-split · Log in · Help
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
John Reimer wrote:
>>    C++:           D:
>>
>>    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
>>    Fl_Group   ->  fl.Group
>>    fl_draw()  ->  fl.draw()
> 
> # // import all symbols in gui.fl.window module into the 'fl' namespace
> #
> # import fl = gui.fl.window;

JJR, that's just what I need.

I have decided to port the code literally first. After all, I need to 
maintain the C++ and D version now. As soon as the literal port id 
working flawlessly, I'll pick up on the Fl_ prefix issue and possibly 
remove the Fl_ for both the C++ and D version and keep them compatible.

I'll set that as a general rule for myself: first a complete port, the 
improve on it. Otherwise, I'll lose track.

Matthias
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
Dave wrote:
> 
> Make sense?

Yes, absolutely! Another issue solved ;-)
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
MatthiasM wrote:
> Dave wrote:
>>
>> Make sense?
> 
> Yes, absolutely! Another issue solved ;-)

One other note on this <g> If a member function needs to be protected or 
public but is not to be overridden, it can be made 'final'. Then the 
compiler will always call it directly and it can be inlined, etc. (the 
compiler is free to 'auto-finalize' anyhow but I don't think it does 
that now). Since private and package functions are never virtual, this 
always applies to them.

Likewise a whole class can be made 'final'.

I don't know if this would apply to FLTK, but if there are some core 
protected or public functions that are called in tight loops then it 
might make a performance difference even over the C++ implementation.

Thanks,

- Dave
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
On Thu, 27 Jul 2006 23:36:22 -0700, MatthiasM <dm@matthiasm.com> wrote:

> John Reimer wrote:
>>>    C++:           D:
>>>
>>>    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
>>>    Fl_Group   ->  fl.Group
>>>    fl_draw()  ->  fl.draw()
>>  # // import all symbols in gui.fl.window module into the 'fl' namespace
>> #
>> # import fl = gui.fl.window;
>
> JJR, that's just what I need.
>
> I have decided to port the code literally first. After all, I need to  
> maintain the C++ and D version now. As soon as the literal port id  
> working flawlessly, I'll pick up on the Fl_ prefix issue and possibly  
> remove the Fl_ for both the C++ and D version and keep them compatible.
>
> I'll set that as a general rule for myself: first a complete port, the  
> improve on it. Otherwise, I'll lose track.
>
> Matthias


Sounds great, Matthias. I understand. :)

-JJR
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
Dave wrote:
> MatthiasM wrote:
>> Dave wrote:
>>>
>>> Make sense?
>>
>> Yes, absolutely! Another issue solved ;-)
> 
> One other note on this <g> If a member function needs to be protected or 
> public but is not to be overridden, it can be made 'final'. Then the 
> compiler will always call it directly and it can be inlined, etc.

Yup.  In general, all C++ functions that are not virtual should be 
marked 'final' in D.  Also, any private virtual functions must be made 
protected instead.


Sean
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
Sean Kelly wrote:
>>
>> One other note on this <g> If a member function needs to be protected 
>> or public but is not to be overridden, it can be made 'final'. Then 
>> the compiler will always call it directly and it can be inlined, etc.
> 
> Yup.  In general, all C++ functions that are not virtual should be 
> marked 'final' in D.  Also, any private virtual functions must be made 
> protected instead.

I see. I do not want to finalize too many functions, simply because I 
have stumbled over a few functions in FLTK that I would love to have 
virtual, but can't change it anymore in FLTK1.1.x because we are keeping 
binary compatibility within a branch, and we are not ready yet to open a 
true 1.2 ;-)

Matthias

PS: I am really interested in what the performance of the "D" code will 
be. It won't matter too much for FLTK itself, but eventually, should I 
port my Robotics simulation, performance is a requirement.
July 28, 2006
Re: FLTK native in 'D'. Would that be useful?
MatthiasM wrote:
> Sean Kelly wrote:
>>>
>>> One other note on this <g> If a member function needs to be protected 
>>> or public but is not to be overridden, it can be made 'final'. Then 
>>> the compiler will always call it directly and it can be inlined, etc.
>>
>> Yup.  In general, all C++ functions that are not virtual should be 
>> marked 'final' in D.  Also, any private virtual functions must be made 
>> protected instead.
> 
> I see. I do not want to finalize too many functions, simply because I 

I don't want to leave the impression that D code needs to be 'tuned' to
match C++ in general, I don't think that's the case but the compilers 
are young yet <g> In general the virtual method dispatch is probably 
just as good, it's just that it's on by default so final is low hanging 
fruit if you run into call speed issues.

IMHO, it's easier to write first-cut fast code with D.

> have stumbled over a few functions in FLTK that I would love to have 
> virtual, but can't change it anymore in FLTK1.1.x because we are keeping 
> binary compatibility within a branch, and we are not ready yet to open a 
> true 1.2 ;-)
> 
> Matthias
> 
> PS: I am really interested in what the performance of the "D" code will 
> be. It won't matter too much for FLTK itself, but eventually, should I 
> port my Robotics simulation, performance is a requirement.

Many would be interested in that too...

Don't know if you've seen these or not:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1

They are trivial but I think it is a good reference for D apps. w.r.t. 
common library functions, etc.

DMD and GDC seem pretty close, w/ DMD maybe being a tad faster for 
integer and GDC for floating point.

The main thing with any D implementation right now is to pre-allocate 
memory if possible before tight loops.

D's easy array slicing makes it easy to do things like:

const char[] s = "hello\n";
const int n = 1_000_000;
const int l = s.length;

char[] str;
for(int i = 0; i < n; i++)
{
    str ~= s;
}

to:

char[] str = new char[n * l];
for(int i = 0; i < n; i++)
{
    str[i*l .. i*l+l] = s;
}

- Dave
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
"matthiasm" <matthiasm_member@pathlink.com> wrote in message 
news:e9r97s$1dg2$1@digitaldaemon.com...
> Hi,
>
> I am one of the co-authors of FLTK. I like 'D' and as a test I have 
> manually
> translated parts of FLTK into
> native 'D' code. This is obvioulsy very different from just writing a 
> wrapper,
> more involved, but also
> more rewarding.
>
> Before I jump into manually porting a few hundred thousand lines of code, 
> I
> would really like to know
> first if the 'D' community is interested in such a thing at all and if I 
> can get
> sufficient support and a
> reasonable number of users.
>
> What do you folks think?
>
> Matthias
>
>
> FLTK is a Fast and Light user interface Tool Kit. It sets directly onto 
> the low
> lever interfaces of the three
> main supported platforms (MSWindows:WIN32, Unix including Linux: X11, Mac 
> OS X:
> Carbon/Quartz).
> FLTK is in use by several thousand people all over the world. It comes 
> with a
> visual user interface
> designer that spews out readable C++ (and after the coversion 'D').
>
> Come check it out at http://www.fltk.org/
>
>

I am an author of Harmonia D gui toolkit.
See: http://harmonia.terrainformatica.com/

I know FLTK and I beleive some ideas of FLTK is there
already.

It is different though. In particular event propagation schema.
It also has lightweight HTML engine (form layout manager,
renderer, form resource definition, etc. )

BTW: One of design goals of Harmonia was to create sort of FLTK
but in D and for D.

Package class map: http://harmonia.terrainformatica.com/map.htm

It would be extremely nice if someone will take care about Linux port:
http://harmonia.terrainformatica.com/pmwiki.php/Harmonia/Porting

Andrew Fedoniouk.
http://terrainformatica.com
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
Andrew Fedoniouk wrote:

... some shameful self-promotion in someone else's thread

<shakes head, sadly>


=========================


Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
available, floating around somewhere?
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
kris wrote:
> 
> Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
> available, floating around somewhere?

I am working on it now.

I have seen a few designs that are reachable via the "links" section. I 
do not know how current they are and if they require much or any core 
source code changes.

For example here:

http://www.tts-sf.com/alexeyp/index.php?act=themes

(in FLTK lingo, they are called schemes (FLTK1) and themes (FLTK2) - no 
idea why ;-)
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home