[fpc-pascal] Re: Support for C++ library format?
Hi, Ok, I understand the situation. I guess I am looking for a "perfect world" where you could choose your language more freely and still use all the great libraries out there. I think support for GCC C++ libraries in FPC could be done with enough effort. It would be much more difficult than supporting cdecl or stdcall calling conventions for C libraries of course. Maybe it is not worth the effort. Interesting things are happening in the interpreted / dynamic language world. For example the Parrot / Perl6 people realized that supporting many languages has no benefit unless they all can use the same libraries as well. And so, all languages run under Parrot really can use libraries written in any of the other supported languages. http://www.parrot.org/languages However, dynamic or interpreted languages have resource hungry virtual machines and so they are not suitable for all tasks, and I don't like bloated SW anyways... I know that Java and such are fast nowadays with JIT compilers but the memory overhead is big and that is not about to change. So, you want to use a compiled object oriented language, supported in many platforms and having decent libraries. What alternatives do you have? There is C++ and ... what else... ? ok, there is Free Pascal! I have a soft spot for Object Pascal because of my use of Delphi. The language syntax is good now when generics were added. Few more improvements and it would be perfect. A common library format for compiled OO languages would be a real improvement, competing directly with the development happening in dynamic / interpreted languages. I guess I am not the first person to have this idea, but... wrote it anyway. Juha Manninen --- > I believe that using C++ objects directly is not very easy. I have found > some time ago this site about how to do this in Delphi. > > http://rvelthuis.de/articles/articles-cppobjs.html > > However, Borland used to publish a C++ compiler at that time. And I > believe that this solution is compiler dependant. > > Overall, I think that wrapping the object into C function then in Free > Pascal is the easy way. If C++ objects are really needed, I prefere to > write a C++ procedure to perform everything that really needs this > coding, then I wrap it in C and Free Pascal. > > I hope I could help more. > > Ciao, > Gilles Marcou ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Support for C++ library format?
On 06 Oct 2009, at 10:25, Juha Manninen wrote: A common library format for compiled OO languages would be a real improvement, competing directly with the development happening in dynamic / interpreted languages. I guess I am not the first person to have this idea, but... wrote it anyway. This is the goal of the Microsoft CLI (Common Language Infrastructure). The library format in this case is an intermediate one rather than a native one (CIL, Common Intermediate Language), but it can be statically compiled into machine code afterwards. It also supports both dynamic languages (there are e.g. IronPython and IronRuby) and non-dynamic languages (C#, F#, C++, C, ...). It's also supposed to have explicit support for mixing different object models in a single program. Borland/CodeGear tried to take advantage of this with Delphi .NET, but apparently weren't very successful with it (although that's probably in the eye of the beholder). I never looked into the details, so I don't know why. Having a common API without an intermediate format would however be virtually impossible to design, especially if you want to guarantee backwards binary compatibility for all of the languages that you want to interoperate. You really need some kind of intermediate level with meta-information (higher level than the pure machine code) which describes what is a class, a method, inheritance trees, etc if you want to enable transparently mixing code coming from different languages/compilers. Well, you could try to write something like http://sourceware.org/libffi/ geared at different object models rather than at simply different ABIs, but I think it would be more fragile and it would offer less integration possibilities. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Clear interactive questions with default values management ?
Hi, Following another post on menu building I'd like to know if someone could help me to build such kind of interactive Linux console questions : Question 1 [Default_Value_1] ? Default_Value_1<- default value appears here if/when I press ENTER (without providing another custom value) Question 2 [Default_Value_2] ? My_Custom_Value<- I enter a value then I press ENTER Question 3 [Default_Value_3] ? etc... Of course any value (default or custom) are grabbed into variables. This appears quite simple but I tried lot of things and there is always something which fails (formatting, default value writting etc...) Hope this is clear. Thanks, Tom -- View this message in context: http://www.nabble.com/Clear-interactive-questions-with-default-values-management---tp25765581p25765581.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Support for C++ library format?
Thanks for your answer.
Now I admit the C++ library support was a bad idea. Even the different C++
compilers are not binary compatible. It is a big mess.
I liked the design of .NET, yes. However, I think compiling CIL to machine
code is not the same thing as with real compiled languages. I don't know the
details though.
At least my experience is that any program run under .NET or Mono starts
slowly and hogs memory. In that respect it is comparable to Java.
So, my "scientific" classification of all object oriented multi-platform
programming languages is here:
| Compiled: | | Interpreted: |
| C++| <---> | All others |
| Object Pascal | | (a long list) |
Note that C is not mentioned because it is not OO.
The "All others" list could be still divided into Dynamic and Non-Dynamic but
it is irrelevant here. Dynamic language features have still more overhead but
when used cleverly they can make the program simpler and smaller.
The main strength of Object Pascal (and FPC) is that it is compiled. I see it
as the only justification for the whole language. Otherwise we could just dump
it and start using C# or Java or something which have cleaner syntax without
carrying historical (pointer) syntax.
This language is not as popular as some others. How to improve it to meet
today's demands?
The syntax could still be improved. I understood generics are coming to FPC,
too, which is good.
Then, backwards compatibility could be broken. Yes. The old pointer syntax
could be forbidden by default and allowed only in some "Error prone mode" or
"Ugly code mode".
That would allow more aggressive optimizations in the compiler, too.
And yes, I have made big complicated programs with Delphi without using
pointer syntax, so it is possible.
Other features could be borrowed shamelessly from other designs and languages.
That's how the open source stuff happens anyway. It is not a bad thing.
The main strengths would remain:
Compiled fast and small binary, easy to deploy.
Fast compilation.
Juha Manninen
> This is the goal of the Microsoft CLI (Common Language
> Infrastructure). The library format in this case is an intermediate
> one rather than a native one (CIL, Common Intermediate Language), but
> it can be statically compiled into machine code afterwards. It also
> supports both dynamic languages (there are e.g. IronPython and
> IronRuby) and non-dynamic languages (C#, F#, C++, C, ...). It's also
> supposed to have explicit support for mixing different object models
> in a single program.
>
> Borland/CodeGear tried to take advantage of this with Delphi .NET, but
> apparently weren't very successful with it (although that's probably
> in the eye of the beholder). I never looked into the details, so I
> don't know why.
>
> Having a common API without an intermediate format would however be
> virtually impossible to design, especially if you want to guarantee
> backwards binary compatibility for all of the languages that you want
> to interoperate. You really need some kind of intermediate level with
> meta-information (higher level than the pure machine code) which
> describes what is a class, a method, inheritance trees, etc if you
> want to enable transparently mixing code coming from different
> languages/compilers.
>
> Well, you could try to write something like http://sourceware.org/libffi/
> geared at different object models rather than at simply different
> ABIs, but I think it would be more fragile and it would offer less
> integration possibilities.
>
>
> Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Support for C++ library format?
On 06 Oct 2009, at 13:28, Juha Manninen wrote: I liked the design of .NET, yes. However, I think compiling CIL to machine code is not the same thing as with real compiled languages. It can be. At least my experience is that any program run under .NET or Mono starts slowly and hogs memory. In that respect it is comparable to Java. You can use .NET in two ways: as a virtual environment similar to Java (in which case you use Mono), or simply as an intermediate bytecode format which is later on compiled to machine code (similar to LLVM -- which you also can use in a virtual environment, for that matter). In the latter case, there is no overhead at all (or there doesn't have to be any, at least). E.g., STMicroelectronics is using this for their embedded systems using GCC4Net: http://gcc.gnu.org/projects/cli.html . That's both a frontend (compiling GCC-supported languages into CIL -- note that C++ is not yet fully supported at this time) and a backend (compiling CIL into machine code for any CPU supported by GCC). The main strength of Object Pascal (and FPC) is that it is compiled. I see it as the only justification for the whole language. Otherwise we could just dump it and start using C# or Java or something which have cleaner syntax without carrying historical (pointer) syntax. If that's the only reason why you use Object Pascal, you can probably start using C# instead without any problems. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Case in Record
In the document (http://www.freepascal.org/docs-html/ref/refsu15.html#x38-450003.3.2) I read the code below: Type MyRec = Record X : Longint; Case byte of 2 : (Y : Longint; case byte of 3 : (Z : Longint); ); end; I still cannot understand what do these two "byte" mean. I have difficulty in understanding "The optional identifier in the case statement serves to access the tag field value, which otherwise would be invisible to the programmer" and need some explain. Thank you. Another problem is about Object and Class. I notice that in wiki (http://wiki.freepascal.org/Object_Oriented_Programming_with_FreePascal_and_Lazarus), Class is explained as a pointer to the structure, while Object returns the whole structure. And the wiki said that Object is not used very much. Does this mean that Object is deprecated? Can Objects contain any properties? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dataset modification and reading at the same time
You are right, but what I want isn't append, I want to insert after the current record, not in the end of the dataset. It seams that what I need is a new button option to TDBNavigator, maybe nbInsertAfter. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
2009/10/6 章宏九 : > In the document > (http://www.freepascal.org/docs-html/ref/refsu15.html#x38-450003.3.2) > I read the code below: > > Type > MyRec = Record > X : Longint; > Case byte of > 2 : (Y : Longint; > case byte of > 3 : (Z : Longint); > ); > end; > > I still cannot understand what do these two "byte" mean. I have > difficulty in understanding "The optional identifier in the case > statement serves to access the tag field value, which otherwise would > be invisible to the programmer" and need some explain. Thank you. Look at the second example on this page: http://delphibasics.co.uk/RTL.asp?Name=Record > > Another problem is about Object and Class. I notice that in wiki > (http://wiki.freepascal.org/Object_Oriented_Programming_with_FreePascal_and_Lazarus), > Class is explained as a pointer to the structure, while Object returns > the whole structure. And the wiki said that Object is not used very > much. Does this mean that Object is deprecated? Can Objects contain > any properties? Look at this page for an explanation of the basic difference: http://freepascal.org/docs-html/ref/refch6.html I can't really comment on the scary details, since I'm rubbish at object oriented programming :) Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
On Tue, Oct 6, 2009 at 10:13 AM, 章宏九 wrote: > Type > MyRec = Record > X : Longint; > Case byte of > 2 : (Y : Longint; > case byte of > 3 : (Z : Longint); > ); > end; I think the cases are useless here. AFAIK the case inside record is utilized to give multiple options of use for the same memory area. It is used so that the same structure can have multiple uses without wasting space. But this is pointless if the case has only 1 option, it should have 2 or more to make sense. For me the above is the same as: Type MyRec = Record X : Longint; Y: Longint; Z: Longint; end; I think that visibility isn't in place because even with multiple options you can access any of them at any given time even if they conflict. > And the wiki said that Object is not used very > much. Does this mean that Object is deprecated? Deprecated means that the feature will or may be removed in the future, but AFAIK there are no plans to remove support for Object. So I would say it's a legacy feature (from Turbo Pascal), but not deprecated at the moment. If you are not sure which one to use, then just use classes. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
2009/10/6 Henry Vermaak : > > I can't really comment on the scary details, since I'm rubbish at > object oriented programming :) And objects aren't deprecated, since the compiler uses them (afaik). Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
On 06/10/2009 15:00, Felipe Monteiro de Carvalho wrote: On Tue, Oct 6, 2009 at 10:13 AM, 章宏九 wrote: Type MyRec = Record X : Longint; Case byte of 2 : (Y : Longint; case byte of 3 : (Z : Longint); ); end; I think the cases are useless here. AFAIK the case inside record is utilized to give multiple options of use for the same memory area. Yup. Like you say, this is a wierd example. It's called a "variant record". Google for that term. http://www.delphicorner.f9.co.uk/articles/op6.htm That means, a record structure where one or more fields occupy the same memory, but have different types. Like a union in C. So depending on which field you read, the memory area can be read in different types. So if you have Type MyRec = Record Case byte of 1: (X : Integer;); 2: (Y : Word;); end; var v : MyRec; Begin v.y := 65535; writeln(v.x); end. assigning 65535 to v.y sets the underlying bytes to $FF, $FF so v.X is -1. Now, one would not normally do this (writing to one field and reading the other). If you write to one field, the memory under the other one(s) is messed up. So you should only read from the field that you write to. How do you know which field to read from? Normally, you would have a tag field. This is a field with a specific ordinal type coming before the variant fields. Type MyRec = Record Case FieldType:byte of 1: (X : Integer;); 2: (Y : Word;); end; Now, if you are writing to field X, you should write a 1 to FieldType. Elsewhere in your program, you can read FieldType, and if it is 1 you read x. If it is 2 you read y. And if it is some other value you output an error message... I think the syntax with just a type and no tag field name (case byte of) was invented afterwards, to handle the case when you don't want a tag field. ... And the wiki said that Object is not used very much. Does this mean that Object is deprecated? Deprecated means that the feature will or may be removed in the future, but AFAIK there are no plans to remove support for Object. So I would say it's a legacy feature (from Turbo Pascal), but not deprecated at the moment. Object was introduced in the first object-oriented Borland Pascal, TurboPascal 5.5. To use polymorphism, you access objects through a pointer (because if you say var o:tMyObject; then you *know* what type it is). When Delphi came along, seems Borland decided that everyone should *always* use pointers for object types, and introduced the Class, which is always on the heap and handled as a pointer. Any new concepts that were introduced, like properties, were applied only to the new classes and objects were left in a corner, like the embarrassing relative that you wish you could get rid of, but can't. IMHO objects are the less confusing of the two, but they seem to be, not quite deprecated, but discouraged. So as Felipe said: If you are not sure which one to use, then just use classes. FP ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
Thank you. I saw all the examples you gave, but I still cannot master how to use a variant record without a specified tag. For example: type TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other); TFigure = record case TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; var Figure1: TFigure; How can I specified the TShapelist value in a Figure1? 2009/10/6 Henry Vermaak : > 2009/10/6 Henry Vermaak : >> >> I can't really comment on the scary details, since I'm rubbish at >> object oriented programming :) > > And objects aren't deprecated, since the compiler uses them (afaik). > > Henry > ___ > fpc-pascal maillist - fpc-pas...@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
[fpc-pascal] Early BSD's Pascal system
I notice that in early 1977, BSD contains a Pascal interpreter (or maybe compiler, I am not sure). How was it later? Is there any remain archives? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Early BSD's Pascal system
In our previous episode, ? said: > I notice that in early 1977, BSD contains a Pascal interpreter (or > maybe compiler, I am not sure). How was it later? Is there any remain > archives? Yes, more commonly known "Berkeley Pascal". The manual, http://roguelife.org/~fujita/COOKIES/HISTORY/2BSD/puman.html seems to mention a certian "William N. Joy" as partial author, the big BSD pioneer and Sun founder. It seems to be a bytecode Pascal. (iow compiler + interpreter like UCSD) Afaik it can be found in old tars of early BSD versions online (at least I could a few years back), but it never migrated to the modern BSD after the Settlement, and afaik it is dead for twenty years. Throwing "Berkeley Pascal" in google will probably turn up some stuff. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Early BSD's Pascal system
On Tue, 6 Oct 2009 23:44:28 +0800, 章宏九 wrote about [fpc-pascal] Early BSD's Pascal system: > I notice that in early 1977, BSD contains a Pascal interpreter (or > maybe compiler, I am not sure). How was it later? Is there any remain > archives? I suspect it is the UCSD (University of California at San Diego) Pascal compiler. It compiled source to p-code and its run-time interpreted the p-code tokens (a la Java, today). Google is your friend. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
2009/10/6 章宏九 : > Thank you. I saw all the examples you gave, but I still cannot master > how to use a variant record without a specified tag. > > For example: > type > TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other); > TFigure = record > case TShapeList of > Rectangle: (Height, Width: Real); > Triangle: (Side1, Side2, Angle: Real); > Circle: (Radius: Real); > Ellipse, Other: (); > end; > var > Figure1: TFigure; > > How can I specified the TShapelist value in a Figure1? You can specify an identifier in the case statement, which will become a new field. You can then specify what the record is used for currently, e.g.: TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other); TFigure = record case Shape: TShapeList of ^^^ Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; Then you can set .Shape to Rectangle, for instance, and fill in .Height and .Width. A function receiving a variable of this record can then see what shape it is currently used for. You need to maintain this .Shape field, though. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Early BSD's Pascal system
Thank you for your detailed information. 2009/10/6 Marco van de Voort : > In our previous episode, 章宏九 said: >> I notice that in early 1977, BSD contains a Pascal interpreter (or >> maybe compiler, I am not sure). How was it later? Is there any remain >> archives? > > Yes, more commonly known "Berkeley Pascal". The manual, > > http://roguelife.org/~fujita/COOKIES/HISTORY/2BSD/puman.html > > seems to mention a certian "William N. Joy" as partial author, the big BSD > pioneer and Sun founder. It seems to be a bytecode Pascal. (iow compiler + > interpreter like UCSD) > > Afaik it can be found in old tars of early BSD versions online (at least I > could a few years back), but it never migrated to the modern BSD after the > Settlement, and afaik it is dead for twenty years. > > Throwing "Berkeley Pascal" in google will probably turn up some stuff. > ___ > fpc-pascal maillist - fpc-pas...@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
[fpc-pascal] Help collecting GetAppConfigDir output
Hello,
I am trying to collect the output of GetAppConfigDir/File from various
systems, but I don't have easy access to a Windows Vista computer.
Maybe someone would be kind enough to run the following trivial
application in Windows Vista and return the output =)
thanks in advance,
program project1;
{$mode objfpc}{$H+}
uses
SysUtils;
begin
WriteLn(GetAppConfigDir(True));
WriteLn(GetAppConfigDir(False));
WriteLn(GetAppConfigFile(True));
WriteLn(GetAppConfigFile(False));
end.
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help collecting GetAppConfigDir output
Felipe Monteiro de Carvalho wrote:
Hello,
I am trying to collect the output of GetAppConfigDir/File from various
systems, but I don't have easy access to a Windows Vista computer.
Maybe someone would be kind enough to run the following trivial
application in Windows Vista and return the output =)
thanks in advance,
program project1;
{$mode objfpc}{$H+}
uses
SysUtils;
begin
WriteLn(GetAppConfigDir(True));
WriteLn(GetAppConfigDir(False));
WriteLn(GetAppConfigFile(True));
WriteLn(GetAppConfigFile(False));
end.
32bit vista home premium SP2
C:\ProgramData\project1\
C:\Users\martin\AppData\Local\project1\
C:\ProgramData\project1\project1.cfg
C:\Users\martin\AppData\Local\project1\project1.cfg
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
Thank you. I saw all the examples you gave, but I still cannot master how to use a variant record without a specified tag. If you use a specific tag as in type TFigure = record case ShapeName : TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; then you will get an additional part in your record named "ShapeName" which can (but not necessarily must) be used to store the meaning of the record variants. If you don't use such a variable name as in type TFigure = record case TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; then you have to detect the meaning of the variants in some other way. In both cases you can directly access the variants as in TFigure.Triangle or TFigure.Rechtangle. But if you stored with one variant and read with another you will get a lot of mess. ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help collecting GetAppConfigDir output
FPC 2.2.4? The implementation changed of this routine changed in recent versions. thanks, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
On Tue, 2009-10-06 at 23:37 +0800, 章宏九 wrote:
> Thank you. I saw all the examples you gave, but I still cannot master
> how to use a variant record without a specified tag.
>
> For example:
> type
> TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
> TFigure = record
> case TShapeList of
> Rectangle: (Height, Width: Real);
> Triangle: (Side1, Side2, Angle: Real);
> Circle: (Radius: Real);
> Ellipse, Other: ();
> end;
> var
> Figure1: TFigure;
>
AFAIK there has to be some fixed part before the variant, e. g.
TFigure = record
name: string;
case TShapeList of
Rectangle: (Height, Width: Real);
Triangle: (Side1, Side2, Angle: Real);
Circle: (Radius: Real);
Ellipse, Other: ();
end;
The program could then determine from the contents of the "name" field
which variant is used in a certain instance. This saves memory ("TShapeList"
has no memory reserved at run time), but the program is responsible
to correctly identify the variant using the "name" field.
Anton
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Early BSD's Pascal system
David W Noon wrote: On Tue, 6 Oct 2009 23:44:28 +0800, 章宏九 wrote about [fpc-pascal] Early BSD's Pascal system: I notice that in early 1977, BSD contains a Pascal interpreter (or maybe compiler, I am not sure). How was it later? Is there any remain archives? I suspect it is the UCSD (University of California at San Diego) Pascal compiler. It compiled source to p-code and its run-time interpreted the p-code tokens (a la Java, today). ... Please see ftp://ftp.freepascal.org/pub/fpc/attic/ucsd-pascal/ Thank you very much . Mehmet Erol Sanliturk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help collecting GetAppConfigDir output
Felipe Monteiro de Carvalho wrote: FPC 2.2.4? The implementation changed of this routine changed in recent versions. thanks, last result was with Free Pascal Compiler version 2.5.1 [2009/09/22] for i386 just tried with Free Pascal Compiler version 2.2.5 [2009/04/03] for i386 same results: C:\ProgramData\project1\ C:\Users\martin\AppData\Local\project1\ C:\ProgramData\project1\project1.cfg C:\Users\martin\AppData\Local\project1\project1.cfg ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help collecting GetAppConfigDir output
Thanks a lot. The change I was talking about was between 2.2.0 and 2.2.4 -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help collecting GetAppConfigDir output
Felipe Monteiro de Carvalho wrote: Thanks a lot. The change I was talking about was between 2.2.0 and 2.2.4 Yep, here are the results with the oldest fpc, I still have... (2.2.2 seems to have the newer/other result) Free Pascal Compiler version 2.2.0 [2007/11/14] for i386 C:\Users\martin\AppData\Local\Temp C:\Users\martin\AppData\Local\project1 C:\Users\martin\AppData\Local\Temp\project1.cfg C:\Users\martin\AppData\Local\project1\project1.cfg ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
I see. That means if no tag name is given, I should make sure my code
is correct by myself.
Thank you.
2009/10/7 Anton Tichawa :
> On Tue, 2009-10-06 at 23:37 +0800, 章宏九 wrote:
>> Thank you. I saw all the examples you gave, but I still cannot master
>> how to use a variant record without a specified tag.
>>
>> For example:
>> type
>> TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
>> TFigure = record
>> case TShapeList of
>> Rectangle: (Height, Width: Real);
>> Triangle: (Side1, Side2, Angle: Real);
>> Circle: (Radius: Real);
>> Ellipse, Other: ();
>> end;
>> var
>> Figure1: TFigure;
>>
>
> AFAIK there has to be some fixed part before the variant, e. g.
>
> TFigure = record
> name: string;
> case TShapeList of
> Rectangle: (Height, Width: Real);
> Triangle: (Side1, Side2, Angle: Real);
> Circle: (Radius: Real);
> Ellipse, Other: ();
> end;
>
> The program could then determine from the contents of the "name" field
> which variant is used in a certain instance. This saves memory ("TShapeList"
> has no memory reserved at run time), but the program is responsible
> to correctly identify the variant using the "name" field.
>
> Anton
>
>
> ___
> fpc-pascal maillist - fpc-pas...@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] TUN/TAP
ifreq becomes
Const
TUNSETIFF = $400454ca
IFF_TUN = $0001
IFF_TAP = $0002
type
ifreq = record
ifr_ifrn : record
case longint of
0 : ( ifrn_name : array[0..15] of char );
end;
ifr_ifru : record
case longint of
0 : ( ifru_addr : sockaddr );
1 : ( ifru_dstaddr : sockaddr );
2 : ( ifru_broadaddr : sockaddr );
3 : ( ifru_netmask : sockaddr );
4 : ( ifru_hwaddr : sockaddr );
5 : ( ifru_flags : smallint );
6 : ( ifru_ivalue : longint );
7 : ( ifru_mtu : longint );
8 : ( ifru_map : ifmap );
9 : ( ifru_slave : array[0..15] of char );
10 : ( ifru_newname : array[0..15] of char );
11 : ( ifru_data : __caddr_t );
end;
end;
now i need to translate sockaddr, ifmap, __caddr_t etc
but thanks !
2009/10/5 Henry Vermaak
> 2009/10/3 Jorge Aldo G. de F. Junior :
> > Can anyone help me decypher the following code :
> >
> > int tun_alloc(char *dev)
> > {
> > struct ifreq ifr;
>
> First, you need to get a pascal definition of struct ifreq, so look in
> /usr/include/linux/if.h and translate it to pascal (or try and use
> h2pas).
>
> > int fd, err;
> >
> > if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
> > return tun_alloc_old(dev);
>
> You will have to use fpopen here.
>
> >
> >
> > memset(&ifr, 0, sizeof(ifr));
>
> Use fillchar.
>
> >
> > /* Flags: IFF_TUN - TUN device (no Ethernet headers)
> >*IFF_TAP - TAP device
> >*
> >*IFF_NO_PI - Do not provide packet information
> >
> >*/
>
> These flags are defined int /sys/include/linux/if_tun.h.
>
> > ifr.ifr_flags = IFF_TUN;
> > if( *dev )
> > strncpy(ifr.ifr_name, dev, IFNAMSIZ);
>
> ifr_name is defined to be ifr_ifrn.ifrn_name in if.h.
>
> >
> > if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
>
> lol. TUNSETIFF (_IOW('T', 202, int)) is generated by the various
> macros in /usr/include/asm-generic/ioctl.h. Work it out, or write a c
> program to give you the number. Then use fpioctl.
>
> The rest should be straight forward.
>
> Henry
> ___
> 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] Case in Record
AFAIK there has to be some fixed part before the variant, e. g. TFigure = record name: string; case TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; The program could then determine from the contents of the "name" field which variant is used in a certain instance. How would that work? "name" is just a string which you can assign an arbitrary value to. The compiler cannot store additional information in it. The detection of the correct variant is completely up to the programmer. There is no help by the compiler. Therefore, there is absolutly no difference between TFigure = record X : TShapeList; case TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; and TFigure = record case X : TShapeList of Rectangle: (Height, Width: Real); Triangle: (Side1, Side2, Angle: Real); Circle: (Radius: Real); Ellipse, Other: (); end; It ends up in the same record and also the programmer does not see any difference. He can store whatever he wants in X in both cases. It has no influences on the variants. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TUN/TAP
> Jorge Aldo G. de F. Junior schrieb: type ifreq = record ifr_ifrn : record case longint of 0 : ( ifrn_name : array[0..15] of char ); end; ifr_ifru : record case longint of 0 : ( ifru_addr : sockaddr ); 1 : ( ifru_dstaddr : sockaddr ); 2 : ( ifru_broadaddr : sockaddr ); 3 : ( ifru_netmask : sockaddr ); 4 : ( ifru_hwaddr : sockaddr ); 5 : ( ifru_flags : smallint ); 6 : ( ifru_ivalue : longint ); 7 : ( ifru_mtu : longint ); 8 : ( ifru_map : ifmap ); 9 : ( ifru_slave : array[0..15] of char ); 10 : ( ifru_newname : array[0..15] of char ); 11 : ( ifru_data : __caddr_t ); end; end; What is the reason of the first case statement in the record? There is only one variant so you can omit it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
On Wed, 2009-10-07 at 07:22 +0200, Jürgen Hestermann wrote: > Therefore, there is absolutly no difference between > > TFigure = record >X : TShapeList; >case TShapeList of > Rectangle: (Height, Width: Real); > Triangle: (Side1, Side2, Angle: Real); > Circle: (Radius: Real); > Ellipse, Other: (); > end; > > and > > TFigure = record >case X : TShapeList of > Rectangle: (Height, Width: Real); > Triangle: (Side1, Side2, Angle: Real); > Circle: (Radius: Real); > Ellipse, Other: (); > end; > > It ends up in the same record and also the programmer does not see any > difference. He can store whatever he wants in X in both cases. It has no > influences on the variants. True. The second example has better style, though. But the point is that X can be completely omitted. E. g. you have the freedom to encode the information contained in X in some other way. It might be derived from a name or a part number. Anton ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Case in Record
On 10/06/2009 06:31 PM, Frank Peelo wrote: Any new concepts that were introduced, like properties, were applied only to the new classes and objects were left in a corner, like the embarrassing relative that you wish you could get rid of, but can't. However, AFAIK Free Pascal supports properties in objects as well as global properties (that is properties, that act like a global variable, outside any object or class). But that's a Free Pascal specific extension, it's not supported by Delphi. Which is a non-issue for me, since I only use FPC these days :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CIL as a target machine for FP binaries
Hi, I am changing the title of the topic, but it follows the discussion with Juha Manninen and the last answer of Jonas. In fact, I have asked some time ago, if there was a way to produce with FPC some kind of Java compatible bytecode. I was answered that it was not possible because of some fundamental choices that has been done during FPC development: generating bytecode would mean to rewrite the whole FPC. But, I have read on the web site posted by Jonas, that the GCC sees the CIL as a target platform of the compiler. If the GCC can do it, isn't it possible to do it also for FPC? Also, does producing CIL compliant binaries could help the development of client side applet for web applications? Ciao, Gilles Marcou ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
