> > Core of this problems is not platform independency. Or not?
> In this particular example, the field was simply forgotton, and we'll
> add it. This is not a problem.
Great! ;-)
If I replay my discussion int very short form, then it is look as:
X> Synapse is not good, because it using lot of I
In reply to your message of July 24, 2003
> In most cases, casting an ansistring as pchar will work. The only caveat is
> when Windows wants to alter the variable you pass' contenets.
> e.g.
>MessageBox( pchar(MyMessage), 'test', MB_OK);
> but not:
> GetUserName( pchar(Username), 255
Having read this thread with interest, I feel compelled to say
something.
Very simply put, I have no care how good a piece of code is by any other
judgement. If it cannot be ported, it has already failed the most
crucial test for code.
Okay, maybe that is a bit harsh, there are obviously exceptions
On Thu, 24 Jul 2003, Lukas Gebauer wrote:
> > That isn't. I was more hinting at the TSystemTime example. Sysutils is
> > platform independant, and Windows is dependant.
>
> Ok, enhance this my example: What is different between TSystemTme
> structure in sysutils and in windows? Windows structure
> That isn't. I was more hinting at the TSystemTime example. Sysutils is
> platform independant, and Windows is dependant.
Ok, enhance this my example: What is different between TSystemTme
structure in sysutils and in windows? Windows structure have only one
additional field 'DayOfWeak'!
Why plat
> > ??? I am using this constructs under Delphi without problems... :-O
> I don't remember ever getting it to work, but then I come from a D1
> background (way back when) so maybe I assumed it doesn't work.
On D1 not exists ansistrings and not exists setlength for strings. on
D1 is impossible do t
> > 100% platform independance is indeed often counter-productive. However
> > that isn't a good reason to don't do anything platform independant at
> > all:-)
>
> But I create tool for programmers and I hide all platform
> differencies in my tool. By my tool other programmers must not
> resolve a
> > FPC may let you do that, but Delphi will have an error about not passing
> > const params iirc. That or the result is garbage back from Windows.
>
> ??? I am using this constructs under Delphi without problems... :-O
I don't remember ever getting it to work, but then I come from a D1
backgroun
> > begin
> > SetLength(Username,255);
> > GetUserName( pchar(Username), 255 );
> > Setlength(username,strlen(pchar(username));
> > end
> FPC may let you do that, but Delphi will have an error about not passing
> const params iirc. That or the result is garbage back from Windows.
??? I am using
> 100% platform independance is indeed often counter-productive. However that
> isn't a good reason to don't do anything platform independant at all:-)
But I create tool for programmers and I hide all platform
differencies in my tool. By my tool other programmers must not
resolve any platform depe
> What about
>
> var username:AnsiString;
>
> begin
> SetLength(Username,255);
> GetUserName( pchar(Username), 255 );
> Setlength(username,strlen(pchar(username));
> end
>
> Or does that mess up reference counts?
FPC may let you do that, but Delphi will have an error about not passing
const pa
> (and this is for huge platform differents, for example: Linux compute
> checksum of ICMPv6, but under Windows must compute by your
> hands...etc. Sorry, but create special library for platform
> independent ICMPv6 checksum computing is not right way.. it only
> create tons of other units... ;-()
[ Charset ISO-8859-1 unsupported, converting... ]
> > I would prefer a language that is tightly integrated with an OS... so
> tightly
> > that OS calls and language calls fit together in one smooth flow. I should
> not
> > have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to
>
Lukas Gebauer wrote:
For little example: On Delphi workd exists structure TSystemTime.
Thjis is defined in Windows.pas, and all related time functions on
delphi using this structure. For example, lot of functions inside
sysutils.pas. it allows get system time by Win32 API call and then
you can hand
> I would prefer a language that is tightly integrated with an OS... so
tightly
> that OS calls and language calls fit together in one smooth flow. I should
not
> have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to
get
> things to work. OS calls should be so seamless as to ap
> > But is is not easy! I create my code on Delphi3, and it working on
> > all higher versions without any modification!
> And does it work on lower versions without any modification? Otherwise
> you still don't support multiple versions.
what? I support Delphi 3, 4, 5, 6 and 7... is is not multip
In reply to your message of July 23, 2003
> If we had a lot of hard working people, we could make a nice new set of
> platform dependant units, and more and more TP units would become legacy.
This is a truly interesting discussion, I hope you don't mind a few comments
from someone who's just now
On woensdag, jul 23, 2003, at 17:04 Europe/Brussels, Matt Emson wrote:
Use aliases for sysutils. That or aliases in Delphi mode for strings,
dos
etc.
That's kind of hard to do if you don't support aliases yet. We may
support them now, but we most certainly did not support them when those
units
> On woensdag, jul 23, 2003, at 16:46 Europe/Brussels, Matt Emson wrote:
>
> > You only therfore need sysutils, *or* the old scheme. Not both.
>
> You do need both if you advertise both TP and Delphi compatibility.
Use aliases for sysutils. That or aliases in Delphi mode for strings, dos
etc.
Mat
[some minor remarks]
> Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe],
> fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see
> no real need for it. I made my opinion of the obj fpc made clear a long time
> ago ;-)
Opinions differ. But the IDE and part
On woensdag, jul 23, 2003, at 16:46 Europe/Brussels, Matt Emson wrote:
You only therfore need sysutils, *or* the old scheme. Not both.
You do need both if you advertise both TP and Delphi compatibility.
Jonas
___
fpc-pascal maillist - [EMAIL PROTECTE
> > But is is not easy! I create my code on Delphi3, and it working on
> > all higher versions without any modification!
>
> And does it work on lower versions without any modification? Otherwise
> you still don't support multiple versions.
Delphi 1 would be unlikely. Delphi 2 was an awful compile
> Because strings already existed in TP.
> Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils.
You only therfore need sysutils, *or* the old scheme. Not both. I understand
why this was done by Borland. Legacy is hard to break, and D1 broke with
legacy.
> > You don't follow the
> > > Sure, but Borland is home for Synapse.
> > Also for FPC. See FPC as yet another Delphi version to support. If you
> > do a large Delphi product that will compile with a lot of versions, you
> > have to make adaptations also.
>
> But is is not easy! I create my code on Delphi3, and it working
> But under Dos you would do simple polling, since the eventloop of your
own.
> The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision,
> but the eventloop is under your control)
Yes, but doing that in DOS was not trivial. Where as in UNIX it's just a
fork away.
> While with mo
On Wed, 23 Jul 2003, Matt Emson wrote:
>
> > So finally, I don't think we're doing a bad job. We'll get there, slowly
> > but surely.
>
> You're all doing a good job, I was just pointing out that these are not new
> issues.
>
> > > Strings.pp for example holds a lot of string related functions t
> So finally, I don't think we're doing a bad job. We'll get there, slowly
> but surely.
You're all doing a good job, I was just pointing out that these are not new
issues.
> > Strings.pp for example holds a lot of string related functions that
really
> > need to be in sysutils now.
>
> They are
> > Even better, without any alterations, I would hope that VCL style
> > implementations would simple seamlessly compile using the wrapper.
>
> ICS of Francois Piette - with some minor patches - compiles using FPC.
> Synapse as well. The changes have been quite minor - even some potential
> bugs
>
> > Hmm, I think this is more due to the move to event driven programming
> models
> > than cooperative multitasking.
>
> No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
> without threads?
Yes.
> It will block untill it receives the response. This completely* stops
On Wed, 23 Jul 2003, Matt Emson wrote:
> > When I porting Synapse into FPC, then i find lot of incompatibilities
> > between Win32FPC and LinuxFPC. For example, look to Kylix
> > sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in
> > another units, some stuffs is missing at all.
> When I porting Synapse into FPC, then i find lot of incompatibilities
> between Win32FPC and LinuxFPC. For example, look to Kylix
> sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in
> another units, some stuffs is missing at all. This is very bad
> situation for create programs
> Hmm, I think this is more due to the move to event driven programming
models
> than cooperative multitasking.
No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
without threads? It will block untill it receives the response. This
*completely* stops the flow of the applic
> > Sure, but Borland is home for Synapse.
> Also for FPC. See FPC as yet another Delphi version to support. If you
> do a large Delphi product that will compile with a lot of versions, you
> have to make adaptations also.
But is is not easy! I create my code on Delphi3, and it working on
all high
> > > When I see to latest voting on lazarus page, then I think, lot of
> > > people need lazarus for Win32... But lazarus Win32 binary downloads
> > > is empty. ;-(
> >
> > This is correct.
> > The lazarus team needs people to help develop the win32 version.
>
> What is major problem in developin
> > Following works perfectly for me for many years:
> >
> > ioctl(Sock,FIONBIO,@tmp); // nonblocking
> >
> > All but one applications are single thread.
>
> Yes. You are using the 'work around'. Traditional UNIX sockets block.
> Microsoft (and others) realised this would not work with a co-operat
> > And the other way around. The main problem with Borland is that it only
> > supports one and a half platform on one processor.
>
> Sure, but Borland is home for Synapse.
Also for FPC. See FPC as yet another Delphi version to support. If you
do a large Delphi product that will compile with a l
ME> Use threads and blocking api.
I have (almost) nothing against threads, but they definitely have
disadvantages to, especially when used in a huge project:
1. synchronization - need to use critical sections / locks
2. they are very hard to debug and time dependant bugs can be
introduced.
3. man
> > When I see to latest voting on lazarus page, then I think, lot of
> > people need lazarus for Win32... But lazarus Win32 binary downloads
> > is empty. ;-(
>
> This is correct.
> The lazarus team needs people to help develop the win32 version.
What is major problem in developing of WIN32 lazar
> Why must I use threads?
You must use threads in blocking tcp/ip else you will hang your application
everytime the network traffic slows or the application you connect to
(server?) does not immediately respond. Try changing your calls to blocking
and see what happens.
> Following works perfectly
On Wed, 23 Jul 2003, Lukas Gebauer wrote:
> > > I create Synapse primary for my programs. I am professional
> > > programmer and I create lot of commercial programs by my Synapse.
> > > This is reason why Borland is very important for me. Programming is
> > > not only compiler, but IDE too! I no
On Wed, 23 Jul 2003 11:36:58 +0200 (W. Europe Daylight Time)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 23 Jul 2003, Lukas Gebauer wrote:
>
> > > And the other way around. The main problem with Borland is that it
> > > only supports one and a half platform on one processor.
>
> > I create Synapse primary for my programs. I am professional
> > programmer and I create lot of commercial programs by my Synapse.
> > This is reason why Borland is very important for me. Programming is
> > not only compiler, but IDE too! I not see comparable IDE for FPC with
> > Borlands IDE. ;
> LG> yes, but... with other large TCP/IP libraries you MUST use threads...
> LG> with synapse you CAN use threads. This is mojor difference! One day
> LG> will be finished thread support in FPC and all will be happy. ;-)
>
> Why must I use threads?
Because not exists non-blocking large TCP/IP lib
On Wed, 23 Jul 2003, Lukas Gebauer wrote:
> > And the other way around. The main problem with Borland is that it only
> > supports one and a half platform on one processor.
>
> Sure, but Borland is home for Synapse.
>
> I create Synapse primary for my programs. I am professional
> programmer and
LG> yes, but... with other large TCP/IP libraries you MUST use threads...
LG> with synapse you CAN use threads. This is mojor difference! One day
LG> will be finished thread support in FPC and all will be happy. ;-)
Why must I use threads?
Following works perfectly for me for many years:
ioctl(S
> It's pretty hard to use blocking sockets without multiple threads without
> your application halting whenever there is a request that takes a long time
> to respond.
yes, but... with other large TCP/IP libraries you MUST use threads...
with synapse you CAN use threads. This is mojor difference!
> And the other way around. The main problem with Borland is that it only
> supports one and a half platform on one processor.
Sure, but Borland is home for Synapse.
I create Synapse primary for my programs. I am professional
programmer and I create lot of commercial programs by my Synapse.
This
> It is greately usable for command-line programs or for visual programs
> where blocking operation is not a problem.
Apps with a GUI will cause a problem, no matter what. I include programs
that use TurboVision/FreeVision/NCurses et al for GUI. I work on a large app
that is completely TCP/IP base
> > I looked at the unit (mainly the synsock unit), and I see a Delphi project
> > patched for Kylix, which is patched for FPC/Linux.
>
> In all library is very small 'IFDEFs' except synsock.pas. However lot of
> 'IFDEFS' is only for FPC incompatbility with Borlands compilers!
And the other way a
> On Tue, 22 Jul 2003, Marco van de Voort wrote:
> > > implementation can be dynamically loaded.
> >
> > Why would an alternate implementation be unloadable just because the built-in
> > default one uses a few units?
>
> I was of course just referring to your last point: i.e. the use of
> structur
> I looked at the unit (mainly the synsock unit), and I see a Delphi project
> patched for Kylix, which is patched for FPC/Linux.
In all library is very small 'IFDEFs' except synsock.pas. However lot of
'IFDEFS' is only for FPC incompatbility with Borlands compilers!
Current Synapse is not final
On Tue, 22 Jul 2003, Marco van de Voort wrote:
> > On Tue, 22 Jul 2003, Marco van de Voort wrote:
> >
> > > > Today I release new version of my 'Ararat Synapse'. (rel. 32)
> > > >
> > > > What it is?
> > > > 'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
> > > > Now it is f
> Is it synchranous/blocking or asynchranous? TCP/IP without threads is an
> interesting idea, but I wouldn't like to have to use it. I don't see how it
> could be usable in a real life app.
Synapse is blocking by default... but you can use it in non-blocking mode
too.
It is greately usable for c
> On Tue, 22 Jul 2003, Marco van de Voort wrote:
>
> > > Today I release new version of my 'Ararat Synapse'. (rel. 32)
> > >
> > > What it is?
> > > 'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
> > > Now it is for FreePascal too! It can be used for Wn32 systems and for
> >
On Tue, 22 Jul 2003, Marco van de Voort wrote:
> > Today I release new version of my 'Ararat Synapse'. (rel. 32)
> >
> > What it is?
> > 'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
> > Now it is for FreePascal too! It can be used for Wn32 systems and for
> > Linux system
> Today I release new version of my 'Ararat Synapse'. (rel. 32)
>
> What it is?
> 'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
> Now it is for FreePascal too! It can be used for Wn32 systems and for
> Linux systems too.
>
> Synapse is set of non-visual classes and procedur
On Tue, Jul 22, 2003 at 09:28:12AM +0200, Michael Van Canneyt wrote:
>
>
> On Tue, 22 Jul 2003, Marco van de Voort wrote:
>
> > > > SNMP, NTP, SNTP, DNS, Syslog, FTP, TFTP, HTTP or LDAP protocols. You
> > > > can also use my MIME encoding and decoding engine, you can use my
> > > > charset trans
On Tue, Jul 22, 2003 at 10:36:54AM +0200, Lukas Gebauer wrote:
> > Why should we use your set of classes vs. another set of classes
> > developer by person X ? :)
> >
> > Just a friendly question, I know there are a lot of TCP/IP suites
> > around...
>
> Why? It is not simple question. ;-)
>
> Be
Looking at Lukas' email, I will direct this at FPC and Michael's 'No thread'
assertion. I see that Synapse itself is perfectly rational when concerning
Multi Threading.
Matt
> > I've been cooperating to get it to work with FPC. It's one of the
> > few suites that doesn't require threads and/or m
> I've been cooperating to get it to work with FPC. It's one of the
> few suites that doesn't require threads and/or message pumps. So it was
> better suited to work with FPC, till we have sufficient support for
> threads and the like. (scheduled for 1.2)
Is it synchranous/blocking or asynchranous
> Why should we use your set of classes vs. another set of classes
> developer by person X ? :)
>
> Just a friendly question, I know there are a lot of TCP/IP suites
> around...
Why? It is not simple question. ;-)
Before a five years I need socket library for Delphi. In this time exists
only two
On Tue, 22 Jul 2003, Marco van de Voort wrote:
> > > SNMP, NTP, SNTP, DNS, Syslog, FTP, TFTP, HTTP or LDAP protocols. You
> > > can also use my MIME encoding and decoding engine, you can use my
> > > charset transcoding engine... and lot of more stuffs. ;-)
> > >
> > > For more informations look
> > SNMP, NTP, SNTP, DNS, Syslog, FTP, TFTP, HTTP or LDAP protocols. You
> > can also use my MIME encoding and decoding engine, you can use my
> > charset transcoding engine... and lot of more stuffs. ;-)
> >
> > For more informations look to 'Ararat Synapse' web.
>
> Why should we use your set o
On Mon, Jul 21, 2003 at 09:39:38AM +0200, Lukas Gebauer wrote:
> Hello FPC community!
>
> Today I release new version of my 'Ararat Synapse'. (rel. 32)
>
> What it is?
> 'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
> Now it is for FreePascal too! It can be used for Wn32 sy
Hello FPC community!
Today I release new version of my 'Ararat Synapse'. (rel. 32)
What it is?
'Ararat Synapse' is TCP/IP library for Delphi, C++Builder and Kylix.
Now it is for FreePascal too! It can be used for Wn32 systems and for
Linux systems too.
Synapse is set of non-visual classes and pr
65 matches
Mail list logo
