Re: [Lazarus] Running on mipsel

Sven Barth wrote: On 25.10.2012 20:03, Bernd wrote: 2012/10/25 Mark Morgan Lloyd : something else appeared to be messing up e.g. the IDE's ability to store/access ~/.lazarus configuration settings: because of this lazbuild wasn't able to build a trivial test project prepared on a different sy

Re: [Lazarus] Running on mipsel

On 25.10.2012 20:03, Bernd wrote: 2012/10/25 Mark Morgan Lloyd : something else appeared to be messing up e.g. the IDE's ability to store/access ~/.lazarus configuration settings: because of this lazbuild wasn't able to build a trivial test project prepared on a different system. You can put

Re: [Lazarus] Cross-compiling -> MIPS

On 25.10.2012 20:05, SkyDiablo wrote: This is related to the fact that 2.6.0's fpcmake does not support mips-linux yet. Possible solution: First do (once, independantly) the following: (assuming the current dir is your 2.7.1 source directory) cd utils\fpcm make all And then add "FPCMAKE=%YOU

Re: [Lazarus] Cross-compiling -> MIPS

This is related to the fact that 2.6.0's fpcmake does not support mips-linux yet. Possible solution: First do (once, independantly) the following: (assuming the current dir is your 2.7.1 source directory) cd utils\fpcm make all And then add "FPCMAKE=%YOURSOURCEDIR%\utils\fpcm\fpcmake.exe" to

Re: [Lazarus] Running on mipsel (was: Re: Cross-compiling -> MIPS)

2012/10/25 Mark Morgan Lloyd : > something else appeared to be messing up e.g. the IDE's ability to > store/access ~/.lazarus configuration settings: because of this lazbuild > wasn't able to build a trivial test project prepared on a different system. You can put environmentoptions.xml pointing

Re: [Lazarus] Deep exe strip :)

On 25/10/2012 14:29, Kostas Michalopoulos wrote: I think there should be a one checkbox solution in project settings that builds (and rebuilds) stuff with the proper settings to make things compact. From what i understand the current situation is way too complex. It is possible. Look on the wi

Re: [Lazarus] Deep exe strip :)

> Is exists any global strip to get the smallest possible exe size? Not to my knowledge, but in my version (1.1 about 1 month ago) if I change build mode then all dependencies are recompiled, with the same options I guess, because I got a slightly smaller binary. -- View this message in context

Re: [Lazarus] How do I fix win32object.inc errors compiling Win64 Lazarus trunk+FPC trunk?

On 25-10-2012 16:20, luiz americo pereira camara wrote: > > > 2012/10/25 Reinier Olislagers > > > > Bump. > > Could somebody have a look if they have time? The bug's not been > assigned to somebody yet. > > > Should be fixed > > Please, test

[Lazarus] Running on mipsel (was: Re: Cross-compiling -> MIPS)

Mark Morgan Lloyd wrote: Henry Vermaak wrote: I built lazarus with fpc 2.7.1 for armhf this weekend. Why do you say 2.6.0 is needed? Because of the feeling with which most developers insist that 2.6.0 is the one true way :-) OK, I'll try it for MIPS in a couple of days. I presume you wer

Re: [Lazarus] How do I fix win32object.inc errors compiling Win64 Lazarus trunk+FPC trunk?

2012/10/25 Reinier Olislagers > > Bump. > > Could somebody have a look if they have time? The bug's not been > assigned to somebody yet. > Should be fixed Please, test Luiz -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists

Re: [Lazarus] Cross-compiling -> MIPS

Am 25.10.2012 12:06, schrieb SkyDiablo: so, next one. there was an fail PREFIX at all so i change it to "mips-linux-gnu-", this scrips works at first: === set PATH=C:\lazarus\fpc\2.6.0\bin\i386-win32;C:\Program Files (x86)\CodeSourcery\Sourcery G

Re: [Lazarus] Deep exe strip :)

I think there should be a one checkbox solution in project settings that builds (and rebuilds) stuff with the proper settings to make things compact. From what i understand the current situation is way too complex. On Thu, Oct 25, 2012 at 1:35 PM, Martin wrote: > On 25/10/2012 11:50, Krzysztof wr

Re: [Lazarus] How do I fix win32object.inc errors compiling Win64 Lazarus trunk+FPC trunk?

On 18-10-2012 5:05, Reinier Olislagers wrote: > On 11-10-2012 19:29, Marco van de Voort wrote: >> On Thu, Oct 11, 2012 at 10:25:17AM +0200, Reinier Olislagers wrote: IMHO, that patch is correct, except: * use UINTPTR instead of THandle as record field. * make sure it still compiles/r

Re: [Lazarus] lnet sockets

On 10/25/2012 01:21 PM, Bernd wrote: In my example I mentioned a modal dialog Regarding the latest message by Antonio this seems like a good idea: a Modal dialogue blocks the GUI while not eating CPU time. So he can fire same to prevent user interaction. Now the user can do nothing but "cance

Re: [Lazarus] lnet sockets

On 10/25/2012 01:41 PM, Antonio Fortuny wrote: this is exactly what I have to avoid: user gains control on screen. A workaround is to disable the window itself. Maybe better: do the calculation in the background (maybe in a thread) and only when ready update the screen and react on any user ac

Re: [Lazarus] lnet sockets

On 10/25/2012 01:30 PM, Bernd wrote: . If it does not work then it is worth to provide patches to make it work Yep. I only think that if it does not work, it's more likely that a patch for the LCL is necessary than for lnet. In fact CallAsyncQueue and PostMessage did not work with the KDE Wid

Re: [Lazarus] lnet sockets, ´"eventer"

2012/10/25 Michael Schnell : > I suppose you mean "...is required by the user to be handled". That means > that the waiting (here of course not "sleeping", as the "sleeping" is done > in the LCL) is done in some "magical" way in the guts of the lnet code. This > does sound nice. Could you explain

Re: [Lazarus] lnet sockets

Le 25/10/2012 13:07, Bernd a écrit : very nice indeed and readable even on pseudo-code, but ... Here is an alternative way to implement it (this one can even reply and have a conversation of multiple commands going forth an back between the client and server): pocedure OnEverythingGetsStarted;

Re: [Lazarus] Deep exe strip :)

On 25/10/2012 11:50, Krzysztof wrote: Does the size change if you do a strip --strip-all executable in one of the large versions down to the small version? With strip-all I can't get the smallest exe which I get with lazarus switchers - 3.7 MB strip and smart-linking/linkable are not relate

Re: [Lazarus] lnet sockets

On 10/25/2012 01:07 PM, Bernd wrote: This will never block and never freeze and never eat any unneeded CPU cycles and it is les code than messing around with the eventers and CallAction directly and also less code than low level programming against sockets and/or winsock2 directly. Sounds good

Re: [Lazarus] lnet sockets

2012/10/25 Antonio Fortuny : > You got it. This is how the WinCE application runs: > user reacts on a Form > the appropriate form event is lauched > some information is needed from the server before carry on any further > processing > ask the net server: > open connection > send reques

Re: [Lazarus] lnet sockets, ´"eventer"

On 10/25/2012 12:31 PM, Bernd wrote: The eventer that is used by default when putting an lnet component onto an LCL form is different from the other eventers that lnet provides. This one is tightly integrated into the LCL and fires its event from the main thread, just like button clicks and othe

Re: [Lazarus] Deep exe strip :)

> Does the size change if you do a > > strip --strip-all executable > > in one of the large versions down to the small version? With strip-all I can't get the smallest exe which I get with lazarus switchers - 3.7 MB > Note that you do not actually need to rebuild the IDE, it is enough to > just c

Re: [Lazarus] lnet sockets, ´"eventer"

2012/10/25 Michael Schnell : > Some questions: > > - Can such an "eventer" be used in the main thread and in worker threads ? > - If used in the main thread, can the "eventer" decently coexist with LCL > based Events (such as TTimer, GIU, QueueAsyncCall, ...), > - If Yes: How ? The eventer tha

Re: [Lazarus] TLazPackageGraph.CheckCompileNeedDueToDependencies: perhaps compile more than now?

On 25-10-2012 12:05, Mattias Gaertner wrote: > > Reinier Olislagers hat am 25. Oktober 2012 um > 10:29 geschrieben: >> In this code in packager\packagesystem.pas, the if Result<>mrOK test >> gives a note unable to load state file.. and the procedure exits: >> >> // check compile state file of req

Re: [Lazarus] Cross-compiling -> MIPS

so, next one. there was an fail PREFIX at all so i change it to "mips-linux-gnu-", this scrips works at first: === set PATH=C:\lazarus\fpc\2.6.0\bin\i386-win32;C:\Program Files (x86)\CodeSourcery\Sourcery G++ Lite\lib\gcc;C:\Program Files (x86)\C

Re: [Lazarus] TLazPackageGraph.CheckCompileNeedDueToDependencies: perhaps compile more than now?

Reinier Olislagers hat am 25. Oktober 2012 um 10:29 geschrieben: > In this code in packager\packagesystem.pas, the if Result<>mrOK test > gives a note unable to load state file.. and the procedure exits: > > // check compile state file of required package > if not RequiredPackage.AutoCreated then

Re: [Lazarus] lnet sockets

On 10/25/2012 10:42 AM, Antonio Fortuny wrote: Right, but does that mean that the lnet cpmponent should be into the thread range ? I don't really know in what way lnet can help you, but if it does not use LCL events or GUI stuff, it should be no problems to use it in a in thread. Or you could

Re: [Lazarus] lnet sockets

Le 24/10/2012 17:43, Bernd a écrit : 2012/10/24 Michael Schnell : WaitForSingleObject ? Is this an LCL application? This is Windows stuff. I assumed he is making an LCL appplication because LCL exits for win-CE too. Also there are platform independent locks and events in the RTL. (RTLEvent

Re: [Lazarus] lnet sockets

Le 25/10/2012 09:50, Michael Schnell a écrit : On 10/24/2012 05:43 PM, Bernd wrote: It is not clear to me what exactly "the application needs to wait" should exactly mean in this context. I think, in a socket-related application, it is rather obvious that the application needs to wait on data f

Re: [Lazarus] lnet sockets

Le 24/10/2012 17:27, Bernd a écrit : 2012/10/24 Antonio Fortuny : Question is: The two pieces of code for the timer(1) and the socket(2) will they be active when the main thread enters the wait state thru the WaitForSingleObject ? Is this an LCL application? If yes then you may MOT block the

[Lazarus] TLazPackageGraph.CheckCompileNeedDueToDependencies: perhaps compile more than now?

In this code in packager\packagesystem.pas, the if Result<>mrOK test gives a note unable to load state file.. and the procedure exits: // check compile state file of required package if not RequiredPackage.AutoCreated then begin Result:=LoadPackageCompiledState(RequiredPa

Re: [Lazarus] lnet sockets, ´"eventer"

I understand that the "eventer" (like the "epoll()" Linux API call) can make the (main-)thread sleep (in the OS) and have it woke and without latency branch to the appropriate handler code as soon as one of the affiliated "events" (such as availability of incoming data from a Socket / Pipe / A

Re: [Lazarus] lnet sockets

On 10/24/2012 05:43 PM, Bernd wrote: It is not clear to me what exactly "the application needs to wait" should exactly mean in this context. I think, in a socket-related application, it is rather obvious that the application needs to wait on data from the socket to arrive. (Same with Pipes, Asy