[fpc-pascal] Common class type
Hi. Is there method in fpc to find the highest common class-type of two derived classes? Regards, Torsten Bonde Christiansen. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Coyo Stormcaller wrote: On 03/19/2015 04:25 AM, Mark Morgan Lloyd wrote: While it is possible to write a complete stack from scratch in any reasonably-complete programming language, and while this has been done for e.g. embedded systems (or by idiots such as myself for demonstration/testing purposes :-), in practice it's avoided on account of (a) the amount of well-tested code that it would attempt to supplant and (b) consideration of the difficulty of implementing all required services in a single program. My interest in Userspace TCP/IP stacks is mostly due to being able to make dramatic modifications to the stack itself without modifying the kernelmode stack, and the ability to route without touching system calls to the socket system. With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP port. I'm developing a version of TCP/IP that uses 512-bit DHT hashes as addresses. When a packet is being routed to an unfamiliar destination IP, it uses Kademlia routing to reach the destination. The host itself has an internal router. All stacks in IPvCoyo have IP routing enabled. Only the first connection is routed in this inefficient way. Along the way, a bidirectional label-switching tunnel is constructed. Subsequent packets are switched rapidly. This is efficient enough that no hardware acceleration is needed. This system is based on CJDNS, but rather than stopping at an IPv6 address, it goes further, altering TCP/IP itself to have full 512-bit DHT hashes as endpoint identifiers. Obviously, applications need to support the socket system. That's where a userspace TCP/IP stack comes in. Applications can use pipes to send and receive traffic to another userspace application (the stack), or preferably, link to it as a dynamically-linked library and send and receive calls to that library. Maybe, if people like the system enough, it can be ported to hardware-accelerated kernelmode code. But for now, modifying a userspace TCP/IP stack seems like the most reasonable approach. If you're wondering why I want to re-design TCP/IP it's because of a dare. I won't lose! Interesting. I've seen at least one complete stack written in Pascal, although I can't remember what it was using as the low-level device: back in the DOS days when such things were common they'd usually have used Packet Driver. My partial implementations (embedded in test routines in a comms program) were on top of SLIP and PPP, my suggestion would be to start off with a simple conventional stack on top of SLIP and to test it against slirp running on Linux. IP etc. are basically fairly simple protocols. The complexity comes from all the options that can be applied at the IP level, and the RFCs that are piled on top of it. The real risk here, even for a research project, is the number of potential buffer overflows that you have to watch out for. It's tempting and comparatively simple to handle incoming messages using either pattern matching or overlaid records, but I think a more robust approach is to use state machines (Pascal doesn't, unfortunately, support coroutines). Things like unix kernels typically pass around messages as pointers, I'd avoid that and use bounds-checked arrays even if that meant that CPU time was wasted copying data around. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mode Delphi and functions as parameters.
On 03/18/2015 03:49 PM, vfclists . wrote: Is passing a function as parameter without the '@' symbol accepted in Delphi? Yep. And to me it looks "nicer than using "@", even though it is obviously sloppy syntax and introduces an ambiguity (what to to if a function has no parameter and returns a value that is a pointer to a function of exactly this type ?) ;-) . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On 03/18/2015 05:36 PM, Tony Whyman wrote: TDataEvent = procedure (Data: PtrInt) of object; To me PtrUInt seems more appropriate. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
On 03/20/2015 12:18 AM, Coyo Stormcaller wrote: With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP port. In fact colleagues of mine once in Delphi implemented a TCP - like solution that uses UDP transfer to do secure, especially low overhead transfers via GPRS. So I understand that such User-space IP stack extensions might make sense in certain cases. But a User-Space "TCP/IP-Stack" implementation that sits on naked Ethernet does not seem to make any practical sense. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Michael Schnell wrote: On 03/20/2015 12:18 AM, Coyo Stormcaller wrote: With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP port. In fact colleagues of mine once in Delphi implemented a TCP - like solution that uses UDP transfer to do secure, especially low overhead transfers via GPRS. So I understand that such User-space IP stack extensions might make sense in certain cases. But a User-Space "TCP/IP-Stack" implementation that sits on naked Ethernet does not seem to make any practical sense. It does if the objective is to experiment with variant protocols. Also remember that things like nmap already reimplement some parts of IP, so there's strong precedent. I don't know what language implementation would be best for the job. The problem is that it's convenient to be able to overlay e.g. an IP packet with a predefined type e.g. a record describing the header followed by an array encompassing the data, however the actual length of the data is unknown at compilation time which means that hardware-supported bounds checking is less than useful. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
Where is the 'write' function defined and how is it different from 'writeln'? I can see a lot of fpc_writeXXX and other Write functions, but no 'write' itself -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
> Where is the 'write' function defined and how is it different from
'writeln'?
>
> I can see a lot of fpc_writeXXX and other Write functions, but no
> 'write' itself
those fpc_writeXXX ARE the actual write. Write(Ln) is NOT a function as like
others whose implementation you can clearly see. It's rather a command for
the compiler to translate to the correct fpc_writeXXX call. So, if you:
WriteLn(123,' is an integer');
the compiler will translate it to:
fpc_write_text_shortint(123);
fpc_write_text_shortstring('is an integer');
fpc_writeln_end;
The same case applies to Read(Ln). AFAIK Pascal's I/O is part of the
language, not the RTL.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Where-is-the-write-function-defined-and-how-is-it-different-from-writeln-tp5721427p5721428.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
On 20 March 2015 at 18:01, leledumbo wrote:
> > Where is the 'write' function defined and how is it different from
> 'writeln'?
> >
> > I can see a lot of fpc_writeXXX and other Write functions, but no
> > 'write' itself
>
> those fpc_writeXXX ARE the actual write. Write(Ln) is NOT a function as
> like
> others whose implementation you can clearly see. It's rather a command for
> the compiler to translate to the correct fpc_writeXXX call. So, if you:
>
> WriteLn(123,' is an integer');
>
> the compiler will translate it to:
>
> fpc_write_text_shortint(123);
> fpc_write_text_shortstring('is an integer');
> fpc_writeln_end;
>
> The same case applies to Read(Ln). AFAIK Pascal's I/O is part of the
> language, not the RTL.
>
>
>
Where does the output go? Is it for stdout, strderr or the console?
--
Frank Church
===
http://devblog.brahmancreations.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
Am 20.03.2015 19:19 schrieb "vfclists ." :
>
>
>
> On 20 March 2015 at 18:01, leledumbo wrote:
>>
>> > Where is the 'write' function defined and how is it different from
>> 'writeln'?
>> >
>> > I can see a lot of fpc_writeXXX and other Write functions, but no
>> > 'write' itself
>>
>> those fpc_writeXXX ARE the actual write. Write(Ln) is NOT a function as
like
>> others whose implementation you can clearly see. It's rather a command
for
>> the compiler to translate to the correct fpc_writeXXX call. So, if you:
>>
>> WriteLn(123,' is an integer');
>>
>> the compiler will translate it to:
>>
>> fpc_write_text_shortint(123);
>> fpc_write_text_shortstring('is an integer');
>> fpc_writeln_end;
>>
>> The same case applies to Read(Ln). AFAIK Pascal's I/O is part of the
>> language, not the RTL.
>>
>>
>
> Where does the output go? Is it for stdout, strderr or the console?
It depends.
Write('foobar');
Will write to whatever Textfile is contained in Output and
Write(xyz, 'foobar');
Will write to the xyz Textfile. And these Textfiles can basically be
anything. By default Output simply writes to StdOut (there's also a
variable for StdErr, but I have forgotten how it's called...), but you
could also use an implementation that writes to a TStream or one which uses
sockets. It's quite flexible...
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
On 20 March 2015 at 19:34, Sven Barth wrote:
> Am 20.03.2015 19:19 schrieb "vfclists ." :
>
> >
> >
> >
> > On 20 March 2015 at 18:01, leledumbo wrote:
> >>
> >> > Where is the 'write' function defined and how is it different from
> >> 'writeln'?
> >> >
> >> > I can see a lot of fpc_writeXXX and other Write functions, but no
> >> > 'write' itself
> >>
> >> those fpc_writeXXX ARE the actual write. Write(Ln) is NOT a function as
> like
> >> others whose implementation you can clearly see. It's rather a command
> for
> >> the compiler to translate to the correct fpc_writeXXX call. So, if you:
> >>
> >> WriteLn(123,' is an integer');
> >>
> >> the compiler will translate it to:
> >>
> >> fpc_write_text_shortint(123);
> >> fpc_write_text_shortstring('is an integer');
> >> fpc_writeln_end;
> >>
> >> The same case applies to Read(Ln). AFAIK Pascal's I/O is part of the
> >> language, not the RTL.
> >>
> >>
> >
> > Where does the output go? Is it for stdout, strderr or the console?
>
> It depends.
>
> Write('foobar');
>
> Will write to whatever Textfile is contained in Output and
>
> Write(xyz, 'foobar');
>
> Will write to the xyz Textfile. And these Textfiles can basically be
> anything. By default Output simply writes to StdOut (there's also a
> variable for StdErr, but I have forgotten how it's called...), but you
> could also use an implementation that writes to a TStream or one which uses
> sockets. It's quite flexible...
>
> Regards,
> Sven
>
> How do you ensure own implementation overrides the system's
implementation, does the compiler take care of that automatically, or will
you have to name your function differently?
--
Frank Church
===
http://devblog.brahmancreations.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Where is the 'write' function defined and how is it different from 'writeln'?
On 20.03.2015 21:18, vfclists . wrote:
On 20 March 2015 at 19:34, Sven Barth mailto:pascaldra...@googlemail.com>> wrote:
Am 20.03.2015 19:19 schrieb "vfclists ." mailto:vfcli...@gmail.com>>:
>
>
>
> On 20 March 2015 at 18:01, leledumbo mailto:leledumbo_c...@yahoo.co.id>> wrote:
>>
>> > Where is the 'write' function defined and how is it different
from
>> 'writeln'?
>> >
>> > I can see a lot of fpc_writeXXX and other Write functions,
but no
>> > 'write' itself
>>
>> those fpc_writeXXX ARE the actual write. Write(Ln) is NOT a
function as like
>> others whose implementation you can clearly see. It's rather a
command for
>> the compiler to translate to the correct fpc_writeXXX call. So,
if you:
>>
>> WriteLn(123,' is an integer');
>>
>> the compiler will translate it to:
>>
>> fpc_write_text_shortint(123);
>> fpc_write_text_shortstring('is an integer');
>> fpc_writeln_end;
>>
>> The same case applies to Read(Ln). AFAIK Pascal's I/O is part of the
>> language, not the RTL.
>>
>>
>
> Where does the output go? Is it for stdout, strderr or the console?
It depends.
Write('foobar');
Will write to whatever Textfile is contained in Output and
Write(xyz, 'foobar');
Will write to the xyz Textfile. And these Textfiles can basically be
anything. By default Output simply writes to StdOut (there's also a
variable for StdErr, but I have forgotten how it's called...), but
you could also use an implementation that writes to a TStream or one
which uses sockets. It's quite flexible...
Regards,
Sven
How do you ensure own implementation overrides the system's
implementation, does the compiler take care of that automatically, or
will you have to name your function differently?
There is no need to ensure that. Here is an example:
=== code begin ===
var
f, oldout: TextFile;
begin
Writeln('Hello Output as StdOut');
oldout := Output;
Assign(Output, 'test.txt');
Rewrite(Output);
Writeln('Hello Output as file');
Close(f);
Output := oldout;
Writeln('Hello Output as StdOut again');
end.
=== code end ===
To see how such a TextFile is implemented you can take a look at unit
StreamIO which is part of FPC's units.
(Though I wonder why "Assign(f, 'test.txt'); Output := f; Writeln('Hello
Output as file');" does not work :/ )
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Portable coroutines
Efficient implementation of coroutines requires CPU-specific code in the RTL and possibly the compiler. However http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html suggests a way that coroutines can be implemented in a portable fashion in C, how can this be done in Object Pascal? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common class type
On 20/03/2015 07:25, Torsten Bonde Christiansen wrote: Hi. Is there method in fpc to find the highest common class-type of two derived classes? I do not know of such a routine, though there may well be one somewhere. I would have said that the highest common class would always be TObject, because a descendent class is usually spoken of as 'lower' rather than 'higher' than its ancestor. I think the following does the job (perhaps rather inefficiently). function LowestCommonClass(class1, class2: TClass): TClass; var sl: TStringList; cp: TClass; function FoundClassInList(aClass: TClass; out aCommonClass: TClass): boolean; var i: integer; s: string; begin Result:=False; aCommonClass:=nil; s:=aClass.ClassName; for i:=0 to sl.Count-1 do if SameText(sl[i], s) then begin aCommonClass:=TClass(sl.Objects[i]); Exit(True); end; end; begin Result:=nil; sl:=TStringList.Create; try sl.AddObject(class1.ClassName, TObject(class1)); cp:=class1.ClassParent; while (cp <> nil) do begin sl.AddObject(cp.ClassName, TObject(cp)); cp:=cp.ClassParent; end; cp:=class2; while (cp <> nil) do begin if FoundClassInList(cp, Result) then Exit; cp:=cp.ClassParent; end; finally sl.Free; end; end; --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fpHttpClient and Https support ?
Hello. First of all, congratulation for fpHttpClient.pas. It works directly, like charms, without to install any dependencies. => wow. I am able to do internet audio streaming with it, perfect. ;-) Hum, while trying to access Https sites, i get errors. ;-( In begin of fpHttpClient.pas, there is => > Todo: > * Https support. Could it be part of the problem ? Are there plan to enable Https support ? Thanks. Fre;D - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/fpHttpClient-and-Https-support-tp5721435.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpHttpClient and Https support ?
On Fri, Mar 20, 2015 at 11:54 PM, fredvs wrote:
> Hello.
>
> First of all, congratulation for fpHttpClient.pas.
> It works directly, like charms, without to install any dependencies. =>
> wow.
>
> I am able to do internet audio streaming with it, perfect. ;-)
>
> Hum, while trying to access Https sites, i get errors. ;-(
>
> In begin of fpHttpClient.pas, there is =>
>
> > Todo:
> > * Https support.
>
> Could it be part of the problem ?
> Are there plan to enable Https support ?
>
> Thanks.
>
> Fre;D
>
> -
> Many thanks ;-)
It is already implemented in trunk. So you just:
program project1;
{$mode objfpc}{$H+}
uses
fphttpclient;
begin
WriteLn(TFPHTTPClient.SimpleGet('https://www.google.com/humans.txt'));
end.
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
