August 13, 2006
Carlos Santander wrote:
> I still get a bus error when pressing Command-Q with rev 5297 (both hello and button):

Thanks. This should be fixed now.

I can't get used to the fact that in "D", you can't compare pointers if one of them may be null:

class Fl_Window {
  ...
};
Fl_Window first_window, this_window;
if (first_window==this_window) ...

Now if first_window is null, I get a crash that I would not get in C++. Ah well ;-)
August 13, 2006
MatthiasM wrote:

> Carlos Santander wrote:
>> I still get a bus error when pressing Command-Q with rev 5297 (both
>> hello and button):
> 
> Thanks. This should be fixed now.
> 
> I can't get used to the fact that in "D", you can't compare pointers if one of them may be null:
> 
> class Fl_Window {
>    ...
> };
> Fl_Window first_window, this_window;
> if (first_window==this_window) ...
> 
> Now if first_window is null, I get a crash that I would not get in C++. Ah well ;-)

Heh, well, == is for value comparison (and is implemented (for objects) like
foo.equals(bar)), is for pointers :)

if (foo is null)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
August 14, 2006
Carlos Santander wrote:
> HideSheetWindow is declared twice in windowmanager.

Thanks. Removed.

> Also, maybe you should change your function pointer types from typedefs to aliases so no casting is required to use them.

Which ones? In the Carbon headers? Or in FLTK?

Matthias
August 14, 2006
Lars Ivar Igesund wrote:
> 
> if (foo is null)
> 

Doh! Of course! Stuff like that is the reason to learn "D", but the transition time is always painful, I guess.

BTW: I added drawing of all boxtypes and a mostly working single line text input widget.

Please folks, keep on testing - and maybe even contribute fixes... .


Thanks,

  Matthias
August 15, 2006
MatthiasM escribió:
> Carlos Santander wrote:
>> Also, maybe you should change your function pointer types from typedefs to aliases so no casting is required to use them.
> 
> Which ones? In the Carbon headers? Or in FLTK?
> 

Carbon. I haven't seen the FLTK code yet, but I suppose you're doing the same, so the same suggestion applies.

-- 
Carlos Santander Bernal
August 15, 2006
MatthiasM wrote:

> BTW: I added drawing of all boxtypes and a mostly working single line text input widget.


"boxtype" seems to be working for drawing at least
http://www.algonet.se/~afb/d/boxtype-fltk-mac.png

> Please folks, keep on testing - and maybe even contribute fixes... .

Did you have some kind of bug tracker for d-fltk ?

revision 5313 says:

button Program received signal EXC_BAD_ACCESS, Could not access memory.
======
#0  0x00028928 in _D9invariant12_d_invariantFC6ObjectZv ()
#1  0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this=@0x1) at fl/window.d:378
#2  0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at test/button.d:54

hello Program received signal EXC_BAD_ACCESS, Could not access memory.
=====
#0  0x00000000 in ?? ()
Cannot access memory at address 0x0
Cannot access memory at address 0x0
#1  0x0001c09c in _D2fl5group8Fl_Group6insertFC2fl6widget9Fl_WidgetiZv (this=@0x406c00, o=@0x407f80, index=0) at fl/group.d:484
#2  0x0001bfec in _D2fl5group8Fl_Group3addFC2fl6widget9Fl_WidgetZv (this=@0x406c00, o=@0x407f80) at fl/group.d:478
#3  0x00011dcc in _D2fl6widget9Fl_Widget5_ctorFiiiiAaZC2fl6widget9Fl_Widget (this=@0x407f80, X=20, Y=40, W=260, H=100, L={length = 13, ptr = 0x3ec34 "Hello, World!"}) at fl/widget.d:119
#4  0x00007670 in _D2fl3box6Fl_Box5_ctorFT2fl12enumerations10Fl_BoxtypeiiiiAaZC2fl3box6Fl_Box (this=@0x407f80, b=2 '\002', X=20, Y=40, W=260, H=100, l={length = 13, ptr = 0x3ec34 "Hello, World!"}) at fl/box.d:49
#5  0x00002920 in _Dmain (args={length = 1, ptr = 0x301160}) at test/hello.d:34

Under Mac OS X 10.3

--anders
August 15, 2006
Anders F Björklund escribió:
> MatthiasM wrote:
> 
>> BTW: I added drawing of all boxtypes and a mostly working single line text input widget.
> 
> 
> "boxtype" seems to be working for drawing at least
> http://www.algonet.se/~afb/d/boxtype-fltk-mac.png
> 
>> Please folks, keep on testing - and maybe even contribute fixes... .
> 
> Did you have some kind of bug tracker for d-fltk ?
> 
> revision 5313 says:
> 
> button Program received signal EXC_BAD_ACCESS, Could not access memory.

Try "make clean" before each new "make".

-- 
Carlos Santander Bernal
August 15, 2006
Carlos Santander wrote:

>> revision 5313 says:
>>
>> button Program received signal EXC_BAD_ACCESS, Could not access memory.
> 
> Try "make clean" before each new "make".

I did. But "button" still crashes, rev. 5316

#0  0x00028928 in _D9invariant12_d_invariantFC6ObjectZv ()
#1  0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this=@0x1) at fl/window.d:378
#2  0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at test/button.d:54

--anders
August 15, 2006
Anders F Björklund wrote:
> Carlos Santander wrote:
> 
>>> revision 5313 says:
>>>
>>> button Program received signal EXC_BAD_ACCESS, Could not access memory.
>>
>> Try "make clean" before each new "make".
> 
> I did. But "button" still crashes, rev. 5316
> 
> #0  0x00028928 in _D9invariant12_d_invariantFC6ObjectZv ()
> #1  0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this=@0x1) at fl/window.d:378
> #2  0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at test/button.d:54

Oh, yes, I had that one before. "make clean" did not clean every file. I just checked in a better attempt at the Makefile.

make clean; make

should now fix this problem.

Is there something like a "makedepend" for "D"?

  Matthias
August 15, 2006
MatthiasM wrote:
> Anders F Björklund wrote:
> 
>> Carlos Santander wrote:
>>
>>>> revision 5313 says:
>>>>
>>>> button Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>
>>>
>>> Try "make clean" before each new "make".
>>
>>
>> I did. But "button" still crashes, rev. 5316
>>
>> #0  0x00028928 in _D9invariant12_d_invariantFC6ObjectZv ()
>> #1  0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this=@0x1) at fl/window.d:378
>> #2  0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at test/button.d:54
> 
> 
> Oh, yes, I had that one before. "make clean" did not clean every file. I just checked in a better attempt at the Makefile.
> 
> make clean; make
> 
> should now fix this problem.
> 
> Is there something like a "makedepend" for "D"?



Yes, Matthias ~ it's called Build, and it effectively adds each import to the compilation list. You can find Build on dsource.org