On 2013-09-18 09:20, Michael Van Canneyt wrote:
>
> The fptimer unit implements a timer with a thread, but this forces the use of
> threads on your application
The way I like it! ;-) Especially considering how thread friendly these
[common place] multi-core CPU's are these days.
Regards,
- G
On Wed, Sep 18, 2013 at 03:57:36PM +0200, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals
> > > > on that behalf. We might want to steal some ideas there.
> > >
> > > While there is sigalarm, but can yo
On 09/18/2013 05:03 PM, Sven Barth wrote:
TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So
that's definitely not "very early".
OK, at least four years ;-) .
I have "Turbo Delphi". Here it is implemented but not to be found in the
help.
-Michael
_
In our previous episode, Sven Barth said:
> > forced to "by hand" use Windows messages to schedule asynchronous Main
> > Thread events.
>
> TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So
> that's definitely not "very early".
D2006 afaik.
__
On 18.09.2013 13:33, Michael Schnell wrote:
On 09/18/2013 01:19 PM, Mattias Gaertner wrote:
Some users asked about messages from/to other applications for nogui
LCL applications on Windows.
OK.
In fact to me it has been a completely silly concept of Borland's that
in early Delphi versions TTh
In our previous episode, Henry Vermaak said:
> > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that
> > > behalf. We might want to steal some ideas there.
> >
> > While there is sigalarm, but can you have multiple independent timers in an
> > application that way?
>
> I thi
On Wed, 18 Sep 2013, Michael Schnell wrote:
On 09/18/2013 01:26 PM, Marco van de Voort wrote:
While there is sigalarm, but can you have multiple independent timers in an
application that way?
I don't know. We would need to ask mse.
mse inverts the problem.
The timer implementation relies
On Wed, Sep 18, 2013 at 01:26:46PM +0200, Marco van de Voort wrote:
> In our previous episode, Michael Schnell said:
> > > The fptimer unit implements a timer with a thread, but this forces the
> > > use of threads on your application which is not always desirable.
> >
> > Should be doable, as we
On 09/18/2013 01:26 PM, Marco van de Voort wrote:
While there is sigalarm, but can you have multiple independent timers
in an application that way?
I don't know. We would need to ask mse.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepasc
On 09/18/2013 01:19 PM, Mattias Gaertner wrote:
Some users asked about messages from/to other applications for nogui
LCL applications on Windows.
OK.
In fact to me it has been a completely silly concept of Borland's that
in early Delphi versions TThread.Queue was not documented (or in very
e
In our previous episode, Michael Schnell said:
> > The fptimer unit implements a timer with a thread, but this forces the
> > use of threads on your application which is not always desirable.
>
> Should be doable, as well. AFAIK, mse (for Linux) uses signals on that
> behalf. We might want to st
On Wed, 18 Sep 2013 10:55:34 +0200
Michael Schnell wrote:
> On 09/18/2013 10:38 AM, Mattias Gaertner wrote:
> > On Wed, 18 Sep 2013 10:25:43 +0200
> > Michael Schnell wrote:
> >
> >> What non-GUI events - additionally to the events I mentioned - would be
> >> needed for "the whole event system
On 09/18/2013 12:05 PM, Luca Olivetti wrote:
Perhaps if you spent your time actually using fpc instead of hunting
for non-problems ...
As already pointed out, I have no intention to do a Project of such kind
myself. I am just trying to construct a toolbox to help my colleagues to
port their D
Al 18/09/13 09:32, En/na Michael Schnell ha escrit:
> It is really frustrating to see, that this now seems to solves the issue
> I am hunting for since some five years.
Perhaps if you spent your time actually using fpc instead of hunting for
non-problems you'd have realized that this worked five
On 09/18/2013 10:38 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell wrote:
What non-GUI events - additionally to the events I mentioned - would be
needed for "the whole event system of the LCL" ?
For example PostMessage can send messages to other applications
On Wed, 18 Sep 2013 10:25:43 +0200
Michael Schnell wrote:
> On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
> > On Wed, 18 Sep 2013 09:32:54 +0200
> > Michael Schnell wrote:
> >
> >> [...]
> >> Instead I was told that I should look at the LCL
> >> source code and that "in Windows, the Event qu
On 09/18/2013 10:20 AM, Michael Van Canneyt wrote:
The fptimer unit implements a timer with a thread, but this forces the
use of threads on your application which is not always desirable.
Should be doable, as well. AFAIK, mse (for Linux) uses signals on that
behalf. We might want to steal so
On 09/18/2013 10:09 AM, Sven Barth wrote:
I would not use Sleep as you need to be able to cancel the timer
A decent point ...
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 09/18/2013 10:05 AM, Mattias Gaertner wrote:
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell wrote:
[...]
Instead I was told that I should look at the LCL
source code and that "in Windows, the Event queuing mechanism is done by
Windows itself and in Linux it is done by a queue in the
On Wed, 18 Sep 2013, Sven Barth wrote:
On 18.09.2013 09:32, Michael Schnell wrote:
- TTimer is implemented including defining the timeout constant for
calls to CheckSynchronize() as the greatest common denominator of the
"Time" property of all enabled TTimer instances in the project (i.e. a
On 18.09.2013 10:00, Michael Schnell wrote:
On 09/18/2013 09:53 AM, Sven Barth wrote:
I wouldn't use the timeout constant for this. If you have two timers
of which the greatest common denominator is 1, but nevertheless rather
large (e.g. two primes) then you'd loop unnecessarily (I know this is
On Wed, 18 Sep 2013 09:32:54 +0200
Michael Schnell wrote:
>[...]
> It is really frustrating to see, that this now seems to solves the issue
> I am hunting for since some five years.
Has it ever come to your mind that "hunting" might not be sufficient to
create code?
> Over the time, there had
On 09/18/2013 09:53 AM, Sven Barth wrote:
I wouldn't use the timeout constant for this. If you have two timers
of which the greatest common denominator is 1, but nevertheless rather
large (e.g. two primes) then you'd loop unnecessarily (I know this is
a constructed example, but nevertheless o
On 18.09.2013 09:32, Michael Schnell wrote:
- TTimer is implemented including defining the timeout constant for
calls to CheckSynchronize() as the greatest common denominator of the
"Time" property of all enabled TTimer instances in the project (i.e. a
simple timer that accumulates delays impos
Conclusion:
Thus we could draft a "living noGUI" TCustomApplication sibling (aka
"LCL WidgetType"), that allows for firing MainThread Events triggered
from (a newly implemented) TTimer, TThread.Queue(),
TThread.Synchronize(), TApplication.QueueAsyncCall() and the legacy
windowish PostMessage(
Thanks for the clear information.
Enhanced by the knowledge about TThread.queue It will allow me to do
some nice tricks.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 09/16/2013 02:01 PM, Sven Barth wrote:
( http://www.freepascal.org/docs-html/rtl/classes/wakemainthread.html ).
IIRC, TThread.Queue does this, as well.
Thus updating this page might be appropriate...
Thanks,
-Michael
___
fpc-pascal maillist -
On 09/16/2013 02:01 PM, Sven Barth wrote:
WakeMainThread
Thanks for the pointer.
I'll take another look there.
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 09/16/2013 02:03 PM, Sven Barth wrote:
CheckSynchronize has a timeout parameter:
http://www.freepascal.org/docs-html/rtl/classes/checksynchronize.html
Great !
Maybe the docs should be updated and mention TThread.Queue, which for me
is most important, as it - finally - allows for decent pa
Am 16.09.2013 13:38, schrieb Michael Schnell:
there is no LCL dependence in theory, but other eventloop systems
might assume they themselves implement the blocking part. (e.g. to
wake up because of OS messages) Services, console network server
implementations etc probably already do that both o
Am 16.09.2013 13:22, schrieb Marco van de Voort:
Did I understand you correctly that there is a "notifying" procedure,
that is called by the Event queuing mechanism each time an event is
pushed onto the queue ?
That was not me, but Sven or sb else. But as I understood it, the queue
method does t
Am 16.09.2013 10:58, schrieb Michael Schnell:
On 09/13/2013 07:08 PM, Sven Barth wrote:
As we have already written in some previous mails to there is a
global event procedure to wake up the main thread that is triggered
when something is queued. The LCL uses this already and other
programs c
On 09/16/2013 01:22 PM, Marco van de Voort wrote:
The non-LCL one must simply call checksynchronize as the blocking part
of the mainthread's eventloop.
Thus, my wish already seems to be fulfilled.
Great !
there is no LCL dependence in theory, but other eventloop systems
might assume they them
In our previous episode, Michael Schnell said:
> OK, so "checksynchronize()" is the correct name of the RTL-provided
> function that pulls the event queue. (Sorry that the correct name
> escaped from my silly brain.)
Yes, it is the connection between VCL and RTL for this kind of stuff.
> AFAIU
On 09/16/2013 11:14 AM, Marco van de Voort wrote:
If you mean integrate with your own eventloop, then yes, make sure
that your idle event in your eventloop calls checksyncrhonize
OK, so "checksynchronize()" is the correct name of the RTL-provided
function that pulls the event queue. (Sorry tha
In our previous episode, Michael Schnell said:
> > As we have already written in some previous mails to there is a global
> > event procedure to wake up the main thread that is triggered when
> > something is queued. The LCL uses this already and other programs
> > could use a TEvent or whatever
On 09/13/2013 07:08 PM, Sven Barth wrote:
As we have already written in some previous mails to there is a global
event procedure to wake up the main thread that is triggered when
something is queued. The LCL uses this already and other programs
could use a TEvent or whatever.
Could you el
Am 13.09.2013 10:47 schrieb "Michael Schnell" :
>
> On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote:
>>
>> would this hamper or cause problems with normal non-gui programs using
the library?
>
>
> 1) This feature of course should only be provided additionally to the
functions we know and love
On 09/13/2013 06:06 AM, wkitt...@windstream.net wrote:
would this hamper or cause problems with normal non-gui programs using
the library?
1) This feature of course should only be provided additionally to the
functions we know and love.
2) Other than the work-alike "Application.QueueAsyncCal
On Thursday, September 12, 2013 7:14 AM, Michael Schnell
wrote:
> On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
> >
> > I've concluded that using a thread is, in fact, preferable
> True.
>
> It's a pity that Synapse and friend (especially SynaSer) does does not
> implement internal th
On 09/12/2013 02:45 PM, Marco van de Voort wrote:
E.g. TComport only starts an helper thread if you register receive
events. If you do not, you can use it in a select/waitformultiple like
way in a thread.
Sounds good.
I'm going to test this ASAP.
-Michael
_
In our previous episode, Michael Schnell said:
> > The very reason I use Synapse is that it DOES NOT use threads.
> > Synapse is simple to use. Keep it so.
>
> Of course I don't vote for Synapse always using threads, but to provide
> _additional_ functions / objects (maybe units) that work simil
On 09/12/2013 02:36 PM, Mark Morgan Lloyd wrote:
Although for certain types of usage being able to get directly to the
hardware (or strictly, to the lowest level the OS supports for normal
users) is absolutely essential, e.g. if timing information has to be
appended to each character or if re
On 09/12/2013 01:28 PM, Michael Van Canneyt wrote:
The very reason I use Synapse is that it DOES NOT use threads.
Synapse is simple to use. Keep it so.
Of course I don't vote for Synapse always using threads, but to provide
_additional_ functions / objects (maybe units) that work similar to
In our previous episode, Mark Morgan Lloyd said:
> > common request, and since the fpc-Team some time ago enabled
> > TThread.Queue in the RTL, this is doable in a straight forward,
> > "fpc-ish" way (portable but Delphi compatible).
>
> Although for certain types of usage being able to get dire
Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when s
On Thu, 12 Sep 2013, Michael Schnell wrote:
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in
On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote:
I've concluded that using a thread is, in fact, preferable
True.
It's a pity that Synapse and friend (especially SynaSer) does does not
implement internal threads that throw appropriate events in the Main
Thread when something comes in (or an
Mark Morgan Lloyd wrote:
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's
telnet client running in the program so would rather stick to the
same library if possible.
AFAIK, Lnet does not do threading int
Mark Morgan Lloyd wrote:
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait
for a connection on a predefined port, read as much data as is
available, repeat? And if so, what does the SerSock parameter to
Accept() represent?
I'd normally use a thread for this, but I've al
Michael Schnell wrote:
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro
On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote:
I'd normally use a thread for this, but I've already got lnet's telnet
client running in the program so would rather stick to the same
library if possible.
AFAIK, Lnet does not do threading internally (as does AsyncPro or -
partly - Indy), so
On 04/02/12 14:14, Bernd wrote:
2012/2/4 Bernd:
You need a robust way to determine how long your
protocol message is, at which byte exactly it ends and the next
message begins.
The simplest way would probably be if you prepend all your messages
with a length field and a checksum field to be sen
2012/2/4 Bernd :
> You need a robust way to determine how long your
> protocol message is, at which byte exactly it ends and the next
> message begins.
The simplest way would probably be if you prepend all your messages
with a length field and a checksum field to be sent as the very first
bytes of
2012/2/1 Malcolm Poole :
> Before I set out to implement the procedures to do this myself, can someone
> reassure me that this needs to be done and that I am not re-inventing the
> wheel?
The TCP protocol will transparently split the data into the packets of
needed size without user intervention,
On Thu, 7 Oct 2010 16:00:31 -0700 Brian Winfrey wrote:
> Here are the modifications I made in exploring this issue:
It works on:
-
% uname -a
FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r213198M: Mon Sep 27
15:43:54 MSD 2010 b...@host.ipt.ru:/usr/obj/usr/src/sys/HOST i386
---
I don't know if you noticed, but it appears that code has some
depracated properties that should be changed.
Here are the modifications I made in exploring this issue:
program GetPrimaryIpAddress;
{$mode objfpc}
uses
baseunix,
unixtype,
sockets,
SysUtils;
procedure Get(out AddrOut: stri
t := '';
>> >>> {$IFDEF UNIX}
>> >>> VStrTemp := TStringList.Create;
>> >>> VProcess := TProcess.Create(nil);
>> >>> try
>> >>> VProcess.CommandLine :=
>> >>> '
t; >>>try
> >>> VProcess.CommandLine :=
> >>> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
> >>
> >> Yuck. This doesn't work on my system (debian). If you really want
inet end/ {print $3}''"';
>>
>> Yuck. This doesn't work on my system (debian). If you really want the
>> least effort, you may have more luck with simply parsing `hostname -I`
>> somehow. The right way to do this is with an ioctl, I believe
>>
I am developing for an embedded system and found out that 'nmap --iflist'
does a faily good job of this if the output is examined and parsed properly.
If it is suitable and you can possibly extract the code (if you are prepared
to go that far) it might help you. It is also cross platform
On 7 Octo
2010/10/7 Luca Olivetti
>
> I didn't try it, but I see that it tries to connect to google's dns server,
> so it'd fail miserably if the computer has no internet access.
>
> Bye
> --
> Luca
>
I tested, without web access does not work. :o
--
Silvio Clécio,
*programmer* *ObjectPascal*
__
En/na Marco van de Voort ha escrit:
In our previous episode, Brian Winfrey said:
I found an example for linux on stack overflow that was in c
http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
Compiles on FreeBSD and the result looks sane (but on a system
Wow, worked perfectely in Ubuntu-10.04, Mandriva-2010 and openSUSE-11.2.
Thanks for the exelent solutions. :)
2010/10/7 Brian Winfrey
>
> I found an example for linux on stack overflow that was in c
>
> http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
>
> -
In our previous episode, Brian Winfrey said:
> I found an example for linux on stack overflow that was in c
> http://stackoverflow.com/questions/212528/linux-c-get-the-ip-address-of-local-computer
Compiles on FreeBSD and the result looks sane (but on a system that has a
routable address)
_
necessary permissions. That is
>>> the main security risk and it is solved by this approach. The fact
>>> that another process running under your login not using O_EXCL
>>> could overwrite it is not an extra security risk (if you have a
>>> rogue process running und
On 06/10/10 14:27, Felipe Monteiro de Carvalho wrote:
Ok, thanks everyone, it seams that I managed to extract a function
from Silvio's code which doesn't use Synapse. I only tested in Windows
so far:
unit chesstcputils;
{$mode objfpc}{$H+}
interface
uses
{$IFDEF MSWINDOWS}
Winsock,
{
In our previous episode, Felipe Monteiro de Carvalho said:
> function ChessGetLocalIP(): string;
> VProcess.CommandLine :=
> 'sh -c "ifconfig eth0 | awk ''/inet end/ {print $3}''"';
Fails if eth0 is not the primary NIC. Doesn't work on non-linux (that use
other ethernet naming
On Wed, Oct 6, 2010 at 7:55 AM, Sven Barth wrote:
> You'll only find "127.0.0.1" for my computer there... I don't think that
> this is a very good solution.
Oh well. That makes sense b/c these are servers that I have obtaining
the same IP over DHCP.
On clients when DHCP is being used with dynami
Ok, thanks everyone, it seams that I managed to extract a function
from Silvio's code which doesn't use Synapse. I only tested in Windows
so far:
unit chesstcputils;
{$mode objfpc}{$H+}
interface
uses
{$IFDEF MSWINDOWS}
Winsock,
{$ENDIF}
Classes, SysUtils;
function ChessGetLocalIP(): s
Am 06.10.2010 14:49, schrieb Andrew Brunner:
I just read the first line in /etc/hosts file. The first entry is the IPv4.
On Tue, Oct 5, 2010 at 3:04 PM, Felipe Monteiro de Carvalho
wrote:
hello,
I am searching for a way to get the local IP. I already found examples
with winsock, synapse and
I just read the first line in /etc/hosts file. The first entry is the IPv4.
On Tue, Oct 5, 2010 at 3:04 PM, Felipe Monteiro de Carvalho
wrote:
> hello,
>
> I am searching for a way to get the local IP. I already found examples
> with winsock, synapse and indy. Does anyone know how to do that wit
Hello,
Actually it uses both synapse (under unix) and winsock (under Windows).
What should one put in the parameter AHTTPSend: THTTPSend ? Where is
this type declared?
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists
Local IP without winsock, synapse, indy or lnet:
http://code.google.com/p/lazsolutions/source/browse/trunk/Core/LSHTTPSend.pas#127
2010/10/5 Felipe Monteiro de Carvalho
> hello,
>
> I am searching for a way to get the local IP. I already found examples
> with winsock, synapse and indy. Does anyo
Am Freitag 11 Juni 2010, 18:50:56 schrieb Felipe Monteiro de Carvalho:
> And from my tests Get is indeed returning the amount read. I still
> don't know if half a packet could be received in the OnReceive event
> or if it only returns an integer amount of packets. That makes
> difference in the al
I sent a direct main to Almindor and he answered my questions.
Basically there is no direct way to detect the barrier between
packages, you have to make your packet structure allow for that, but
luckly mine was already prepared for this.
And from my tests Get is indeed returning the amount read.
On Mon, 2010-06-07 at 14:15 +0200, Felipe Monteiro de Carvalho wrote:
> Ok, thanks, now I seam to be able to get it working using
> TLTCPComponent, but I am unsure about how to read data.
>
> Ok, I read that it will call OnReceive when there is data ready, but I
> couldn't find anything about how
Ok, thanks, now I seam to be able to get it working using
TLTCPComponent, but I am unsure about how to read data.
Ok, I read that it will call OnReceive when there is data ready, but I
couldn't find anything about how much data is waiting to be read?
I would like to get each single Packet which i
On Mon, Jun 7, 2010 at 10:41 AM, Graeme Geldenhuys
wrote:
> I don't use Lnet, so don't know if it already has two packages
> (run-time and design-time) defined.
It already has two packages, but the wiki page is geared towards the
design-time one.
--
Felipe Monteiro de Carvalho
_
On Mon, 7 Jun 2010, Felipe Monteiro de Carvalho wrote:
Hello,
I am trying to use lNet and I have some questions.
1> Can I use TLTcp or do I need to use the "visual" version, TLTcpComponent?
2> Can I use only the base package or do I need to use the "visual" one?
Basically I am not a big fa
On 07/06/2010, Felipe Monteiro de Carvalho wrote:
>
> 1> Can I use TLTcp or do I need to use the "visual" version, TLTcpComponent?
>
> 2> Can I use only the base package or do I need to use the "visual" one?
>
> Basically I am not a big fan of design time packages, I prefer to add
> the units and c
You do not need to use Lazarus at all in order to develop with LNet.
You do however need the runtime package in order to work with it if you want
to use the TLTCPComponent, however if you do not want to use it, you simply
need to tell the compiler where to find LNet, and use the normal classes.
82 matches
Mail list logo
