Re: [fpc-devel] HTTP client/server components committed.
I've committed simple HTTP server (threaded or not) and HTTP Client components to FCL-Web. They work using the fcl-net ssockets unit. (for which a fix has been committed as well). Both use blocking sockets. Great news ! It should be now possible to develop a WST web service http server and/or client out of the box :-) -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 13:01:39 +0300 schrieb ik ido...@gmail.com: Why not to create something like: *macro* Macro_Name(Param) *begin* *end*; The Pascal way ? It's more readable. But then what do you gain with that Macro ? -Doing it this way would not be acceptable by any developer, therefor tactical reason to suggest it like I did, remember even Florian wrote, he could live with that - and that is a big plus -! -The way to write it is almost only syntactical sugar (feel free to implement a concept as you like and can) -The comment parenthesis for all low level pascal behavior changing things is commonly accepted -I did not try to extend pascal - new tokens, grammar all that -The kind of writing you suggest (ironically) lets pretend a macro is like a pascal procedure, but it is not. Macro works so completely different from pascal, that it makes no clue for me, to let it look like an procedure. Last days where much rumor, so I did not find the time to answer that special question, here it is. The gains are always the same: To do some things which could not be done that easy in an other way! Lets purpose you have an idea to extend the pascal syntax and you want to check out, how it works, which problems it brings... Maybe you decide to implement it with a macro and play around with it. Then if you are ready with it you ask development: Look it works pretty as a macro, if we incorporate it (into the language) this way there will be no harm. You can have two or three different approaches this way, without even touching the compiler. But I am not that crazy, to bring that argument by myself, because this is the most common fear, to bring up the possibility to change the language and so ... Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On Tue, 17 May 2011, Inoussa OUEDRAOGO wrote: I've committed simple HTTP server (threaded or not) and HTTP Client components to FCL-Web. They work using the fcl-net ssockets unit. (for which a fix has been committed as well). Both use blocking sockets. Great news ! It should be now possible to develop a WST web service http server and/or client out of the box :-) Exactly, I had thought about that as well :-) Will you look at it, or would you like me to do it ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On 05/17/2011 01:10 PM, Michael Van Canneyt wrote: Will you look at it, or would you like me to do it ? It would be just great if an example project would come with the components. Thanks a lot ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
2011/5/17 Michael Van Canneyt mich...@freepascal.org On Tue, 17 May 2011, Inoussa OUEDRAOGO wrote: I've committed simple HTTP server (threaded or not) and HTTP Client components to FCL-Web. They work using the fcl-net ssockets unit. (for which a fix has been committed as well). Both use blocking sockets. Great news ! It should be now possible to develop a WST web service http server and/or client out of the box :-) Exactly, I had thought about that as well :-) Will you look at it, or would you like me to do it ? I would like you to look at it :-) as I am busy right now with cpstrnew. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martin f...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can always decide not to
accept any code inside rtl, packages,tools, whatever which contains
macros. Easy. If it compiles with warning, back to sender.
You are willing to take the risk, to get the power.
I am not willing to be exposed to the risk, so you can get the power.
= see my other mail, about them being used n 3rdparty open source,
add ons, etc = if they exist, I (and everyone) will be confronted
with them.
Discussion about that, or stated? and end of the line. Will not bore.
Want not to waste my time, too.
A point which is possibly worth thinking about:
If you have a feature request you can let them try it out,
different approaches welcome, do try it with a macro. Easier
then changing the compiler for my own playground. Generics,
fine. Templates (unit approach for generics), too.
Lets try, this way. And lets try thats way.
Easy done.
Regards
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
On 17/05/2011 12:19, Joerg Schuelke wrote:
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martinf...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can always decide not to
accept any code inside rtl, packages,tools, whatever which contains
macros. Easy. If it compiles with warning, back to sender.
1) The point is, one may not be able to reject it.
If I used a 3rd party package (open source) for a long time, heavily
relaying on it. And the add it, and I need a bug fix, that requires me
to update
2) the example itself is beside the point.
All our examples are beside the point. Mine, yours, any
I think we can easily agree on the following:
1) It is possible to find examples that some people may want to use
(never mind if alternatives exist)
2) It is always possible to find examples of (lack of a better word):
abuse
As for 1, you made yourself a statement: It will be a few people only in
some rare cases. I can try to find your emails.
As for 2, it is mostly there problem, so why bother? Except for if such
code gets into the public domain, as described above
Any way, I feel neither of those 2 statements can be argued (with the
hope of success). I think that can be concluded, after about 85 mails,
trying to find the ultimate example for either side, and no-one any
closer to proving their point...
-
Or at least they can not be argued, unless we answer this question:
Should the compiler protect people from doing potentially dangerous
thinks (knowing this is never a 100% protection anyway)
C obviously doesn't give a damm what people do to themself.
Pascal is supposed to care about it?
If that care is wanted, then the bad examples may gain some importance
--
To me that leaves one other remaining questions. But feel free to add
other points...
Looking at it as a potential feature. How does one evaluate if a feature
should be added.
After all adding features has always been a selective process. this is
not new for this case
1) Is there a need for this feature = We apparently have trouble to
agree on this point. There may be a need for some
2) Does the cost/benefit equation work out
We need to define need (for feature), cost and benefit (benefit is
somewhat coupled to need)
For you as an individual, there is a need, and the benefit is bigger
than the cost.
For me as individual, it is the opposite.
To get a fairer measure we can (in my opinion) only base this on average
values. If you take the entire community, and (in lack of better data
take a guess how many people need it, how many may use it, and how many
may be affected. And assume some averages based on this.
The definition of the terms below, are not solely meant for macro
feature = they apply to every feature (past/future/accepted/rejected)
- every feature shares the same risks, and provides benefits, and for
every feature this cost/benefit can be calculated
need
= The amount of people that want this feature to be implemented (in
this case feature means the extension from what it currently already is)
= It should not matter why they want it (because we tried that
discussionm without success), but only if they want it.
cost
= side-effects of the feature
- This can be the above described undesired exposure to the use of the
feature by others (in the case that use of the code of the other can not
be avoided). Probably low risk.
- this can be any side effect it has on the compiler. (all those are
potential / the may or may not apply, the may pose a very small, or not
so small risk...)
Bugs intruduced (now or in future)
Resource usage, memory, cpu time (potential slow down)
Effects on future features / making it harder to add other features
(which may be wanted by a bigger amount of people, provide greater benefits
Maintenance cost of the code itself
benefit
- objective benefits: like the ability to write code that by some
definition is better/cleaner
- subjective benefits: the ability for some individuals,to use the
feature, for whatever perceived gain
As for the need/benefit = It is not known how many people would be
affected.
But you said yourself several times, probably only a few, and only in
few cases
As for cost, we do not know how many risks will actually turn into
reality (so maintenance cost for example will exist). But if any risk
happens to come true, it affects every one.
Based on this. The question is does the benefits really outweigh the cost ?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On 05/17/2011 01:19 PM, Inoussa OUEDRAOGO wrote: I am busy right now with cpstrnew. Yeah ! Great ! Can you say anything about the state of same ? Thanks a lot -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
2011/5/17 Michael Schnell mschn...@lumino.de On 05/17/2011 01:19 PM, Inoussa OUEDRAOGO wrote: I am busy right now with cpstrnew. Yeah ! Great ! Can you say anything about the state of same ? It is getting better. At least on WinXP/32 I can the fpc test suite, there are some failed tests, but not that much. Check it out and test it by yourself. Tests (preferably validated with delphi) are welcome. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Am Tue, 17 May 2011 12:59:57 +0100 schrieb Martin f...@mfriebe.de: Based on this. The question is does the benefits really outweigh the cost ? Of course not. The much writing shows there is only Hans-Peter possibly for a try. I thought that some of the reasons where only educational ;-) Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing (pre-processor)
On 17/05/2011 13:19, Joerg Schuelke wrote: Am Tue, 17 May 2011 12:59:57 +0100 schrieb Martinf...@mfriebe.de: Based on this. The question is does the benefits really outweigh the cost ? Of course not. The much writing shows there is only Hans-Peter possibly for a try. I thought that some of the reasons where only educational ;-) Going for educational.. or theoretical... There is another idea = which would still make some of this possible. but which I don't know if it would be worth it. ... The macro processing (that has been proposed before) can be done by a pre-processor. The draw-backs may be solvable. (assuming I am correct about point 3) A pre-processor would create temporary files, with the macros expanded. It has to be agreed, that those temp files, are only for the purpose of compilig, and must never be touched/edited by a person (since changes would be lost the next time the pre-processor runs). In fact those temp files should be deleted right after compilation. This does affect: 1) the ability of fpc to check if a ppu needs to be recompiled, because the source file known to fpc doesn't exist 2) the output of line numbers for compile errors and warnings 3) line numbers in debug info 1: would be solved by the pre-processor, that would to the check, and put a new temp file in the place, expected by fpc 2: can be solved easily. The pre-processor has to run fpc, the pre-processor reads the fpc output, and maps line numbers to the correct place 3: Could be solved by compilng to asm. (I assume): fpc must write the info for the assembler how the line numbers map. so they could be corrected. And the assembler can be called once line numbers are corrected It is quite some work though. But you do not need to touch fpc at all. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On 05/17/2011 02:13 PM, Inoussa OUEDRAOGO wrote: It is getting better. At least on WinXP/32 I can the fpc test suite, there are some failed tests, but not that much. Check it out and test it by yourself. Tests (preferably validated with delphi) are welcome. Sounds good. I frequently do check in the svn tree for it. But this is an FPC not a Lazarus thingy. I'm not really sure how to install and use an independent frpc. But maybe I'll try tomorrow... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug in IBConnection?
Hi, I did an ssh tunnel to a remote server that has a Firebird 2.5 database,
this way, my computer can connect to that database by simply pointing to
'localhost', this works when I connect through FlameRobin, but I can't make it
work using this simple program:
program dbtest;
{$mode objfpc}
uses
Classes, SysUtils, IBConnection, sqldb;
var
IBConnection1: TIBConnection;
SQLTransaction1: TSQLTransaction;
lSql: TSQLQuery;
begin
IBConnection1 := TIBConnection.Create(nil);
IBConnection1.DatabaseName := 'test';
IBConnection1.UserName := 'SYSDBA';
IBConnection1.Password := 'masterkey';
IBConnection1.HostName := 'localhost';
IBConnection1.CharSet := 'UTF8';
IBConnection1.LoginPrompt := False;
IBConnection1.Connected := True;
IBConnection1.Free;
end.
When I run it, I get this exception:
An unhandled exception occurred at $00488EFB :
EIBDatabaseError : : DoInternalConnect :
-database /usr/path_to_database/TEST.IB shutdown
$00488EFB
$0048A1E1
$00489C98
What can be causing this error?
P.S.: I'm connecting from an Ubuntu 10.10 64bits box with libfbclient2 ver
2.5.0.26074-0.ds4-4, and the server is a FreeBSD 8.2 64bits with Firebird 2.5.
Thanks in advance,
Leonardo M. Ramé
http://leonardorame.blogspot.com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On Tue, 17 May 2011, Michael Schnell wrote: On 05/17/2011 01:10 PM, Michael Van Canneyt wrote: Will you look at it, or would you like me to do it ? It would be just great if an example project would come with the components. There are example projects (see my initial mail). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTTP client/server components committed.
On Tue, 17 May 2011, Inoussa OUEDRAOGO wrote: 2011/5/17 Michael Van Canneyt mich...@freepascal.org On Tue, 17 May 2011, Inoussa OUEDRAOGO wrote: I've committed simple HTTP server (threaded or not) and HTTP Client components to FCL-Web. They work using the fcl-net ssockets unit. (for which a fix has been committed as well). Both use blocking sockets. Great news ! It should be now possible to develop a WST web service http server and/or client out of the box :-) Exactly, I had thought about that as well :-) Will you look at it, or would you like me to do it ? I would like you to look at it :-) as I am busy right now with cpstrnew. OK. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing (pre-processor)
Am Tue, 17 May 2011 13:38:35 +0100 schrieb Martin f...@mfriebe.de: Going for educational.. or theoretical... You understand, it is not even easy for someone to have a need ore a valid use for an macro, after 30 years without? Then crutch macro support that fpc has, makes that not better. It makes people preventing them, even if they could be helpful. That was meant by educational. There is another idea = which would still make some of this possible. I know. The main pitfall in my eyes is the replication of the scanner, a mass of handwritten code, which I am not willing to hold in sync. But there is a package too. Or writing a table driven. I´ll look at it. Regards Jörg ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Compilation is broken at rev. 17482 ?
Hello all, is it me, or compilation is broken (revision: 17482): ... Fatal: Can't find unit fphttpclient used by pkgfphttp Fatal: Compilation aborted make[4]: *** [pkgfphttp.ppu] Error 1 make[4]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages/fppkg' make[3]: *** [fpc_smart] Error 2 make[3]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages/fppkg' make[2]: *** [fppkg_smart] Error 2 make[2]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___' make: *** [build-stamp.i386-win32] Error 2 Regards Žilvinas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compilation is broken at rev. 17482 ?
On Tue, 17 May 2011, Žilvinas Ledas wrote: Hello all, is it me, or compilation is broken (revision: 17482): ... Fatal: Can't find unit fphttpclient used by pkgfphttp Fatal: Compilation aborted make[4]: *** [pkgfphttp.ppu] Error 1 make[4]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages/fppkg' make[3]: *** [fpc_smart] Error 2 make[3]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages/fppkg' make[2]: *** [fppkg_smart] Error 2 make[2]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `E:/lazarus/fpc/fpc_my/source_SVN___' make: *** [build-stamp.i386-win32] Error 2 Please update packages/Makefile* and try again. I added a dependency of fppkg on fcl-web Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compilation is broken at rev. 17482 ?
On 2011-05-17 20:36, Michael Van Canneyt wrote: Please update packages/Makefile* and try again. I added a dependency of fppkg on fcl-web Michael. Thank you, it works now. Regards Žilvinas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
