I just now updated from cvs and cycled my compiler without any problems. I saw your email on the FPC list and I answered it. I think your compile problem has to do with a path you have in your /etc/ppc386.cfg file. You have a path -Fu../../units/linux. I used to have this directory that I would copy the rtl .ppu files to. But it was causing me problems all the time, so I removed it from the ppc386.cfg file and quit copying the rtl files to it. Now I just have the path the rtl directory in my ppc386.cfg file and I haven't had any problems cycling the compiler since. Like I said, I just now did an update of everything from cvs (compiler, rtl, gtk, fcl, api, lazarus, lcl, etc.) and rebuilt everything without any problems. I bet that path is what is causing you problems.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

This is not a path problem with the compiler. That only occures when the compiler complains about not found files or invalid PPU's

Curtis White wrote

I think your compile problem has to do with a path you have in your /etc/ppc386.cfg file.

I don't USE a ppc386.cfg file and never have.

Like I said, I just now did an update of everything from cvs (compiler, rtl, gtk, fcl, api, lazarus, lcl, etc.) and rebuilt everything without any problems. I bet that path is what is causing you problems.

NO. NO. NO.

I guess I didn't make myself clear. This isn't because I don't know what I am doing. I have been cycling compilers for months. Yes I know how to "make clean" everything, that was the first thing I tried. My shell app does it automatically but I did it myself manually to be sure. Then as a further test I deleted ALL my source and tried to build from totally fresh source. SAME PROBLEM. The interim compiler ppc1 generates a runtime error 240 when trying to recompile syslinux.pp.

If you just did a complete update out of CVS and rebuilt a Linux compiler I sure would like to know how.

I just did a build 16 hours ago without any problems. Something changed within then and now.

I guess I am not going to get the Trace stuff into CVS this afternoon. I checked out new RTL stuff from CVS so I would have the fix Peter made. I built a new RTL, FCL, etc but was getting GLIB not found errors in glib.pp. So I decided to make sure I had everything checked out and cycled the compiler. It failed. Now I can't build a new compiler so I can't test Trace, yadda, yadda, yadda.

Anybody else having trouble cycling a new compiler?

Michael A. Hess wrote

[...] Anybody else having trouble cycling a new compiler?

Same trouble here:-(

bye,

Stefan

Curtis White wrote

But I will be more careful about trying to help from now on.

My apologies Curtis. Please don't let my momentary frustration deter you from trying to lend a hand. If I seemed curt (well I guess I was, sorry) it was my frustration of spending 2 days tring to get one simple thing working.

I should have been more diplomatic about it, Stefan sure was. Again 20 lashes with a wet noodle for me, not you. :-)

I just did this one and a half hours ago and it worked fine for me.

As Peter said that is REAL strange since it was a bug in the RTL which meant it just wouldn't work. Not real sure how you made a successful build.

Can someone please explain some things to me about how the GtkInt units are setup to work?

I am having trouble figuring out the purpose/difference between the different IntSendMessage procedures. Right now, there are 3 IntSendMessage procedures and they each take different parameters. How do we know which one to use to do what we need?

I have a lot of Gtk functions I am going to need to call in the TNotebook component. So do I setup new methods in the GtkInt object for each of the different things I need to do? Or do I adapt them to some of the existing methods/functions? And if I adapt them to the existing functions, what if they need more parameters to be passed?

Are we only calling methods in the GtkInt object by sending messages with the IntSendMessage procedures and then having them call the methods, or are we calling methods directly?

I just need to know how to use this GtkInt object so I am not doing something way off course.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

1) I am trying to use only Sendmessage 2 and 3. 3 is good if you can send the SELF parameter. 2 is good for sending a bunch of info because you can send that last pointer as a record. Look at the function SetBounds in CONTROL.INC it sends a TRect as the last pointer value. If you want to send a whole bunch of stuff TextOut I(and other procedures) I set up a TLM******* record and send that as the last pointer. Then I reference it in gtkinterface. I define the record layout in lmessages.pp

So, if you can send just the SELF parameter, use 3, else use 2.

2) We are ONLY calling gtk by using the sendmessage. That way when we convert a gtkinterface object to QT, we don't have to change anything.

Shane

Awsome. Now I understand. This is pretty cool. Now I can get all the GTK code moved out of the Notebook files and into GtkInt. Hopefully I will have that done later today or tomorrow (I have to go with the wife to dinner at some friends tonight so won't get much done :( ).

Thanks for the excellent explanation.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

Thanks Michael. This is a huge help. Now I can get all the gtk code moved from the notebook units (hopefully today).

I won't call any methods directly. I will use the messages. Like Shane said, if I can't pass enough info in the existing IntSendMessages, I will create a record and pass it to IntSendMessage2. This is really cool. You guys did good in coming up with this gtkint object. I'm impressed! :-)

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

Curtis White wrote

Can someone please explain some things to me about how the GtkInt units are setup to work?

A bit confusing isn't it. ;-)

I am having trouble figuring out the purpose/difference between the different IntSendMessage procedures. Right now, there are 3 IntSendMessage procedures and they each take different parameters. How do we know which one to use to do what we need?

Hopefully as things move along we can combine some of the IntSendMessage methods into just one or 2. I created the Message3 to allow more information to be pulled from the TControl class instead of passing a lot of parameters. I didn't modify the other Message methods for fear of breaking something else.

At this point if you need more or different parameters then are passed in the existing Message methods, create another one. As we start finalizing more of the components we will be able to see which is the most likely optimized Message method structure. Then we can combine them into 1 or 2 methods. But for now so that you don't break someone elses code make an IntSendMessage4 if you need it.

Are we only calling methods in the GtkInt object by sending messages with the IntSendMessage procedures and then having them call the methods, or are we calling methods directly?

This is the prefered method. This helps separate the class library all the more from the GUI API being used. If you create a method that you call directly from your unit then it just means one more thing that needs to be addressed if we make a version for a different API. If at all possible try to use the SendMessage method found in TControl. This method calls the actual IntSendMessage method but since you are already inheriting TControl it means that you don't need to place the interface unit in your uses clause. Hopefully we can end up with TControl being the only unit that actually does any calls to the interface unit. Again this just helps isolate the class libraries from the GUI API.

On 28-Jul-99 Michael A. Hess wrote

I don't USE a ppc386.cfg file and never have.

OK. Well I just saw that -Fu../../units/linux path in there and assumed you were using the ppc386.cfg file since that is not one of the standard paths. Sorry for the incorrect assumption.

Sorry. I know you have been doing this for a long time. I really didn't mean to offend you. Like I said above, I saw that path and just assumed that it could be causing problems because it caused me a ton of headaches when I was using it. I was just trying to help. But I will be more careful about trying to help from now on.

If you just did a complete update out of CVS and rebuilt a Linux compiler I sure would like to know how.

I just told you how. It was on Red Hat Linux 6.0 with patches up to 2.2.9. Here are the exact steps I did. I can do it again and send you the output if you don't believe me:

cd /opt/fpc
cvs -z3 update base api fcl lazarus gtk rtl compiler gdbpas ide utils gdbint fv fpinst
cd rtl
make clean
cd ../compiler
make cycle
cd ..
mv ppc386 ppc386.0728
cp compiler/ppc386 .
cd rtl
make clean
make
cd ../fcl
make clean
make
cd ../gtk
make clean
make
cd ../api
make clean
make
cd ../lazarus/lcl
make clean
make
cd ..
make clean
make lazarus

I just did a build 16 hours ago without any problems. Something changed within then and now.

I just did this one and a half hours ago and it worked fine for me.

Curtis

Strange, because it was a RTL bug. A bug created by fixing another bug :)

But it works now again... Tomorrow i want to see the assert's :)

Peter

Peter Vreman wrote

The asserts in the RTL are in shortstring. This will need then some compiler magic for ansistrings to insert conversions. I'll take a look at it tomorrow...

Asserts with Trace is working real cool!

First i need to take a sleep now it's already 3:15am... but i can create finally again .so files with glibc2 :)

Get some sleep. 8-]

Interesting. I wonder if my cvs isn't updating correctly or something. It did update some files in the rtl directory today when I did cvs update. But the compiler built just fine. So now I am wondering what is wrong with my system that it isn't updating things the right way. I thought I was keeping my compiler updated, but now I think it was just fooling me all along and isn't updating everything the right way. How can I find out if the cvs update worked correctly?

No problem. I know the feeling. I was getting pretty frustrated trying to get the notebook component to accept controls (as a container). I fought it for several days and today, I finally got it working.

I should have been more diplomatic about it, Stefan sure was. Again 20 lashes with a wet noodle for me, not you. :-)

No problem. I'm easy. You only have to get 10 lashes :-)

As Peter said that is REAL strange since it was a bug in the RTL which meant it just wouldn't work. Not real sure how you made a successful build.

I agree. I don't understand why it worked for me. All I can think is that my cvs update didn't update everything it was supposed to for some reason. I need to check my file permissions. But I just updated and cycled a new compiler now that the fix has been made so I don't have that bug in there somewhere waiting to get me :-)

Curtis

Peter Vreman wrote

But it works now again... Tomorrow i want to see the assert's :)

It will work but it does still have one quirk. If uTrace has {$H+} declared the const Msg isn't handled correctly. The length character for the message string is also printed at the front of the string. If {$H+} is declared in uTrace then when the complete uTrace code is used it blows up. It doesn't really need {$H+} but this still might cause some problems someplace. Oh yeah the unit that was setting the Assert line also did NOT have {$H+} set so maybe that is where the confusion comes in. Just something else to check. :-)

The {$H+} in the unit that calls the assert() is not important, the string is already automaticly converted to shortstring. You only need to declare your new assertproc with 'shortstring' instead of 'string', then the $H+ doesn't matter anymore. Maybe we need to declare assertproc with a procvar instead of only a pointer, which is again one of borlands strange decissions.

The asserts in the RTL are in shortstring. This will need then some compiler magic for ansistrings to insert conversions. I'll take a look at it tomorrow... First i need to take a sleep now it's already 3:15am... but i can create finally again .so files with glibc2 :)

Peter