[fpc-devel] Lazarus/fpc on Apple store. Crazy Idea or smart move?
Hi fpc developers. On my Mac I tested the UTM virtualization, and I stumbled in that sentence from UTM website: UTM is and always will be completely free and open source. The Mac App Store version is identical to the free version and there are no features left out of the free version. The only advantage of the Mac App Store version is that you can get automatic updates. Purchasing the App Store version directly funds the development of UTM and shows your support . Couldn't we do the same? The advantages: 1. coming from a known developer the free download of dmg would not be subject to the annoying procedure of forcing installation 2. purchasers would provide a source of financing for the Lazarus/fpc project Disadvantages: 1. an affordable annual fee, which should however be more than compensated by the income 2. none other I can see Taking into account that: * UTM is provided by a Chinese company, which lives on that product, and a companion Iso image downloader. * That Chinese business traditions date from before the foundation of Rome and they hardly invest in something not ensuring a good return I believe that the matter does deserve further investigation. What do you think? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alignment issue on macOS 13 with Xcode 15 and up
Il 04/10/23 12:19, Karl-Michael Schindler via fpc-devel ha scritto: With the command line tools of Xcode 14 it runs through without any warning nor error. Would a patch from this commit (https://gitlab.com/freepascal.org/fpc/source/-/blob/82dd70e72f3ab33b1b8737f743e1cdd009d9c8a1/compiler/x86_64/cpupara.pas) help? By googling around I found a lot of complaints of Mac users about XCode 15 incompatibilities with previous versions, and weird errors. Maybe it would be wise to wait that Apple fixes Xcode 15 before patching fpc. One might be forced to revert the patch. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cocoa and NOT relocatable
Il 08/06/23 20:33, Martin Frb via fpc-devel ha scritto: Great... Yes, it is an important security feature. But a show stopper for people who need to debug. https://forum.lazarus.freepascal.org/index.php/topic,63571.0.html 1) Afaik, FPC still can't resolve addresses with -gl (the line info unit, that produces nice dumps on other Platforms). 2) Users can't later resolve them either. I wasn't aware of the ASLR feature. But digging in my memory I remembered a similar crash issue. After digging in the scant information provided by the debugger it turned out that the problem was generated in the thread initialization code. As in the application involved I wasn't using threads, I just commented out the cthreads line in the uses clause, and the problem disappeared. I didn't investigate further. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cocoa and NOT relocatable
Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto: It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that dumping a stack at runtime for each run (no new compile) gives new addresses. Fpc 3.2.2 Is there a way to turn this off? (some flag to pass to the linker?) AFAIK there's no way. It's a feature deep in the way the OS handles memory. In a multiprogramming environment any executable must be by definition relocatable, because at each run it must fit in a free area of memory. So the OS has two choices. Either the executable is not relocatable, and you trick it by altering the Memory Management Unit tables to map its virtual fixed addresses to any free memory area, or you make it relocatable, loose a little time when loading to locate it, and do not tamper with MMU mapping tables. It's a system design choice. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: In the meantime, I'm working on making "as" and "is" work with ordinal types as well as enumerations, although currently some headaches occur if the right-hand side is larger than the CPU word size (e.g. Int64 on i386). I'll upload the patch to the issue once it's working properly. Sorry for jumping in without having followed the full discussion, but I wonder if "as" and "is" are the best constructs to implement range checking. Wouldn't "in" be much more appropriate? Sort of: if value in enumvar then DoThat else IgnoreIt; Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TRegistry and Unicode
Il 14/03/2019 18:32, Bart ha scritto: That is not really the issue. My machine is Win10 on i5 with 8GB memory. I run Mint in aVirtualBox VM (a bit sluggish, but do-able). I don't have a Windows installable medium with license that I can install into a VM. And I'm not gonna buy it, nor am I gonna use some pitate copy. You don't need to buy a licence, or to use a pirated copy to run your Windows in a VM. You may run your legal copy of Windows on a VM just by using the raw disk or raw partition feature of VirtualBox. What I've done is the following. I have repartitioned the original disk in order to free enough space for a Linux install. By installing Linux on the free space, the first result is to have a dual boot box. Then, in Linux I have created my VM machines, and among them a Windows VM which just uses the Windows partitions of the disk. That way the physical disk is the same of the original install, and Windows doesn't complain about licensing issues. You may find detailed instructions on how to do it in the VirtualBox Help, under Advanced topics->Advanced storage configuration. But basically that's done from Linux with just one command line, which in my case is: VBoxManage internalcommands createrawvmdk -filename ~/VirtualBox\ VMs/Windows7/windows7.vmdk -rawdisk /dev/sda -partitions 1,2,3,5 -mbr win7.mbr where the required MBR has been created from Linux with sort of: dd if=/dev/sda of=win7.mbr count=1 if you want to get the main MBR, or dd if=/dev/sda1 of=win7.mbr count=1 if you want to get the MBR from the Windows start partition. If you select a "conservative" Linux distro (such as CentOs) you get a rock solid, bullet proof, main OS for any other task, you may do a lot of Windows testing by just using wine, and you may safely play with all of yours VM's, creating snapshots before doing dangerous things such as tampering with registry. But you keep the chance to run the "native" Windows in order to judge the real performance, and look. Maybe, before doing all of that, a full backup of your disk with Clonezilla would be a wise precaution Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
Il 20/02/2019 19:11, Nikolai Zhubr ha scritto: Now it is getting even more curious. Admittedly I don't use C too much (and C++ even less so, approximately never), maybe that is why I do not understand your reasoning. Could you maybe give an example of such problematic inline declaration and its negative effect, in C++ at least? Honestly I can't imagine any. Very easy: you read your code written some time before, or someone else's code, you miss the inline declaration, because it's buried in the code, and you mistake the variable with another one previously declared, in the outer scope. I have just met such a situation: I ported from C++ to Pascal an algorithm for the computation of the kinematics of a Delta Robot, and I was badly bitten. In that case you are just dealing with X,Y,Z coordinates, and Theta0,Theta1,and Theta2 angles, and you find, in the body of a procedure, some X,Y,Z or Theta which have global scope, and some which are just local to some smaller (but not too small) block and which are redeclared inline. Rather hard to tell them apart. Redeclaring inline an index I, which you'll be then using a lot of times, is the best way to shoot you in the feet. Pascal encourages you to use I,J,K at first, then ii,jj,kk etc. Moreover, using a modern tool such as Lazarus, you never need to scroll 1000 lines to find a declaration: you just press alt+Up to go to the declaration of the symbol over the cursor, and Ctrl+H to go back to the line of code. Keeping all declarations separated from code is just good programming practice. Mixing declaration and code is bad programming practice, IMO, and I appreciate Pascal for not supporting it. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bugtracker 003007
Il 25/02/2018 00:07, Sven Barth ha scritto: Am 24.02.2018 17:07 schrieb "Giuliano Colla" mailto:giuliano.co...@fastwebnet.it>>: Attn. Sven Bart Hi, on jan 14 I had told you that I had to postpone further work on the https://bugs.freepascal.org/view.php?id=33007 <https://bugs.freepascal.org/view.php?id=33007> issue, because I was going to be abroad for a couple af weeks. Then I came back, I put in practice your suggestions, posted new patches on the bugtracker, and dropped you a line to let you know that I was back. Since then (feb. 8th) I didn't get any feedback. Is that because you failed to notice, or because you've been otherwise busy? Sorry, I had forgotten. I'll try to take a look at your corrected version. Regards, Sven Any news? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected behaviour with intermediate results
Il 12/06/2018 02:07, J. Gareth Moreton ha scritto: Someone pointed out that if you perform "(x shl 8) shr 8", where x is of type Word, the result is always x, even though logic dictates that the upper 8 bits should be shifted out and hence the result actually be equal to "x and $FF". IMHO logic dictates that (x shl 8) shr 8 should give x, because the shr cancels the effect of shl, and that a further compiler optimization might simply suppress the code at all. Register size when performing a calculation is not dictated by logic, but by physical constraints, which have nothing to do with logic. If the programmer wishes to mask out some bits he should explicitly use an *and* instruction, making the code both more readable and more portable. Generating a less efficient code, with and instructions added with the sole purpose of supporting the improper usage of a shl instruction wouldn't be very smart. I'm in favour of a compiler which generates the most efficient code, and leaves to the programmer the responsibility to mask unwanted bits. Just my 2 cents. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
Il 25/02/2018 21:33, Mark Morgan Lloyd ha scritto: Easily put in the makefile Well I wouldn't say "Easily"!:'( I can live without parameter macros in Pascal like I did until now, but just for personal satisfaction I tried to get the Gnu Pascal Preprocessor. In order to get the preprocessor, you need to get a full GNU Pascal installation. It turned out that: Gnu Pascal has stopped with gcc 3.x and is 32 bits only. Configure doesn't recognize an x86_64 platform. Once you've managed to tell configure to generate an i686 it turns out that the 32 bit tools available on a 64 bit environment aren't sufficient to compile gcc, which is a prerequisite for compiling Pascal and its Preprocessor. A few header files are either missing or incorrect. Switch to a virtual 32 bit machine and restart. Then you discover that the syntax used by gcc 3.x isn't supported by gcc 4.x, which you try to use for compiling: gcc 4.x "enhancement" is to reject typecast on the left side of an assignment which was not only accepted by gcc 3.x, but also used in writing the compiler itself. You need to install a "compatibility package" including a gcc 3.4 You manually edit the Makefile, to force the usage of the compatibility compiler. When you finally have managed to compile and install, you don't find the Preprocessor in the generated binaries. If you didn't give up long before, you'll finally find the Preprocessor in the libraries folder. I went through the full odyssey, and I got a 32 bit gpcpp which runs also in a 64 bit environment where 32 bit libraries are present. It appears to work, but it has still to be seen if it can be used in practice. Should anybody else be eager to try it, I hope that my Calvary will be of some help.>:o Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
Il 25/02/2018 18:34, Florian Klämpfl ha scritto: http://www.gnu-pascal.de/gpc/Preprocessor.html, nobody prevents people to run a preprocessor before FPC gets the code. That's a constructive suggestion. If fpc doesn't implement an actual preprocessor, but macro expansion is part of the source parsing, then I must agree with you that the effort required wouldn't be justified by the benefits obtained. Thank you for your time. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
Il 25/02/2018 13:55, Florian Klämpfl ha scritto:
To limit their use.
Well, just for sake of argument, it appears to me a rather drastic approach.
You may write other similar pages on stackoverflow, telling why
Dereferencing is evil, Typecasting is evil, or why "Absolute" or the
"with" construct are evil. All of them, if misused, can lead to
unexpected results, with code hard to read, easy to misinterpret, and
hard to debug. Nonetheless they're part of the language, and, properly
used, are useful programmer's tools.
Most of the drawbacks of macro arguments can be easily overcome if
a) The listing of preprocessor output is generated.
b) The preprocessor output is provided to the debugger as the actual
program source
None of the two should require a titanic effort!
IMHO macro arguments, if properly used, may be a valid additional
programmer tool.
E.g. Converting a C program to Pascal I had:
C code:
#define EXCH_INITIALIZER(nam) \
{NULL,NULL,NULL,NULL,NULL,PTHREAD_MUTEX_INITIALIZER,nam}
EXCHANGE_DESCRIPTOR cp_ready_ex = EXCH_INITIALIZER("CP_RDY");
Lacking macro arguments, the equivalent declaration in fpc became:
cp_ready_ex: exchange_descriptor = (
message_head : Nil;
message_tail : Nil;
task_head : Nil;
task_tail : Nil;
exchange_link : Nil;
mutex : (__m_reserved: 0; __m_count: 0; __m_owner: Nil;__m_kind: 0;__m_lock:
(__status: 0;__spinlock:0));
name: ' CP_RDY';);
(and I had quite a number of them!)
A lot of error prone typing, just to provide the only useful
information, i.e. the readable name of the thing.
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
Il 25/02/2018 13:15, Sven Barth via fpc-devel ha scritto: Yes, we definitely feel good about this, because we don't *want* parameter support in FPC's macro handling. Maybe I'm obtuse, but I fail to grasp the reason why. Can you elaborate a bit more? Thanks Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bugtracker 003007
Attn. Sven Bart Hi, on jan 14 I had told you that I had to postpone further work on the https://bugs.freepascal.org/view.php?id=33007 issue, because I was going to be abroad for a couple af weeks. Then I came back, I put in practice your suggestions, posted new patches on the bugtracker, and dropped you a line to let you know that I was back. Since then (feb. 8th) I didn't get any feedback. Is that because you failed to notice, or because you've been otherwise busy? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Il 27/12/2017 15:05, Sven Barth via fpc-devel ha scritto:
No matter the syntax that might be chosen for this it will likely be
sufficient to handle that feature by an absolutevarsym with a boolean
flag or something like that. The difference to an ordinary absolute
variable appears to be too small to warrant a new sym type.
After struggling sometime to find out the best way to implement the
based feature without adding a new keyword, I found that the syntax:
aVar: anyType ABSOLUTE somePTR^;
can be implemented with minimal changes.
Attached the patch which does the trick, and which works like the old
proven one.
It doesn't support *implicit* dereferencing, because I've left untouched
the code which filters it out.
One could remove the filtering for consistency, but I don't like very
much the idea: the aim of such a feature is to provide a more readable
and understandable code, not the opposite.
Giuliano
diff --git a/compiler/pdecvar.pas b/compiler/pdecvar.pas
index 1c828f5..5d67d28 100644
--- a/compiler/pdecvar.pas
+++ b/compiler/pdecvar.pas
@@ -61,7 +61,7 @@ implementation
fmodule,htypechk,
{ pass 1 }
node,pass_1,aasmbase,aasmdata,
- ncon,nset,ncnv,nld,nutils,
+ ncon,nset,ncnv,nld,nutils,nmem,
{ codegen }
ngenutil,
{ parser }
@@ -1133,11 +1133,13 @@ implementation
abssym : tabsolutevarsym;
pt,hp : tnode;
st : tsymtable;
+ isBased: boolean;
{$if defined(i386) or defined(i8086)}
tmpaddr : int64;
{$endif defined(i386) or defined(i8086)}
begin
abssym:=nil;
+ isBased:= false;
{ only allowed for one var }
vs:=tabstractvarsym(sc[0]);
if sc.count>1 then
@@ -1146,6 +1148,15 @@ implementation
Message(parser_e_initialized_not_for_external);
{ parse the rest }
pt:=expr(true);
+ { Support for absolute deref -
+ syntax:
+ sym: type ABSOLUTE ptr^;
+ }
+ if pt.nodetype=derefn then begin
+pt := tderefnode(pt).left; // let's find the actual pointer
+if pt.nodetype=loadn then // and check that it's valid
+ isBased:= true;
+end;
{ check allowed absolute types }
if (pt.nodetype=stringconstn) or
(is_constcharnode(pt)) then
@@ -1257,6 +1268,7 @@ implementation
abssym:=cabsolutevarsym.create(vs.realname,vs.vardef);
abssym.fileinfo:=vs.fileinfo;
abssym.abstyp:=tovar;
+ abssym.isBased:= isBased;
abssym.ref:=node_to_propaccesslist(pt);
{ if the sizes are different, can't be a regvar since you }
diff --git a/compiler/pexpr.pas b/compiler/pexpr.pas
index 6d972de..ecc0533 100644
--- a/compiler/pexpr.pas
+++ b/compiler/pexpr.pas
@@ -3016,11 +3016,17 @@ implementation
begin
p1:=nil;
propaccesslist_to_node(p1,nil,tabsolutevarsym(srsym).ref);
+if tabsolutevarsym(srsym).isBased then
+ p1 := cderefnode.create(p1);
p1:=ctypeconvnode.create(p1,tabsolutevarsym(srsym).vardef);
include(p1.flags,nf_absolute);
end
else
+ begin
+ if tabsolutevarsym(srsym).isBased then
+p1 := cderefnode.create(p1);
p1:=cloadnode.create(srsym,srsymtable);
+end;
end;
staticvarsym,
diff --git a/compiler/symsym.pas b/compiler/symsym.pas
index d522314..86bc007 100644
--- a/compiler/symsym.pas
+++ b/compiler/symsym.pas
@@ -316,6 +316,7 @@ interface
tabsolutevarsym = class(tabstractvarsym)
public
abstyp : absolutetyp;
+ isBased : boolean;
asmname : pshortstring;
addroffset : PUint;
ref : tpropaccesslist;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the best way to debug the fpc compiler?
Il 28/12/2017 14:54, Sven Barth via fpc-devel ha scritto: A "make install" I do only when I need to use the compiler in Lazarus for a different project, for everything else I simply add the unit directories of the needed packages to the run parameters. I hope this helps you :) Thanks a lot Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] What's the best way to debug the fpc compiler?
Hi fpc developers, I'm playing a bit with the compiler. In order to debug my changes I need to compile some test programs. To stay on the safe side, currently when I modify something I rebuild everything (make all - make install) in order to provide a consistent compilation environment. This is rather time consuming and I do compile a lot of unnecessary stuff. Is there a better way? Any suggestion is welcome Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto: As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people.:) What was allowed before 2.4.0 was *implicit* keyword dereferencing, while explicit dereferencing has never been allowed. This was rather inconsistent, and rightfully suppressed. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto:
Am 26.12.2017 13:33 schrieb "Giuliano Colla"
mailto:giuliano.co...@fastwebnet.it>>:
If the idea is not rejected, then a number of refinements (which
I'm ready to implement) are required to make the feature generally
available:
My following remarks are independent of an eventual acceptance of the
feature :
- All architectures should be supported (now it's only for x86_64
- symcpu.pas).
It might be possible to implement this in a platform independent way
that might simply need to expand the capabilites of "absolute".
The feature in itself is platform independent.
The only catch is that in pdecvar.pas (where variable declaration is
handled) there's a per platform hook for each symbol type, in order to
allow for special handling of some features.
For consistency I did follow the same rule, which is used for all the
other declarations, disregarding whether they're platform independent or
not.
As a consequence, for each supported platform you must add in its
specific symcpu.pas a type entry:
tcpubasedvarsym = class(tbasedvarsym)
end;
tcpubasedvarsymclass = class of tcpubasedvarsym;
and a line of code:
cbasedvarsym:=tcpubasedvarsym;
As this is tedious, I've only done it for the platform I'm using
(x86_64/symcpu.pas). To deploy the feature, the same lines must be added
in each platform symcpu.pas unit. There's no more that that.
- It should be decided if to make the feature generally available,
or conditioned by an {$IFDEF FPCHASBASED}
- It should be decided if the feature should be available in all
modes or only in a selected number of modes (what of TurboPascal
Mode or Delphi Mode?).
Rule of thumb: new features added as a separate mode switch, no
FPC_HAS_* define necessary as by definition this can be done with
version checks (there is only one trunk version, namely the current one).
- It should be decided if error messages should be specific for
the BASED construct or common to the ABSOLUTE one, slightly
rephrasing the error message.
Might be one or the other depending on the message.
- It should be decided if internal error # which currently keep
the same number of the nearby ABSOLUTE internal error should be
given new values.
Internal errors shall always be unique as they are used to find the
error location, even for copy pasted code.
What's the rule to avoiding clashes? I gathered sort of MMDD## is it
correct?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto: HI, On Tue, 26 Dec 2017, Thorsten Engler wrote: Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people. :) I'd not be in favour of using the same syntax for two quite different beasts. Although the practice implementation is similar, the semantics is completely different: ABSOLUTE declares a variable whose storage is known and assigned at compile time. BASED declares a variable whose storage is unknown, and will only be instantiated at run time. Mixing the two things may cause a lot of troubles, and most likely that's the reason why it was removed from fpc 2.4.0. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto: What does gdb (and possibly other debuggers) make of this? What currently gdb tells (and any other debugger would tell) is : No symbol "Item" in current context. Once the appropriate entries are implemented in the debugger symbol table, it will behave like it does in similar conditions, i.e. displaying a value referenced by a pointer. I didn't mention in my ToDo list because I'm a bit lazy, but this too has to be done. Is it really appropriate to declare Item as a variable, when it's really more akin to a macro? It's not different from the declarations: myString: string; myObject: TObject; where your declaration only reserves a pointer, while the actual string or object will be instantiated only at run time. Item is a variable, whose location isn't known at compile time, but will be known only at run time. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] An extension of fpc language: the BASED construct
Hi fpc developers,
here enclosed a patch to the compiler (and ppudump) to support
the BASED construct (PL/1 and PL/M style), together with a patch
to Lazarus codetools in order to be able to use it with Lazarus
IDE.
For those unfamiliar with the BASED construct, here's a short
description taken from Intel's PL/M-86 manual:
Based Variables
Sometimes a direct reference to a PL/M-86 data element is either
impossible or inconvenient. This happens for example, when the
location of a data element must remain unknown until it is
computed ad run time. In such cases, it may be necessary to write
PL/M-86 code to manipulate the locations of data elements
themselves.
To permit this type of manipulation PL/M-86 uses "based
variables". A based variable is one that is pointed to by another
variable called its "base". This means the base contains the
address of the desired (based) variable.
In short the BASED construct makes the C-style dereferencing
operator unnecessary, by moving dereferencing from code to
declaration.
In fpc this translates into code looking like this, in this trivial
example:
var
I: BYTE;
I1: INTEGER;
ItemPtr: Pointer;
Item: BYTE BASED ItemPtr;
IntegerItem: INTEGER BASED ItemPtr;
ItemPtr := @I;
Item := $41;
ItemPtr := @I1;
IntegerItem := -32767;
This code will load the BYTE value $41 into the variable I, and the
INTEGER value -32767 into the variable I1.
In more formal terms, the Declaration section of the fpc manual
should include a new path:
>--Variable modifiers -- based -- pointer -->
| | | | |
| -- PUint _expression_ ---| |
etc..
The main points are:
It doesn't break anything. - I have thoroughly tested it in
my private fpc versions since fpc 2.2.4
Nobody is forced to use it: whoever doesn't like it can
simply ignore its existence.
It provides a feature consistent with the general Pascal
approach, to avoid whenever possible redundant dereferencing
and typecasting, moving the tedious jobs from the developer
to the compiler.
It saves a number of C-style declarations, dereferencing and
typecasting, and it provides a better type checking, making
the code less error prone and much more readable and more
"Pascalish".
It's very useful in message passing techniques, where
different message types are funnelled to a single endpoint.
Typically such messages are records composed by a fixed header
which tells about the message type, followed by a variable
content. They can be found everywhere, from IPC to X11
interface to tcp/ip packets.
I found it also useful in data entry applications, where
different fields require different data types.
The implementation is rather trivial: a BASED declaration is nothing
else than an ABSOLUTE declaration with an added dereferencing.
Therefore I've simply duplicated the code for the ABSOLUTE, with a
minimal change in pexpr.pas, and minimal adaptations elsewhere.
The enclosed patches are provided just to permit testing,
evaluation and scrutiny from fpc maintainers. They only contain
what is required for my personal usage.
If the idea is not rejected, then a number of refinements (which
I'm ready to implement) are required to make the feature generally
available:
- All architectures should be supported (now it's only for x86_64
- symcpu.pas).
- It should be decided if to make the feature generally
available, or conditioned by an {$IFDEF FPCHASBASED}
- It should be decided if the feature should be available in all
modes or only in a selected number of modes (what of TurboPascal
Mode or Delphi Mode?).
- It should be decided if error messages should be specific for
the BASED construct or common to the ABSOLUTE one, slightly
rephrasing the error message.
- It should be decided if internal error # which currently keep
the same number of the nearby ABSOLUTE internal error should be
given new values.
- Maybe something else which I failed to notice.
I'd love to see my favourite programming language enriched by
such a feature!
Giuliano
Index: nld.pas
===
--- nld.pas (revisione 37753)
+++ nld.pas (copia locale)
@@ -292,6 +292,8 @@
case symtableentry.typ of
absolutevarsym :
resultdef:=t
Re: [fpc-devel] Math expressions in wiki
Il 14/04/2017 22:08, Werner Pamler ha scritto: It looks to me that something (the math template?) is missing from the Lazarus/FPC wiki infrastructure. If this is right, is there anybody I could contact? Maybe I'm wrong, but I believe that you can either load the template from the infrastructure, or add it somehow in your page. That's what I gathered from a quick reading of the wiki Template reference. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Math expressions in wiki
Il 14/04/2017 17:21, Werner Pamler ha scritto: How do I activate this template? https://en.wikipedia.org/wiki/Wikipedia:Template_namespace and in particular (to fetch the template text) https://en.wikipedia.org/wiki/Wikipedia:Template_namespace#Substitution Hope that it helps. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Il 12/04/2017 19:54, Bernd Oppolzer ha scritto:
I'm no FPC macro language wizard, but in my believe
you are replacing Positiva with False, followed by a semicolon,
and so you get the error from the compiler.
{$define Positiva:=False}
should probably work.
You are right, I was misled by some examples in the docs, but reading
more carefully, actually it states that the syntax is
{$define ident:=expr}
so that my semicolon is part of the define, and not a termination as I
had understood.
Thanks a lot.
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug in macro handling?
Il 12/04/2017 19:51, Michael Van Canneyt ha scritto:
Try removing the semicolon:
{$define Positiva:=False}
{$define Negativa:=True}
Without semicolon it works!
Thanks a lot.
BTW, do you think that this holds true only for the define of boolean
values?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Compiler bug in macro handling?
Hi honourable fpc developers!
I found a strange error (both with fpc 2.6.4 and fpc 3.0.0, in Linux
environment)
The following snippet of code:
{$MACRO ON}
{$define Positiva:=False;}
{$define Negativa:=True;}
...
if HDCOUNT0 >= COUNT0 then V_PIU0 := Positiva
else V_PIU0 := Negativa;
gives rise to a Fatal: syntax error: ";" expected but "ELSE" found.
But if I change the code into:
if HDCOUNT0 >= COUNT0 then V_PIU0 := False
else V_PIU0 := True;
(which IMHO should be identical) it compiles without complaining.
Am I doing something wrong or it is a bug?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Il 23/09/2014 18:00, Boian Mitov ha scritto: Hi Giuliano, I was not talking hypothetical example. All of our products use this technology. Again, what you are telling me is some suggestion for probable solution, but even when you do it, you immediately add additional code and containers (list) just to support it due to the lack of ref counting. This immediately allows me to argue that your solution will use more memory and will be slower as it needs additional containers and support code altogether. So you basically are reconfirming yet again the advantages of using ref. counting. I didn't claim that your example was hypothetical. I just argued that it's a very specific implementation. Maybe I'm simple minded but I still have some pain understanding how a producer thread may manage to send an object to a one or more consumer threads which a) are unknown to it, and b) may not yet exist. Again not an hypothetical case. Just a different application frame. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Il 22/09/2014 23:04, Boian Mitov ha scritto: If you are experienced in parallel processing, you should know the answer. This is a huge topic, and I have done number of sessions on some aspects of it, but here will give you a small example (again this is just a small example). You have a data object that needs to be processed by 600 threads, and when they all have consumed(finished with it) it, it needs to be disposed. With ref counting you create the object send it to all threads, each thread has its own reference to the object. When they all release the references the object is destroyed. I agree with you that parallel processing is a very huge topic, but just because of that I strongly disagree with your assumption that what can be good for a very specific kind of application is good for every application. In addition to the observations of Marco, I can give you a small counter-example: You have a number of threads creating thousands of data objects, which should be processed by "consumer" threads. Creating threads are unaware of how data will be used (it may depend on active options, and it follows the golden rule of "reusable code") so they can't send those objects anywhere. Therefore pointers to those objects are inserted in a list. A "consumer" thread can either process a data object, and then dispose of it, or leave it in the list for further processing, or move it to a different list, again depending on the selected options. This scheme can apply to quite a number of applications, from data collected in a real-time process to data-base transactions, etc. However you attempt to apply reference counting in this scheme, you'll realize that either it doesn't work at all, or it forces you to add a considerable amount of code, whose purpose would be only to fool reference counting, and artificially increase or decrease reference count. The same applies to your example, if it happens that when creating your data object you don't know which threads will consume it, because threads are created dynamically (captors activated and deactivated, options enabled/disabled, users connecting and disconnecting, etc). Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] weak referencing (was Suggestion:.....)
Il 23/09/2014 02:24, John Briggs ha scritto: Sven At the risk of starting a flame war I have been pondering this question since these threads have started: Why has there been so many messages on this list debating the pros and cons of reference counting objects? Because many of us are scared to death from the idea of adding as a default a "feature" which could break millions of lines of existing code, degrade performance, and create incredible debugging headaches, without bringing any benefit to the overwhelming majority of users. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Il 21/09/2014 05:51, Hans-Peter Diettrich ha scritto: Giuliano Colla schrieb: I might, for example, tell you that my company has been successfully implementing since more than 30 years a class of applications for the control of industrial processes, with hundreds of threads running simultaneously in a multi-CPU environment, [...] IMO realtime applications require an realtime OS, providing all required means of process synchronization and communication. Ordinary systems and developers should be happy with primitive threads, doing their work in the background and exiting when done. Our class of applications takes advantage of a distributed intelligence model. IOW a number of CPU's working in parallel, each one running his own real-time multitasking environment. They're organized in a hierarchical tree and almost all of them take advantage of dedicated real-time OS's, up to the root of the tree, which governs the full process, and also provides human interface, data collection, connection with factory network and data-bases, remote connection for assistance, debugging and upgrading. The top level, until recent times, was provided by a Linux box, with a real-time patched kernel (Adeos-Ipipe). The result was a real-time nanokernel, running the application real-time tasks, and having Linux as its idle task. On Linux side, the visual portion was provided by Kylix. But, with the increase of CPU speed, and the the significant improvements of Linux kernel latency, it's now become possible to get rid of the foreign real-time patch, and to take advantage directly of Linux kernel thread scheduling, without a significant performance loss. It's good to know that FPC allows to implement and manage more complex parallel processing, if I understand you and Boian correctly? FPC comes into play with the latest evolution I described above, because all the high level functions (such as user interface, data collection, etc.) are being handled using Lazarus for the visual functions, and a number of FPC threads for the rest. While Kylix did provide a more suitable (and less buggy :-( ) widgetset, synchronization of the main thread with FPC/Lazarus is significantly better. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hi Boian, I'm easily convinced that you've developed a lot of things using reference counting. Design is the art of compromise, and possibly in your class of application that's the best compromise. But we should never forget that our class of applications isn't the only possible one in the world. What is a bonus for you might be either useless or extremely harmful for someone else. I might, for example, tell you that my company has been successfully implementing since more than 30 years a class of applications for the control of industrial processes, with hundreds of threads running simultaneously in a multi-CPU environment, with thread synchronization in the sub-millisecond range (with time it has improved down to the sub-microsecond area, with the evolution both of hardware and software tools), where reference counting simply doesn't apply, because of the specific nature of the problems. All the required resources must be created at startup, and they can only be destroyed when the process is stopped, at the end of the day in some cases, at the end of the week or for the annual vacations in others. Or that we have another class of multithreaded applications (not so many as the other ones, and with just around 14 years of history) where objects are mainly manipulated by means of lists of pointers, and where, again, reference counting doesn't apply, because an object can't possibly be aware of what happens to one or several pointers pointing to it. In some cases it's required that destroying the list the objects are destroyed also, in other cases they must be kept. But this must be decided by program logic, not by a generic algorithm. In any case, in our range of applications, memory leakage due to objects not destroyed, or crashes due to unduly destroyed objects has never been an issue. For those reasons I have nothing against reference counted objects, provided I'm not forced to use them, because, in our class of applications we would only suffer the disadvantages. Should TObject become reference counted by default, I'm afraid that for most of us, me included, switching to ANSI C would become a choice to be seriously considered, like Peter Popov suggested in this thread... Kind regards, Giuliano Il 20/09/2014 21:27, Boian Mitov ha scritto: Hi Giuliano, All of our libraries, are heavily multithreaded, and use exclusively reference counting with interfaces, as well as lazy evaluation nested object reference counting for performance. We have been doing this for over 11 years with great success, and we continue to expand the functionality. Not only is it doable, but it is nearly impossible to do really complex heavily distributed threading without it. Trust me, I have been doing multithreading since the days we had to implement it in interrupt cascades in 6502/6800 8 bit processors 30 years ago ;-) . I know what it takes to do it in assembler, C, C++, Delphi, with and without OOP, as well as with and without ref. canting ;-) . I have done them all... With best regards, Boian Mitov --- Mitov Software www.mitov.com ------- *From:* Giuliano Colla <mailto:giuliano.co...@fastwebnet.it> *Sent:* Saturday, September 20, 2014 11:33 AM *To:* FPC developers' list <mailto:fpc-devel@lists.freepascal.org> *Subject:* Re: [fpc-devel] Suggestion: reference counted objects Il 20/09/2014 19:20, Boian Mitov ha scritto: Hi Chriss, Personally I favor reference counted objects. While there are interfaces as you pointed, and in Delphi you can even use smart pointers now, there is still a lot of cases when you need to use objects, and have to manually free them. In single threaded environment that is not such an issue, but in parallel and heavily multithreaded environments, reference counting is a life saver. Can you explain how reference counting can be safely implemented in a parallel multithreaded environment, without heavily affecting performance? A mere increment or decrement of count means to get a lock and to release a lock on that object. Application code can know what is thread safe and what is not, and use lock only when appropriate. A general mechanism to be reliable should take into account all possibilities. If it does, it will block threads even when unnecessary. If it doesn't, it will be unsafe. What do I miss? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Il 20/09/2014 19:20, Boian Mitov ha scritto: Hi Chriss, Personally I favor reference counted objects. While there are interfaces as you pointed, and in Delphi you can even use smart pointers now, there is still a lot of cases when you need to use objects, and have to manually free them. In single threaded environment that is not such an issue, but in parallel and heavily multithreaded environments, reference counting is a life saver. Can you explain how reference counting can be safely implemented in a parallel multithreaded environment, without heavily affecting performance? A mere increment or decrement of count means to get a lock and to release a lock on that object. Application code can know what is thread safe and what is not, and use lock only when appropriate. A general mechanism to be reliable should take into account all possibilities. If it does, it will block threads even when unnecessary. If it doesn't, it will be unsafe. What do I miss? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TTimers and TThreads. Attn Michael Schnell
Il 27/06/2014 20:01, Hans-Peter Diettrich ha scritto: Giuliano Colla schrieb: If you're using relative times and not absolute ones, then you may avoid the search, without need to resort, using a slightly different scheme, i.e. entering in a sorted list the times *relatives to the previous one*. Then your queue can run out of sync with the absolute time. It depends on his needs. He's stated that hes not using absolute times, so I presume that absolute time is of no interest for him. Therefore I suggested a more efficient technique to handle relative times. I don't see an advantage with using relative times, or unsorted lists. On insertion a binary search over the list can be made, when the entries are sorted by absolute time. Removal of entries occurs always from the list head. I don't either. But that's what he does. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TTimers and TThreads. Attn Michael Schnell
Il 27/06/2014 13:10, Michael Schnell ha scritto: On 06/27/2014 12:54 PM, Giuliano Colla wrote: 1) a list of timer events, ordered by expiration time. Thanks for the pointers. I in fact do something similar. My TTimer class has a class variable that is a dynamic array of TTimers. When the program is going to wait for anything (a timer or a thread firing an event) it searches for the next timer to expire and uses the difference time as a waiting timeout. I don't sort the list, as it would need to be re-sorted with any timer event. So I always need to do a linear search for the next Timer to expire. If you're using relative times and not absolute ones, then you may avoid the search, without need to resort, using a slightly different scheme, i.e. entering in a sorted list the times *relatives to the previous one*. You have event a) to occur 10ms from now, and event b) to occur 100ms from now: event b) will be entered with a value of 90 (i.e. 100-10). If you have a third event to occur 50ms from now, it will be entered between the first and the second, being 50 > 10 and (50-10) < 90, with a value of 40 (50-10). The time for the following event will be corrected to 50 (90-40). The insertion involves the overhead to calculate how much of the time for the first timer to expire has already passed, and to insert the new event in the right place, adjusting also the following, but it involves less overhead than scanning a possibly long list to find the event to fire. You must always scan the full list, because two event may fire at the same time. With this scheme an event simultaneous to the previous one would have a timer value of zero. If you're in Linux environment, however, the actual libc functions provide only absolute times, and they're quite efficient. I can't say about Windows. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TTimers and TThreads. Attn Michael Schnell
I've faced problems similar to yours in the past, and I've successfully used a simple and quite effective scheme: 1) a list of timer events, ordered by expiration time. Each entry holds the absolute time, and the action to take (the semaphore to signal, where a thread is waiting, in my case). The queue is built as a double linked list, for ease of insertion/deletion. 2) whenever a new timer event must be scheduled, it's inserted in the appropriate place of the list. if it happens to go to the head of the list, the timer must be reprogrammed, otherwise it's left untouched. 3) When the timer expires, the head item is removed from the list, and the action is activated. Optionally, if timer for next event is lower than a given threshold, also next event can be activated too, and removed from the list. The timer is reprogrammed from the next item in the list (which has become the head of the list). If the list has become empty, the timer is not reactivated. Pros: you have only one timer to deal with, no overhead for useless timer events, minimal overhead on timer events. Cons: you have some overhead when programming a timer event, because the list must be scanned to insert the event in the appropriate place. Just my 5 c. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus 1.0.8 Release
Il 19/03/2013 10:28, Mattias Gaertner ha scritto: The Lazarus team is glad to announce the release of Lazarus 1.0.8. This is a bug fix release, built with the current fpc 2.6.2. The previous release 1.0.6 was built with 2.6.0. Although with the last updates RHEL5.x and CentOs 5.x do claim to support the new compression format, they don't manage to handle those rpm's. I didn't test with Suse 10.x, but I'm afraid that the problem will be there too. For those interested, repackaged versions of Lazarus 1.0.8 and fpc 2.6.2, compatible with those distros can be downloaded from the following link: http://www.bononiadocta.it/Lazarus/ Have fun! Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [fpc-other] Lazarus 1.0.8 Release
Il 19/03/2013 10:28, Mattias Gaertner ha scritto: The Lazarus team is glad to announce the release of Lazarus 1.0.8. This is a bug fix release, built with the current fpc 2.6.2. The previous release 1.0.6 was built with 2.6.0. Although with the last updates RHEL5.x and CentOs 5.x do claim to support the new compression format, they don't manage to handle those rpm's. I didn't test with Suse 10.x, but I'm afraid that the problem will be there too. For those interested, repackaged versions of Lazarus 1.0.8 and fpc 2.6.2, compatible with those distros can be downloaded from the following link: http://www.bononiadocta.it/Lazarus/ Have fun! Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus 1.0 and fpc 2.6 do not install on popular distributions
Il 23/11/2012 00:27, Michel Catudal ha scritto: On 11/22/2012 05:27 PM, Giuliano Colla wrote: Hi fpc and Lazarus developers. I just discovered that Lazarus 1.0.x and fpc 2.6 do not install out of the box on widely used distributions such as RHEL 5.8, CentOs 5.8, and Suse Enterprise 10.1. They're the most popular enterprise versions, which should be an important target for Lazarus and fpc diffusion. Paying customers are there! I purchased an HP laptop just a few weeks ago, and the preinstalled OS was Suse Enterprise 10.1. As the current policy of enterprise distro's is to provide a longer life cycle (Red Hat, followed by CentOs now provides a 10 years life cycle) the problem will stay there for a long time, unless some simple steps are taken. I would suggest to check for a version for a distribution that is closest to SuSE Enterprise. I use Scientific Linux 6.2 and probably could have used a version for Fedora 12 or 13 since that is what Redhat Enterprise is based on. You could download the one from my website. It was compiled for Scientific Linux 6.2 and might work on SuSE. If not just recompile it, I provide the source package. Thanks, but I managed to install. I just wanted to point out that those incompatibilities may frighten or discourage a new user. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Lazarus 1.0 and fpc 2.6 do not install on popular distributions
Hi fpc and Lazarus developers. I just discovered that Lazarus 1.0.x and fpc 2.6 do not install out of the box on widely used distributions such as RHEL 5.8, CentOs 5.8, and Suse Enterprise 10.1. They're the most popular enterprise versions, which should be an important target for Lazarus and fpc diffusion. Paying customers are there! I purchased an HP laptop just a few weeks ago, and the preinstalled OS was Suse Enterprise 10.1. As the current policy of enterprise distro's is to provide a longer life cycle (Red Hat, followed by CentOs now provides a 10 years life cycle) the problem will stay there for a long time, unless some simple steps are taken. The first problem is the rpm format: rpm's are generated with a recent version, which provides a higher compression level (lzma), but which isn't supported by the previous rpm versions. Using a graphic interface installer will not give any clue, just signaling an "unknown error". Anybody not stubborn enough will believe that the files are corrupted, and will give up, thinking that Lazarus and fpc are shit. Only by switching to command line, and trying to interpret the rather cryptic messages, one can understand the problem. The solution is to download the rpm's on a very recent distro, and use rpmrebuild to rebuild the rpm's with a more widely supported compression format (gz or bz2). If one gets there, he will discover that there are no unsatisfied dependencies, that all relevant libraries are available, and he'll boldly try to compile his first "hello world". And he'll stumble in the second problem: the "hello world" program won't compile, because of an ld error: unknown option --build-id. Again anybody not stubborn enough will give up, instead of editing fpg.cfg which enables by default the build-id option, unsupported by the ld version of those distributions. An experienced user can easily be told to use rpmrebuild, and to comment out the -k--build-id line on fpc.cfg, but that's hardly the way to encourage new users. Just by setting CPACK_RPM_SPEC_MORE_DEFINE to %define _binary_payload w9.bzdio or %define _binary_payload w9.gzdio into the rpm SPEC, and commenting out the -kbuild-id line on the fpc.cfg file, one can make available rpm's which will install almost anywhere, at the price of slightly longer files, and of letting the experts who need the build-id option the burden to uncomment the line, if appropriate. If it's desirable to widen the usage of fpc and Lazarus, anything that can discourage first time users should be avoided. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Il 22/07/2012 23:15, Marco van de Voort ha scritto: In our previous episode, Florian Kl?mpfl said: Then "friend" classes as C++ offers and wait for this feature were implemented before proceeding with the optimization :) I never saw a C++ class pretending to be somebodies friend. iirc friend classes must be defined in the class which elements shall be access. So C++ like friend classes would help exactly nothing (iirc). Indeed, and in our case those friends list would be in precompiled code. As far as Guiliano's suggestion goes, then I rather use a cmdline option for that (when compiled with that option it is allows to access private fields), rather than syntax. (but I don't know if the PPU format actually contains enough info to access private fields, so this is probably not easy). A command line option would make *all* private fields of *all* objects fully visible. A different class definition would make visible just a few selected classes. It makes quite a difference. But since it is apparently not worth discussing individual cases over, IMHO that means it is not worth compiler changes either. There's an issue which isn't individual but general. Free software means having the freedom of using it however you see fit for your application. This applies to fpc itself, and to fpc based tools, like Lazarus, FPGui, MSEide, MSEgui etc. If fpc offered a way to provide a higher degree of freedom, it would be a general improvement of fpc. If it were done properly it could keep all the advantages of stable guaranteed API's with the flexibility required by a large number of individual cases, which, taken one by one, would be almost impossible to cope with. Taken as a group they make a general case, worth considering. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Il 22/07/2012 10:39, Michael Van Canneyt ha scritto: On Sat, 21 Jul 2012, Florian Klämpfl wrote: Am 21.07.2012 23:06, schrieb Ivanko B: No, just reorder the fields so that they can be properly $IFDEFed as protected for nonLAZARUS and left (private) as is otherwise. Why should lazarus people have less chances to mess with private fields? Either we make them public for all or for nobody. Of course, then everybody has to take care of the fact that users might mess with these fields. Which is exactly why we will not do this. The base classes expose a well-defined API. This API is a contract you make with the developers of descendent classes. Some fields are kept private to ensure that the terms of the contract can be met. Making them public/protected means that the terms of the contract can be broken by Developer A, when the code of developer B depends on the terms being rigorously enforced, and his code can go very wrong. This is of course not so for all private fields, which is why I ask for reasons, so I can decide for each field what can or cannot be done. There are excellent reasons not to expose private fields. What must be opaque and what must be visible to end users are designers decisions which involve the capability of providing new implementation without breaking existing code, take into account multiplatform needs, consider the planned improvements, etc. etc. On the other side there are sometimes good and sound reasons for someone to break this rule, at his own risk, of course. It may be to quickly fix a bug, to provide an extra feature by reusing an existing object instead of rewriting a lot of code, etc. Of course this is a practice not to be recommended in general, but it occurs. And in many cases it is connected to specific needs which aren't of general interest, making the effort of supporting them hardly worthwhile. IMHO a clean solution can be found at language level: if I declare TMyclass = class(TWhatever) then I just get the degree of visibility that the class designer has decided. But if I declare (just an example, a better keyword can be found) TMyclass = subclass(TWhatever) then I get full visibility, all the private fields of TWhatever become just protected in TMyclass, and of course, I'm on my own. The designer is not bound to any contract, because I have explicitly decided to run the risk. This solution would allow mainstream designers to keep fields visibility to what they deem to be a safe level in general, without making it impossible to non mainstream designers to provide features which aren't considered of general interest. Just my 5 cents. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Trolling about: Breaking change in FPC 2.6.1
Mattias Gaertner ha scritto: On Wed, 02 May 2012 18:49:13 +0800 Paul Ishenin wrote: 02.05.12 18:18, Graeme Geldenhuys wrote: So instead of jumping around with various delphi versions (a bit of D7 and a bit of 2009 etc), maybe start from the oldest delphi version (eg: D7) and move towards the newest? Maybe you can teach us how to do this by sending appropriate patches? We will sit then and criticize them. If you don't like the dish - cook yourself. Please don't feed the trolls. This is starting to become off-topic. IMHO a more open attitude towards criticism, instead of just labeling it as "trolling" would bring big benefits to everyone. I'm perfectly aware that we're all in debt to voluntary work created by good willing people. Nonetheless, whenever you undertake a task, be it for free or for a fee, you assume responsibilities for what you're doing, because there are people relying on you. If I undertake the task to help old ladies to cross the road, every old lady I help should be reasonably thankful for that. But if I leave an old lady in the middle of the road, to help another one, I don't believe that the first lady will be thankful. She may even, and rightly, use strong words against me. Breaking compatibility is something very similar to leaving an old lady in the middle of the road. If one knows how to help old ladies then he's welcome to do it. But if he happens to leave them in the middle of the road, then he'd better think twice before saying "If you don't like my way, then cross by yourself" to the lady standing in the middle of the highway and shouting between cars and buses! One of the reasons of the average good quality of open source, is that it takes advantage of user feedback. Better remember it, from time to time. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Il 01/05/2012 22:05, Sven Barth ha scritto:
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be
useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
You can not "surround" code with {$mode Delphi}. It's a unit global
option and also it only changes syntax and semantic handling in the
compiler not code in the units.
Also we are talking about three kinds of Delphi compatible here:
* pre-Delphi 2007 for which used String
* Delphi 2007 which used Pointer
* Delphi 2009 and newer which uses TBytes
This is another reason why using something like "{$mode delphi}" would
be useless here.
Well {$mode Delphi} was just a way to illustrate the point, which could
perhaps obtained with some {$ifdef Delphi-pre07} or {$ifdef Delphi-07}
or {$ifdef Delphi-09} or whatever. Leaving whoever doesn't define a
Delphi compatibility to take advantage of a sane fpc way.
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real use. IMO "deprecated"
means to the user that he should change his code *now*, in
anticipation of the coming change. This obviously is not the case
with the breaking change of the bookmark type, where *no* workaround
exists in the current release.
Instead of repeating the remark, suggesting a solution would be useful.
Criticism is easy. Coming up with solutions obviously much less so.
I never used TDataset.Bookmark, and I'm not likely to use it in future,
so my attitude is that of an external observer, which might be
completely unaware of implications, but, as a general rule, wouldn't it
be wise to surround with an {$mode Delphi} all changes made to comply
with Delphi whims, to satisfy those who need Delphi compatibility, and
keep for the rest of the users things as stable and consistent as
possible, avoiding whenever possible to break compatibility with
existing code?
Giuliano
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xlib and XCB: any plans?
Il 05/03/2012 11:36, Graeme Geldenhuys ha scritto: On 5 March 2012 11:05, Sven Barth wrote: Wayland is not the same as X11. If one wants the CustomDrawn widgetset (or fpGUI for that matter) to support Wayland natively and not through a X11 server that runs on top of Wayland then one needs to use completely new bindings. I thought that is exactly what I said. :-) Also even if Wayland is successful it will take some time till the distros supply it (not to mention as default). True, but Wayland seems to be the most promising X11 alternative - and there has been many attempts over the years. Also if or when Wayland arrives, X11 should still be supported, and your current Xlib implementation of your toolkit wouldn't magically disappear. So you have time to spare. Then again, GTK, QT and some other GUI toolkits are already making good progress with there Wayland support. Ubuntu is also going to push Wayland support hard, and Fedora has also shown positive interest in Wayland. That's to big Linux distros already. But I wouldn't remove Xlib support in fpGUI any time soon. Why? Because even if Wayland is a 100% success story, it is ONLY for Linux (it currently takes advantage of Linux-only features). I still want fpGUI to support the *BSD systems, Solaris etc. Again, I wouldn't bother with a XCB specific binding. The gains are just too little, and as I already showed, the current XLib implementations (and least on Linux) are already wrappers around XCB. Many thanks to both of you. Now the picture is more clear. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Xlib and XCB: any plans?
I'm attempting to contribute to the CustomDrawn components project for Lazarus. One of the target platforms is X, and we may take advantage of the X and Xlib units of fpc. However Xorg discourages the usage of Xlib for new developments, and suggests the usage of XCB instead. What's the situation of fpc in respect of XCB? It would be frustrating to start from scratch with h2pas, to discover that someone else has already done all what's required! -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [Lazarus] OT: Happy new year
I join Ido in wishing you all a very happy new year. To Ido, shana tova umetukah. Giuliano ik ha scritto: Hello All, Sorry for the offtopic, but I wish you all happy new year. I hope that in 2010 we'll see Pascal, FPC and Lazarus become more main stream. Have a great new year and 2010, Ido http://ik.homelinux.org/ -- ___ Lazarus mailing list laza...@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A newbie question about m_none and m_all modeswitches
Jonas Maebe ha scritto: On 26 Nov 2009, at 12:44, Giuliano Colla wrote: But I fail to grasp the difference between *m_none* and *m_all*. These are used in tokens.pas. Tokens marked as m_all are treated as a keyword in all syntax modes (i.e., you can never use them as identifier without escaping them). Tokens marked as m_none are never treated as a keyword. Thank you, now I understand. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] A newbie question about m_none and m_all modeswitches
Hello developers. I'm trying to gain some understanding of fpc internals, in view of possible contributions, and I stumbled in something I don't understand. The tmodeswitch type is, as far as I can grasp, an enumerated type used to enable or disable features according compilation switches, such as delphi objfpc, etc. Some tokens are conditioned by compilation switches, as reflected by the appropriate field in arraytokeninfo while some others are not, and this I understand: some constructs are mac specific, others are delphi specific, etc. But I fail to grasp the difference between *m_none* and *m_all*. Could someone shed some light on this subject? Thank in advance, Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is the switch PREPROCWRITE still alive?
Jonas Maebe ha scritto: On 23 Nov 2009, at 12:49, Giuliano Colla wrote: I think it's indeed stale code that hasn't been maintained since a long time. Thanks a lot, Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Is the switch PREPROCWRITE still alive?
I'm toying with the idea of implementing a feature in FPC. Out of sheer laziness I just tried to compile the FPC sources which I had downloaded together with Lazarus rpm's, and, to my wonder, I got a functioning compiler, so I began playing with it. I found a compilation switch "PREPROCWRITE" which apparently causes to write the preprocessor output, and which would be very useful to debug my feature. But if I try to enable it, then I get a number of undefined, namely the procedure "Get_directive" and the identifiers "is_conditional", "_DIR_DEFINE" and "_DIR_UNDEF". Searching in the source tree they appear not to be anywhere. Are they only to be found in svn repository, or it's just stale stuff, not used anymore? Many thanks, Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM "based" construct?
Thaddy ha scritto: Giuliano Colla wrote: I've never found the C++ way (Button->Click) more telling than FPC way (Button.Click), on the contrary I find it cumbersome, but of course you're free to think otherwise. Huh? Button.Click is perfectly legal in C++... Not if Button is a pointer. C++ makes a difference wether between Button.Click (direct) and Button->Click (dereference). FPC, in case of objects does not. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM "based" construct?
Micha Nelissen ha scritto: Giuliano Colla wrote: Micha Nelissen ha scritto: Giuliano Colla wrote: With "absolute" you need a) to declare an extra type (PByte, or "Declaring an extra type" is one of those things that make Pascal what it is; declaring before use. You mean that declaring "twice" is smarter than declaring just once? You're actively trying to deceive me here? Nothing is declared "twice" as in "two times", but the declaration is split in two pieces. Btw, 9 times out of 10 the type declaration is reused multiple times so in the end it saves typing. I try to make myself more clear. Of course the "based" construct comes useful when you're dealing with structured data such as records. And of course you need a type declaration for your record. But currently you need a second type declaration for a pointer to that record. This is not a split declaration, but an extra declaration. one for the typed pointer itself. The Pascal type is visible in the pointer type declaration, and not in the pointer declaration (which is in a different section, var vs. type, which in a large program can be That's why names were invented in programming languages. Names can add meaning to types. It can make the reader see structure instead of chaos. The record type name is meaningful, the pointer type name is not. The usual way is to use the same name of the record, prepended by a P. If it can be inferred from the structure name, it's pleonastic. If it can't it's obfuscating. The "based" construct makes it implicit. It would be more consistent with the rest of the language, but what I suggest is to push consistency on the opposite direction. The opposite direction is the wrong direction. I've never found the C++ way (Button->Click) more telling than FPC way (Button.Click), on the contrary I find it cumbersome, but of course you're free to think otherwise. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM "based" construct?
Micha Nelissen ha scritto: Giuliano Colla wrote: With "absolute" you need a) to declare an extra type (PByte, or "Declaring an extra type" is one of those things that make Pascal what it is; declaring before use. You mean that declaring "twice" is smarter than declaring just once? You need two declarations: one for the type of the typed pointer, and one for the typed pointer itself. The Pascal type is visible in the pointer type declaration, and not in the pointer declaration (which is in a different section, var vs. type, which in a large program can be quite far away). I hardly see the point. whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, So we're talking about saving typing of a '^' ? Explicitly typing a '^' when you're derefencing a pointer makes the code more readable, not less. You mean that string or object references where pointers are implicitly dereferenced make the code less readable? A MyString^[3] or a MyButton^.Click would be more readable than the current MyString[3] and MyButton.Click? It would be more consistent with the rest of the language, but what I suggest is to push consistency on the opposite direction. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM "based" construct?
Micha Nelissen ha scritto: Giuliano Colla wrote: var Pfoo: pointer; foo: "any valid FPC Type" based Pfoo; or foo: based Pfoo "any valid FPC type"; . Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; I don't see the difference between "based" and absolute, except order of keywords? With "based" you declare a variable name, which you access directly, without need of an extra type declaration. Pfoo is the pointer, foo is the variable, no ambiguity. With "absolute" you need a) to declare an extra type (PByte, or whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, then you have ambiguities wether Pfoo means the variable or the pointer. Order of keywords of course is not relevant, I just picked up the first one coming to my mind. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Could FPC add the PLM "based" construct?
Hello FPC developers I've been using Algol-like languages since the times of Algol '60. In general I'm rather happy with FPC, but I miss a feature which I found in Intel's PLM languages. I'd like to submit it to see if there's a chance it could be introduced in FPC. The feature is the *based* construct, which makes IMHO typed pointers much easier to deal with. It makes the code easier to write, more readable, and shouldn't break anything existing: it would be a language extension, which, in my incompetent judgment, should be fairly simple to implement. Those who don't like it could just avoid using it, and continue the old way. For those unfamiliar with PLM, the construct in FPC could like that: var Pfoo: pointer; foo: "any valid FPC Type" based Pfoo; or foo: based Pfoo "any valid FPC type"; . Pfoo := APointer; foo := Whatever; WhateverElse := foo; This would make Pfoo an untyped pointer, while any occurrence of foo would be replaced by the compiler with a Pfoo^, typed unambiguously by foo type. Multiple declarations are allowed such as: var Pfoo: pointer; Bfoo: byte based Pfoo; Ifoo: Integer based Pfoo; implementation Pfoo := ABytePointer; Bfoo := WhateverByte; Pfoo := AnIntegerPointer; WhateverInteger := Ifoo; This becomes particularly handy when the fpc types more complex, such as different record types. Currently, to achieve the same result you need to write more, without adding to readability and maintainability, but perhaps adding something to obscurity instead: type PByte: ^byte; PInteger: ^Integer; ... var Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; implementation PBfoo := ABytePointer; PBfoo^ := whateverByte; ... PIfoo := AnIntegerPointer; whateverInteger := PIfoo^; Something of the sort is already done with objects or strings where the pointer declaration is implicit. This construct would extend the same logic to all other types, but with an explicit declaration of the pointer. It would, IMHO help to get rid of some of the obscurity inherited by the C language constructs. This would also help to get rid, of the ambiguities (also inherited for C) where a variable name sometimes means the value, sometimes means the pointer, depending on context. Any opinion? -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetText's GetLanguageIDs()
Graeme Geldenhuys ha scritto: On 01/03/2008, Ales Katona <[EMAIL PROTECTED]> wrote: Graeme Geldenhuys wrote / napísal(a): I use getText in my game and I strip anything after 2 chars since I consider only the 2 char lang codes to be valid. Depends I guess... At the moment I changed my code to strip anything from the '.' onwards in the first language ID returned. That seems to fix my problem for now. I can't strip anything after two characters because of differences in languages like: pt_BR (Brazilian Portuguese) and pt_Pt (Portugal Portuguese) Usually this difference is ignored in text translation. It becomes relevant for other issues (such as keyboard layout, date and currency format, etc.) The top, for maximum flexibility wold be: if there's a full match use it, if not find a match with the characters up to "_". So, if you have fpgui.en_US.po, fpgui.en_GB.po, an user from Canada or from Australia (en_CA, en_AU) will still have an English translation (GB or US, the first found), and not a default language af_ZA or whatever. On Linux it's easy to deal with those matters, because you may just create symlinks, but on Windows, if you use the full qualifier, you're forced to duplicate a lot of files (de_AT,de_DE,de_CH, or fr_FR,fr_CA,fr_CH, etc.). Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
Felipe Monteiro de Carvalho ha scritto: On Mon, Feb 25, 2008 at 10:12 AM, Michael Schnell <[EMAIL PROTECTED]> wrote: IMHO, nowadays, 8 (and 16) bit processors only make sense for very small projects. Those are very hardware specific and thus using C here does make sense. I have to disagree with this one, depending with what "small" means. If you mean "small" in project complexity, I'd say this is very far from true. BOSCH uses 8-bit microcontrolers (8051) widely inside several sensors (tire pressure sensors for example) and I'm sure I wouldn't call those projects simple considering the number of workers and years involved on them. If you mean "small" in size, then maybe =) The sensors are really small. Also considering how much time I saw the other internship student waste trying to understand the criptic C code for the microcontroler I'd also disagree that using C is necessarely the best choice. If Pascal, or another decent language is available, C is *never* the best choice. :-) Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] misleading error msg in fpc 2.2.0
Peter Vreman ha scritto: Please submit a bug report with example code so it will not be forgotten. Done. Thank you Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] misleading error msg in fpc 2.2.0
While porting Delphi CLX library to fpc/Lazarus, I mixed up things, and I tried to override an ancestor method which is static in CLX, because I remembered it to be virtual in Lazarus. So far so good, but it took me some time to sort out the problem, because the compiler error message was "There's no ancestor method to be overridden", instead of "A static method can't be overridden" (as Delphi tells in such cases). So I started looking for typos, wrong inheritance, etc, instead of looking for the real bug. Has this error message been fixed in 2.3.1 or it's still there? Clear and unambiguous error messages are among the advantages of Pascal over C++. It would be a pity to leave there a misleading error message. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBits class bug?
Michael Van Canneyt ha scritto: Please submit a patch to me. I'll review and apply it. O.K. Provided I succeed ;-) , I'll do it. Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBits class bug?
Marco van de Voort ha scritto: However FPC implementation makes inconsistent the values returned from OpenBit with those obtained reading Size. Do I miss some point? I can imagine bits being allocated in words to avoid endianess problems. So it could be a deliberate deviation for portabilities sake. That the implementation needs to be different to support different platforms I can understand. Delphi implementation uses asm code which make it i386 specific. What I find harder to swallow is that a size of 31 is reported, when the allocated size is 1 and the available size is 32. Current implementation makes it impossible to detect if an OpenBit has actually created a grow of the bitlist or not, which is necessary if the bitlist is used to keep track of other objects being allocated. If nobody else is taking care of the matter, as I have a test case ready, I could try and fix TBits implementation, in oder to keep portability but to provide self-consistency, and submit a patch. Kind regards, Giuliano -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TBits class bug?
While porting the Delphi Kylix CLX library to fpc, I had errors related
to Tbits class. Simply lifting the Delphi implementation into the code
solved the problems.
A quick investigations shows that at least the Size property has a
different meaning.
While Delphi reports the actual number of allocated bits (i.e. 1-2-3
etc) FPC reports a fixed value of 31 for 1 to 32 bits allocated, and
then 63, and so on:
{bits.inc}
function TBits.getSize : longint;
begin
result := (FSize shl BITSHIFT) - 1;
end;
It seems to me that, besides not being Delphi compatible, this is also
wrong, because the actual available space size is (FSize shl BITSHIFT)
not decreased by one.
However FPC implementation makes inconsistent the values returned from
OpenBit with those obtained reading Size.
Do I miss some point?
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] kernel module with fpc
Jonas Maebe ha scritto: See the exaplanation right above the Makefile that your copied from the wiki page: http://wiki.freepascal.org/linux/kernel/module_development#Compilation "In order to compile the kernel module, you need an object file called kernel_module_info.o. This file is generated automatically by the kernel build system." Copy it to the same directory as the other files. No kernel_module_info.* in my kernel build tree. I'm using a kernel 2.6.17. Is that a feature of newer, or older kernels, or should I have selected some special options when compiling the kernel? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] kernel module with fpc
I'd need to create kernel modules written in fpc, so I started by testing the Wiki example: http://wiki.freepascal.org/linux/kernel/module_development but I stuck in an error message I never met before when dealing with kernel modules: No rule to make target kernel_module_info.s needed by kernel_module_info.o (See attached make output). Why does it need an assembler source? What I'm missing? Any help is appreciated, Giuliano fpc kernel_module Free Pascal Compiler version 2.2.0 [2007/08/31] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Linux for i386 Compiling kernel_module.pas Compiling system.pas kernel_module.pas(164,9) Note: Local variable "data" not used kernel_module.pas(165,9) Note: Local variable "cmd" not used kernel_module.pas(14,9) Note: Local variable "i" not used kernel_module.pas(14,12) Note: Local variable "j" not used kernel_module.pas(27,9) Note: Local variable "msg" not used kernel_module.pas(28,9) Note: Local variable "msg_Ptr" not used 467 lines compiled, 0.0 sec 6 note(s) issued make -C /lib/modules/2.6.17.11rtai/build SUBDIRS=/home/colla/Applicazioni/Lazarus/KernelMod modules make[1]: Entering directory `/home/colla/Applicazioni/linux-2.6.17' make[2]: *** No rule to make target `/home/colla/Applicazioni/Lazarus/KernelMod/kernel_module_info.s', needed by `/home/colla/Applicazioni/Lazarus/KernelMod/kernel_module_info.o'. Stop. make[1]: *** [_module_/home/colla/Applicazioni/Lazarus/KernelMod] Error 2 make[1]: Leaving directory `/home/colla/Applicazioni/linux-2.6.17' make: *** [default] Error 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] merge request for 9342
Vincent Snijders ha scritto:
Can revision 9342 (Allow using constants in {$IF } directive in OBJFPC
mode) be merged to the fixes 2.2 branch?
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=9342
Sorry, I replied thinking you were referring to Lazarus-dev. Mail filter
put the message in the wrong folder!
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] merge request for 9342
Vincent Snijders ha scritto:
Can revision 9342 (Allow using constants in {$IF } directive in OBJFPC
mode) be merged to the fixes 2.2 branch?
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=9342
I can't see anything against, now.
Maybe I'll have obejctions once the patch is applied, and it turns out
that it breaks the IDE, but c'est la vie!
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
