Re: [lazarus] I still have an ifdef request
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Mattias Gaertner wrote: > > > > > Ok, then plan a. The IDE should add the -B automatically. > > > > > > > > Thanks a lot. > > > > Where should I start looking? Or it's the sort of things which is > > > > more readily done than explained? > > > > > > Yes. Implemented for packages and project. > > > > Can the codetools also detect changes in the FCL/RTL, and then maybe > > show a warning to recompile? > > No, because there are no lazarus packages for them. > (The FCL package in the IDE is a dummy package.) Is it possible to create real packages for FCL/RTL, so that the IDE can manage their recompile? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] I still have an ifdef request
Mattias Gaertner wrote: > > > Ok, then plan a. The IDE should add the -B automatically. > > > > Thanks a lot. > > Where should I start looking? Or it's the sort of things which is > > more readily done than explained? > > Yes. Implemented for packages and project. Can the codetools also detect changes in the FCL/RTL, and then maybe show a warning to recompile? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: > Ok. You can download your patch by (all on one line): > svn diff http://svn.freepascal.org/svn/fpc/tags/release_2_0_2 > http://svn.freepascal.org/svn/fpc/tags/release_2_2_0 > ugrade.patch Thanks a lot! When will this be on sourceforge as .bz2? Thanks again for the great support! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: > Al Boldi ha scritto: > > Giuliano Colla wrote: > >> I've been earning my bread and butter developing computer applications > >> for 40 years now (my God, how old I've become! :-) ) > > > > Wow, that's impressive. > > > > Maybe you could share some of your experience regarding these question: > > > > What languages did you use? > > Compiled languages: > > 1) Assembler from HP minicomputers to IBM mainframes (including an > incredible Siemens computer, which at start-up was typing an obscure > message in german: if you just typed return, it would take the default > action, i.e. assume a new installation and reformat its hard disks! :-) > ) , and then micros for all the Intel Family, from 4004 (it was a > nightmare, three instructions to read a memory location but with good > macros you could get away) to nowadays Pentium > 2) Fortran (different flavors in time) > 3) Algol 60 > 4) Intel's PLM's: PLM48 PLM51 PLM80 PLM86 PLM386 > 5) C > 6) C++ > 7) Delphi Pascal > 8) Free Pascal > > Interpreted Languages: > > 9) Basic > 10) Visual Basic > 11) Python > 12) Tcl/Tk > > Possibly I've left out some, but that's more or less the picture. > > > Which one is the best? : : > Among OOPL doubtlessly Pascal. Why? > > How does OOP affect development (pros/cons)? : : > The con's are that it may encourage lazyness. You may end up using an > object because it's ready made, taking advantage of a minimal part of > its features, and making your code bigger and slower, and maybe harder > to debug, when a small subroutine could have served the same purpose. Good point. > (I can detect sarcasm at least since as > long as I have been programming, but your questions deserved a reply > nonetheless). Actually, there should be nothing sarcastic about trying to learn from somebody more experienced. Just one more question: In another thread you said Java is ugly, what about the language, and how does it compare to pascal? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: > IMHO zipped incremental updates are impossible, because you cannot zip > file removals. I think you can, like this: diff -ruNp file.pas /dev/null > file.diff patch < file.diff This removes the file. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Vincent Snijders wrote: > Al Boldi schreef: > >> Is there any specific reason you are stuck with 2.0.2 and can't > >> upgrade? If it's a good reason, I can consider adding a IFDEF in the > >> code. > > > > Well, when Vincent starts posting incremental updates, I may actually be > > able to upgrade easily. > > Are you referring to me? If so, what exactly are you talking about? Sorry Vincent, but I thought you were the person responsible for packaging. I am currently on 2.0.2, and when wanting to upgrade to a new stable-release there should be a way to download only an incremental update like: 2.0.2-2.0.4.tgz and 2.0.4-2.2.0.tgz. Same goes for laz stable-releases. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Graeme Geldenhuys wrote:
> On 22/01/2008, Al Boldi <[EMAIL PROTECTED]> wrote:
> > Before you do that, I just tried fpGUI and it didn't compile due to
> > cursorfont unit missing. So I added {$include cursorfont.inc} from
> > fpc/packages/extra/forms, then it compiles ok, but I get this crash on
> > run using fpc2.0.2:
>
> The last time I tested it worked fine with 2.0.4 and 2.2.0. I honestly
> don't see the point in supporting all old versions of FPC when you can
> upgrade for free. So if you can, please upgrade to fpc 2.0.4 or
> preferably 2.2.0. I tend to only support the last two FPC versions
> until I know the latest FPC release has proven itself to be truly
> stable, then I start using features of that (latest) release.
>
> As far as I can see the 'cursorfont' unit in X11's backed comes from
>/packages/extra/x11/cursorfont.pp
>
> Is there any specific reason you are stuck with 2.0.2 and can't
> upgrade? If it's a good reason, I can consider adding a IFDEF in the
> code.
Well, when Vincent starts posting incremental updates, I may actually be able
to upgrade easily.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
Giuliano Colla wrote: > I've been earning my bread and butter developing computer applications > for 40 years now (my God, how old I've become! :-) ) Wow, that's impressive. Maybe you could share some of your experience regarding these question: What languages did you use? Which one is the best? How does OOP affect development (pros/cons)? Is there a better dev-approach than OOP? What has OOP missing? When is it wrong to use OOP? How can OOP be misused? Thanks for shedding some light! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gärtner wrote: > Zitat von Al Boldi <[EMAIL PROTECTED]>: > > > > > > Exactly right! The best feature is find > > > > > > declaration/implementation, but this only works for pascal code. > > > > > > What is needed to make this work for c/c++? > > > > > > > > > > Maybe a plugin for ctags can be written. > > > > > > > > Yes, that may be the easiest way. But I think we should use ctags > > > > inlined, so that the index is created on-the-fly, and then fed into > > > > the codetools as you open each file. Do the codetools support this? > > > > > > Partially. > > > The codetools already support three 'languages': pascal (delphi, > > > objfpc, parts of macpas, parts of tp), lfm and pascal directives. > > > > > > The file caches could and should be used (for speed and for integrity > > > with the other IDE tools). > > > > The problem with the caches is that they are somewhat misleading when > > you start changing the code, and then forget to reindex. So doing it > > on-the-fly should be much safer and faster for large trees. > > I can't follow you here. > I was talking about the caches for files. For example the cache for the > file unit1.pas. The pascal parser reads and creates a code tree. This code > tree is cached as well, but this is another cache and can not be used by > the ctags. I only said, that the plugin should use the file caches instead > of accessing the files on disk directly. Ok, then we are in agreement. > > I think the least we should handle are the #include's, otherwise the > > on-the-fly ctags may not work. Parsing the files for #include's should > > be easy, right? > > I'm no ctags expert. I don't know if ctags has a preprocessor. AFAIK it doesn't. For example "ctags *" only indexes the current dir, and doesn't pick up includes, whereas "ctags -R" does it recursively picking up the whole tree except external includes. Which means that we have to handle the #include's manually. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] What is wrong with the Toolbar?
Graeme Geldenhuys wrote:
> On 22/01/2008, Paul Ishenin <[EMAIL PROTECTED]> wrote:
> > > Moving implementation from LCL to widgetset is simply the WRONG way to
> > > go.
> >
> > Then use fpGUI or mseGUI. This is not wrong way, it is way selected by
> > lazarus team long time ago. Custom controls cannot bring native
> > functionality - only imitation of it. This is not what we want and what
> > we need.
>
> Okay, I'll shut up now.
Before you do that, I just tried fpGUI and it didn't compile due to cursorfont
unit missing.
So I added {$include cursorfont.inc} from fpc/packages/extra/forms, then it
compiles ok,
but I get this crash on run using fpc2.0.2:
An unhandled exception occurred at $08055F23 :
EAccessViolation : Access violation
$08055F23 TNETWINDOWLAYER__UPDATESUPPORTEDATOMS, line 296 of _netlayer.pas
$08057856 TNETWINDOWLAYER__CREATE, line 1021 of _netlayer.pas
$08051DCD TFPGWINDOWIMPL__DOSETWINDOWTITLE, line 1202 of gfx_x11.pas
$08055A01 TFPGFORM__SETWINDOWPARAMETERS, line 171 of gui_form.pas
$08051A79 TFPGWINDOWIMPL__DOALLOCATEWINDOWHANDLE, line 1090 of gfx_x11.pas
$0804E0C6 TFPGWINDOWBASE__ALLOCATEWINDOWHANDLE, line 718 of gfxbase.pas
$08054845 TFPGWIDGET__HANDLESHOW, line 468 of gfx_widget.pas
$08055C8E TFPGFORM__HANDLESHOW, line 239 of gui_form.pas
$08055B63 TFPGFORM__SHOW, line 197 of gui_form.pas
$0808C876 TMAINDESIGNER__CREATEWINDOWS, line 287 of vfdmain.pas
$08078866 MAINPROC, line 38 of uidesigner.lpr
How can this be fixed?
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gärtner wrote: > Zitat von Al Boldi <[EMAIL PROTECTED]>: > > Mattias Gaertner wrote: > > > Al Boldi <[EMAIL PROTECTED]> wrote: > > > > Exactly right! The best feature is find declaration/implementation, > > > > but this only works for pascal code. What is needed to make this > > > > work for c/c++? > > > > > > Maybe a plugin for ctags can be written. > > > > Yes, that may be the easiest way. But I think we should use ctags > > inlined, so that the index is created on-the-fly, and then fed into the > > codetools as you open each file. Do the codetools support this? > > Partially. > The codetools already support three 'languages': pascal (delphi, objfpc, > parts of macpas, parts of tp), lfm and pascal directives. > > The file caches could and should be used (for speed and for integrity with > the other IDE tools). The problem with the caches is that they are somewhat misleading when you start changing the code, and then forget to reindex. So doing it on-the-fly should be much safer and faster for large trees. > The code trees can be used (with other constants). > Then some ctags functions should be added to the TCodeToolManager for easy > handling. > Finally some IDE features could use the ctags information. e.g. method > jumping and code explorer. > Of course ctags is a pretty simple parser and can not be used to parse > macros correctly. And of course the file interdependencies can not be > handled neither, as this requires a C IDE, which is not the goal of > lazarus. I think the least we should handle are the #include's, otherwise the on-the-fly ctags may not work. Parsing the files for #include's should be easy, right? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Exactly right! The best feature is find declaration/implementation, > > but this only works for pascal code. What is needed to make this > > work for c/c++? > > Maybe a plugin for ctags can be written. Yes, that may be the easiest way. But I think we should use ctags inlined, so that the index is created on-the-fly, and then fed into the codetools as you open each file. Do the codetools support this? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making the IDE work with C/C++
Joost van der Sluis wrote: > Op maandag 21-01-2008 om 16:57 uur [tijdzone +0300], schreef Al Boldi: > > Exactly right! The best feature is find declaration/implementation, > > but this only works for pascal code. What is needed to make this work > > for c/c++? > > Just re-write the codetools. That's rather sad for an OOP design. But still, I think it is important, so how hard would a rewrite be, and would people be interested in joining the effort? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Making the IDE work with C/C++
Graeme Geldenhuys wrote: > On 21/01/2008, Giuliano Colla <[EMAIL PROTECTED]> wrote: > > Without a mature IDE to work with, fpGUI isn't worth the trouble. It > > becomes much easier to learn C++ and use Qt Designer, or whatever. > > Umm... I don't know how I should take this! :-) fpGUI is by no means > tied to Lazarus. I often build my apps on test machines using 'gedit' > or 'mcedit' via the command line. Also, fpGUI has it's own visual > forms designer. Saying all this, I still prefer to use Lazarus as my > editor - with all the add-ons, source code navigation and keyboard > shortcuts, I'll be hard pressed to find any other editor that comes > close to it. Exactly right! The best feature is find declaration/implementation, but this only works for pascal code. What is needed to make this work for c/c++? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Rebuilding RTL and FCL inside LazIDE
Peter Vreman wrote: > >>Mattias, what is needed to add rebuilding RTL/FCL from within the IDE? > > I don't think this is a good idea to add to an IDE. Because > recompiling the RTL means that you need to recompile all installed units. > > For fpc we are working on a package system that can help in this > dependency issue. This can maybe included as an tool, but the > functionalitiy should not be included in the IDE. Right now when I change something in the RTL/FCL, I need to start a console and run make inside the fpc dir. When I forget to do this, the RTL/FCL source will be different from the compiled one. Why can't the IDE detect that, and option the user to rebuild the RTL/FCL? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Rebuilding RTL and FCL inside LazIDE
Christian U. wrote: > RTL and FCL are never build while building lazarus its a bit hard to add > an option for this i think. Mattias, what is needed to add rebuilding RTL/FCL from within the IDE? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Native debugger
Cesar Liws Gmail wrote: > >We need a native debugger support for FPC/Lazarus programs on all > >platforms.That's the big issue everyone seems to avoid talking about... > > I agree with you, and this is the kind of Project that I want to > participate. Check out http://sourceforge.net/projects/mseide-msegui It's got a nicely integrated debugger, complete with CpuView and integrated disassembler. Would be nice if somebody ports this over. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] HowTo increase developer contributions
Vincent Snijders wrote: > So what we need it users that are willing to become contributors, not > users that contribute nothing. They are welcome of course. But they are > not *needed* for Lazarus to advance. > > Please, correct me, where I am making a mistake in my reasoning. Things start small like babies; and then they grow-up to become either a winner or a looser. If you want winners, you need to give people a chance in the beginning, and support them to start walking on their own, then maybe they will start to contribute, but only when you have been nice and supportive to them. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Giuliano Colla wrote:
> BTW could you refresh my memory? What kernel and libc are you running
> with?
linux2.6.22/libc2.3.1
Here is threadbug.c which doesn't show any leaks:
// gcc -lpthread threadbug.c -o threadbug
#include
void *threadbug() {
printf(".");
}
main(){
int i;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_t threads[999];
while (1) {
printf("\nstarting threads...\n");
sleep(3);
for (i=0;i<1000;i++)
if ( pthread_create(&threads[i],&attr,threadbug,NULL) )
perror("pthread_create");
printf("\nfreeing threads...\n");
sleep(3);
for (i=0;i<1000;i++) {
pthread_join(threads[i], NULL);
printf(".");
}
}
}
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Giuliano Colla wrote:
> willem ha scritto:
> > well I made 10 copy's of threadbug and run them in parallel. In my
> > case libpthread does not allocate a 10 Mb memory block, because
> > the 10 processes should allocate 100Mb of memory Top does show only a
> > sligth increase in memory . On my kubuntu there are
> > 145 processes allocated . So i can not reproduce your problem.
:
:
> I've modified threadbug to activate many threads instead if just one.
> I show you the results with 300 threads.
>
> Thats Top report when threadbug is started:
> Mem: 1024940k total, 496500k used, 528440k free,22416k buffers
> Swap: 1028152k total,0k used, 1028152k free, 312576k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 4227 colla 17 0 2548 788 488 S0 0.1 0:00.00 threadbug
>
> That's the output of Top after 300 threads have been activated:
> Mem: 1024940k total, 501224k used, 523716k free,22664k buffers
> Swap: 1028152k total,0k used, 1028152k free, 312708k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 4227 colla 24 0 3004m 3300 520 S0 0.3 0:00.08 threadbug
>
> You can see that memory usage has minimally changed, from 496500k to
> 501224, but you can also see that the virtual memory allocated to
> threadbug has jumped from 2548k to 3004m (i.e. 3Gb!).
>
> That's Top output after the 300 threads have been destroyed:
> Mem: 1024940k total, 535096k used, 489844k free,24288k buffers
> Swap: 1028152k total,0k used, 1028152k free, 334308k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 4227 colla 15 0 33364 988 576 S0 0.1 0:01.20 threadbug
>
> You can see that total memory usage has increased instead of decreasing,
> because some allocated memory has been actually used, but what's more
> important, you can see that virtual memory allocated to threadbug is
> 33364 kB instead of the initial 2254.
Great analysis!
So if you see this problem on fpc2.2.0 even with WaitFor, then this is a
regression on top of the bug, because your multithread.lpr runs without
leaks using fpc2.0.2.
To get the leak on fpc2.0.2 you have to change your code like this:
for I := 0 to high(BugArray) do begin
t1 := BugArray[I];
t1.Terminate;
-t1.WaitFor;
write ('.'); // this causes intermittent idles causing the leak
if not Ft then begin
sleep(50);
t1.Free;
end;
end;
...and...
writeln('WaitFor? [y/N]');
+ t1.Terminate;
readln(ans); // you need to idle after terminate to see the leak
- t1.Terminate;
if ans='y' then begin
if not Ft then begin
t1.WaitFor;
writeln('OS thread memory released.');
end;
end else
writeln('OS thread memory left dangling.');
Also note that when you TThread.Free a running thread it will do an implied
Terminate and WaitFor, and therefore works without leaking on fpc2.0.2.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
willem wrote: > well I made 10 copy's of threadbug and run them in parallel. In my case > libpthread does not allocate a 10 Mb memory block, because > the 10 processes should allocate 100Mb of memory Top does show only a > sligth increase in memory . On my kubuntu there are > 145 processes allocated . So i can not reproduce your problem. I just tried on another distribution, and without WaitFor the leak is still there, but a lot smaller, only ~12kb per thread. Did you run with or without WaitFor? How big is the thread overhead? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Giuliano Colla wrote:
> Al Boldi ha scritto:
> > For now, when you start a thread non-suspended, TThread.Execute(false),
> > can you see the memory increase for your project1 app when checking with
> > top? Then, when you TThread.WaitFor/TThread.Free, does it decrease? And
> > by how much?
> >
> > Below is the simplified console app.
> >
> >
> > Thanks for the feedback!
>
> Feedback:
> I couldn't see any change with top, so I slightly modified your console
> app, by adding:
>
> writeln('Type to start thread');
>
> readln(ans);
>
> before
>
> t1:=TThreadBug.Create(false);
Ok, much better!
> With Lazarus 0.9.4.1, fpc 2.2.0 the result is the following:
> before starting the thread TOP says:
>
> 4732 colla 16 0 2564 808 488 S0 0.1 0:00.00 threadbug
>
> after the thread is started it becomes:
>
> 4732 colla 15 0 12860 916 576 S0 0.1 0:00.00 threadbug
That's a huge increase; almost 12mb. On fpc2.0.2/linux2.6.22 it increases by
~2mb, a lot less, but still large.
Can somebody check what the gcc thread overhead is?
> and it doesn't change anymore until program termination, either typing y
> or n.
If this is with v2.2.0, then this means a regression on top of a bug.
> I tried to set true FreeOnTerminate of your thread (with proper
> adjustments, because WaitFor and Free don't work anymore, of course) but
> there's no change.
>
> For sake of completeness, I made the same with my test program, where I
> can terminate, free and restart the thread multiple times, and I see the
> memory usage increasing each time: it started with 12Kb
You mean 12mb, right?
> and I stopped
> when it had become 122Mb! However all memory is released before closing
> the program, because heaptrc correctly reports an increasing number of
> blocks allocated and freed, as a function of the number of times I
> started my thread.
I don't think heaptrc detects RTL associated OS leaks. It only detects RTL
object leaks, and it seems those are freed correctly.
> As soon as I can, I'd like to perform the same tests with Kylix, to see
> if it makes a difference.
Thanks a lot!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Giuliano Colla wrote:
> Al Boldi ha scritto:
> > I played with this some more, and it turns out that not only is
> > FreeOnTerminate completely broken but Free only frees the OS-thread
> > memory if the thread is still running or is preceded by a WaitFor. This
> > is on fpc2.0.2/linux. Maybe this has been fixed in 2.2.0?
> >
> > Below is the test-code.
> >
> > Can somebody confirm this on other platforms/fpcVersions.
>
> I've made some quick tests, with what I have ready at hand and with my
> test app. Not so different from yours, except that it allows me more
> options. Platform Linux, fpc 2.0.4 and 2.2.0, Lazarus.fixes and Lazarus
> trunk latest svn. Widgetset gtk1.
>
> With fpc 2.0.4, FreeOnTerminate leaks memory whatever I've tried.
Ok, same here.
> With fpc 2.2.0, using Synchronize, I've been unable to get rid of memory
> leaks if the thread is terminated within an OnClose event.
> If the thread is terminated before closing the form, it behaves properly.
>
> With fpc 2.2.0, if I don't use Synchronize, but rather a message queue
> processed by the OnIdle handler, then I don't experience any memory
> leak, whatever is the thread termination.
>
> My conclusion: fpc 2.0.4 has almost certainly some bug on
> FreeOnTerminate. In many cases it segfaults, meaning, I guess, that
> there's some NilAndFree in place of FreeAndNil :-)
>
> With fpc 2.2.0 it's harder to tell at first glance, but one would say
> that the problem is on Lazarus side, because the fpc rtl Syncronize
> provide just a thread safe frame, and leaves all the work to the main
> thread loop.
>
> Synchronize is heavily widgetset dependent. That's why I only report
> gtk1 results. With gtk2 I've met inconsistent results from one revision
> to the next, with qt synchronize for me doesn't work at all.
Ok, synchronize is another problem, which I would like to deal with
separately.
For now, when you start a thread non-suspended, TThread.Execute(false), can
you see the memory increase for your project1 app when checking with top?
Then, when you TThread.WaitFor/TThread.Free, does it decrease? And by how
much?
Below is the simplified console app.
Thanks for the feedback!
--
Al
---
program threadbug;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes
{ add your units here };
type
{ TThreadBug }
TThreadBug=class(TThread)
procedure Execute; override;
end;
{ TThreadBug }
procedure TThreadBug.Execute;
begin
writeln('just ran a thread... done!');
end;
var t1:TThreadBug; ans:string;
begin
t1:=TThreadBug.Create(false);
writeln('WaitFor? [y/N]');
readln(ans);
if ans='y' then begin
t1.WaitFor;
writeln('OS thread memory released.');
end else
writeln('OS thread memory left dangling.');
t1.Free;
writeln('Confirm with top now!');
readln;
end.
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Al Boldi wrote:
> Micha Nelissen wrote:
> > Al Boldi wrote:
> > > I think the race comes in when you have two competing threads wanting
> > > to synchronize the the main thread. It just hangs.
> >
> > Are you sure? This should work properly. Can you provide example (in a
> > bugreport)?
>
> Well, it's not easily repeatable, and seems to be very OS dependent. On
> linux, I work around this problem by inserting a sleep(0) just before the
> synchronize.
>
> But there is another problem, it seems FreeOnTerminate doesn't actually
> free the memory on exit, unless the main thread actually waits for it to
> terminate, and this is on linux again. Can you confirm this?
I played with this some more, and it turns out that not only is
FreeOnTerminate completely broken but Free only frees the OS-thread memory
if the thread is still running or is preceded by a WaitFor. This is on
fpc2.0.2/linux. Maybe this has been fixed in 2.2.0?
Below is the test-code.
Can somebody confirm this on other platforms/fpcVersions.
Thanks!
--
Al
---
type
{ TThreadBug }
TThreadBug = class(TThread)
public
procedure Execute; override;
end;
{ TForm1 }
TForm1 = class(TForm)
Button1: TButton;
Button2: TButton;
Button3: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
t1:TThreadBug;
end;
var
Form1: TForm1;
implementation
{ TThreadBug }
procedure TThreadBug.Execute;
begin
writeln('just ran a thread... done!');
end;
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
begin
t1:=TThreadBug.Create(false);
end;
procedure TForm1.Button2Click(Sender: TObject);
begin
t1.Free; // Only frees RTL object memory
// OS-thread memory left dangling
end;
procedure TForm1.Button3Click(Sender: TObject);
begin
t1.WaitFor; // Correctly frees OS-thread memory
t1.Free; // Frees RTL object memory
end;
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Micha Nelissen wrote: > Al Boldi wrote: > > I think the race comes in when you have two competing threads wanting to > > synchronize the the main thread. It just hangs. > > Are you sure? This should work properly. Can you provide example (in a > bugreport)? Well, it's not easily repeatable, and seems to be very OS dependent. On linux, I work around this problem by inserting a sleep(0) just before the synchronize. But there is another problem, it seems FreeOnTerminate doesn't actually free the memory on exit, unless the main thread actually waits for it to terminate, and this is on linux again. Can you confirm this? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote:
> Al Boldi wrote:
> >> I do not know how to do it,
> >
> > It turns out that you need an export trick to do this.
> >
> > Include the attached 'LibSyncMgr.inc' into your lib after your
> > exports-line with this line:
> >
> > {$i LibSyncMgr.inc}
> >
> > Make sure there is no LCL or Interfaces unit included in your library
> > project.
> >
> > Then include the attached 'LibSyncMgr.pas' in your main-apps uses
> > clause.
> >
> > Then add this line:
> >
> > TLibSyncMgr.Create(self).LibHandle := LibHandle;
> >
> > right after your LoadLibrary call.
>
> I have updated code with your suggestions, but synchronize still does
> not work.
I tried your project, but it wouldn't work on linux. I had to change a few
things:
1. Add cthreads in uses clause
2. Add a 'writeln('lib loaded');' inside begin end of libthread.dpr,
otherwise it crashes.
3. Change LoadLibrary('libthread.dll') to LoadLibrary('./liblibthread.so')
Then it works on linux.
To help further, you have to put a few debug writeln's throughout the code to
see exactly where it stops working.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OnIdle event is effective only on last (last created?) form ?!
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Andrey Gusev wrote: > > > With many forms have implements OnIdle event > > > (TApplicationProperties) only one work really. > > > Sample projects is attached. Debug output files must be identical, > > > but for lazarus's project > > > we only see output from 'bbb' form, whereas for delphi's - correct, > > > intermittent from both forms > > > (see *.log files in attached archive). > > > I think, that is bug or incompleteness of TApplicationProperties > > > component. > > > What developers team thinked about that ? > > > > The problem is that Application.OnIdle is global, so setting it will > > only fire for the last one. Application.OnIdle should be set to > > TApplicationProperties.OnIdle, then TApplicationProperties should > > check whether there are other TApplicationProperties components, and > > then fire those. Should be easy to fix. > > TApplicationProperties now uses handler lists instead of global events. > That means for example, two TApplicationProperties can now both set > OnIdle and both are called. Which version had this change? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] OnIdle event is effective only on last (last created?) form ?!
Andrey Gusev wrote: > With many forms have implements OnIdle event (TApplicationProperties) > only one work really. > Sample projects is attached. Debug output files must be identical, but > for lazarus's project > we only see output from 'bbb' form, whereas for delphi's - correct, > intermittent from both forms > (see *.log files in attached archive). > I think, that is bug or incompleteness of TApplicationProperties > component. > What developers team thinked about that ? The problem is that Application.OnIdle is global, so setting it will only fire for the last one. Application.OnIdle should be set to TApplicationProperties.OnIdle, then TApplicationProperties should check whether there are other TApplicationProperties components, and then fire those. Should be easy to fix. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote:
> Al Boldi wrote:
> > But, you could instead just try setting WakeMainThread in your lib
> > yourself, and let the handler post a message to the mainthread. That's
> > what the Interfaces unit does. Can you try this
>
> I do not know how to do it,
It turns out that you need an export trick to do this.
Include the attached 'LibSyncMgr.inc' into your lib after your exports-line
with this line:
{$i LibSyncMgr.inc}
Make sure there is no LCL or Interfaces unit included in your library
project.
Then include the attached 'LibSyncMgr.pas' in your main-apps uses clause.
Then add this line:
TLibSyncMgr.Create(self).LibHandle := LibHandle;
right after your LoadLibrary call.
> Btw, I solved the problem using threadx.pas;
Sure, but this isn't cross-platform.
Thanks for testing!
--
Al
{ Library Exports for External Synchronize support }
procedure LibCheckSynchronize(TimeOut : longint=0);
begin
CheckSynchronize(TimeOut);
end;
procedure LibSetWakeMainThread(WakeProc: TNotifyEvent);
begin
WakeMainThread:=WakeProc;
end;
exports LibCheckSynchronize,LibSetWakeMainThread;
unit LibSyncMgr;
interface
uses
ExtCtrls,DynLibs,Classes;
type
TLibCheckSynchronize = procedure (TimeOut: LongInt = 0);
TLibSetWakeMainThread = procedure (WakeProc: TNotifyEvent);
{ TLibSyncMgr }
TLibSyncMgr = class(TComponent)
private
FLibHandle: TLibHandle;
FLibSync: TLibCheckSynchronize;
FLibWake: TLibSetWakeMainThread;
FTimer: TTimer;
procedure SetLibHandle(const AValue: TLibHandle);
procedure Wake(Sender: TObject);
procedure DoSync(Sender: TObject);
public
constructor Create(AOwner: TComponent); override;
property LibHandle: TLibHandle read FLibHandle write SetLibHandle;
end;
implementation
{ TLibSyncMgr }
constructor TLibSyncMgr.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FTimer:=TTimer.Create(self);;
FTimer.Enabled:=false;
FTimer.Interval:=1;
FTimer.OnTimer:=DoSync;
end;
procedure TLibSyncMgr.SetLibHandle(const AValue: TLibHandle);
begin
if FLibHandle=AValue then exit;
FLibHandle:=AValue;
if Pointer(FLibHandle) = nil then exit;
FLibSync := GetProcedureAddress(LibHandle, 'LibCheckSynchronize');
if not Assigned(FLibSync) then exit;
FLibWake := GetProcedureAddress(LibHandle, 'LibSetWakeMainThread');
if not Assigned(FLibWake) then exit;
FLibWake(Wake);
end;
procedure TLibSyncMgr.Wake(Sender: TObject);
begin
FTimer.Enabled:=true;
end;
procedure TLibSyncMgr.DoSync(Sender: TObject);
begin
FTimer.Enabled:=false;
FLibSync(1000);
end;
end.
Re: [lazarus] libview enhancement
Roberto Padovani wrote: > Btw, when I don't feel like working I'm having a look at how to make > it work under *nix (which will fit to my beloved Mac, as well) Thanks a lot! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
Vincent Snijders wrote: > Al Boldi schreef: > > Vincent Snijders wrote: > >> WakeMainThread is just one way to make sure that the calling thread > >> calls CheckSynchronize from time to time. Synchronize does not depend > >> on how the main thread call CheckSynchronize, just that it is > >> accomplished. > > > > Sure, you are talking about normal apps. But with dynamic libs > > CheckSynchronzie doesn't work. Try it. > > Please provide complete source. melchiorre already posted the source. > Aare you calling the correct CheckSynchronize? Note that there are two > RTL involved, one of the main app and one of the dll. That's the problem. melchiorre wants to Synchronize from the dll to the main app and not to the dll itself. Maybe an export trick can do it? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
Vincent Snijders wrote: > WakeMainThread is just one way to make sure that the calling thread > calls CheckSynchronize from time to time. Synchronize does not depend on > how the main thread call CheckSynchronize, just that it is accomplished. Sure, you are talking about normal apps. But with dynamic libs CheckSynchronzie doesn't work. Try it. It looks like CheckSynchronize is waiting on the wrong event, because the dynamic lib uses it's own private Classes CommonInit. Should it do that? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
Michael Van Canneyt wrote: > On Sat, 15 Dec 2007, Al Boldi wrote: > > melchiorre caruso wrote: > > > I found an article that explains why my code does not work on Windows: > > > > Actually, I had a closer look at synchronize, and it turns out to be > > dependent on the GUI, which probably means that you need to include > > 'Interfaces' in your library uses clause. Can you try this on windows? > > No. > Synchronize does not depend on the GUI, it does depend on the main > thread calling CheckSynchronize from time to time. The problem is that synchronize depends on calling WakeMainThread, but that only gets set when you include the Interfaces unit. melchiorre caruso wrote: > libthread.dpr(4,3) Fatal: Can't find unit Interfaces used by libthread > > I add manually $(LazarusDir)\lcl\interfaces\$(TargetOS) to the paths but > an other error occours: > > Fatal: Can't find unit InterfaceBase used by Interfaces > > "The dog bites the tail" > > I use WinXp Sp2 > Lazarus svn > Fcp 2.2.0 Try adding the LCL to your project. But, you could instead just try setting WakeMainThread in your lib yourself, and let the handler post a message to the mainthread. That's what the Interfaces unit does. Can you try this? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote: > I found an article that explains why my code does not work on Windows: Actually, I had a closer look at synchronize, and it turns out to be dependent on the GUI, which probably means that you need to include 'Interfaces' in your library uses clause. Can you try this on windows? > http://www.clevercomponents.com/articles/article019/delphi6sync.asp Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Micha Nelissen wrote: > Martin Schreiber wrote: > > Fourthly there is FPC synchronize with the problem that checksynchronize > > is called once in onidle of then main event loop. One can call > > application.wakeupguithread to enable processing but there is a race > > condition. > > AFAICS, these are all variants on the TThread.Synchronize "hack". There > is no race condition in TThread.Synchronize, so why not use this then? I think the race comes in when you have two competing threads wanting to synchronize the the main thread. It just hangs. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Graeme Geldenhuys wrote: > On 13/12/2007, Martin Schreiber <[EMAIL PROTECTED]> wrote: > > > Is there web gateway for this? > > > > No, use a news client, Mozilla Thunderbird for win32/Linux or > > KNode for Linux for example. You will probably like the conversation > > by NNTP, much more convenient than mailing lists or web forums IMHO. > > I can't agree more. NNTP is a lot more convenient and preferred by > me, that mailing list. The problem is that sometimes NNTP ports are blocked. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] cross compile deb status and next problem
Mattias Gaertner wrote: > To compile the binutils you need the c development packages for your > system. That's quite a lot. Yes, that's why I think a precompiled binutils package containing only the 3-4 binaries for cross-compile could save a lot. Just like binutils-win32. > And you need the FPC source and install repositories. I can't imagine a developer not having the FPC/laz sources. But these aren't enough to cross compile. What we need is a binutils-linux-i386-win32. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Swen Heinig wrote: > Hello Al Boldi, > > you are able to send emails from future? I would suggest to check the > date settings on your computer. Thanks for pointing this out! This is a linux suspend-to-disk/ram problem. The bios clock is correct, it's the linux-system clock that gets sometimes advanced exactly 24h when using s2ram/disk. Thanks again! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] cross compile deb status and next problem
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > It would be nice to only have the absolute minimum needed to enable > > cross-compile. The tools should be in another package. > > The tools are for example assembler and windres. > Some tools like gprof are nice to have. True, but optional. > > Why are the ppu's in there? Can't they be compiled locally? > > No. > Unless you are a FPC crack. > Maybe it will become possible with the fppackage system. And how big is that going to be? More than 2MB? BTW, there still aren't any incremental tarballs for FPC/laz to facilitate easy upgrading sources from 2.0.2 to 2.0.4 to 2.2.0, and 0.9.14-0.9.24. Is there a chance this could be available? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] cross compile deb status and next problem
Vincent Snijders wrote: > Al Boldi schreef: > > Mattias Gaertner wrote: > >> Al Boldi <[EMAIL PROTECTED]> wrote: > >>> Mattias Gaertner wrote: > >>>> Sam Liddicott <[EMAIL PROTECTED]> wrote: > >>>>> THAT much works; so merely installing a cross-compiler deb will > >>>>> let lazarus just pick it up and run > >>>> > >>>> Nice. Just like the existing fpc_crosswin32 package, but finally for > >>>> more platforms. :) > >>> > >>> I had a look at fpc_crosswin32. It's huge, ~25MB. > >> > >> It contains tools and ppu. > >> What parts should be left out? > > > > It would be nice to only have the absolute minimum needed to enable > > cross-compile. The tools should be in another package. > > > > Why are the ppu's in there? Can't they be compiled locally? > > So can the binutils. The binutils are ~14MB. All we need are maybe 3-4 binaries, right? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Martin Schreiber wrote: > On Friday 14 December 2007 10.52, Al Boldi wrote: > > Martin Schreiber wrote: > > > Don't forget MSEide+MSEgui: > > > http://sourceforge.net/projects/mseide-msegui > > > MSEgui has several possibilities to synchronize worker threads with > > > the main GUI thread. > > > > Sounds interesting. Is it possible to use MSEgui via the laz-ide? > > MSEgui has its own sophisticated IDE (MSEide). I know, I tried it. > TFrame, visual form > inheritance and datamodules with cross form/datamodule design time > component linking are implemented for example, Wow, I didn't get that far. I had to disable db-support, because I compiled the MSEide with FPC2.0.2. BTW, why isn't there a makefile or lpr file to compile the MSEide directly with FPC/laz without the MSEide bin? > the integrated debug > facilities of MSEide are better than the Lazarus ones IMO. Not only IYO but also IMHO. Especially the CPUview and the integrated disassembler view are amazing. Couldn't this be merged with the laz-ide? > Lazarus can not be used to design MSEgui forms. That's sad. MSEgui looks rather professional, but forcing a developer to change the ide is rather drastic. > There is a NNTP newsgroup for questions about MSEide+MSEgui: > news://news.grid-sky.com/public.mseide-msegui.talk Is there web gateway for this? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] cross compile deb status and next problem
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Mattias Gaertner wrote: > > > Sam Liddicott <[EMAIL PROTECTED]> wrote: > > > > THAT much works; so merely installing a cross-compiler deb will > > > > let lazarus just pick it up and run > > > > > > Nice. Just like the existing fpc_crosswin32 package, but finally for > > > more platforms. :) > > > > I had a look at fpc_crosswin32. It's huge, ~25MB. > > It contains tools and ppu. > What parts should be left out? It would be nice to only have the absolute minimum needed to enable cross-compile. The tools should be in another package. Why are the ppu's in there? Can't they be compiled locally? > > Is there any > > chance to release a mini-fpc_crosswin32 akin to > > binutils-2.15-win32-i386-linux. > > Why binutils 2.15? Actually, or any later version, if that version proves stable. 2.15 seems rather stable. > > > IOW, where is binutils-2.15-linux-i386-win32? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Martin Schreiber wrote: > Don't forget MSEide+MSEgui: > http://sourceforge.net/projects/mseide-msegui > MSEgui has several possibilities to synchronize worker threads with the > main GUI thread. > > First there is application.lock/unlok which works on a mutex. The main > eventloop acquires the mutex on start of a new round of the main eventloop > and releases it after it gets idle. > > Secondly there is application.synchronize which runs a callback in a > try/finally block with application.lock/unlock. > > Thirdly there is application.postevent in order to send messages to MSEgui > components. The posted events are feed into the main event queue and are > delivered to the component in context of the main thread. > application.postevent is thread safe and does not block. > tmsecomponent.postcomponentevent and asyncevent can be used for > convenience, tmseform tmsedatamodule have onevent and onasyncevent where > the messages can be handled in context of the main thread. > > Fourthly there is FPC synchronize with the problem that checksynchronize > is called once in onidle of then main event loop. One can call > application.wakeupguithread to enable processing but there is a race > condition. > > Worth to mention is teventthread with its own message queue. > The graphic subsystem has its own locking mechanism so it is possible to > draw onto off screen canvas (pixmap or printer) from worker threads. Sounds interesting. Is it possible to use MSEgui via the laz-ide? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] cross compile deb status and next problem
Mattias Gaertner wrote: > Sam Liddicott <[EMAIL PROTECTED]> wrote: > > THAT much works; so merely installing a cross-compiler deb will let > > lazarus just pick it up and run > > Nice. Just like the existing fpc_crosswin32 package, but finally for > more platforms. :) I had a look at fpc_crosswin32. It's huge, ~25MB. Is there any chance to release a mini-fpc_crosswin32 akin to binutils-2.15-win32-i386-linux. IOW, where is binutils-2.15-linux-i386-win32? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Michael Van Canneyt wrote: > On Wed, 12 Dec 2007, Razvan Adrian Bogdan wrote: > > The synchronize method is simple but inefficient, it pauses your > > thread until the main thread has time to execute your code and could > > take some time until it does, i personally also dislike the fact that > > one cannot call any procedure/function with any number of parameters > > with synchronize. > > That's not possible in pascal without hacking the stack. Why? > > I think mark proposed once the solution of using a List (StringList or > > something else) in a synchronised manner with CriticalSections > > protecting access to the list and this way creating a message system > > similar to the OS one but this implementation is also not always > > comfortable but it isn't blocking as synchronize, the problem is not > > with the windows widgetset which is message based and quite thread > > safe and one can easily use CriticalSections with Controls, Borland > > started to make the VCL threadsafe but they didn't complete this task, > > maybe LCL would be more popular if it was threadsafe, i do realise > > it's a lot of work but it might be worth it. > > This may work for windows, but X is not thread safe, so you would have > maybe a slightly less blocking system, but it would be blocking > nonetheless. I think the gain would be minimal. This is basically the problem with threading: it's not enough for your code to be thread-safe, you also need to make sure all linked libs are thread-safe, which makes threading only useful for code you control. So, making the LCL thread-safe is really the easy part, but more importantly you need to make sure that all libs the LCL links to are thread-safe. One easy work-around may be to run your app multi-processed instead of multi-threaded, thereby conveniently circumventing any threading issues in the foreign libs. Could the LCL support such an architecture? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
Giuliano Colla wrote: > To discover that if your timer event doesn't change something visual, > the smart thing decides that there's nothing important to do, and stays > Idle, so that the OnIdle handler is never called. My kludge has been to > have the Timer update a Label in a hidden corner of the screen, with a > sequence of - \ | / - . This wakes up the main thread, which then goes > Idle, triggers the OnIdle event, and the queue can be processed. You may > see that this is far from satisfactory. Not sure what you mean? OnTimer does trigger OnIdle even if there is no visual update. And even if it wouldn't, you could trivially trigger the OnIdle inside the OnTimer handler yourself. > Up to now I've not yet tested Lazarus with a real demanding threaded > app, but from what I've read about the OnIdle events from Felipe and > others, I'm afraid that the result won't be much different. I think it is. Try it. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] libview enhancement
Roberto Padovani wrote: > This helps me because I had some dll with many exported functions and > with both call type. > I hope someone will find it useful, as well. Neat, but this only works on windows. Can you make it cross-platform? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote: > Can You send to me the source that runs correctly on linux? I am using your source. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote: > Al Boldi wrote: > > So it's either an fpc or windows issue. > > > > Can you statically link it on windows, and see if it make a difference? > > I have statically linked library to application with this results > > Library.MainBlock MainThreadID = 3496 > Library.MainBlock CurrentThreadID = 3496 > > Library.CreateMyThread MainThreadID = 3496 > Library.CreateMyThread CurrentThreadID = 3496 > > Thread MainThreadID = 3496 > Thread MainThreadID = 3852 > > on windows, the static and dynamic link have the same result. Sure, the threadIDs are ok, but you probably have a problem with the windows specific implementation of synchronize. As I am not on windows, maybe somebody from the fpc team can help out here. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote: > Al Boldi wrote: > > melchiorre caruso wrote: > >> if I use in execute method the source > >> > >> "if Assigned (FMethod) then > >> FMethod;" > >> > >> instead of > >> > >> "if Assigned (FMethod) then > >> Synchronize(FMethod);" > >> > >> the method fMethod is called but not synchronized. Then the application > >> closes > > > > What does GetCurrentThreadID and MainThreadID give you from your lib and > > app and thread? > > These are the results: > > From TTestLibrary.TestBtnClick procedure > > MainThreadID= 3712 > CurrentThreadId = 3712 > > From thread2lib.CreateMyThread function > > MainThreadID= 3712 > CurrentThreadId = 3712 > > From TMyThread.Execute > > MainThreadID= 3712 > CurrentThreadId = 3280 I tried your example on linux with fpc 2.0.2, and it works: lib loaded Library MainThreadID16384 Library CurrentThreadID 16384 Thread MainThreadID16384 Thread CurrentThreadID 16386 TestForm MainThreadID16384 TestForm CurrentThreadId 16384 Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work Synchronize call work OnTerminate event work So it's either an fpc or windows issue. Can you statically link it on windows, and see if it make a difference? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote:
> Al Boldi wrote:
> > melchiorre caruso wrote:
> >> procedure TTestLibrary.TestBtnClick(Sender: TObject);
> >> LibHandle := LoadLibrary('thread2lib.dll');
> >> CreateMyThreadFunc := GetProcedureAddress(LibHandle,'CreateMyThread');
> >
> > Make sure your library actually loads...
>
> if I use in execute method the source
>
> "if Assigned (FMethod) then
> FMethod;"
>
> instead of
>
> "if Assigned (FMethod) then
> Synchronize(FMethod);"
>
>
> the method fMethod is called but not synchronized. Then the application
> closes
Ok, so your lib loads.
What does GetCurrentThreadID and MainThreadID give you from your lib and app
and thread?
> > BTW, can you stop sending html messages?
>
> Sorry, it is right now?
Yes.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote:
> procedure TTestLibrary.TestBtnClick(Sender: TObject);
> begin
> LibHandle := LoadLibrary('thread2lib.dll');
> CreateMyThreadFunc := GetProcedureAddress(LibHandle,
> 'CreateMyThread');
Make sure your library actually loads...
> if Assigned(CreateMyThreadFunc) then
... otherwise it won't enter this.
BTW, can you stop sending html messages?
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] A Thread in DLL
melchiorre caruso wrote: > Can you post text only messages? > I try to use CheckSyncronize() in the application loop but without > result; > The function synchronize appears to be broken and, > the event on-terninate not be called. I do not know the reason. Can you post example-code? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Search engine for Lazarus and Free Pascal concerned stuff
Sam Liddicott wrote: > Al Boldi wrote: > > Sam Liddicott wrote: > >> I recommend xapian; www.xapian.org > >> > >> I've worked on it, I've used it and I've followed it's progress and > >> when I worked at Orange we hired one of the developers to enhance it. > >> > >> It is based on a once-commercial search engine. > > > > It's not bad, > > you've clearly not used it much > > > but it's huge. > > I don't think xapian is huge, although it can deal with huge data sets. > It's being used to index gmane. > > > I'm currently using swish-e, which is small and > > fast. > > It is a probabilistic search engine that also uses boolean terms > The btree index for xapian has been re-written from scratch 3 times for > maximum speed. > > I don't know fully how swish-e and xapian compare but I can't have > anyone maligning xapian :-) Actually, trying to compare xapian to swish-e, would be like comparing KDE with WindowMaker. They don't compare. That's why I use WindowMaker, and only use KDE as a back-end when I need the extra features. But, when you start comparing their size, that's when you understand what I mean with HUGE. Just the xapian engine distribution alone is about 10x larger than swish-e. So, if there is a mini-xapian engine distribution that would weigh in at around 250kb compressed, then I would definitely like to know about it. Until then, xapian is definitely overkill for simple indexing needs. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Search engine for Lazarus and Free Pascal concerned stuff
Sam Liddicott wrote: > Tom Gregorovic wrote: > > Hi, > > it crossed my mind that it would be convenient to have one search > > service for all the information about Lazarus and Free Pascal, which > > are in forums, mail list archives, documentation reference, wiki, > > Mantis, SVN repository, SVN log, blog ... > > One possibility is Google Custom Search Engine > > (http://www.google.com/coop/cse/): > > * it is free for noncommercial usage, but I think it parses not all > > resources The alternative is to use some web search engine running on > > own server (e.g. http://www.mnogosearch.org/ ). > > I recommend xapian; www.xapian.org > > I've worked on it, I've used it and I've followed it's progress and when > I worked at Orange we hired one of the developers to enhance it. > > It is based on a once-commercial search engine. It's not bad, but it's huge. I'm currently using swish-e, which is small and fast. I once posted a patch to allow interfacing the output of any search engine with the Find-In-Files dialog, but I don't think it got ever merged. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Clone objects
Vincent Snijders wrote: > Mattias Gaertner schreef: > On Mon, 12 Nov 2007, Damien Gerard wrote: > > I use this : > > http://wiki.lazarus.freepascal.org/Streaming_components However > > I ve got an exception error : Class "" not found (I put only a > > panel). > > > > > Maybe this helps: > > lazarus/examples/componentstreaming/ > > http://wiki.lazarus.freepascal.org/Streaming_components > > Maybe it didn't work. Maybe this could be wrapped into a clone method. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] ParentWindow
Mattias Gaertner wrote: > Maybe my statement was not clear: The Parent/Child connection is the > main problem. It would be easier to handle the child/parent > relationship by the LCL and keep the 1:1 mapping between controls and > handles. > So, all that is needed is a TForeignHandleControl with a SetHandle > method. Still not clear what you mean. Maybe like this: TForeignHandleControl(x).SetHandle:=hWnd; then: form1.parent:=TForeignHandleControl(x).SetHandle; or : TForeignHandleControl(x).Setparent:=form1.hWnd; Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote:
> Al Boldi wrote:
> > Oh, I meant the OPF design. Is it possible to isolate the OPF from the
> > MVP?
>
> Ah yes, they are completely decoupled. You can:
>
> var
>VClient: TClient;
>VClientList: TPressProxyList;
> begin
>VClient := TClient.Create;
>// or
>VClient := TClient.Retrieve('1');
>// or
>VClientList := PressOPFService.OQLQuery(
> 'select * from TClient where name = ''SomeName''');
>if VClientList.Count > 0 then
> VClient := VClientList[0].Instance as TClient;
>// or use a query class
>
>// and then
>VClient.Name := 'AnotherName';
>VClient.Store;
>VClient.Free; // with respective try/finally, of course
> end;
Looks neat. Can you give a more complete example based on a simple TPerson
db with 2 fields: id, name
> > Sure, this is great when you are working with a disconnected
> > presentation layer like a web interface. But for native apps, you don't
> > need this, because your presentation layer is already connected to your
> > model via TForm. So what we need is for a TForm to directly connect to
> > the OPF without going through the redundant MVP framework. Is this
> > possible?
>
> Redundand!? No, no! You simply cannot compare a form with three combos
> and two grids between dbware and mvp approaches. The former will eat
> five groups of data access components, shortcuts to include some
> funcionality and a lot of time to configure and debug everything. MVP
> will eat five lines of code, nothing more. The same model that will
> manage this controls, will also generate the DDL necessary to build the
> database metadata for you.
Well, your demo phone app doesn't look so simple. Maybe you can just create
a mini app with just 2 fields: id name , with dbnav/edit-buttons.
> > BTW, as I said, the MVP would be great for a disconnected presentation
> > layer like in web development, so it would be really useful to have an
> > MVP to WebPresentation proxy. Does your MVP include this feature?
>
> No web features atm, it is included in the 2.0 roadmap though.
Great. Keep us posted.
> > Also, I tried to compile the demo, but it gives this error:
> > ObjectModel.pas(23,3) Error: Only class which are compiled in $M+ mode
> > can be published
>
> I think I have fixed this annoying issue. Just place $M+/$M- around the
> forward class declaration, or include a $M+ on the top of the unit.
Still doesn't work. But I just moved the default published fields into
public and it compiles and runs, but then I get this dialog:
No service 'Messages' assigned or registered
So I turn {$DEFINE UsePressOPF} on and then I get this
../Press/Source/Brokers/PressSQLdbBroker.pas(48,16) Error: Identifier not
found "TSQLConnector"
> Notes: There are known issues with combobox and the F2 shortcut that I
> have not workarounded to the LCL interface (VCL interface is nice). They
> are registered in the Lazarus tracker. I am refactoring the demo app in
> order to use some new features, take a look at the project page now and
> then.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] ParentWindow
Mattias Gaertner wrote: > I think ParentWindow is very widgetset specific (see below). Probably > it will work cross platform very limited. See at end for an > alternative solution. > > - AFAIK under winapi you can stack handles even of different processes. > gtk does not allow this. I don't know about qt, carbon, fpgui, but > probably they all have some limitations of child/parent relationships. Actually the gtk does support this, but in a really hacky way, using GTKSocket/GTKPlug. > - the LCL handles messages and delegates them downwards and upwards to > parents/childs TControls. But if the Handle has no associated > TWinControl then messages can not be passed this way. Only the > widgetset knows how to handle this. You must check every place where a > handle is used if it is a normal LCL handle or a foreign handle. This > will be a lot of work. > > Solution: > It is probably easier to create a wrapper TWinControl / TCustomForm > with the ability to use the foreign Handle. Correct; all that is needed is a SetParent(hWnd) method. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Graeme Geldenhuys wrote: > On 10/11/2007, Al Boldi <[EMAIL PROTECTED]> wrote: > > > You don't need to do this. Eg: create a form without code or > > > non-visual components, bind BO attributes and components in a single > > > line, and the MVP will do the rest for you using informations from the > > > model. > > > > Sure, this is great when you are working with a disconnected > > presentation layer like a web interface. But for native apps, you don't > > need this, because your presentation layer is already connected to your > > model via TForm. > > I've lost you there. Why don't you need something like that? You > should never be mixing your BOM (business object model) with your > presentation layer. Borland didn't help this much be DB-aware > components and developers slapping loads of business rules in the > Forms directly. This is a big misconception. The fact that TForm has the ability to host business rules and whatever else does not mean that you have to do it this way. You can maintain whatever model you like with TForm, for the mere fact that it's event-driven. > A GUI is the presentation layer. A Web interface is > another. Separating the BOM and the presentation layer you can have > one application that can server a standard GUI or Web interface. We > have such a product. And the business rules are maintained in a > single location. So if we change a text entry validation rule, it gets > automatically applied to both the GUI and Web application. Because we > have not business rules in our forms. This also makes unit testing > much easier. Yes, if your requirements are such that they call for a disconnected presentation layer, then you have a case to use an MVP. But again, don't let the TForm name mislead you into thinking that the TForm is about the presentation layer only. It's a lot more than that. It's about an event driven approach that happens to easily and directly inline the presentation layer. You don't have to use this layer if you don't like to, and you could conceivably create a disconnected model based on TForms much like the MVP, but this would increase code complexity a lot, so you would only want to do it when absolutely necessary. > I don't use MVP, but instead MGM (Model-GUI-Mediator) which is an > alternative to MVP. I used it extensively with tiOPF in our products. > I wrote mediators for LCL and fpGUI which can make any standard > (non-db) component object aware without sub-classing. > > http://www.atug.com/andypatterns/mgm.htm Sounds interesting. Does it feature a WebPresentation proxy? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > Al Boldi wrote: > > Of course you are not caching any relational data, but you said that you > > are using a connection broker to the rdb, which caches the rdb data, > > which means extra overhead. > > Hmmm... the rdb or the suite that access the rdb caching data means > extra resource usage I think, on behalf of performance. Exactly. But you wouldn't want to do this caching twice. > > Ok, I had a quick look through the docs, and it seems that you have the > > design tightly coupled to the MVP. > > The MVP _is_ the design, or even better, is the presentation framework. Oh, I meant the OPF design. Is it possible to isolate the OPF from the MVP? > > Is there a way to directly attach LCL > > objects to your OPF? > > You don't need to do this. Eg: create a form without code or non-visual > components, bind BO attributes and components in a single line, and the > MVP will do the rest for you using informations from the model. Sure, this is great when you are working with a disconnected presentation layer like a web interface. But for native apps, you don't need this, because your presentation layer is already connected to your model via TForm. So what we need is for a TForm to directly connect to the OPF without going through the redundant MVP framework. Is this possible? BTW, as I said, the MVP would be great for a disconnected presentation layer like in web development, so it would be really useful to have an MVP to WebPresentation proxy. Does your MVP include this feature? Also, I tried to compile the demo, but it gives this error: ObjectModel.pas(23,3) Error: Only class which are compiled in $M+ mode can be published Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > Al Boldi wrote: > > Where is the data cached? > > Attributes belong to business objects. BOs are reference counted and the > ones that wasn't removed from the memory are referenced by a cache that > belongs to the persistence service. Sounds great, really! > >> 3.lazy loading of objects and attributes mixed with bulk retrieving. > > > > And how does the app access this object-data? > > Retrieving its OID through the persistence service. This service will > query the cache (binary tree -- todo list) in order to know if the > object was already instantiated. If it exist, its address is returned, > otherwise the persistence (xml, database, whatever) is queried in order > to retrieve information to instantiate such object. Wow! > >>>> and the way to remove it is writing a connection > >>>> broker that doesn't depend of a db suite like SQLdb or Zeos, and that > >>>> doesn't depend of the tdataset as well. > >>> > >>> If you do it this way, then you are actually implementing proxies, and > >>> proxies should not be used unless there is a need for them like for > >>> border-gateways, because proxies add overhead. > >> > >> I think you meant wrappers. And yes, wrappers to SQLdbs are necessary > >> in this case, because implement wrappers to database API at this stage > >> of the project demands an effort that I would like to use to other more > >> important tasks like tests, docs and the expert. > > > > The problem with this is that, the proper construction of the OOrdb > > cache manager is critically dependent on the native access to the dbAPI. > > Otherwise you may be hindered by the dual-cache problem. > > No, only one cache that references objects. No relational data is > cached, just some datasets. Of course you are not caching any relational data, but you said that you are using a connection broker to the rdb, which caches the rdb data, which means extra overhead. > >>> What you may want to try is to refactor the OPF, dataBroker, and > >>> dbConnectionLib into their respective layering components, and then > >>> recompose a native OPF wrapper based on those layering components. > >>> This should give a decoupled system while maintaining native > >>> performance. > >> > >> Perhaps what you are proposing is something I have already implemented. > >> I don't use any db* class and have created an abstract data access to > >> improve speed as much as possible (or as I can) -- writing wrappers to > >> database APIs in future versions. Have a look in the code. > > > > Sure. Can you give us a link to a tarball? > > Sure. A 'zipball': > http://pressobjects.org/snapshot/press-snapshot-20071103-r706.zip or > subversion: > https://pressobjects.svn.sourceforge.net/svnroot/pressobjects/trunk Ok, I had a quick look through the docs, and it seems that you have the design tightly coupled to the MVP. Is there a way to directly attach LCL objects to your OPF? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > Al Boldi wrote: > >> A small overhead do exist actually, > > > > I don't think it's small, unless you mean small apps which deal with > > textual data only. For large apps that deal with blobs, the overhead may > > bring down your system. > > No, small overhead even to applications that handle large objects. There > are three points to consider: 1. the real bottleneck is in the database > and in the network; Correct. Let's call this the server-side, which isn't under our control. Then comes the client-side, which we can control. > 2. moving data between layers doesn't mean big > overhead due to refcount of ansistrings or other managed objects; Ok, that sounds like a cache manager. So you are not actually moving any data, but rather managing the pointers. Where is the data cached? > 3.lazy loading of objects and attributes mixed with bulk retrieving. And how does the app access this object-data? > >> and the way to remove it is writing a connection > >> broker that doesn't depend of a db suite like SQLdb or Zeos, and that > >> doesn't depend of the tdataset as well. > > > > If you do it this way, then you are actually implementing proxies, and > > proxies should not be used unless there is a need for them like for > > border-gateways, because proxies add overhead. > > I think you meant wrappers. And yes, wrappers to SQLdbs are necessary in > this case, because implement wrappers to database API at this stage of > the project demands an effort that I would like to use to other more > important tasks like tests, docs and the expert. The problem with this is that, the proper construction of the OOrdb cache manager is critically dependent on the native access to the dbAPI. Otherwise you may be hindered by the dual-cache problem. > > What you may want to try is to refactor the OPF, dataBroker, and > > dbConnectionLib into their respective layering components, and then > > recompose a native OPF wrapper based on those layering components. This > > should give a decoupled system while maintaining native performance. > > Perhaps what you are proposing is something I have already implemented. > I don't use any db* class and have created an abstract data access to > improve speed as much as possible (or as I can) -- writing wrappers to > database APIs in future versions. Have a look in the code. Sure. Can you give us a link to a tarball? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > Al Boldi wrote: > > You see, trying to create an OPF as a separate layer that > > connects to the db via a broker is just broken by design, as this will > > introduce a tremendous overhead due to the dual caching problem. > > I agree with you that this will cause some overhead, but it is not as > much as you figured. The main bottleneck of an OPF is the database > access, how the OPF builds DMLs, Yes, that's the easy part. > do object cache, lazy loading, bulk retrieving, etc. That's where things become interesting, because you have to figure out how to interface with your non-OO db, aka relational-DB, without incurring any duplicate overhead. > > In fact, the correct way forward seems to be to implement the OPF as the > > broker, just like you implement the broker against a specific db-lib. > > What you get is a db specific OPF that wraps the broker inside it in a > > native fashion. > > If I understood you correctly, this means build an OPF tied to an > specific database, and this isn't a nice approach. I know it does not sound nice, but an OPF should not be considered an independent layer, but rather as a wrapper/converter/adapter to the non-OO db, much like the connection broker, only the connection broker output is a tdataset wheras the OPF should give you direct access to your native objects. > In the current design I have: > >user <-> mvp <-> data type <-> opf engine broker <-> > connection broker (tied with) db engine > > You can change every part without changing the others. If you implement the OPF as a pluggable system, then you may do the same. > A small overhead do exist actually, I don't think it's small, unless you mean small apps which deal with textual data only. For large apps that deal with blobs, the overhead may bring down your system. > and the way to remove it is writing a connection > broker that doesn't depend of a db suite like SQLdb or Zeos, and that > doesn't depend of the tdataset as well. If you do it this way, then you are actually implementing proxies, and proxies should not be used unless there is a need for them like for border-gateways, because proxies add overhead. What you may want to try is to refactor the OPF, dataBroker, and dbConnectionLib into their respective layering components, and then recompose a native OPF wrapper based on those layering components. This should give a decoupled system while maintaining native performance. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > Al Boldi wrote: > > Joao Morais wrote: > >> I am currently working in an IO-like project with a smarter, faster and > >> more customizable OPF engine, decoupled frameworks (after all data type > >> and opf aren't the same thing), no dbware or tdataset dependency, and > >> the best item: no backward compatibility to bother. > >> www.pressobjects.org > > > > Sounds great! > > > > Does your OPF handle data storage natively? > > The OPF just creates DDLs and DMLs based on an object oriented model, > built over a data type framework. The DDLs and DMLs are sent to the > database through a connection broker, built against Zeos, UIB, SQLdb > (and also DOA and IBX when compiled with Delphi). Oh. > Native access is in the 2.0 roadmap. That's great. You see, trying to create an OPF as a separate layer that connects to the db via a broker is just broken by design, as this will introduce a tremendous overhead due to the dual caching problem. In fact, the correct way forward seems to be to implement the OPF as the broker, just like you implement the broker against a specific db-lib. What you get is a db specific OPF that wraps the broker inside it in a native fashion. Now, in the end this OPF may end up pluggable, but it would still be native per db, with one single cache manager. > Let me know if this answer your question. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Lazarus and InstantObjects ?
Joao Morais wrote: > I am currently working in an IO-like project with a smarter, faster and > more customizable OPF engine, decoupled frameworks (after all data type > and opf aren't the same thing), no dbware or tdataset dependency, and > the best item: no backward compatibility to bother. www.pressobjects.org Sounds great! Does your OPF handle data storage natively? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Lazarus on one window (aka SDI)
Víctor R. Ruiz wrote:
> Hi:
Hi
> 2007/9/12, Al Boldi <[EMAIL PROTECTED]>:
> > I once posted "A Studio IDE layout", which worked by re-parenting the
> > ide windows inside a TStudio form. This meant that it did not require
> > any changes to the original windows, which made it possible to easily
> > switch between SDI and MDI.
> >
> > The reason it did not use docking was because docking wasn't working
> > correctly. And as Mattias mentioned, once docking gets fixed, it should
> > be easy to have a flexible IDE interface.
>
> I didn't know TStudio (I'm rather new to Lazarus), where I can find
> more info? Surely the solution is similar, I don't use "real" docks
> either -I didn't found info about how they worked. This hack also
> panels and re-parenting.
You can probably find it on google, but I attached it here for convenience.
Thanks!
--
Al
--- Begin Message ---
Al Boldi wrote:
> This form implements a Studio-style IDE layout in contrast to the current
> VB-style. It works by hooking it into main.pp with something like this:
>
> IDEloStyle.TStudio.Create(Self).Show;
>
> Note, keep the following windows open before calling:
> ProjectInspector
> ObjectInspector
> CodeExplorer
> Messages
>
> Many known bugs like:
> First invocation of SourceEditor crashes. -> Close SourceTab and reload.
> SourceEditor codetips don't work.
>
> Todo:
> Stream layout state.
> Allow link/unlink windows.
> Allow window to tab capture.
This new version goes full screen with integrated component palette.
Call like this:
IDEloStyle2.TStudio.Create(Self).Show;
Your comments/improvements/fixes are most welcome.
Thanks!
--
Al
unit IDEloStyle2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, LResources, Forms,
MainBar, MainBase, MsgView, ProjectInspector, CodeExplorer,
Controls, ExtCtrls, Menus;
type
{ TStudio }
TStudio = class(TForm)
Panel1: TPanel;
Panel2: TPanel;
Panel3: TPanel;
Panel4: TPanel;
Panel5: TPanel;
Panel6: TPanel;
Panel7: TPanel;
Panel8: TPanel;
Splitter1: TSplitter;
Splitter2: TSplitter;
Splitter3: TSplitter;
Splitter4: TSplitter;
procedure FormCreate(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Studio: TStudio;
implementation
{ TStudio }
procedure TStudio.FormCreate(Sender: TObject);
var mnu: TMainMenu;
begin
if Assigned(Studio) then begin
Studio.show;
abort;
end;
Studio:=self;
MainBase.ObjectInspector1.Parent:=panel3;
MainBase.ObjectInspector1.Align:=alClient;
CodeExplorer.CodeExplorerView.Parent:=panel4;
CodeExplorer.CodeExplorerView.Align:=alClient;
ProjectInspector.ProjInspector.Parent:=panel5;
ProjectInspector.ProjInspector.Align:=alClient;
MainBase.SourceNotebook.Parent:=panel6;
MainBase.SourceNotebook.Align:=alClient;
MsgView.MessagesView.Parent:=panel7;
MsgView.MessagesView.Align:=alClient;
mnu:=MainBar.MainIDEBar.Menu;
MainBar.MainIDEBar.Menu:=nil;
self.Menu:=mnu;
MainBar.MainIDEBar.Parent:=panel8;
MainBar.MainIDEBar.Align:=alClient;
end;
initialization
{$I idelostyle2.lrs}
end.
object Studio: TStudio
Caption = 'Studio'
ClientHeight = 476
ClientWidth = 718
OnCreate = FormCreate
PixelsPerInch = 75
WindowState = wsMaximized
HorzScrollBar.Page = 717
VertScrollBar.Page = 475
Left = 32
Height = 476
Top = 77
Width = 718
object Panel1: TPanel
Align = alRight
BevelOuter = bvNone
Caption = 'Panel1'
ClientHeight = 476
ClientWidth = 170
TabOrder = 0
Left = 548
Height = 476
Width = 170
object Panel4: TPanel
Align = alClient
BevelOuter = bvNone
Caption = 'Panel4'
ClientHeight = 277
ClientWidth = 170
TabOrder = 0
Height = 277
Width = 170
end
object Panel5: TPanel
Align = alBottom
BevelOuter = bvNone
Caption = 'Panel5'
ClientHeight = 194
ClientWidth = 170
TabOrder = 1
Height = 194
Top = 282
Width = 170
end
object Splitter3: TSplitter
Align = alBottom
Beveled = True
Cursor = crVSplit
Height = 5
Width = 170
ResizeAnchor = akBottom
Cursor = crVSplit
Height = 5
Top = 277
Width = 170
end
end
object Panel2: TPanel
Align = alClient
BevelOuter = bvNone
Caption = 'Panel2'
ClientHeight = 476
ClientWidth = 327
TabOrder = 1
Left = 216
Height = 476
Width = 327
object Panel6: TPanel
Align = alClient
BevelOuter = bvNone
Caption = 'Panel6'
ClientHeight = 361
ClientWidth = 327
TabOrder = 0
Height = 361
Top = 58
Width = 327
Re: Lazarus on one window (aka SDI)
Well, I guess the screenshot was too big (87KB), so here is the text only. Graeme Geldenhuys wrote: > Hi Victor, > > Could you explain how you managed the MDI look? Where the editor > (synedit) gets created? I use the Toolbar Editor add-on package which > creates a panel above the editor tabs. After applying you patch is > opens a blank editor window with the toolbar panel, but nothing else. > Eventually I figured out that I need to resize the Main Form to see > the editor window, but obviously the Editor Toolbar is now missing. > > :-( > > I guess I would have to modify the Toolbar Editor to create a panel in > a different location depending on the SDI or MDI interface in use. > I'll leave that for now, until your changes are actually in SVN. I > just wanted a head start on where to look, to fix the issue. I once posted "A Studio IDE layout", which worked by re-parenting the ide windows inside a TStudio form. This meant that it did not require any changes to the original windows, which made it possible to easily switch between SDI and MDI. The reason it did not use docking was because docking wasn't working correctly. And as Mattias mentioned, once docking gets fixed, it should be easy to have a flexible IDE interface. For now, I have been using TStudio ever since. Attached is a screenshot. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] How to compile IDE for Windows platform
Giuliano Colla wrote: > Al Boldi ha scritto: > > I have the sources of FPC/Laz up and running on linux, and now I want to > > compile them on windows. Do I need to download the sources again, or is > > there a platform specific tools package that allows me to recompile with > > the same sources? > > There's a slightly different directory layout in windows, because fpc is > inside the lazarus tree. > Faced with the same problem, I solved it in this way: > 1) download and install a stable win32 release (9.22). Is this a full source release with tools included? If so, wouldn't it be much smarter to split the sources from the tools, such that we can have one big fully platform independent source package and many tiny platform dependent tools packages? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] How to compile IDE for Windows platform
I have the sources of FPC/Laz up and running on linux, and now I want to compile them on windows. Do I need to download the sources again, or is there a platform specific tools package that allows me to recompile with the same sources? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New User Friendly BuildLazDialog patch
Giuliano Colla wrote: > Graeme Geldenhuys ha scritto: > > On 25/07/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > >> All in all I think it would be better to have a PageControl with 2 tabs > >> "Quick build" and "Custom". It's cleaner and more conform the other > >> dialogs in the IDE. The jumping of the buttons is weird and disturbing. > >> (to my taste). > > > > I agree. Jumping buttons are normally a GUI design NO-NO. > > You're both correct. A page control with two tabs would be much more > better. This was just a quick and dirt implementation to see if the idea > is worth developing or not. I didn't care about language compatibility, > didn't test under Windows, etc. But if the opininion of Felipe prevails, > then the extra work required for a tabbed control would be a loss of time. > BTW. In case of tabbed control, most of the options still visible should > go to the "Advanced" page, I believe. > > Waiting for further comments. Your quick build buttons are great. Just change the Interface radiogroup to a dropdown list and merge the quick build buttons there. Then send us a .png. BTW, don't send html formatted messages. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New User Friendly BuildLazDialog patch
Mattias Gärtner wrote: > Zitat von Al Boldi <[EMAIL PROTECTED]>: > > Graeme Geldenhuys wrote: > > > On 25/07/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > > All in all I think it would be better to have a PageControl with 2 > > > > tabs "Quick build" and "Custom". It's cleaner and more conform the > > > > other dialogs in the IDE. The jumping of the buttons is weird and > > > > disturbing. (to my taste). > > > > > > I agree. Jumping buttons are normally a GUI design NO-NO. > > > > Correct, but I was thinking we could have options folding instead of > > pages. > > 1. Folding should be done with a folding control, to allow easy designing. > But because we don't have yet a folding control I vote for using a > pagecontrol/notebook. Ok, but we really need that folding control. > 2. The Target OS/CPU/Dir and 'Options' are definitely advanced options. > > I think most people only need > 'Clean up and build all', > 'Build all', > 'Build LCL', > 'Build IDE with packages', > 'Build IDE without packages', > and the Interface radiogroup option. The Interface radiogroup is taking up way to much space. Maybe change it to a dropdown list and merge the quick build buttons there. > The components are built automatically anyway. The clean up makes only > sense after an svn up. If you want to cross compile, you probably read the > wiki and there the 'advanced' options are described. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] New User Friendly BuildLazDialog patch
Graeme Geldenhuys wrote: > On 25/07/07, Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > All in all I think it would be better to have a PageControl with 2 tabs > > "Quick build" and "Custom". It's cleaner and more conform the other > > dialogs in the IDE. The jumping of the buttons is weird and disturbing. > > (to my taste). > > I agree. Jumping buttons are normally a GUI design NO-NO. Correct, but I was thinking we could have options folding instead of pages. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Mattias Gärtner wrote: > Zitat von Al Boldi <[EMAIL PROTECTED]>: > > Michael Van Canneyt wrote: > > > On Mon, 23 Jul 2007, Al Boldi wrote: > > > > Graeme Geldenhuys wrote: > > > > > So again, what is the pros and cons between the two design choices > > > > > when using the Object Pascal language? > > > > > > > > .dfm is good for beginners, who get confused looking at code they > > > > didn't write. > > > > > > > > .pas is good for pros, who need to take control of their project > > > > code. > > > > > > Obviously you are unaware of the real reasons the .dfm mechanism was > > > used, otherwise you would not use such unappropriate demeaning tone. > > > > No offense meant. The .lfm is probably there for compatibility reasons. > > Well, using a similar system like Delphi makes porting easier. But it is > not there for 'Delphi compatibility'. The .lfm is used because: > - a separate file is independent of syntax errors in the source code > - the file format should be easy to read/stream > > The lfm reader/writer was at hand at the time. Nowadays we could use the > xml reader/writer too, although that is less human readable. > Using pascal source as file format would be possible and has some > advantages but some disadvantages as well. What are the disadvantages? > > > There are/were good reasons for it's use. These reasons may have been > > > outdated, but at the time, they were certainly valid. It was (and is, > > > in my opinion) a defendable choice. I have not seen you give any valid > > > and objective reasons why code is better than resources. Unless you > > > plan to give such reasons, I suggest you abstain from such demeaning > > > comments. > > > > This really has nothing to do with resources. Resources should still be > > saved in its own .res file. > > > > This is about code init, and as such should not be mutilated into some > > obscure hardcoded "code init" translator, but instead be obviously > > exposed for code control. > > Well, it is exposed, because it is a simple text file. And you can edit it > in the IDE (just make sure to close the designed form, while doing so). If > we would switch the lfm file format to a more pascal like dialect you will > not get more code control, because the parser will not understand your > extensions. Replacing the parser with a jit compilation may solve this problem. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Michael Van Canneyt wrote: > On Mon, 23 Jul 2007, Al Boldi wrote: > > This really has nothing to do with resources. Resources should still be > > saved in its own .res file. > > Forms are stored in resources. A dfm is changed to resource and then > compiled in the binary ? The .dfm is being used for two things: 1. create resource 2. create code init It's the code init that's objectionable, because it removes code control. > > This is about code init, and as such should not be mutilated into some > > obscure hardcoded "code init" translator, but instead be obviously > > exposed for code control. > > There is certainly something to be said for this point of view, but they > obviously thought otherwise: Do not forget that in the TP days, it was > done like you propose, with their Turbo Vision. Was Turbo Vision the Delphi codename, or do you mean Object Vision? > If they switched to > resources, they probably had their reasons for it. Two of them, which I > happen to know, I explained in my initial response to Graeme. I think they changed because they saw VB, and wanted to mimic them. This doesn't mean Delphi was a VB copy-cat, on the contrary, VB was an Object Vision copy-cat, but VB beat Delphi to market, then Delphi copied VB's .frm. > There is always a history for each choice. This is so for Delphi, and for > FPC/Lazarus too. People may not know it any more after X years, but that > doesn't mean it didn't exist. At best, you can question it's current > validity. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making Configure Build Lazarus more user friendly
Mattias Gärtner wrote: > Zitat von Al Boldi <[EMAIL PROTECTED]>: > > Giuliano Colla wrote: > > > The configure build lazarus IDE provides a lot of options which the > > > majority of us don't use, but we're however forced to check/uncheck. > > > > > > Therefore I've added a small Group Box, named "Quick Configure > > > Options" with thre buttons: All, LCL, and Custom. The first two cover > > > (in my opinion) the needs of the vast majority of users, while the > > > third one can be handy. > > > The "All" Button checks all the Build (or Clean+Build, if Clean All is > > > checked), the "LCL" button unchecks everything, except LCL (which is > > > set to Build or Clean+Build as above), while Custom unchecks > > > everything. If the idea seems good, the attached patch can be applied, > > > or someone can do it better. > > > If not, I'll just keep it for me, because I find it handy. > > > > This is great, but there is one important option missing: > > > > Build Packages > > > > which would turn off everything, except IDE with Packages. > > Maybe there should be two pages: > One with a simple radiogroup called 'Common' and the other with the > current options called 'Advanced'. Instead of pages, have an "Advanced" button that fold and unfold additional config. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making Configure Build Lazarus more user friendly
Giuliano Colla wrote: > The configure build lazarus IDE provides a lot of options which the > majority of us don't use, but we're however forced to check/uncheck. > > Therefore I've added a small Group Box, named "Quick Configure Options" > with thre buttons: All, LCL, and Custom. The first two cover (in my > opinion) the needs of the vast majority of users, while the third one > can be handy. > The "All" Button checks all the Build (or Clean+Build, if Clean All is > checked), the "LCL" button unchecks everything, except LCL (which is set > to Build or Clean+Build as above), while Custom unchecks everything. > If the idea seems good, the attached patch can be applied, or someone > can do it better. > If not, I'll just keep it for me, because I find it handy. This is great, but there is one important option missing: Build Packages which would turn off everything, except IDE with Packages. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Michael Van Canneyt wrote: > On Mon, 23 Jul 2007, Al Boldi wrote: > > Graeme Geldenhuys wrote: > > > So again, what is the pros and cons between the two design choices > > > when using the Object Pascal language? > > > > .dfm is good for beginners, who get confused looking at code they didn't > > write. > > > > .pas is good for pros, who need to take control of their project code. > > Obviously you are unaware of the real reasons the .dfm mechanism was used, > otherwise you would not use such unappropriate demeaning tone. No offense meant. The .lfm is probably there for compatibility reasons. > There are/were good reasons for it's use. These reasons may have been > outdated, but at the time, they were certainly valid. It was (and is, > in my opinion) a defendable choice. I have not seen you give any valid > and objective reasons why code is better than resources. Unless you > plan to give such reasons, I suggest you abstain from such demeaning > comments. This really has nothing to do with resources. Resources should still be saved in its own .res file. This is about code init, and as such should not be mutilated into some obscure hardcoded "code init" translator, but instead be obviously exposed for code control. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Form designer code inside .pas unit
Graeme Geldenhuys wrote: > Hi, > > What are the pros and cons for letting the form designer add code > inside the .pas unit instead of a separate .lfm file? > > For example: > Lazarus and Delphi uses external files (.lfm and .dfm) to save > information about forms designed using the form designer. .dfm is a straight copy-cat from VB, to obscure code structure for beginners. It's probably one of the worst mistakes Delphi could mimic > Visual Studio and CodeGear's C# IDE's use the source code unit > directly instead of a external unit. They embed the form/component > creation code inside a private method called from the constructor. The > code in that private method is also wrapped in C# Region so that it is > hidden by default with code folding. Java always did it like this, and now others are starting to mature. > So again, what is the pros and cons between the two design choices > when using the Object Pascal language? .dfm is good for beginners, who get confused looking at code they didn't write. .pas is good for pros, who need to take control of their project code. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Find in Files using an external Indexing Engine
Al Boldi wrote:
> Michael Van Canneyt wrote:
> > On Sun, 4 Jun 2006, Mattias Gaertner wrote:
> > > Al Boldi <[EMAIL PROTECTED]> wrote:
> > > > Mattias Gaertner wrote:
> > > > > Al Boldi wrote:
> > > > > > The SourceEditor currently has the ability to search in files by
> > > > > > searching a complete directory hierarchy. This may result in
> > > > > > prolonged searches if the hierarchy is large.
> > > > > >
> > > > > > By pre-Indexing the sources, this could be reduced dramatically.
> > > > > >
> > > > > > Would this be difficult to implement?
> > > > >
> > > > > Can you give an example how this pre-Indexing should work?
> > > >
> > > > On the search in files dialog, there could be a button to create a
> > > > word index of the sources, and a checkbox to use this index instead
> > > > of grepping the files each time.
> > >
> > > Implementing should be simple. But making it fast, can be a lot more
> > > work. If you want to implement it and have any questions, don't
> > > hesitate to ask.
> >
> > I suggest that if this is implemented, it should be done as an external
> > program, so it can be run in the background, or immediatly after
> > installation.
>
> Sure. Do you know of any external mini-crossindexing engine? Jedi?
I finally found one, and the reason it took me so long is because it was
hiding behind some obscure name just like lazarus; it's called: swish-e
It's lightening fast, especially during retrieve, but what's important is
that it outputs a list of filenames ready to be loaded into the TheFileList
object for DoFindInFiles to do the rest. Like this:
{Search All the files in a project and add the results to the
SearchResultsView Dialog}
procedure TSourceNoteBook.FIFSearchIndex(ADialog: TLazFindInFilesDialog);
var
TheFileList: TStringList;
SearchForm: TSearchForm;
begin
try
TheFileList:= TStringList.Create;
SearchForm:= FIFCreateSearchForm(ADialog);
ExecuteProcess('/bin/sh'
,'-c "/idx '
+SearchForm.SearchDirectory+' '
+SearchForm.SearchText
+' | grep '
+SearchForm.SearchMask
+' > /tmp/idx.dmp"');
TheFileList.LoadFromFile('/tmp/idx.dmp');
SearchForm.SearchFileList:= TheFileList;
DoFindInFiles(SearchForm);
finally
FreeAndNil(TheFileList);
FreeAndNil(SearchForm);
end;
end;
There are two things to notice:
1. This is not swish-e dependent, here "/idx" is a shell script, which means
any indexing engine that can output a list of files can interface with
DoFindInFiles.
2. This is specific to the unix platform; how can we make it platform
independent.
Thanks!
--
Al
_
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] form embedded in another form
Cesar Romero wrote: > >> And why do you think a form.OnCreate would fire at the right moment ? > > > > Well, using embedded forms at runtime... you create the form when you > > need the form. At which point the OnCreate fires. Frames are meant > > for usage at design time, so you have no control at runtime, as to > > when it was created. > > I agree and share the same opinion that Graeme, I use extensivelly form > creation at runtime, and I had to drop the TFrame and use > embedded TForm. Same here! TFrame is useless when the widget-set supports embedding TForm. Also, embedding out-of-process TForms is indispensable, but not all widget-sets support this; gtk currently doesn't. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] CodeTools and a GUI Class Builder
Graeme Geldenhuys wrote: > On 15/06/07, Al Boldi <[EMAIL PROTECTED]> wrote: > > A good starting point would probably be a DBTable-To-Class importer. > > tiOPF already has something link this - well kinda. The tool is called > tiSQLEditor. You write and execute you SQL statement and see the > result screen. In that screen you can then generate different sets of > code for BOM, Visitors, MapRowToObject, etc and the code gets placed > in the Clipboard, ready to paste into you IDE's editor. I had a look at the tiOPF dist but could not find this tool. Is this a standalone tool? > > Does CodeTools offer the necessary functions to implement this easily? > > Well looking at the examples, I would say yes. The Class Builder will > use feature that are already used by the Lazarus IDE, just in a > slighly different way. Things like Code Completion and Refactoring, > etc.. > > I've already created all the skeleton dialogs I would need. Now it's > time to plug in the CodeTools functions. :-) Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] CodeTools and a GUI Class Builder
Graeme Geldenhuys wrote: > Hi, > > Has anybody done something like this with CodeTools yet? Creating a > GUI Lazarus addon or seperate application that can build or edit > classes? Great idea! > I would like to build such a tool or help someone that already started > with such a tool. This would be extremely handy in projects like tiOPF > where you need to create hundreds of Business Objects. Agreed! It's extremely useful for db-driven application dev, and something that could also ease the ObjectModel to DataModel integration. A good starting point would probably be a DBTable-To-Class importer. Does CodeTools offer the necessary functions to implement this easily? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Threads and Forms
Luca Olivetti wrote: > I wasn't actually interested in updating the counter, it was just a test > to see if while I was sleeping ;-) the LCL became automagically thread > safe :-D [*] (I still remember the shock when I wrote my first delphi > 2.0 heavily multithreaded application only to discover that it didn't > work at all because the VCL wasn't thread-safe). The VCL was not and is not thread-safe, and neither is the LCL. Do you know why? > e.g. I also tested adding lines to a memo directly from the thread with > no apparent problems. Pure chance. > [*]in fact, a couple of years ago, when I lastly used lazarus for a > project, if I used synchronized the program did't work at all (IIRC > either it would lock or the synchronized method was triggered more than > once), so I just boldly avoided using synchronize. I don't remember the > exact details, so it may just have been a fringe case where synchronize > wasn't actually needed[**]. It's a simple program but it's been running > unattended 24 hours a day since then. > > [**]Ok, I looked again at that old code and I cheated: the access to the > data was protected with a critical section, but I'm pretty sure I > avoided synchronize because it didn't work right at the time. Have you found a problem with synchronize now? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] PHP IDE-plugin
Cesar Romero wrote: > Im already using here, dispite any other opinion, D4PHP is a very > productive tool. Pieter Valentijn wrote: > I just Bouth it as well. > Even do its class herachie is not optimal it's mutch beter than notepad It sure is! But the real question is: How difficult would it be to have a PHP IDE-plugin based on VCL4PHP? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] AllocateHWnd
Felipe Monteiro de Carvalho wrote: > On 4/3/07, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > > Can someone give a short example or point me to the right mail, where > > AllocateHWnd is needed and why it must be implemented in all LCL > > interfaces instead of the LCL? > > At some point I thougth about implementing it purely on LCL, but I > discarted this option a little later. It was a implementation option. > I don´t remember exactly the reasons, I think the reason you abandoned it is because you want to leverage existing code, which is fine. But you probably loose cross-platform compatibly that way, as each platform does it differently, unless you are really lucky. On linux, for example, message loops are done via IPC, as is shmem and mutex. So, what we need is an IPC component, that wraps the platform details inside the component, and exposes a platform-independent interface. > but I can try to thing again about it. Good idea. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] History of the widget set design?
Sergei Gorelkin wrote: > And there are tons of similar issues, which make any fpGUI app feel > extermely alien in Windows. As a programmer, I can say that fixing > such issues is actually a much harder and boring job than what you > had already done. Agreed. > Nevertheless, you are on a really good way with the fpGUI! Being free > of legacy bugs and external dependencies, and at the same time > compatible with VCL to a certain degree, it has real potential to > eventually become a very useful library. Great things do start small, and actually evolving slowly is one great recipe for success. Keep up the good work, and make sure that improvements aren't at the cost of quality, as in: Quality comes first, looks are second. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing TObject
Marco van de Voort wrote: > On Wed, Mar 21, 2007 at 07:15:41AM +0300, Al Boldi wrote: > > > > > (reserved in the VMT by the virtual directive), it doesn't create > > > > > room. > > > > > > > > > > This is also why you can't override non virtual methods. > > > > > > > > Thanks for this very clear and to the point answer. > > > > > > > > Would it be possible to implement virtual objects? > > > > > > Depends on what you mean by "virtual objects". > > > > You know, an object that can be overridden like a virtual method > > But what is exactly overriden in the object? In the case of a method it is > clear. The code of that specific method is overridable. Override the whole object; consider this: TObject1 = class; This inherits the ancestor and changes the name, whereas something like: TObject = class ; override; Would inherit/override the ancestor while keeping the name. Is this possible to implement? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing TObject
Marco van de Voort wrote: > > Marco van de Voort wrote: > > > (reserved in the VMT by the virtual directive), it doesn't create > > > room. > > > > > > This is also why you can't override non virtual methods. > > > > Thanks for this very clear and to the point answer. > > > > Would it be possible to implement virtual objects? > > Depends on what you mean by "virtual objects". You know, an object that can be overridden like a virtual method, possibly implementing a VOT like a VMT? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing TObject
Marco van de Voort wrote: > On Tue, Mar 20, 2007 at 01:58:56PM +0300, Al Boldi wrote: > > Antonio Sanguigni wrote: > > > And, broadly speaking, it is not a good practice modifying an ancestor > > > to suite these needs. > > > > Yes, as this would probably require a recompile of the ancestor. > > > > But, why is it not possible to override the ancestor? > > The size of fields of TObject is used in planning the layout of > descendants of TObject. Overriding only makes use of room already there > (reserved in the VMT by the virtual directive), it doesn't create room. > > This is also why you can't override non virtual methods. Thanks for this very clear and to the point answer. Would it be possible to implement virtual objects? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Changing TObject
Antonio Sanguigni wrote: > And, broadly speaking, it is not a good practice modifying an ancestor to > suite these needs. Yes, as this would probably require a recompile of the ancestor. But, why is it not possible to override the ancestor? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Illegal Expression -- Exit
Bram Kuijvenhoven wrote: > If Exit is a variable or field in the local scope, you actually get the > 'illegal expression' error. But, it should at least give you a warning at the overriding variable then? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Difference between TThread and BeginThread
Sebastian Kraft wrote: > I looked through fpc docs and found the function BeginThread( func) to > execute the function func as a seperate thread. > > What are the (dis)advantages of this very easy usage compared to creating > a TThread class? TThread is an oop-wrapper for BeginThread, and binds helpers and events into one class. What we need is a TThread component. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: Ideas to implement AllocateHwnd
Felipe Monteiro de Carvalho wrote: > I started implementing this on LCLIntf, but I am having a lot of > trouble with type declarations. AllocateHWnd needs a parameter of type > TWndProc = procedure (var Message: TLMessage) of object; > > But TWndProc is declared on controls, and no basic lcl unit uses > controls, and if i add controls on lclintf or other units, I get > circular references. The usual way to break circular references, is to add them to the uses clause of the implementation section. Did you try that? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Copy 'n paste in the editor
Vincent Snijders wrote: > Al Boldi schreef: > > Vincent Snijders wrote: > >> Kris Leech schreef: > >>> Ger Remmers wrote: > >>>> Select some text (plain ascii) in a mail message (Kmail) or a news > >>>> post (Knode) and copy it (CTRL-C or CTRL-Ins). Switch to Lazarus > >>>> Editor Window and > >>>> right-click. In the menu select Paste. Nothing visual happens ie, no > >>>> text appears. Right-click again, Lazarus closes without any error > >>>> messages. > >> > >> It doesn't happen with me when I use Lazarus from SVN. But maybe I > >> don't have right content on the clipboard ... > > > > This is how I get the bug: > > > > 1. start IDE > > 2. open saved project > > 3. copy a selection with ^C > > 4. paste into foreign app - nothing happens. > > 5. copy/paste of IDE is now in a corrupt state and does not work with > > outside apps. > > 6. to recover restart IDE > > > > Workaround: > > I tried this on windows 2000 and it worked and there was no corruption. > What OS did you use? wmaker on Linux 2.6.20. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Copy 'n paste in the editor
Vincent Snijders wrote: > Kris Leech schreef: > > Ger Remmers wrote: > >> Select some text (plain ascii) in a mail message (Kmail) or a news post > >> (Knode) and copy it (CTRL-C or CTRL-Ins). Switch to Lazarus Editor > >> Window and > >> right-click. In the menu select Paste. Nothing visual happens ie, no > >> text appears. Right-click again, Lazarus closes without any error > >> messages. > > It doesn't happen with me when I use Lazarus from SVN. But maybe I don't > have right content on the clipboard ... This is how I get the bug: 1. start IDE 2. open saved project 3. copy a selection with ^C 4. paste into foreign app - nothing happens. 5. copy/paste of IDE is now in a corrupt state and does not work with outside apps. 6. to recover restart IDE Workaround: 1. start IDE 2. open saved project 3. copy a selection from a foreign app 4. paste into IDE - works ok. 5. copy/past of IDE is now in a correct state and works with outside apps. 6. repeat same workaround for each newly opened project. It seems that copy/paste is not properly initialized for first use, and workaround infers a correct initialization. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] add a timer?
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > 于野 wrote: > > > I'm a Chinese OIer(which is short for someone who has intersts in > > > 'Olympiad in Informatics'). Now I'm using Lazarus to debug. but > > > every time when I want to know how much time it spend during the > > > program runs, I have to add something like this: var > > > ta,tb:Tsystemtime; begin > > > datetimetosystemtime(now,ta); > > > > > > > > > datetimetosystemtime(now,tb); > > > writeln(); > > > end. > > > It's so boring. > > > > I got bored too, so I wrote TElapsed. > > Did you try 'time' and gprof (Linux, MacOSX and FreeBSD)? time is good for timing total elapsed time. gprof is good for timing function calls. TElapsed is good for timing inline code segments. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] add a timer?
于野 wrote:
> I'm a Chinese OIer(which is short for someone who has intersts in
> 'Olympiad in Informatics'). Now I'm using Lazarus to debug. but every time
> when I want to know how much time it spend during the program runs, I have
> to add something like this: var ta,tb:Tsystemtime;
> begin
> datetimetosystemtime(now,ta);
>
>
> datetimetosystemtime(now,tb);
> writeln();
> end.
> It's so boring.
I got bored too, so I wrote TElapsed.
Thanks!
--
Al
unit elapsed;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils;
type
{ TElapsed }
TElapsed = class(TComponent)
private
FStart:TDateTime;
public
procedure Start;
function ms: integer;
function mss: string;
end;
procedure Register;
implementation
procedure Register;
begin
RegisterComponents('Standard', [TElapsed]);
end;
{ TElapsed }
procedure TElapsed.Start;
begin
FStart:=Now;
end;
function TElapsed.ms: integer;
begin
Result:=DateTimeToTimeStamp(Now-FStart).Time;
end;
function TElapsed.mss: string;
begin
Result:=IntToStr(ms);
end;
initialization
end.
Re: [lazarus] lazarus saves every time I compile
Andrea Mauri wrote: > My "problem" is, I have a big project, with many units, I make a lot of > modifications daily, I want to test if everything works as I want, so I > compile my project many times in a day. > I don't want that lazarus saves my project every time I compile it and I > don't want to make a manual backup of my project every time I modify it. > I want that lazarus saves my project only if I decide to save it and not > if I compile it. Good point. I am working around this problem by using versions. (see EnvironmentOptions:Backup) > Is it not possible to have the same behavior as in Delphi? It probably is possible. We just have to figure out how to implement it. Any ideas? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] TStringGrid to replace TListBox in Messages window
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Mattias Gaertner wrote: > > > Al Boldi <[EMAIL PROTECTED]> wrote: > > > > > > Preallocating the tree in TTreeView could improve its speed a > > > > > > lot. > > > > > > > > > > I doubt that. It already works with exponential growth. > > > > > > > > Preallocate in 16sec > > > > TreeView1.BeginUpdate; > > > > TreeView1.Items.Clear; > > > > for i:=1 to 10 do > > > > TreeView1.Items.Add(nil,''); > > > > TreeView1.EndUpdate; > > > > > > I improved it. Please try. > > > > Do you have a patch against 0.9.15? > > I can create one, but I'm not sure, if the rest of 0.9.15 will work > with it. > Attached. Thanks! It didn't apply, but with this change / else if Index>Count-5 then begin // optimization for the last nodes Result:=GetLastSubNode; i:=Count-1; while (Index No preallocation > 2min ^C == > TreeView1.BeginUpdate; > TreeView1.Items.Clear; > for i:=1 to 10 do begin > TreeView1.Items.Add(nil,'tst'+inttostr(i)); > for j:=1 to 10 do > TreeView1.Items[i-1].Text:=IntToStr(i)+','+IntToStr(j); > end; > TreeView1.EndUpdate; > = speeds thru in 19sec. TStringGrid is still 4 times faster. What change is required for preallocation? Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
