Re: [Lazarus] How to program with time in milliseconds?

On 05/18/2014 08:10 PM, Graeme Geldenhuys wrote: {$IFDEF Windows} begin QueryPerformanceCounter(Result); Did you check that this is a low overhead function ? {$ELSE} do_syscall(syscall_nr_clock_gettime,TSysParam(CLOCK_MONOTONIC),TSysParam(@ts)) It seems that a syscall is not necessary with

Re: [Lazarus] How to program with time in milliseconds?

On 05/18/2014 08:10 PM, Graeme Geldenhuys wrote: And that is exactly what my local copy of EpikTimer does for over a year alread - just one of many improvements I've made to my copy of EpikTimer, but sadly never got around to sharing the code (which I'll do shortly). Thanks a lot ! If the code

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 07:34 PM, Junior wrote: I need precision, I'll be working with many timers in milliseconds. (Windows 32 bits/64bits; Linux 32 bits/64bits; Android; MacOS; among others) No normal (not dedicatedtly "realtime") OS provides "decent" millisecond precision. The OS might stall any p

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 05:26 PM, Reimar Grabowski wrote: OP: "I need to develop a game for all possible Operating Systems." "EpicTimer" uses "QueryPerformanceCounter" for Windows. I did not check into this, but I suppose this already is what he needs. But it uses "fpgettimeofday" in Linux. This is w

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 02:44 PM, Sven Barth wrote: Nevertheless we could add vDSO support to the Linux unit so that users can make use of it without the need to link to libc or implement it themselves. :) Hence fpGetTimeOfDay would need multiple implementations. clock_gettime seems to be Linux-onl

Re: [Lazarus] [ANN] Brook 3.0.0 release!

On 05/15/2014 01:45 PM, Leonardo M. Ramé wrote: Can you add a "What's new" item in the home page or in the Wiki?. Plus a "What's old" item for silly me ;-) . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.laza

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 01:06 PM, Henry Vermaak wrote: Yes, as I said earlier. It's in the man page, too. And in the kernel source I pointed to. Henry, Thanks a lot for you patience ! So this (using vDSO to call "clock_gettime" in fact is what the OP was searching for, and what would needed tp be imple

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 01:29 PM, Henry Vermaak wrote: You seem a bit confused about some of these things, and people are talking at cross purposes, Right you are. I e.g. was inappropriately ignoring the fact that the time of day can be unaffectedly modified under the hood. Now I know better. (Disrega

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 11:43 AM, Henry Vermaak wrote: Only the speed can be improved by calling into the vDSO, not the precision. You need to use clock_gettime() for nanosecond precision I see. Is clock_gettime not available via vDSO ? To me this seems even more viable than for fpGetTimeOfDay. (a

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 11:18 AM, Michael Van Canneyt wrote: fpGetTimeOfDay is used to implement Now(). This should not be changed. Why not, If there are better ways ? I did a quick search in the RTL sources and found that there is "GetTickCount64" that maybe could be used as a central cross-platform

Re: [Lazarus] How to program with time in milliseconds?

On 05/15/2014 09:51 AM, Michael Van Canneyt wrote: Of course in the end I need something that works for any CPU and OS. There is nothing. EpikTimer pretends to fill this gap, but it does not. Yep. If necessary I could try to do something myself (i.e. an improved version of fpgettimeofday

Re: [Lazarus] How to program with time in milliseconds?

--- sorry, previous mail seems to be digested by some scrambler --- On 05/14/2014 09:44 PM, Michael Van Canneyt wrote: Hopefully you got rid of the fpgettimeofday, or else the component is no better than using Now() :-) Michael, Even though I of course was aware of this, I did used fpgettime

Re: [Lazarus] How to program with time in milliseconds?

On 05/14/2014 09:44 PM, Michael Van Canneyt wrote: Hopefully you got rid of the fpgettimeofday, or else the component is no better than using Now() :-) Michael, Even though I of course was aware of this, I did used fpgettimeofday to implement TTimer with the "ActiveNoGui" WidgetType, as I di

Re: [Lazarus] How to program with time in milliseconds?

On 05/13/2014 12:00 PM, Henry Vermaak wrote: This doesn't have anything to do with vDSO, though. The standard library doesn't use any assembler to read these registers. It calls into a page that the kernel makes available to userspace that contains certain functions where the overhead of a sysc

Re: [Lazarus] How to program with time in milliseconds?

On 05/13/2014 10:45 AM, Mark Morgan Lloyd wrote: There's an obvious pitfall there: a poor implementation might /think/ that it's directly accessing the counters when in actual fact it's being virtualised or fixed up by a signal handler. Regarding just reading the "performance-monitoring cou

Re: [Lazarus] How to program with time in milliseconds?

On 05/12/2014 10:37 PM, Henry Vermaak wrote: On linux, glibc (and others) will route gettimeofday() (and clock_gettime() for certain clock IDs) via vDSO and no syscall will be called, so it's very fast. I don't think the fpc rtl does this, though? I checked with X86 32 Bit Linux: you are righ

Re: [Lazarus] How to program with time in milliseconds?

On 05/12/2014 02:47 PM, Reinier Olislagers wrote: The wiki page even explicitly mentions ARM. Right. As it does a system call in Linux, this should be independent of the CPU arch Do you mean direct access to the hardware bypassing the OS? I thought that wasn't possible in Windows? I don't

Re: [Lazarus] How to program with time in milliseconds?

On 05/11/2014 09:44 AM, Graeme Geldenhuys wrote: Take a look at EpikTimer. It uses hardware timers where available, with an easy to use API for the developer. IO took a look. Seemingly this is only available for X86 and X86_64. In Windows, "QueryPerformanceCounter" is called. I supposed (I d

Re: [Lazarus] Forcing TMemo to dislplay last entry

On 04/25/2014 07:35 PM, Sandro Cumerlato wrote: SendMessage(Memo1.Handle, EM_LINESCROLL, 0, Memo1.Lines.Count); AFAIK, this is a Windows-only option that does not work cross-platform (and hence should not be recommended). OTOH, I don't know a better one :-( . -Michael -- _

Re: [Lazarus] Wanted: OpenGL gui framework supporting Windows, Linux, Mac, Android, etc.

On 04/24/2014 12:05 PM, Hans-Peter Diettrich wrote: I don't see how and why somebody would use such a framework, as long as no component library (like LCL) is implemented for it. Using the LCL requires that the components are of the basic types (TComponent, TControl, TCustomForm...). Usin

Re: [Lazarus] Now function - returning UTC?

On 04/21/2014 12:49 PM, Felipe Monteiro de Carvalho wrote: On Sat, Apr 19, 2014 at 4:07 PM, Luca Olivetti wrote: BTW, the name of the unit isn't really meaningful (NowUTC and GetTickCount64, the only 2 functions defined in that unit, don't seem to have any relation with utf8). The idea was tha

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 05:30 PM, Martin Frb wrote: So I will not add those gdb/gdbserver myself. I do not know, if anyone else wants to work on that. I did try (see the other mail). Also which installer should they be added to? I suppose you mean installer for Lazarus ? The only installer which does

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 07:33 PM, Martin Frb wrote: Look at the log, if you see the -exec-... & and the work then all is ok. I have the ARM machine in question (a "topless" QNAP NAS) at home and will try to make sense of this during the weekend. BTW.: In fact the helpful person from Austria did start

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 05:33 PM, Martin Frb wrote: That would work. (and I would accept a patch (adding an option / not making it mandatory) Sounds nice to me, especially regarding that gdbserver is not that "common" and hence not easily to come by in some cases. But at this stage, I prefer the asy

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 05:14 PM, Martin Frb wrote: Or do you have another way? A wild Idea might be to open two SSH sessions: one for gdb (maybe in sync mode of this makes sense), and another that just accesses a little SIGINTServer application that is used to send the signal when appropriate.. -Mi

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 03:30 PM, Martin Frb wrote: On 10/04/2014 14:14, Michael Schnell wrote: Moreover I found that, with an embedded target, finding or creating a normal gdb might be a lot easier that finding or creating the "cross gdb" (running on PC but understanding the Target's

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 05:06 PM, Michael Schnell wrote: Manually using gdb via ssh (to bash) can do it, So why should the IDE not be able to ? (Or does - when in non-remote mode - the IDE really send a SigInt *directly* to the application and not via the debugger ) Hum. Re-Thinking: When manually

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/10/2014 03:30 PM, Martin Frb wrote: The IDE ssh debugger, can not pause the app either. I don't understand why this should be the case. Manually using gdb via ssh (to bash) can do it, So why should the IDE not be able to ? (Or does - when in non-remote mode - the IDE really send a Sig

Re: [Lazarus] Remote debugger looses connection to target on Windows 7

On 04/09/2014 06:27 PM, Bernd Mueller wrote: I stepped through the program until the problem occurred and hit then pause. As far as I could see, nothing happened. Then I hit stop. I once was told that with using gdbserver, "Pause" (while not hitting a breakpoint) is not possible. That is w

Re: [Lazarus] lfm file format

On 04/06/2014 09:50 PM, Marc Santhoff wrote: floating Bells ringing "Firemonkey" :-) ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] [LAZARUS] Any Free/Cheap Async Serial Port Component

On 04/03/2014 12:53 PM, Mark Morgan Lloyd wrote: I think the two would need to be designed together, even if in practice one was coded first. In fact I am planning to do a NoGUI WidgetType some day (hopefully soon), and since some time I do know how this in fact can be done. Unfortunately no

Re: [Lazarus] [LAZARUS] Any Free/Cheap Async Serial Port Component

On 04/02/2014 10:53 PM, Roberto P. wrote: I'd like to point out that CPortLaz is multithreaded Does it work similar to AsyncPro ? In fact, IMHO, it would be desirable to have a component that _internally_ uses TThread to handle blocking ports (either using just a byte-FIDO - this is what Asy

Re: [Lazarus] TTimer woes (newbie)

On 03/31/2014 07:51 PM, Flávio Etrusco wrote: TTimer in Windows (and the basic timer support in Windows ) is implemented using window messages and you're not allowing the app to process messages inside your loop. This necessity is not limited to Windows nor to TTimer. Any Object Pascal Eve

Re: [Lazarus] TTimer woes (newbie)

On 03/31/2014 01:44 AM, Bob Axtell wrote: can someone show a newbie how to use the two system timers? What do you mean by system timers ? In a normal GUI based application you normally use TTimer for time-based actions. You easily can create as many TTimers as you like (as well "visually"

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/19/2014 01:00 PM, Martin Schreiber wrote: Maybe have a look how it is done in MSEgui with tmseevent/tobjectevent, application.postevent() and friends? IIRC you already played with them? :-) :-) :-) Yep ! I do like this stuff ! On behalf of OS and Widget-Set independent and user friendl

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/19/2014 02:04 AM, Hans-Peter Diettrich wrote: For Windows applications you should eventually know some bits about the main thread message queue. Not really, as LCL and RTL provide as well TThread.Queue and Application.QueueAsyncCall in Windows and Linux (and Mac, AFAIK). In Delphi you

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/18/2014 05:52 PM, Joao Morais wrote: I missed the "async" part, sorry. What about reuse App.QueueAsyncCall with interface? Combining the Interface idea with asynchronous signaling in fact is a nice idea. The real issue is that in many cases you need to queue not only the call but the

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/19/2014 12:53 AM, Hans-Peter Diettrich wrote: This queue may be unusable for LCL messages (dunno). It _is_ used for the said purpose, simply because the TThread class is provided by the fpc RTL (not the LCL) and here it can't do other but feed the Queue in the RTL. And this obviously wor

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/18/2014 02:13 PM, Hans-Peter Diettrich wrote: Then try to explain how e.g. a key or button press event is processed in your model. I don't have a "model". I just tried to describe what the LCL does. You can see the multiple Queues in the source code: - Queue in the fpc RTL that is fe

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote: The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. Yep. (Even though I prefer the term "Event Queue" as the queued information this is not necessarily similar to Windowish "Mess

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 10:38 PM, Sven Barth wrote: Am 17.03.2014 19:15 schrieb "Hans-Peter Diettrich" mailto:drdiettri...@aol.com>>: > > How would you handle keyboard and mouse input and painting in an application? Like any other widgetset which does know nothing about PostMessage does? AFAIK, al

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 11:22 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 05:42 PM, Marcos Douglas wrote: Could you send the sources of this test? I could if you are interested. This is a testing project I did for the development of Widget Types (with and without GUI Binding) on behalf of TThread.Synchronize, TThread.Queue, Application.QueueAsyncCal

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 04:20 PM, Michael Schnell wrote: I'm not sure if you simply can do "free;" as the last instruction before returning from the procedure. I just did a test and even this seems to work: An object seemingly can free itself and return to the caller of the function

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 04:09 PM, Michael Schnell wrote: If you meant the self pointer of AMethod, I of course am with you (as same is a "procedure of object"). But that is rather trivial, and AMethod could be a procedure of any class (inducing but not forcing the "TThread" ins

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 03:36 PM, Marcos Douglas wrote: The pointer to the Event Procedure, the self pointer of it's instance (both denoted by "AMethod") and the pointer to the parameter to have it called with (denoted by"Data" are queued and when the main thread is ready to handle the event, it calls "

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 01:31 PM, Marcos Douglas wrote: Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance) I don't understand. The definition of the function (I use) is procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent; Data: PtrInt);

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/17/2014 11:03 AM, zeljko wrote: No, I'll keep using QueueAsyncCall as it is because it satisfies my needs. I am with you, as QueueAsyncCall additionally provides queuing a parameter for the procedure to be called in the main thread. -Michael -- _

Re: [Lazarus] Console app

On 03/17/2014 11:14 AM, Mattias Gaertner wrote: Feel free to add it. It's not as impossible as I initially thought, as the fpc RTL already provides the basic Queue implantation that can be used (while all other "active" Widget Types use a queue provided by the GUI infrastructure they attach

Re: [Lazarus] Console app

On 03/17/2014 11:04 AM, Bart wrote: The NoGUI WS doesn't allow this? No. It does not provide an Event Queue for the main thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/li

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. -Michael -- __

Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall

On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) "Windowish" method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCa

Re: [Lazarus] Console app

On 03/15/2014 08:10 AM, Richard Mace wrote: Hi All, I have never written a console app and was wondering 2 things. Firstly, if I was to write an app that doesn't require a GUI, that runs on both Windows and Linux (with no XServer) is that classed as a console app? And secondly, is it fairly str

Re: [Lazarus] Checking characters in a string

On 03/12/2014 07:08 PM, silvioprog wrote: It is not hard to allow chars like "ã", "Ã", "ñ", "Ñ", "ç", "Ç", "ä", "Ä" etc. I left the function a little faster too: These beasts in UTF-8 are not "char" s (but multi-Byte codes) so your example code "c: char" ... will not work :-( . -Mic

Re: [Lazarus] Checking characters in a string

On 03/12/2014 02:53 PM, Richard Mace wrote: I am trying to check to make sure the a string contains at least 1 uppercase character, 1 lowercase character and 1 number. Any ideas as of the best way of coding this? When using Unicode (under the hood) this is really difficult, as (AFAIK) there is

Re: [Lazarus] How to access C and C++ libraries?

On 03/06/2014 08:31 PM, Chavoux Luyt wrote: Years ago I used Delphi (on Windows) to access a C or C++ API You can't access a C++ API. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailm

[Lazarus] Lazarus on Odroid

Good news from Jy V Original Message Subject:Re: fpcup first native build working Date: Thu, 20 Feb 2014 16:49:55 +0100 From: Jy V To: Reinier Olislagers , Michel Catudal , Michael Schnell , Khk , Henry Vermaak , Thomas Schatzl , Dennis Poon , Michael Van

Re: [Lazarus] Getting help for a type if its unit is not in uses

On 02/18/2014 10:40 PM, Graeme Geldenhuys wrote: Simply run: docview + or docview or docview I was trying o use Docview integrated in in the Lazarus IDE. This is fact worked rather nicely with multiple files. I seem to remember that there were some issues (AFAIR, you intended to s

Re: [Lazarus] play video and music from the web

On 02/13/2014 02:37 PM, Andrew Brunner wrote: Chrome is by far the most widely versatile. FireFox did not spring for MP3 licensing. Firefox requires streams as ogg. For Videos I do on on Websites I now use HTM5 with both mp4 and ogg. With that most browsers are happy (but not the old IE that

Re: [Lazarus] play video and music from the web

On 02/12/2014 10:36 PM, duilio foschi wrote: This requires the browser to support HTML5 (nowadays most do) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Getting help for a type if its unit is not in uses

On 02/10/2014 09:19 PM, Graeme Geldenhuys wrote: Yes, simply use DocView ... Been there. Loved it. But I never was able to generate the files for DocView from the current revisions of the SVNs. (Here, multiple files are necessary (language definition,. RTL, LCL, "Help on Help" you nam

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/07/2014 05:31 PM, Hans-Peter Diettrich wrote: Window managers do not care about widgets,,, So maybe I am confused about the term "Window Manager" (I think I did not introduce it here) -Michael -- ___ Lazarus mailing list Lazarus@lists.laza

Re: [Lazarus] kzdesktop...

On 02/07/2014 03:20 PM, William Oliveira Ferreira wrote: But it's a brazillian project... I know that its Portuguese. (I use to play keyboards in a band with a Brazilian singer) But I don't understand a word nonetheless -Michael -- ___ Lazarus maili

Re: [Lazarus] kzdesktop...

On 02/07/2014 12:51 PM, William Oliveira Ferreira wrote: KZDesktop could be followed by here... http://www.raphaelz.com.br/page/KZDesktop-Uma-interface-robusta-para-seu-Lazarus!.aspx IMHO, non-English te

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/07/2014 03:57 AM, Hans-Peter Diettrich wrote: fill their video buffer, This only sounds appropriate for pixel graphics, not for the complex stuff "widgets" create and that result in "object descriptions" that are rendered by the processor in the video adapter. -Michael --

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/06/2014 05:39 PM, Mark Morgan Lloyd wrote: OK, so assuming an OS similar to X, can a single app support two forms on different displays, and/or move forms between displays? Because if it could, one of those displays could be a local X session and the other could be something like a VNC

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/06/2014 04:17 PM, Mark Morgan Lloyd wrote: I think that the only thing remotely worth pursuing, bearing in mind the current state of widget sets etc I don't suppose this makes much sense unless the infrastructure called by the LCL supports it in a proven way. OTOH: In the other

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/06/2014 02:13 PM, Hans-Peter Diettrich wrote: When an application relies on high speed updates, it should serialize these requests itself, as required, instead of leaving this to the desktop manager and its arbitrary request scheduling. Once again, this is not about serializing "requests"

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/06/2014 01:21 PM, Reimar Grabowski wrote: So a gain for a small amount of apps but a lot of work to support the solution. Correct, but this is not the definition of not being a shortcoming. Currently there are other options but you do not want to use them. Your choice. Can't you read ? j

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/06/2014 11:54 AM, Reimar Grabowski wrote: You see that as shortcomings. Most others (even widgetset developers) see thread-safe GUIs as nonsense without real benefit, else they would be available. I think we can agreee to disagree. This is a funny opinion indeed. - we did a project in

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 07:37 PM, Reimar Grabowski wrote: OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus and fpc and do everything in ASM. And loose your job for missing deadline after deadline. ;) ... What I meant by the sarcasm is: Even if there are other ways to reach a goal,

Re: [Lazarus] Lazarus/FPC for Web Development only

On 02/05/2014 11:57 AM, Michael Schnell wrote: by an "xxx"- WidgetType / xxx = one of ExtJS, JQuery, qooxdoo or dojo (or whatever the hype is these days). :-) By this, the application programmer would be enabled to switch between the "hype of the day" java script tools b

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote: Please note that even a CPU with multiple cores doesn't have multiple data busses for the cores. That's the narrowest bottleneck, which limits the throughput on every standard machine. Right, But this is why 1st Level cache has been invented :

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 01:54 PM, Hans-Peter Diettrich wrote: Then you have to include appropriate hardware, where multiple GPUs are preferable to multiple CPUs when it comes to processing multiple video streams concurrently. In fact the system runs just fine for multiple customers right now with many dy

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 12:15 PM, Reimar Grabowski wrote: Talk to the driver directly ... OK, I could drop considering using KDE, QT, Gnome, the LCL and Lazarus and fpc and do everything in ASM. But in fact Lazarus is more fun :-) . -Michael -- ___ Lazaru

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 11:40 AM, Mark Morgan Lloyd wrote: I think a realistic question is how close can multiple threads get to a form without fouling up the LCL or widget set. Yep ! Seemingly not doable at the moment. The LCL _could_ be updated to be reentrant, but if the Widget Set it binds to does

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/05/2014 10:51 AM, Michael Van Canneyt wrote: Judging by your explanation to Dido, it seems you must explain your users the limits of their own brains. Adding monitors and indicators does not guarantee that they will process more info :) Please see the discussion on surveillance camera s

Re: [Lazarus] Lazarus/FPC for Web Development only

On 02/05/2014 08:58 AM, Michael Van Canneyt wrote: I have succesfully developed such (big) projects in Lazarus: Server side is Lazarus (more specific: fcl-web and the webdata/json-rpc modules) Client side is ExtJS - but JQuery, qooxdoo or dojo (or whatever the hype is these days) would work eq

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 03:11 PM, Michael Van Canneyt wrote: Exactly: you can perfectly collect 20 stills and display a composed view of all 20 stills, 10 times a second. Should be perfectly in reach of a single thread. Sounds correct on the first sight, but my colleagues found that this was not good eno

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 03:48 PM, Sven Barth wrote: When you call a method of a widget that results in some GUI related stuff Qt checks the current thread ID against the thread ID the QApplication was created in (or more precisely: the thread ID the event loop is running in) using an Assert. While there

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 04:20 PM, Reimar Grabowski wrote: It is not unusual to show the same frame three times to bring the framerate up to 72fps to reduce the "black screen time" which will be percieved as flickering. Motion blur helps a lot to make the experience 'smooth'. Why do you think it is recrea

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 04:02 PM, Reimar Grabowski wrote: You can talk to the GPU from different threads (with a little overhead) but you actually gain nothing, because of how the drivers work. Very wrong, IMHO. There is a lot to do for the CPU between the user programmer's code calls an Language RTL- (

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 04:02 PM, Mark Morgan Lloyd wrote: I'm afraid that's... highly questionable. The more video streams (etc.) that are visible the smoother you want the overall presentation to be: the human brain is /very/ sensitive to small timing differences. Yep. We don't do such systems, but

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 03:42 PM, Michael Van Canneyt wrote: But complicated information like statistics or information of 20 cameras, needs time to be processed by the brain in order to react on it. There is therefor no need to have it refreshed in intervals that the brain cannot discern anyway. What co

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 03:19 PM, Mark Morgan Lloyd wrote: I'm not unreservedly siding with MichaelS's position, since unless it completely bypassed any existing widget set (and preferably drew directly to the framebuffer) it could be screwed at any time by off-project developers (i.e. the Gnome, Qt or W

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 07:10 PM, Hans-Peter Diettrich wrote: Right, nobody tries to support threads in GUI related libraries, because this doesn't make sense. IMHO it does make sense in certain applications. The one my colleagues did is a "user interfaces application" for a huge (including many PCs

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 02:40 PM, Michael Van Canneyt wrote: I play a video at full HD, 1 thread handles the screen display. It works just fine, Playing two videos at the same time does make sense in some applications (we "create" 20 small "videos" in our application to have the user see what the syste

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 01:39 PM, Sven Barth wrote: Upon creation of the QApplication class it remembers the thread ID and every GUI widget is checked that it is owned by this thread ID as well. Certain events like rendering are also checked for the thread ID. While I don't exactly see the point (as eac

Re: [Lazarus] BSD Magazine Pascal quote

On 02/04/2014 11:57 AM, Hans-Peter Diettrich wrote: I've just visited the German Wikipedia page for Pascal, and found it in questionable state, too. +1 -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote: Right, and the restriction to one widgetset resides in the Lazarus widgetset handling. I do know. But it does not make much sense to be nagging towards the powers here about LCL not being reentrant, if the library (Widget Set, ...) it bind

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 11:36 AM, Mark Morgan Lloyd wrote: At that point why not bite the bullet and exploit GPU parallelism? Yep ! :-) (And this hint is going out to whom ? ;-) ) KDE and Qt are minor issues, far more significant is arbitrary restrictions that GTK imposes because they envisage some us

Re: [Lazarus] Threads and Libraries (dll and so)

BTW.: What we did to take advantage of the multicore architecture in fact was creating multiple applications, each of which handles such a GUI element in a dedicated Window that is automatically placed at the appropriate location "above" the main window. But of course the overhead for managin

Re: [Lazarus] Threads and Libraries (dll and so)

On 02/04/2014 11:12 AM, Michael Van Canneyt wrote: It kind of defeats the purpose, as it suggests that only 1 thread at a time can access the display. Of course concentrating the GUI stuff to a single thread makes things a lot easier to handle. But I already did explain the purpose I (once) ha

Re: [Lazarus] Threads and Libraries (dll and so)

I stumbled over this: http://tronche.com/gui/x/xlib/display/XInitThreads.html So Xlib is thread aware and they seem to suggest that it dopes make sense to create multiple X sessions (i.e. one per thread) in a single program. (And I learned that in fact XInitThreads() can be called in Lazarus

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/20/2014 11:01 AM, Michael Van Canneyt wrote: http://qt-project.org/doc/qt-4.8/threads-starting.html "Note that QCoreApplication::exec() must always be called from the main thread (the thread that executes main()), not from a QThread. In GUI applications, the main thread is also cal

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/20/2014 11:10 AM, Sven Barth wrote: Trust me, I'm currently working with Qt's internals as I've just finished the port of Qt to my company's OS, so I know what I'm talking about... (and I've already hit an assertion regarding this) I see. In fact I already came across applications

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/17/2014 06:25 PM, Sven Barth wrote: Wouldn't help much, because e.g. Qt does not allow usage of GUI widgets in multiple threads. http://qt-project.org/doc/qt-4.8/threads.html I did not thoroughly read this but it seems that QT is thread-aware -Michael -- ___

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/17/2014 05:47 PM, Marcos Douglas wrote: I said: IMHO, not only "programmers around the world"... so, for me is not a "received wisdom", but a lesson learned. ;-) Unfortunately Lazarus uses global variables in the LCL. Otherwise it would be possible to create a project with a TApplication i

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/17/2014 03:06 PM, Marcos Douglas wrote: But why do you need a global var in the DLL? IMHO (and for many programmers around the world), global var is not good, even in the application code. I don't suppose I'll ever want to do this. :-) - I just was being nosy. -Michael -- __

Re: [Lazarus] Threads and Libraries (dll and so)

On 01/17/2014 01:25 PM, Marcos Douglas wrote: is better not use global variables in the DLL. Of course I agree. A reason for using global variables in a DLL might be to access that value as well in the DLL as in the main program. Is this even possible ? (To allow for this loading the DLL wo

<    1   2   3   4   5   6   7   8   9   10   >