Re: [fpc-pascal] xmlrpc unit
In our previous episode, Graeme Geldenhuys said: > > * Deprecated in favour of fcl-web and WST > > In all fairness, deprecated normally means it is "marked" as deprecated at > least for one release *before* it gets deleted. If I was ik, I'd be pretty > pissed off working on a project that might be released in a week or two. > Already tried and tested and passed QA, and then suddenly need to switch to > an unfamiliar technology that has not passed our QA yet. Just my 2c worth. Fixes still contains it. Most of the fpweb changes are not merged back to 2.4.x See http://www.stack.nl/~marcov/fpctomerge.txt or whatever you generate with GIT for this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, 1 Jul 2010, Graeme Geldenhuys wrote: Op 2010-06-30 18:00, Jonas Maebe het geskryf: * Deprecated in favour of fcl-web and WST In all fairness, deprecated normally means it is "marked" as deprecated at least for one release *before* it gets deleted. If I was ik, I'd be pretty pissed off working on a project that might be released in a week or two. Already tried and tested and passed QA, and then suddenly need to switch to an unfamiliar technology that has not passed our QA yet. Just my 2c worth. True, but given that the examples didn't compile since many, many years, I'd say that the probability that xmlrpc passed the QA in a company was very remote indeed. That was why we decided to remove it alltogether at once. And since the code was not being maintained anyway, he could just have kept the latest copy of it: so no harm done. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
Op 2010-07-01 09:15, Marco van de Voort het geskryf: > > Fixes still contains it. Most of the fpweb changes are not merged back to > 2.4.x As usual you don't understand me correctly, as your above statement proves. Let me explain again. The r15346 should not be merged to 2.4.x yet, the code in 2.4.x should FIRST be marked as deprecated for one release (maybe even as soon as FPC 2.4.2 seeing that the 'deprecated' hint directive doesn't break anything). Then only in the NEXT release should r15346 be merged, resulting in those units being removed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt wrote: > > > On Thu, 1 Jul 2010, Graeme Geldenhuys wrote: > > Op 2010-06-30 18:00, Jonas Maebe het geskryf: >> >>> >>> * Deprecated in favour of fcl-web and WST >>> >> >> In all fairness, deprecated normally means it is "marked" as deprecated at >> least for one release *before* it gets deleted. If I was ik, I'd be >> pretty >> pissed off working on a project that might be released in a week or two. >> Already tried and tested and passed QA, and then suddenly need to switch >> to >> an unfamiliar technology that has not passed our QA yet. Just my 2c >> worth. >> > > True, but given that the examples didn't compile since many, many years, > I'd > say that the probability that xmlrpc passed the QA in a company was very > remote > indeed. That was why we decided to remove it alltogether at once. > Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP without any given reason (glib error on an existed code that works on other servers), and I prefer to use something stable and fast rather then something that is not, because I do not have a lot of time to make things work properly (the life of freelancing). I remembered that FPC have an XMLRPC generator that allow me to just focus at the task I require, and wanted to use it, but the generator could not be compiled because of the missing unit. I still do not understand (at all) how fpWeb works, and all the examples works with JSON only (I wish I could use it, but the spec files of my client uses XML-RPC), and even Lazarus is unable to properly work with it (some files are missing even after adding fpWeb package to Lazarus), so it does not help much :( For now I'll add another JVM running and make it a server (because I can do it very quickly) but when I'll have more time to learn fpWeb I would really want to move away from Java + PHP in this cases to FPC in my client production servers. > > And since the code was not being maintained anyway, he could just have kept > the > latest copy of it: so no harm done. > > Michael. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > Ido ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Is this if /else syntax wrong?
The following code generates a syntax error, if the semicolon after the if/else statement is removed. Is its absence a syntax error? Pascal version is 2.2.4 procedure TfrmHometel.SetSplitterSizes; var i: integer; begin for i:= 0 to ComponentCount - 1 do begin if Components[i] is TSplitter then begin with TSplitter(Components[i]) do begin if Cursor = crHSplit then Width := 7 else if Cursor = crVSplit then Height := 7; ; // <-- removing this semicolon results in a syntax error. Is it syntax error some kind of extra strict compiler check. Color := clBlue; end; end; end; end; -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
Op 2010-07-01 09:33, Michael Van Canneyt het geskryf: > > And since the code was not being maintained anyway, he could just have kept > the > latest copy of it: so no harm done. Either way, see my reply to Marco. Your actions might have been ok for Trunk, but definitely will not be for the stable "fixes" branch. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
Op 2010-07-01 09:44, ik het geskryf: > existed code that works on other servers), and I prefer to use something > stable and fast rather then something that is not, because I do not have > a lot of time to make things work properly (the life of freelancing). This is exactly the point I was trying to make. I don't use XML-RPC, but I am arguing the way the change was handled (and the same way proposed for Fixes branch). The Fixes branch must at least be treated with more care that the Trunk branch - give end-user developer more time to adjust there code and learn new technologies if needed. I'm pretty sure we are all very busy (I know I am), so instantly being forced to use something you don't know is not a very nice thing to do. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, 1 Jul 2010, ik wrote: On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt wrote: In all fairness, deprecated normally means it is "marked" as deprecated at least for one release *before* it gets deleted. If I was ik, I'd be pretty pissed off working on a project that might be released in a week or two. Already tried and tested and passed QA, and then suddenly need to switch to an unfamiliar technology that has not passed our QA yet. Just my 2c worth. True, but given that the examples didn't compile since many, many years, I'd say that the probability that xmlrpc passed the QA in a company was very remote indeed. That was why we decided to remove it alltogether at once. Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP without any given reason (glib error on an existed code that works on other servers), and I prefer to use something stable and fast rather then something that is not, because I do not have a lot of time to make things work properly (the life of freelancing). I remembered that FPC have an XMLRPC generator that allow me to just focus at the task I require, and wanted to use it, but the generator could not be compiled because of the missing unit. Where is this generator ? I should remove it too. In each case the stable branch still contains it. Copy it from there, and be warned: it is no longer supported. As for fp-web being json: There is nothing JSON specific about WST, on the contrary, I would say ? I am still looking into getting a more leight-weight implementation of xml-rpc in fp-web directly, as WST is sometimes a bit heavy for simple things. If you experience problems compiling the lot, let me know, I'll see what I can do to help. Be warned that fpweb development is strictly in trunk. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this if /else syntax wrong?
Compiles just fine (with or without the semicolon) with Lazarus r25303M / fpc 2.4.1 Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, 1 Jul 2010, Graeme Geldenhuys wrote: Op 2010-07-01 09:33, Michael Van Canneyt het geskryf: And since the code was not being maintained anyway, he could just have kept the latest copy of it: so no harm done. Either way, see my reply to Marco. Your actions might have been ok for Trunk, but definitely will not be for the stable "fixes" branch. That's why I work only in trunk. And as I understood it, Marco explicitly mentioned that it is not merged back to fixes. It also does not appear in http://www.stack.nl/~marcov/fpctomerge.txt Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
In our previous episode, Graeme Geldenhuys said: > > Fixes still contains it. Most of the fpweb changes are not merged back to > > 2.4.x > > As usual you don't understand me correctly, as your above statement proves. > Let me explain again. The r15346 should not be merged to 2.4.x yet, (or at all) > the > code in 2.4.x should FIRST be marked as deprecated for one release (maybe > even as soon as FPC 2.4.2 seeing that the 'deprecated' hint directive > doesn't break anything). We all know that, but we don't do that for a reason: Unit level deprecated is 2.5.1 functionality (r14767 , Mantis 13373) Still, comments could be added and procedures/methods flagged. I'll take care of this. I also added to user changes trunk. Michael, please have a look and expand on it: http://wiki.freepascal.org/User_Changes_Trunk > Then only in the NEXT release should r15346 be > merged, resulting in those units being removed. Units are generally only removed between major releases. I'm not so sure this will happen at all. Specially since the mutation rate of the new stuff is still high. As you can see in http://www.stack.nl/~marcov/fpctomerge.txt or your local GIT equivalent, most of the fcl-web/json stuff is not merged. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, Jul 1, 2010 at 10:54, Michael Van Canneyt wrote: > > > On Thu, 1 Jul 2010, ik wrote: > > On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt > >wrote: >> >> In all fairness, deprecated normally means it is "marked" as deprecated at least for one release *before* it gets deleted. If I was ik, I'd be pretty pissed off working on a project that might be released in a week or two. Already tried and tested and passed QA, and then suddenly need to switch to an unfamiliar technology that has not passed our QA yet. Just my 2c worth. >>> True, but given that the examples didn't compile since many, many years, >>> I'd >>> say that the probability that xmlrpc passed the QA in a company was very >>> remote >>> indeed. That was why we decided to remove it alltogether at once. >>> >>> >> >> Actually I have a code in PHP that does XMLRPC and a new CentOS >> installation >> crashes PHP without any given reason (glib error on an existed code that >> works on other servers), and I prefer to use something stable and fast >> rather then something that is not, because I do not have a lot of time to >> make things work properly (the life of freelancing). >> >> I remembered that FPC have an XMLRPC generator that allow me to just focus >> at the task I require, and wanted to use it, but the generator could not >> be >> compiled because of the missing unit. >> > > Where is this generator ? I should remove it too. > The generator does not exists anymore, the example of svrclass_xmlrpc requires it under: fpc/packages/fcl-net/examples > In each case the stable branch still contains it. Copy it from there, > and be warned: it is no longer supported. > > As for fp-web being json: There is nothing JSON specific about WST, on the > contrary, I would say ? I am still looking into getting a more > leight-weight > implementation of xml-rpc in fp-web directly, as WST is sometimes a bit > heavy for simple things. > The names are misleading then :( WST is webdata am I correct ? > > If you experience problems compiling the lot, let me know, I'll see what I > can do to help. Be warned that fpweb development is strictly in trunk. Thanks, I hope I'll be able to touch it in several weekends from now to test and learn it properly. > > > Michael. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > Ido ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting a graphical DOS program to fpc
I' would defininately convert it to a GUI program (and use Lazarus for that). Take a look at TCanvas and it's methods to draw on it. There are plenty people out here (on the Lazarus list or the Lazarus forum) that can help you. And the wiki too: http://wiki.lazarus.freepascal.org/Developing_with_Graphics Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is this if /else syntax wrong?
On Thu, 1 Jul 2010 10:01:52 +0200 Bart wrote: > Compiles just fine (with or without the semicolon) with Lazarus > r25303M / fpc 2.4.1 2.5.1 eats both too. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On 1 July 2010 10:04, Michael Van Canneyt wrote: > > And as I understood it, Marco explicitly mentioned that it is not merged > back to fixes. It also does not appear in > http://www.stack.nl/~marcov/fpctomerge.txt You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On 1 July 2010 10:06, Marco van de Voort wrote:
>> code in 2.4.x should FIRST be marked as deprecated for one release (maybe
>> even as soon as FPC 2.4.2 seeing that the 'deprecated' hint directive
>> doesn't break anything).
>
> We all know that, but we don't do that for a reason:
>
> Unit level deprecated is 2.5.1 functionality (r14767 , Mantis 13373)
My apologies, I didn't know unit level deprecated doesn't work in
fixes branch. I was just about to comment on this (after I tried it
myself and it failed), when I saw your reply.
> Still, comments could be added and procedures/methods flagged. I'll take
> care of this. I also added to user changes trunk.
Maybe adding it as a {$warning This unit is deprecated} will suffice
for now, until r14767 is merged with 2.4.x. I just tested {$warning
...} below the 'unit ...;' line, and indeed it does output a warning
in the compiler output.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
In our previous episode, Graeme Geldenhuys said:
>
> Maybe adding it as a {$warning This unit is deprecated} will suffice
> for now, until r14767 is merged with 2.4.x. I just tested {$warning
> ...} below the 'unit ...;' line, and indeed it does output a warning
> in the compiler output.
I already added text to the source headers and a "deprecated" modifier to
all constructor.
We also want this to show if people use precompiled units :-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Is this if /else syntax wrong?
> procedure TfrmHometel.SetSplitterSizes; > var > i: integer; > begin > for i:=3D 0 to ComponentCount - 1 do > begin > if Components[i] is TSplitter then > begin > with TSplitter(Components[i]) do > begin > if Cursor =3D crHSplit then > Width :=3D 7 > else if Cursor =3D crVSplit then > Height :=3D 7; > ; // <-- removing this semicolon results in a syntax error. Is it > syntax error some kind of extra strict compiler check. > Color :=3D clBlue; > end; > end; > end; > end; Compare with next: if Cursor =3D crHSplit then Width :=3D 7 else if Cursor =3D crVSplit then Height :=3D 7; // <-- This semicolon is for the "if". ; // <-- This semicolon is for the "else". Is like this: IF ... THEN BEGIN ... END ELSE BEGIN IF ... THEN BEGIN ... END; // <-- This END is for the "IF". END; // <-- This END is for the "ELSE". I recommend to use "BEGIN ... END" blocks in nested "IF" always to prevent this kind of mistakes. Regards, Guillermo "Ñuño" Martínez. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
On Thu, 1 Jul 2010, ik wrote: On Thu, Jul 1, 2010 at 10:54, Michael Van Canneyt wrote: On Thu, 1 Jul 2010, ik wrote: On Thu, Jul 1, 2010 at 10:33, Michael Van Canneyt wrote: In all fairness, deprecated normally means it is "marked" as deprecated at least for one release *before* it gets deleted. If I was ik, I'd be pretty pissed off working on a project that might be released in a week or two. Already tried and tested and passed QA, and then suddenly need to switch to an unfamiliar technology that has not passed our QA yet. Just my 2c worth. True, but given that the examples didn't compile since many, many years, I'd say that the probability that xmlrpc passed the QA in a company was very remote indeed. That was why we decided to remove it alltogether at once. Actually I have a code in PHP that does XMLRPC and a new CentOS installation crashes PHP without any given reason (glib error on an existed code that works on other servers), and I prefer to use something stable and fast rather then something that is not, because I do not have a lot of time to make things work properly (the life of freelancing). I remembered that FPC have an XMLRPC generator that allow me to just focus at the task I require, and wanted to use it, but the generator could not be compiled because of the missing unit. Where is this generator ? I should remove it too. The generator does not exists anymore, the example of svrclass_xmlrpc requires it under: fpc/packages/fcl-net/examples I'll remove that too. In each case the stable branch still contains it. Copy it from there, and be warned: it is no longer supported. As for fp-web being json: There is nothing JSON specific about WST, on the contrary, I would say ? I am still looking into getting a more leight-weight implementation of xml-rpc in fp-web directly, as WST is sometimes a bit heavy for simple things. The names are misleading then :( WST is webdata am I correct ? Ah, nono. WST is Webservices Toolkit. You can find it on lazarus-ccr. It can exist completely without lazarus, though. very good and stable product. It works since years. The support for fcl-web is rather recent, though. you can also use it without fcl-web, just with synapse, apache or even indy. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
Graeme Geldenhuys wrote on Thu, 01 Jul 2010: On 1 July 2010 10:04, Michael Van Canneyt wrote: And as I understood it, Marco explicitly mentioned that it is not merged back to fixes. It also does not appear in http://www.stack.nl/~marcov/fpctomerge.txt You do you mean, I clearly see it listed in fpctomerge.txt (I just double checked). The fpctomerge.txt file is a bit badly named. It simply contains all revisions in trunk that are not in the fixes branch. There is no list of revisions that are scheduled to be merged. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] xmlrpc unit
In our previous episode, Jonas Maebe said: > > On 1 July 2010 10:04, Michael Van Canneyt wrote: > >> > >> And as I understood it, Marco explicitly mentioned that it is not merged > >> back to fixes. It also does not appear in > >> http://www.stack.nl/~marcov/fpctomerge.txt > > > > You do you mean, I clearly see it listed in fpctomerge.txt (I just > > double checked). > > The fpctomerge.txt file is a bit badly named. It simply contains all > revisions in trunk that are not in the fixes branch. There is no list > of revisions that are scheduled to be merged. (strictly speaking it lists the one that are available for merging, so all revisions-already merged - blocked ones . But we haven't done much blocking recently) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting a graphical DOS program to fpc
Op 2010-07-01 10:11, Bart het geskryf: > I' would defininately convert it to a GUI program (and use Lazarus for that). or fpGUI Toolkit. :-) I'm currently working on a DirectFB backend for fpGUI which will allow for "gui" apps in a console environment. As for BGI to ... I don't think there is an easy (automated) solution to this, sorry. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Is this if /else syntax wrong?
I will be upgrading to 2.4.0 soon. It shouldn't be an error then. 2010/7/1 Guillermo Martínez Jiménez > > procedure TfrmHometel.SetSplitterSizes; > > var > > i: integer; > > begin > > for i:=3D 0 to ComponentCount - 1 do > > begin > > if Components[i] is TSplitter then > > begin > > with TSplitter(Components[i]) do > > begin > > if Cursor =3D crHSplit then > >Width :=3D 7 > > else if Cursor =3D crVSplit then > >Height :=3D 7; > > ; // <-- removing this semicolon results in a syntax error. Is it > > syntax error some kind of extra strict compiler check. > > Color :=3D clBlue; > > end; > > end; > > end; > > end; > > Compare with next: > > if Cursor =3D crHSplit then >Width :=3D 7 > else >if Cursor =3D crVSplit then > Height :=3D 7; // <-- This semicolon is for the "if". > ; // <-- This semicolon is for the "else". > > Is like this: > > IF ... THEN > BEGIN > ... > END > ELSE BEGIN > IF ... THEN > BEGIN >... > END; // <-- This END is for the "IF". > END; // <-- This END is for the "ELSE". > > I recommend to use "BEGIN ... END" blocks in nested "IF" always to > prevent this kind of mistakes. > > Regards, > Guillermo "Ñuño" Martínez. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Pascal grammar: Program heading can include parameters
Hi,
I'm busy writing a Object Pascal grammar section for the Language Reference
doc.
In the ref.pdf (page 144) it says that the PROGRAM line can contain
'program parameters', but is ignored by the compiler. Can anybody explain
these "program parameters" and when and how they were actually used? I'm
just curious. This obviously stems from the original Pascal days.
Looking in the Kylix 3 Language Reference doc (page 3-2) it also mentions
the program parameters and also mentions that the compiler ignores those
parameters. :-/
Syntax is as follows:
Program -> PROGRAM Ident ['(' IdentList ')'] ';'
ProgramBlock '.'
Here is an actual implementation, and it compiles fine with FPC 2.4.x, but
you can't do anything with those parameters.
eg:
-[ test.pas ]--
program Test (param1, param2, param3, param4);
{$mode objfpc}{$H}
uses
Classes, SysUtils;
begin
writeln('hello world');
end.
--[ end ]--
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal grammar: Program heading can include parameters
In our previous episode, Graeme Geldenhuys said:
> I'm busy writing a Object Pascal grammar section for the Language Reference
> doc.
>
> In the ref.pdf (page 144) it says that the PROGRAM line can contain
> 'program parameters', but is ignored by the compiler. Can anybody explain
> these "program parameters" and when and how they were actually used? I'm
> just curious. This obviously stems from the original Pascal days.
In original pascal you had to specify all opened files there, including
input/output.
This was used by some OSes for their file I/O (e.g. VMS, where afaik the
shell allocates memory and handles for open files). There was also some
functionality for unnamed files (temporary ones).
If you want details, talk to the GPC people, read their docs (or Scott
Moore's site)
But usually there were assign() like non standarized workarounds to open
files later than at program start.
> Syntax is as follows:
>
> Program -> PROGRAM Ident ['(' IdentList ')'] ';'
> ProgramBlock '.'
Strange. Where are the modifiers (deprecated etc)? Or where unit level
modifiers post D7 ?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal grammar: Program heading can include parameters
Op 2010-07-01 12:14, Marco van de Voort het geskryf:
>
> In original pascal you had to specify all opened files there, including
> input/output.
Thanks for that history. :)
>> Syntax is as follows:
>>
>> Program -> PROGRAM Ident ['(' IdentList ')'] ';'
>> ProgramBlock '.'
>
> Strange. Where are the modifiers (deprecated etc)? Or where unit level
> modifiers post D7 ?
As far as I know modifiers are not allowed in a Program unit, only in a
Unit unit. FPC's ref.pdf and Kylix 3 lang ref doc seem to confirm this.
Here is the grammar for a UNIT.
Unit -> UNIT Ident [PortabilityDirective] ';'
InterfaceSection
ImplementationSection
InitSection '.'
...
PortabilityDirective -> platform
-> deprecated
-> library
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Is this if /else syntax wrong?
Zitat von Frank Church : I will be upgrading to 2.4.0 soon. It shouldn't be an error then. 2010/7/1 Guillermo Martínez Jiménez > procedure TfrmHometel.SetSplitterSizes; > var > i: integer; > begin > for i:=3D 0 to ComponentCount - 1 do > begin > if Components[i] is TSplitter then > begin > with TSplitter(Components[i]) do > begin > if Cursor =3D crHSplit then >Width :=3D 7 > else if Cursor =3D crVSplit then >Height :=3D 7; > ; // <-- removing this semicolon results in a syntax error. Is it > syntax error some kind of extra strict compiler check. > Color :=3D clBlue; > end; > end; > end; > end; Compare with next: if Cursor =3D crHSplit then Width :=3D 7 else if Cursor =3D crVSplit then Height :=3D 7; // <-- This semicolon is for the "if". ; // <-- This semicolon is for the "else". No. A semicolon ends *all* open if/if-else/do statements. The second semicolon is an empty statement - a 'no operation'. Is like this: IF ... THEN BEGIN ... END ELSE BEGIN IF ... THEN BEGIN ... END; // <-- This END is for the "IF". END; // <-- This END is for the "ELSE". I recommend to use "BEGIN ... END" blocks in nested "IF" always to prevent this kind of mistakes. In general I agree, but in this case there are no nested ifs, so it won't help here. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Is this if /else syntax wrong?
It is working now on 2.2.4. I think it was a temporary IDE glitch, which is what I suspected. Adding the ; made it go away, but it wasn't really the problem 2010/7/1 Mattias Gärtner > Zitat von Frank Church : > > > I will be upgrading to 2.4.0 soon. >> >> It shouldn't be an error then. >> >> 2010/7/1 Guillermo Martínez Jiménez >> >> > procedure TfrmHometel.SetSplitterSizes; >>> > var >>> > i: integer; >>> > begin >>> > for i:=3D 0 to ComponentCount - 1 do >>> > begin >>> > if Components[i] is TSplitter then >>> > begin >>> > with TSplitter(Components[i]) do >>> > begin >>> > if Cursor =3D crHSplit then >>> >Width :=3D 7 >>> > else if Cursor =3D crVSplit then >>> >Height :=3D 7; >>> > ; // <-- removing this semicolon results in a syntax error. Is it >>> > syntax error some kind of extra strict compiler check. >>> > Color :=3D clBlue; >>> > end; >>> > end; >>> > end; >>> > end; >>> >>> Compare with next: >>> >>> if Cursor =3D crHSplit then >>> Width :=3D 7 >>> else >>> if Cursor =3D crVSplit then >>> Height :=3D 7; // <-- This semicolon is for the "if". >>> ; // <-- This semicolon is for the "else". >>> >> > No. A semicolon ends *all* open if/if-else/do statements. > The second semicolon is an empty statement - a 'no operation'. > > > > Is like this: >>> >>> IF ... THEN >>> BEGIN >>> ... >>> END >>> ELSE BEGIN >>> IF ... THEN >>> BEGIN >>> ... >>> END; // <-- This END is for the "IF". >>> END; // <-- This END is for the "ELSE". >>> >>> I recommend to use "BEGIN ... END" blocks in nested "IF" always to >>> prevent this kind of mistakes. >>> >> > In general I agree, but in this case there are no nested ifs, so it won't > help here. > > Mattias > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Is this if /else syntax wrong?
Frank Church wrote on Thu, 01 Jul 2010: It is working now on 2.2.4. I think it was a temporary IDE glitch, which is what I suspected. Adding the ; made it go away, but it wasn't really the problem If you are using the textmode IDE, you might want to wait with updating until 2.4.2, because there was a bug in the 2.4.0 IDE that, in many cases, causes compilation to always fail (until a restart of the IDE) after an error occurred once (even if you fix that error). Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal grammar: Program heading can include parameters
On 7/1/10, Marco van de Voort wrote: > In original pascal you had to specify all opened files there, including > input/output. That is how I learned it (from a book about standard(?) pascal). I remember having several programs with long lists of files, before I discovered that this was not necessary in TP3 ;-) (My TP3 had written documentation in Arabic, which didn't help me all that much) Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
On Sun, 27 Jun 2010 09:50:35 +0200 Benjamin Jan Alexander Rosseaux wrote: > > Hello, > > I've done a working Free Pascal android JNI example (with working .apk > for current ARM-based Android device of the second device generation > (because with VFPv3, so Motorola Droid/Milestone, HTC Desire, Nexus One, > Samsung Galaxy S, and so on) inside) This sounds very interesting. I only played a little with FPC and Android, meaning I build the crosscompiler (which was quite easy) and tested some simple command line stuff. Of course I could not build .apks so my programs had to be uploaded and started via adb, but at least they worked fine. Unfortunately I currently have no time to play around with your code, but I will as soon as I can. From your mail it is not clear which ld and as you used. I just took them from the Android NDK, you too? Did you try if gdb and gprof are working? All in all great work and perhaps you can claim the bounty: http://wiki.lazarus.freepascal.org/Bounties#Cross-Compile_to_Android_on_Ubuntu_X64 My compiler runs on Ubuntu64, so yours should too and with JNI you are able to build real .apks which I think is good enough to claim the bounty. Thanks for showing us R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
