[fpc-pascal] Place of elements in record
Hi,
I'm developping a arm-embedded project. I need to store some variables
to EEPROM. What I'm doing now is manually give each variable an address
and then I use that address to store the variable in EEPROM.
Unfortunately, that's not easy. Yesterday I spent some hours trying to
see why the code I wrote does not work. This morning I thought of a
possible reason, and I think I'm right : I was overlapping some variables.
So I'm trying to find a simpler way to have the relative position of
variables to use as an address in an EEPROM.
I'm tinking about using a record. Is there a way to get the relative
position of a record-element ?
Some psuedo-code :
EEPROM_Content : record of
Var1 : byte;
Var2 : word;
Var3 : byte;
end{EEPROM_Content};
EEPROM_WriteByte(position of Var1 in EEPROM_Content,EEPROM_Content.Var1);
//position of Var1 in EEPROM_Content should be 0
EEPROM_WriteWord(position of Var2 in EEPROM_Content,EEPROM_Content.Var2);
//position of Var2 in EEPROM_Content should be 1
EEPROM_WriteByte(position of Var3 in EEPROM_Content,EEPROM_Content.Var3);
//position of Var3 in EEPROM_Content should be 4
I think I could use
@EEPROM_Content.Var1-@EEPROM_Content.Var1
@EEPROM_Content.Var2-@EEPROM_Content.Var1
@EEPROM_Content.Var3-@EEPROM_Content.Var1
as those positions, but is this computed at compile-time, or at run-time
? Am I right if I assume EEPROM_Content.Var1 is at relative position 0
in the record ?
I prefer to have the individual variables written to EEPROM, but maybe
writing the whole record in one go would be possible also. Then I don't
need to hassle with the positions. I mean, it _is_ possible to do that
but if it's suited for the project I don't know yet.
Other solutions ?
Mmm, writing things out clears the mind. I think it would be better to
write the whole record.
Thanks for your input.
Regards,
Koenraad Lelong
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get info about CPU and Memory usage?
On Wed, 27 Feb 2013, Graeme Geldenhuys wrote: On 2013-02-27 16:49, Michael Van Canneyt wrote: It is better to simply parse /proc/cpuinfo and /proc/PID/* and hope all distros behave the same. My experience with OnGuard work is that your mileage will vary. I happen to know the code will have to run only on 1 type of system. Even so, I would still advise this over running an external program. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On Thu, 28 Feb 2013, Simon Kissel wrote: exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running those tests, again on the same system, the Delphi executable completes the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same 180 tests!!! From our measures the Delphi and Kylix compilers in most cases on x86 produces code that is about in the order of 50% faster than FPC. You mentioned that you would like to contribute to FPC. Maybe this is an area where you can contribute: more aggressive optimizations. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Place of elements in record
On 02/28/2013 08:59 AM, Koenraad Lelong wrote: Other solutions ? type EEPROM_Content= record Var1 : byte; Var2 : word; Var3 : byte; end; ... @EEPROM_Content(nil^).Var2 gives you the relative address of Var2 in the record. Calculated at compile time. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Copying over one .pas and modifying it - problem with debug info or... me
Cryptic subject, isn't it? I tried to modify fpreadtiff.pas by copying only that module over to a new directory, write a test program that uses fpreadtiff, fpimage and other units. AFAIK from the User's Guide, 3.1.2, the fpreadtiff.pas in my program's directory should have been found first when searching for fpreadtiff, while other units are found in the search path (because they're not in my program directory). The test program works (I've put in a writeln to show it's modified) but debugging in Lazarus doesn't because it misses debug info. 1. Is what I am doing the right way? 2. Is there a problem with FPC generating no debug info/duplicate debug info? I've tried both with stabs and dwarf, with standard FPC 2.6.0 without debug info as well as FPC trunk with -gw2 -godwarfsets -gl Martin found problems with missing debug info in my log [1] [1] Discussion on http://lazarus.freepascal.org/index.php/topic,20066.0.html Test program in this post: http://lazarus.freepascal.org/index.php/topic,20066.msg115278.html#msg115278 Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get info about CPU and Memory usage?
Graeme Geldenhuys wrote: On 2013-02-27 16:49, Michael Van Canneyt wrote: It is better to simply parse /proc/cpuinfo and /proc/PID/* and hope all distros behave the same. My experience with OnGuard work is that your mileage will vary. For this sort of thing /proc/pid is the way to go, since- I'm pretty sure- it's what's used by ps so there are certain things that can't be changed. The non-pid stuff, specifically things like /proc/cpuinfo, is far more of a problem. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
ik wrote: Hello, I was going over the wiki and looked at http://wiki.freepascal.org/FPC_New_Features_Trunk . It looks like some of the features here, actually breaks Pascal, and create something like Jascal or something, but it's not Pascal in spirit. For example 1000.to_string ?! I have it on Ruby and Java, but it's not Pascal syntax. Same goes for array constructors. I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ? As long as it has the dangling-else flaw, it's 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Place of elements in record
Koenraad Lelong wrote: Hi, I'm developping a arm-embedded project. I need to store some variables to EEPROM. What I'm doing now is manually give each variable an address and then I use that address to store the variable in EEPROM. Unfortunately, that's not easy. Yesterday I spent some hours trying to see why the code I wrote does not work. This morning I thought of a possible reason, and I think I'm right : I was overlapping some variables. So I'm trying to find a simpler way to have the relative position of variables to use as an address in an EEPROM. I'm tinking about using a record. Is there a way to get the relative position of a record-element ? .. Mmm, writing things out clears the mind. I think it would be better to write the whole record. I'd suggest that this depends in part on the semiconductor technology. You might be best transferring individual fields for old-fashioned EEPROMs, or defining a larger block with a magic number for more RAM-like devices particularly if they have load-levelling. I've had to deal with the mess left by a contractor who was pathologically incapable of keeping NVR layout consistent across versions, and it wasn't pleasant. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Place of elements in record
On 28-02-13 09:41, Mark Morgan Lloyd wrote: I'd suggest that this depends in part on the semiconductor technology. You might be best transferring individual fields for old-fashioned EEPROMs, or defining a larger block with a magic number for more RAM-like devices particularly if they have load-levelling. Hi, I'm using old-fashioned EEPROM (1 kilobyte). In the device every write-cycle takes about 3ms. So writing individual variables each takes 3ms. But writing the whole record would also take 3ms (I think, I have to verify this). So it's tempting to do that. But a whole record could cross memory-pages, then the record needs to be split in two (or more) cycles. But at the moment I'm saving less than 20 variables, so splitting will be for later. Thanks for your input, same for you Ludo. Regards, Koenraad Lelong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
In our previous episode, ik said: I was going over the wiki and looked at http://wiki.freepascal.org/FPC_New_Features_Trunk . It looks like some of the features here, actually breaks Pascal, and create something like Jascal or something, but it's not Pascal in spirit. For example 1000.to_string ?! I have it on Ruby and Java, but it's not Pascal syntax. Same goes for array constructors. We already have had this discussion for VB (D4/COM extensions), .NET etc. Yes Delphi will copy everything what is popular in a desperate attempt to increase its appeal. I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ? FPC is not clean either. Constructs like case string of remind of basic and the proposed tuple support is not exactly hardcore imperative languges (let alone Pascal) either. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
In our previous episode, Graeme Geldenhuys said: That will probably rid us from some of the Pascal Language stereotyping. :) RemObjects (with their Oxygene language) tagline says it best: This is not your daddy's pascal I love that tagline. So Sulphur then? It is the next element in the same group of the periodic table and twice as heavy as Oxygen? Moreover hints at being a bit evil and vile. The idea behind hinting on that last bit is if we simply admit we are dirty, we won't have any useless cleanness discussions anymore? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
2013/2/28 Simon Kissel sc...@untergrund.net: In the long run, new object pascal language features optimally should be discussed by those active in the field BEFORE they get implemented. Sadly right now Embarcadero still are far too arrogant and close-minded to understand that FPC actually benefits the ecosystem they sell products in. So let's call the Delphi-compatible version Rascal ? ;) All this being said: I know that FPC is not after business goals. But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not. I agree. We need better optimisations at least as much as fancy 123.tostring. Is there other companies here interested in Linux 64 bits target optimisations ? -- Marc Pertron CTO at Mailjet.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 27.02.2013 23:40, ik wrote: Hello, I was going over the wiki and looked at http://wiki.freepascal.org/FPC_New_Features_Trunk . It looks like some of the features here, actually breaks Pascal, and create something like Jascal or something, but it's not Pascal in spirit. For example 1000.to_string ?! I have it on Ruby and Java, but it's not Pascal syntax. Same goes for array constructors. The main language dialect used with FPC (though its not the default one) is Object Pascal, not Pascal. If you want Pascal, then stop using classes immediately! Object Pascal unlike Pascal is not defined anywhere as the driving force behind it is Delphi. I personally don't agree with some syntaxes as well, but I'm mostly all for the feature they represent. For example anonymous functions: ugly as hell, but this concept of closures is awesome. When the anonymous methods from Blais' branch will be ready for merging I'll extend the so far that we can also pass nested functions to them (which isn't allowed in Delphi), so that one can use it's power without cluttering the code. Also I'll think about adding a less verbose syntax for simple cases (more lambda syntax like, but more Pascal like than the variation from Oxygene). Another example: Attributes. The idea that you can tag attributes to classes, their fields and methods is a wonderful one. This way you can group additional information (e.g. DB field, HTTP Parameter, etc.) together with the element it represents. It also opens the possiblity for automatic Dependency Injection which can reduce code coupling (which is good except for performance critical systems like the compiler) and thus also simplyfy testing. Yet I find the syntax absolutely un-Pascal-like. Those prefixed attributes are simply copied from C#. My plan is currently before Joost's branch with attributes is merged that I extend the syntax in mode ObjFPC to be a suffix instead like virtual and deprecated modifiers behind which the attributes in a [...] block follow. And for array constructors: I would prefer somearray := [ element1, element2, element3 ]; instead and maybe I'll implement that somewhen in the future :) For the type helpers I've also done something more consequential: in Delphi helpers for primitive types are declared as record helper while in ObjFPC they are declared by type helper. It's very likely that I'll allow the usage of records in type helper as well and deprecate the record helper syntax in ObjFPC (it will be kept of course for backwards compatibility to 2.6.x). I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ? As others already said: There are components or frameworks out there that use modern Delphi features or frameworks of other languages that make use of such features. Example: DSpring, which is a Delphi dependency injection framework. Another example I'd like to see is .NET's Reactive Extensions which allow you to work with asynchronous data streams (which requires interface helpers and closures). Maintaining a language is not only about satisfying users that are happy with the current state. Languages evolves and so should do Pascal. While we currently do follow Delphi's lead my plan is to also research (not necessarily implement in trunk!) language features that aren't found in Delphi, but in other languages. Features like type inference, duck typing, aspect oriented programming and traits. By implementing them we can attract developers which got used to such features and swear that they can simplyfy work. Yet I'm also aware about the heritage we have and that we must honor it. Which is why I want to implement no language features in an as Pascal way as possible and which is also why I was opposed to the tuple feature as suggested by Alexander. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpweb: handling DELETE method as well as GET
Using fpweb, I'm trying to handle DELETE requests.
The code below works for GET calls:
GET /cgi-bin/tigercgi/document/ HTTP/1.1 200
but gives a 500 server error for DELETE calls:
DELETE /cgi-bin/tigercgi/document/ HTTP/1.1 500
The code doesn't even seem to hit the function:
AResponse.Contents.Add('pGot request method: '+ARequest.Method+'/p');
doesn't seem to be hit.
How should I fix this?
Thanks,
Reinier
procedure TFPWebdocument.DataModuleRequest(Sender: TObject; ARequest:
TRequest;
AResponse: TResponse; var Handled: Boolean);
// We don't define any actions but handle the request at the module
level before any actions would be evaluated.
{
DELETE http://server/cgi-bin/tigercgi/document///delete all docs?!?!
GEThttp://server/cgi-bin/tigercgi/document///list of docs
DELETE http://server/cgi-bin/tigercgi/document/304 //remove document
with id 304
GEThttp://server/cgi-bin/tigercgi/document/304 //get document with
id 304
}
var
DocumentID: integer;
IsValidRequest: boolean;
StrippedPath: string;
begin
IsValidRequest:=false;
{
pathinfo apparently returns something like
/document/304
StrippedPath will remove trailing and leading /
}
StrippedPath:=copy(ARequest.PathInfo,2,Length(ARequest.PathInfo));
if RightStr(StrippedPath,1)='/' then
StrippedPath:=Copy(StrippedPath,1,Length(StrippedPath)-1);
AResponse.Contents.Add('ptodo: debug; document module/p');
AResponse.Contents.Add('pGot request method: '+ARequest.Method+'/p');
// Make sure the user didn't specify levels in the URI we don't support:
case ARequest.Method of
'DELETE':
begin
case WordCount(StrippedPath,['/']) of
1: //http://server/cgi-bin/tigercgi/document/
begin
IsValidRequest:=true;
//todo: delete every document
AResponse.Contents.Add('ptodo delete all documents/p');
end;
2: //http://server/cgi-bin/tigercgi/document/304
begin
DocumentID:=StrToIntDef(ExtractWord(2,StrippedPath,['/']),
INVALIDID);
if DocumentIDINVALIDID then IsValidRequest:=true;
//todo: delete given document
AResponse.Contents.Add('ptodo delete document
'+inttostr(documentid)+'/p');
end;
end;
end;
'GET':
begin
case WordCount(StrippedPath,['/']) of
1: //http://server/cgi-bin/tigercgi/document/
begin
IsValidRequest:=true;
//todo: get every document
AResponse.Contents.Add('ptodo get all documents/p');
end;
if not(IsValidRequest) then
begin
AResponse.Code:=404;
AResponse.CodeText:='Document not found.';
AResponse.Contents.Add('pDocument not found/invalid request/p');
end;
Handled:=true;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
Am 28.02.2013 10:56, schrieb Sven Barth: [...] Features like type inference, duck typing, aspect oriented programming and traits. By implementing them we can attract developers which got used to such features and swear that they can simplyfy work. But there should be a line that nobody will cross. Otherwise someday someone try to attract PHP developers with removing the type safety from Free Pascal. *shudder* Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 28.02.2013 11:18, Michael Fuchs wrote: Am 28.02.2013 10:56, schrieb Sven Barth: [...] Features like type inference, duck typing, aspect oriented programming and traits. By implementing them we can attract developers which got used to such features and swear that they can simplyfy work. But there should be a line that nobody will cross. Otherwise someday someone try to attract PHP developers with removing the type safety from Free Pascal. *shudder* I can guarantee you that *I* won't be the one who will cross that line ;) Type safety is one of the main features of Pascal based languages and without that it would definitely not be Pascal any longer ^^ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpweb: handling DELETE method as well as GET
On 28-2-2013 10:58, Reinier Olislagers wrote:
Using fpweb, I'm trying to handle DELETE requests.
The code below works for GET calls:
GET /cgi-bin/tigercgi/document/ HTTP/1.1 200
but gives a 500 server error for DELETE calls:
DELETE /cgi-bin/tigercgi/document/ HTTP/1.1 500
The code doesn't even seem to hit the function:
AResponse.Contents.Add('pGot request method: '+ARequest.Method+'/p');
doesn't seem to be hit.
How should I fix this?
Oh, the Apache error log shows this for for the delete requests:
Premature end of script headers: tigercgi
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC Lazarus used for teaching down under
Hi, I thought I would share this bit of info. I'm not sure what I am more impressed about though. The fact that a long time Delphi developers is [finally] impressed with FPC / Lazarus, or the fact that pascal is still being used in some places [in this case, Melbourne Australia] for teaching programming. :-) Well done Peter, and keep up the good work. Spread the pascal love... -- Forwarded message -- From: Peter Hinrichsen Date: 28 February 2013 09:49 Subject: Re: tiOPF: repository migrated to Git To: Graeme Geldenhuys, Ian Krigsman ...sip... Am taking a bit of a right-hand turn with work - am teaching four classes a week of programming to Year 5 - 9 kids. The younger kids start with Lego robotics their software, then we move to programming Lego with C, then game programming with FPC. Am very impressed with FPC / Lazarus. P. --[ end ]--- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpweb: handling DELETE method as well as GET
On Thu, 28 Feb 2013, Reinier Olislagers wrote:
On 28-2-2013 10:58, Reinier Olislagers wrote:
Using fpweb, I'm trying to handle DELETE requests.
The code below works for GET calls:
GET /cgi-bin/tigercgi/document/ HTTP/1.1 200
but gives a 500 server error for DELETE calls:
DELETE /cgi-bin/tigercgi/document/ HTTP/1.1 500
The code doesn't even seem to hit the function:
AResponse.Contents.Add('pGot request method: '+ARequest.Method+'/p');
doesn't seem to be hit.
How should I fix this?
Oh, the Apache error log shows this for for the delete requests:
Premature end of script headers: tigercgi
I am on it. Need it myself at this very moment.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 2013-02-28 09:31, ik wrote: But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use. +1 Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 2013-02-28 09:56, Sven Barth wrote: Which is why I want to implement no language features in an as Pascal way as possible I very much appreciate your efforts, and do like the fact that you try and keep new language features more pascal-like. Kudos for that. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get info about CPU and Memory usage?
On 2013-02-28 08:12, Michael Van Canneyt wrote: Even so, I would still advise this over running an external program. Agreed. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpweb: handling DELETE method as well as GET
On Thu, 28 Feb 2013, Reinier Olislagers wrote:
On 28-2-2013 10:58, Reinier Olislagers wrote:
Using fpweb, I'm trying to handle DELETE requests.
The code below works for GET calls:
GET /cgi-bin/tigercgi/document/ HTTP/1.1 200
but gives a 500 server error for DELETE calls:
DELETE /cgi-bin/tigercgi/document/ HTTP/1.1 500
The code doesn't even seem to hit the function:
AResponse.Contents.Add('pGot request method: '+ARequest.Method+'/p');
doesn't seem to be hit.
How should I fix this?
Oh, the Apache error log shows this for for the delete requests:
Premature end of script headers: tigercgi
Fixed in rev. 23667.
In fact, I've disabled the method checking altogether.
At a later point, we can consider having a property that
checks the method and enforces a HTTP spec compliant method.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. An llvm target will move the optimisation burden away from fpc, which would be very interesting. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
Well:
{$mode jascal}{$H+}
:)
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Lazarus used for teaching down under
On Thu, Feb 28, 2013 at 7:37 AM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: Hi, I thought I would share this bit of info. I'm not sure what I am more impressed about though. The fact that a long time Delphi developers is [finally] impressed with FPC / Lazarus, or the fact that pascal is still being used in some places [in this case, Melbourne Australia] for teaching programming. :-) Well done Peter, and keep up the good work. Spread the pascal love... -- Forwarded message -- From: Peter Hinrichsen Date: 28 February 2013 09:49 Subject: Re: tiOPF: repository migrated to Git To: Graeme Geldenhuys, Ian Krigsman ...sip... Am taking a bit of a right-hand turn with work - am teaching four classes a week of programming to Year 5 - 9 kids. The younger kids start with Lego robotics their software, then we move to programming Lego with C, then game programming with FPC. Am very impressed with FPC / Lazarus. P. --[ end ]--- Regards, - Graeme - Very good! But I'm afraid if someone thinking if Pascal is just for kids 5-9 years old... not here, but out there! :) Thank you for share it. Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On 28.02.2013 11:45, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. Optimisation is also not necessarily easy. Especially if you are on the assembler level you need to know the CPU's characteristics. I might dive a bit deeper into the topic of optimizations once m68k is ready for optimizations... (currently I only use -O- there :) ) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpweb: handling DELETE method as well as GET
On 28-2-2013 12:22, Michael Van Canneyt wrote: On Thu, 28 Feb 2013, Reinier Olislagers wrote: On 28-2-2013 10:58, Reinier Olislagers wrote: Using fpweb, I'm trying to handle DELETE requests. The code below works for GET calls: GET /cgi-bin/tigercgi/document/ HTTP/1.1 200 but gives a 500 server error for DELETE calls: DELETE /cgi-bin/tigercgi/document/ HTTP/1.1 500 The code doesn't even seem to hit the function: Fixed in rev. 23667. Ok, that works, thanks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Lazarus used for teaching down under
On 28/02/13 12:19, Marcos Douglas wrote: Very good! But I'm afraid if someone thinking if Pascal is just for kids 5-9 years old... not here, but out there! :) Thank you for share it. Year 5-9 kids refers to their school year, not their calendar age. In the UK a Year 9 teenager is 13 or 14 years old. I imagine the school year numbering scheme in Australia is similar. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Lazarus used for teaching down under
On Thu, Feb 28, 2013 at 9:54 AM, Howard Page-Clark h...@talktalk.net wrote: On 28/02/13 12:19, Marcos Douglas wrote: Very good! But I'm afraid if someone thinking if Pascal is just for kids 5-9 years old... not here, but out there! :) Thank you for share it. Year 5-9 kids refers to their school year, not their calendar age. In the UK a Year 9 teenager is 13 or 14 years old. I imagine the school year numbering scheme in Australia is similar. Oh, Ok. I read fast, sorry. Thanks for the explanation. Best regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On Feb 28, 2013 5:23 AM, Henry Vermaak henry.verm...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. An llvm target will move the optimisation burden away from fpc, which would be very interesting. Henry Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On Thu, Feb 28, 2013 at 07:43:15AM -0600, Kenneth Cochran wrote: On Feb 28, 2013 5:23 AM, Henry Vermaak henry.verm...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. An llvm target will move the optimisation burden away from fpc, which would be very interesting. Henry Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. Not just performance, they gain access to all the architectures that llvm supports. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPJSON and float values.
Hello, Please see: http://bugs.freepascal.org/view.php?id=23970 Thank you! -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
In our previous episode, Kenneth Cochran said: Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. And, like LLVM, they only care about popular targets anyway. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On Thu, 28 Feb 2013 10:56:42 +0100 Sven Barth pascaldra...@googlemail.com wrote: As others already said: There are components or frameworks out there that use modern Delphi features or frameworks of other languages that make use of such features. Example: DSpring, which is a Delphi dependency injection framework. I did not find DSpring. Do you mean Spring4D? If this is the case I'd rather stay with the real thing (meaning Spring Framework for Java). By implementing them we can attract developers which got used to such features and swear that they can simplyfy work. This I highly doubt. Why should I change languages only because FPC now has a feature that I already have in Java/Ruby/Groovy/etc and leave all the libraries and frameworks behind to get win32 only frameworks that are chasing the features of the multiplatform ones I left? If you are not a Pascal guy you won't become one just because FPC supports closures or dependency injection or whatever. Delphi is trying hard to stay relevant and so is FPC by following because becoming too different to Delphi will make the community quite a bit smaller. That's all there is to the new features. Pascal is a niche language and will stay one. There won't be the year of Pascal and suddenly thousands of developers start using it. You may write the next Facebook in FPC and it won't matter. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
On Thu, 28 Feb 2013, silvioprog wrote: Hello, Please see: http://bugs.freepascal.org/view.php?id=23970 Fixed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
2013/2/28 Michael Van Canneyt mich...@freepascal.org On Thu, 28 Feb 2013, silvioprog wrote: Hello, Please see: http://bugs.freepascal.org/**view.php?id=23970http://bugs.freepascal.org/view.php?id=23970 Fixed. Michael. Wow, very fast. Thank you very much buddy! :) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 02/28/2013 03:25 AM, Marco van de Voort wrote: So Sulphur then? It is the next element in the same group of the periodic table and twice as heavy as Oxygen? Moreover hints at being a bit evil and vile. Won't work. The truth is: 1.) most don't kown/know their current state. 2.) those that do, are rightly wanting to align properly. 3.) loss of naturally good talent (it only takes one bad idea to misguide) 4.) draw of skilled talent that binds contention. 5.) there is a measurable force that supports M$'s (project of the day). The force involves collective conscientiousness. And control over perception. The social fabric is presently being shaped in their favor. From our perspective, no-one ever lost their teeth buying Microsoft's Windows. But from their perspective, no-one ever lost their job buying a M$ project. Both perceptions are negative towards the truth. Proof to me that they have successfully adopted a viable strategy. 6.) Collective conscientiousness demonstrates that Pascal is a dead language. So either we overcome the notion that the language is dead (my favourite) or perhaps call it something else and try to ignite a spark and see what happens. The idea behind hinting on that last bit is if we simply admit we are dirty, we won't have any useless cleanness discussions anymore? With strong acting/performance project, cleanliness is just inherent. So I would say sure. With such a project, bad code would be limited to reflect on the code contributor/creator. But to 1.) above, wrongly kowning up to bad code contributions is my largest genuine concern. -- Andrew Brunner Aurawin LLC 15843 Garrison Circle Austin, TX 78717 https://aurawin.com Aurawin is a great new way to store, share, and explore all your content featuring our innovative cloud social computing platform. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Copying over one .pas and modifying it - problem with debug info or... me
On 28-2-2013 9:24, Reinier Olislagers wrote: The test program works (I've put in a writeln to show it's modified) but debugging in Lazarus doesn't because it misses debug info. 1. Is what I am doing the right way? 2. Is there a problem with FPC generating no debug info/duplicate debug info? I've tried both with stabs and dwarf, with standard FPC 2.6.0 without debug info as well as FPC trunk with -gw2 -godwarfsets -gl Martin found problems with missing debug info in my log [1] [1] Discussion on http://lazarus.freepascal.org/index.php/topic,20066.0.html Test program in this post: http://lazarus.freepascal.org/index.php/topic,20066.msg115278.html#msg115278 Martin's post: http://lazarus.freepascal.org/index.php/topic,20066.msg115300.html#msg115300 I checked your new code again (just with GDB 7.5): It claims, that the exe contains no code for TFPReaderTiff.ReadImgValue (from your unit). It does not matter if that claim is right or wrong. If the claim is wrong, it still can not be fixed in the IDE. --- I put a writeln in there. And it gets called. So gdb/fpc or linker is wrong. It seems to be the linker. At least on windows. If I use -Xe (external linker) then it works. So you an check with the FPC team if this is a known issue with the build in linker, or if you should report it as a bug. 3. Is this a known issue with the built-in linker or should I report a bug? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
Btw, there is already an object pascal implementation targeting llvm. https://code.google.com/p/llvm-pascal/ On Thu, Feb 28, 2013 at 8:36 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Kenneth Cochran said: Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. And, like LLVM, they only care about popular targets anyway. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
In our previous episode, Kenneth Cochran said: Btw, there is already an object pascal implementation targeting llvm. https://code.google.com/p/llvm-pascal/ I know. Afaik it was for teaching purposes though, not for production. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
2013/2/28 Michael Van Canneyt mich...@freepascal.org: On Thu, 28 Feb 2013, silvioprog wrote: Hello, Please see: http://bugs.freepascal.org/view.php?id=23970 Fixed. Seems that you committed by accident code to make AsJSON output more compact. This may lead to compatibility problems. Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
On Thu, 28 Feb 2013, luiz americo pereira camara wrote: 2013/2/28 Michael Van Canneyt mich...@freepascal.org: On Thu, 28 Feb 2013, silvioprog wrote: Hello, Please see: http://bugs.freepascal.org/view.php?id=23970 Fixed. Seems that you committed by accident code to make AsJSON output more compact. This may lead to compatibility problems. You are right. I fixed this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
2013/2/28 luiz americo pereira camara luiz...@oi.com.br
2013/2/28 Michael Van Canneyt mich...@freepascal.org:
On Thu, 28 Feb 2013, silvioprog wrote:
Hello,
Please see:
http://bugs.freepascal.org/view.php?id=23970
Fixed.
Seems that you committed by accident code to make AsJSON output more
compact.
This may lead to compatibility problems.
Luiz
You touched on an important point. It would be nice to be able to customize
the output format of JSON. For example, currently the fpjson format is this:
{ foo : bar }
And I personally prefer:
{ foo: bar }
The latter format is what we see in all JavaScript libraries. :)
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
On Thu, 28 Feb 2013, silvioprog wrote:
2013/2/28 luiz americo pereira camara luiz...@oi.com.br
2013/2/28 Michael Van Canneyt mich...@freepascal.org:
On Thu, 28 Feb 2013, silvioprog wrote:
Hello,
Please see:
http://bugs.freepascal.org/view.php?id=23970
Fixed.
Seems that you committed by accident code to make AsJSON output more compact.
This may lead to compatibility problems.
Luiz
You touched on an important point. It would be nice to be able to customize the
output format of JSON. For example, currently
the fpjson format is this:
{ foo : bar }
And I personally prefer:
{ foo: bar }
The latter format is what we see in all JavaScript libraries. :)
I will not change the default format. Whitespace is irrelevant anyway.
But: If you want to customize the output, you can use the FormatJSON function.
It has many options.
If you think of additional formatting options for this method, you are welcome
to provide a patch.
But please note that all these wishes will have impact on speed.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPJSON and float values.
2013/2/28 Michael Van Canneyt mich...@freepascal.org
On Thu, 28 Feb 2013, silvioprog wrote:
2013/2/28 luiz americo pereira camara luiz...@oi.com.br
2013/2/28 Michael Van Canneyt mich...@freepascal.org:
On Thu, 28 Feb 2013, silvioprog wrote:
Hello,
Please see:
http://bugs.freepascal.org/**view.php?id=23970http://bugs.freepascal.org/view.php?id=23970
Fixed.
Seems that you committed by accident code to make AsJSON output more
compact.
This may lead to compatibility problems.
Luiz
You touched on an important point. It would be nice to be able to
customize the output format of JSON. For example, currently
the fpjson format is this:
{ foo : bar }
And I personally prefer:
{ foo: bar }
The latter format is what we see in all JavaScript libraries. :)
I will not change the default format. Whitespace is irrelevant anyway.
But: If you want to customize the output, you can use the FormatJSON
function. It has many options.
If you think of additional formatting options for this method, you are
welcome to provide a patch.
But please note that all these wishes will have impact on speed.
Michael.
You're right.
By default, the output could be uglify (without spaces). It is more fast.
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
Am 28.02.2013 01:16, schrieb Simon Kissel: All this being said: I know that FPC is not after business goals. But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not. The mission goal of FPC is to provide an OSS pascal compiler in a community effort by pascal users so this implicitly means that we try to avoid to destroy the ecosystem we are living in. So FPC tries also to support as much as possible pascal dialects. Actually, nothing prevents people to provide a completly rewritten rtl throwing old stuff away but it must live together with the existing one. Staying with the bazaar and cathedral metapher: one can always build up his own market stand in FPC's bazaar. But one cannot come with a big bulldozer and remove other people's stand to make room for the own stand. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 28.02.2013 15:40, Reimar Grabowski wrote:
On Thu, 28 Feb 2013 10:56:42 +0100
Sven Barth pascaldra...@googlemail.com wrote:
As others already said: There are components or frameworks out there
that use modern Delphi features or frameworks of other languages that
make use of such features. Example: DSpring, which is a Delphi
dependency injection framework.
I did not find DSpring. Do you mean Spring4D? If this is the case I'd rather
stay with the real thing (meaning Spring Framework for Java).
Yes, sorry, I did indeed mean Spring4D. And staying with the real thing
does only help if you use Java...
By implementing them we can attract developers which got used to such features
and swear that
they can simplyfy work.
This I highly doubt. Why should I change languages only because FPC now has a
feature that I already have in Java/Ruby/Groovy/etc and leave all the libraries
and frameworks behind to get win32 only frameworks that are chasing the
features of the multiplatform ones I left?
If you are not a Pascal guy you won't become one just because FPC supports
closures or dependency injection or whatever.
There are people that aren't as fixed with their programming language as
me (though I DO use C/C++ or even Java if the need exists...) and do
take a look here and then for other languages, because they might be
unhappy with a few things. I have a friend for example who is - in his
company - a PHP developer (and he likes it), but when he started a
bigger hobby project he had taken a look at Free Pascal and liked it.
Delphi is trying hard to stay relevant and so is FPC by following because
becoming too different to Delphi will make the community quite a bit smaller.
That's all there is to the new features. Pascal is a niche language and will
stay one. There won't be the year of Pascal and suddenly thousands of
developers start using it. You may write the next Facebook in FPC and it won't
matter.
The interesting thing is how long can we afford to follow Delphi? They
added a {$ZEROBASEDSTRINGS} directive in XE3, added type helpers (they
didn't just add them because of nothing) and seem to want to add
automatic reference counting to TObject. Put this together with them
developing a completely new compiler and this *might* lead to them
dropping backwards compatibility. This event would be - in my opinion -
where we definitely need to stop swimming in their backwash and steer free.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On 28.02.2013 12:22, Henry Vermaak wrote: On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. An llvm target will move the optimisation burden away from fpc, which would be very interesting. While we would welcome a LLVM backend it is basically a consent in the development team that this would only be an additional alternative to the normal backends FPC provides. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [news] DA-Soft discontinues AnyDAC component suite
On 5/2/2013 9:44 μμ, Sven Barth wrote: Does this fall under worst fears confirmed? At least from the POV of a FPC user... The first release of FireDac comes with FPC package included how well this works or how long it will last I have no idea. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [news] DA-Soft discontinues AnyDAC component suite
On 28.02.2013 20:00, stdreamer wrote: On 5/2/2013 9:44 μμ, Sven Barth wrote: Does this fall under worst fears confirmed? At least from the POV of a FPC user... The first release of FireDac comes with FPC package included how well this works or how long it will last I have no idea. In their FAQ they only talk about Delphi XE3 and C++ builder... also they mention in Does it work with other IDEs? No, it doesn't... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On Thu, 28 Feb 2013 19:46:07 +0100 Sven Barth pascaldra...@googlemail.com wrote: Yes, sorry, I did indeed mean Spring4D. And staying with the real thing does only help if you use Java... Which was implicit. Choosing the right tool for the job (in this case Spring). If this means using a different language so be it. a PHP developer (and he likes it), but when he started a bigger hobby project he had taken a look at Free Pascal and liked it. PHP and developer in the same sentence, funny stuff. :) And he likes Pascal because of class helpers, (upcoming) closures and all the other fancy new stuff? If not your anecdote does not fit the topic at hand. He may also like it because pascal is a nice and clean language which is easy to learn and not because of the new features. But your point was that new developers come to FPC BECAUSE it now has the stuff they are used to. And this I doubt. This event would be - in my opinion - where we definitely need to stop swimming in their backwash and steer free. My opinion has always been that neither FPC nor Lazarus should try so hard to be compatible. Doing your own stuff instead of following Delphi downhill has its benefits. But this is all up to the developers and not my business. If I don't like the changes, I don't have to use them. Easy as that. Looking forward to seeing FPC 'steer free' because then I can grab my skates and go ice skating in hell. :) R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 28.02.2013 21:42, Reimar Grabowski wrote: On Thu, 28 Feb 2013 19:46:07 +0100 Sven Barth pascaldra...@googlemail.com wrote: Yes, sorry, I did indeed mean Spring4D. And staying with the real thing does only help if you use Java... Which was implicit. Choosing the right tool for the job (in this case Spring). If this means using a different language so be it. For me it's more about providing the FPC users with the possiblities to nicely do things like dependency injection, etc. a PHP developer (and he likes it), but when he started a bigger hobby project he had taken a look at Free Pascal and liked it. PHP and developer in the same sentence, funny stuff. :) And he likes Pascal because of class helpers, (upcoming) closures and all the other fancy new stuff? If not your anecdote does not fit the topic at hand. He may also like it because pascal is a nice and clean language which is easy to learn and not because of the new features. But your point was that new developers come to FPC BECAUSE it now has the stuff they are used to. And this I doubt. Ehm... ok... that was indeed a bad example -.- This event would be - in my opinion - where we definitely need to stop swimming in their backwash and steer free. My opinion has always been that neither FPC nor Lazarus should try so hard to be compatible. Doing your own stuff instead of following Delphi downhill has its benefits. But this is all up to the developers and not my business. If I don't like the changes, I don't have to use them. Easy as that. We have different language dialects after all. As I already wrote in one of my previous mails I try to implement Delphi features in a more Pascal like way if I see it fit. And with most of the principles BEHIND that features I agree (e.g. attributes, closures, etc.). Looking forward to seeing FPC 'steer free' because then I can grab my skates and go ice skating in hell. :) I wouldn't mind the hell not freezing over even if we steer free... I'm saying this after I've spent most of the day in a +6 degree celsius cold satellite antenna... ( https://ssimuc.de/content/pmwiki.php?n=Main.Groundstation ) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
Hi, first of all: no matter what - stay with 'Free Pascal' - I don't think there would be any advantage renaming a project - except for the whole project loosing its identity. My experience is that most people don't even know Pascal - I wouldn't say Pascal as a language has a bad reputation. [Every time a program crashes with segfault or similar, I wish it had been written in Pascal... :) ] But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use. +1 from my side, too. I wouldn't see it as closely. Only dead languages are static - there is no good reason to hinder well thought out features to be added, as long as they support the IMO most important two goals of Pascal: readability, and type safety. BUT: the sheer amount mustn't be decisive - feature bloat can have very negative effects... Optimisation is a topic which really needs to be discussed - maybe when fpc reaches a (temporary) state of temporary 'feature completeness'. [lets 2.X be the feature version, 3.X the optimised version :D ] Especially for mobile targets well optimised / efficient programs have great advantage, but the problem mostly is not speed, but energy consumption. [Btw. big thanks for merging the android branch +100] Nice to hear, that the option to 'detach' from Delphi is considered here as well, as I'm sure there will be no other option sooner or later... Last OT: I wouldn't mind the hell not freezing over [...] Nice... It's pretty damn cold in this area (almost at my front door) for this time of the year, so that's really a valid wish... :) Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
On 2013-03-01 00:04, dev.d...@gmail.com wrote: first of all: no matter what - stay with 'Free Pascal' - I don't think there would be any advantage renaming a project We were only joking around with the name. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
All the new strange features doesn't really matter as long as: 1) the backward compatibility is in place (and or guidelines are given how to make the code compatible with minimal efforts) 2) executable size doesn't suffer much ;) 3) the new target is supported and the existing code can be applied to it. Luckily, syntactic sugar is really optional and it is up to developers to discipline themselves not using it. It might be unavoidable to interface with a target platform, but in this case unholy unpascalish code can be locked away into a separate unit, to keep the cross-platform core library nice and clean. Self-discipline. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
Am 2013-03-01 04:41, schrieb dmitry boyarintsev: All the new strange features doesn't really matter as long as: 1) the backward compatibility is in place (and or guidelines are given how to make the code compatible with minimal efforts) 2) executable size doesn't suffer much ;) 3) the new target is supported and the existing code can be applied to it. The problem with this is that you cannot read code written by others anymore unless you learn *all* details about the large number of added features. And that's meanwhile like learning 2-3 other languagues and no longer the easy to learn Pascal of earlier times. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
