[fpc-pascal] bootstrapping from svn
Well, I decided to make another attempt at running from the svn fixes_2_6 branch The first problem I encountered was that I could not compile from fpc 2.4.4. It sure would be nice if a compatible ppc386 executable was included in the repository, so I wouldn't have to go download it from somewhere else. Thoughts? ~David (Graeme, if you read this, have you considered creating a git branch for the 2.6 fixes branch?) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] math round vs banker's round
Hi all, I have just discovered that the system.round function has this very odd behavior of rounding towards an even number when the fractional part is .5 -- in the system.round documentation this is described as "banker's rounding" I do not like this behavior. How can I use a more mathematically-traditional round function, which always rounds .5 up, and everything below .5 down? Do I need to write this function myself? Thanks! ~David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] math round vs banker's round
Thanks for the suggestions, guys! José Mejuto wrote: > SimpleRoundTo I think. But I want an integer result, and this returns a floating point. Sven Barth wrote: Take a look at SetRoundMode in unit Math: http://www.freepascal.org/docs-html/rtl/math/setroundmode.html After calling SetRoundMode(rmNearest); I find that system.round() is still doing banker's rounding. Am I missing something? I don't see this TfpuRoundingMode mentioned anywhere in the documentation, other than the "get" and "set" functions for the same. What does it effect? ... Anyway I guess I am going to have to write my own round() function :P Cheers, ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] aggpas examples
I am trying to compile some of the aggpas examples included with lazarus, but I am getting errors upon errors. I have also tried compiling examples against the aggpas sources as downloaded from the aggpas website, outside lazarus, and again, errors and more errors. Is there a recommended way of compiling, or a source to get these sources from, where examples just work? I would like to try out this graphics library but since I am unfamiliar with it, it is not very easy to debug. Thanks! ~David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] aggpas examples
I have also tried compiling examples against the aggpas sources as downloaded from the aggpas website, outside lazarus, and again, errors and more errors. Start by naming one error. Thanks very much for your encouragement Matthias! I managed to resolve everything by moving the $include agg_mode.inc statement up above the uses clause -- that include does a delphi mode definition, which was necessary before the uses clause. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] which editor - emacs?
It took me a couple years to take that plunge (of course a couple years ago Lazarus was not as robust as it is today) but I will never go back! Lazarus does have the distinct disadvantage that it's cumbersome to work on multiple projects at once. Especially, e.g., if I want to test some feature or idea in a new little project, I tend to just do that in a separate editor rather than opening another group of lazarus windows or closing the big project I'm working on. Some of the most valuable hotkeys for me are ctrl-click on an identifier to jump to declaration; and the same can be done with ctrl-shift-up. To go down to implementation, ctrl-shift-down (codetools commands - find procedure method). I've also customized other hotkeys, e.g. moving from tab to tab, which make the source editor feel more like other editors. The customizability coupled with the great codetools features are unmatched. ~D. On Sun 10 Jan 2010, Hans-Peter Suter wrote: > 2010/1/10 dmitry boyarintsev : > > I use Lazarus as my primary IDE (i have to use Delphi in windows sometimes). > > Lazarus is the only IDE i'm using on Mac OS X. > > Just installed Lazarus and it's much better than I expected. Simple > things like 'navigating around' are great. Didn't (yet) debug and > still call the make script from the terminal though. > > What I miss, is the TextMate ability to drag a folder containing > subfolders with .pas code files into the (libray) project. > > Cheers, > Hans-Peter > > PS: thanks also to the other suggestions! And if somebody uses Emacs I > am still interested to hear about how it goes. Thanks again! > ___ > 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] FPC class syntax was extended to support delphi code
Thank you for this message! This stuff sounds really cool. In
particular, I have been itching for class constants.
A few questions come to mind:
a. 'var' sections -- I assume that 'var' is optional when declaring
fields that occur first (i.e. directly after "private", "public", etc)
b. What does "strict private" mean, as opposed to private without
strict? (My best guess is that it would be accessible only within the
methods+properties of that class within the unit, as opposed to being
available anywhere in the same unit where the class is declared...???)
c. What is the purpose of a class method? It would seem to me that
methods should do the same thing whether they are class methods or not.
Traditional variables change from instance to instance, but methods do
not vary between instances, as far as I know-- right?
d. What happens with inheritance?
d.1. wrt class constants and class vars-- are there separate "instances"
(for lack of a better word) of these, one instance for each descendant?
Or is the class var/const only stored once for the ancestor that
declares it, and all descendants share that?
d.2. wrt class methods, can they be virtual? (This strikes me as being
closely related to d.1)
I guess an example is in order for d:
type
t_parent = class
private
class var
x : integer;
const
c = 5;
end;
t_child = class (t_parent)
private
const
c = 7; // can I do this?
end;
If I change t_child.x will it change t_parent.x?
e. Is it available in {$mode objfpc}? (I hope I hope I hope)?
I'd love to test this stuff out, though I usually stick with release
versions... perhaps this is what is needed for me to take the plunge!
Either way, I'm looking forward to this being released. Great work.
Cheers,
David
On Wed 13 Jan 2010, Paul Ishenin wrote:
> Hello, FPC-Pascal users discussions
>
> I want to notify you that fpc trunk has extensions for the class
syntax.
>
> Class can have now the next sections:
>
> 1. 'var' sections to start regular fields declaration. 'var' can be
used
> after other sections and after methods
> 2. 'class var' sections to start static fields declaration. Fields
> delcared in the 'class var' section are static fields
> 3. 'type' sections to declare types local to a class. It is allowed
now
> to declare nested classes too.
> 4. 'const' section to declare constants local to a class.
> 5. 'class property' - similar to regular property but works with
static
> fields and methods
>
> Some examples:
> http://wiki.lazarus.freepascal.org/class_extensions_examples
>
> Please test and report bugs found.
>
> Best regards,
> Paul Ishenin.
> ___
> 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] FPC class syntax was extended to support delphi code
Doug Chamberlin wrote: > Class methods allow you to call the method without instantiating the > class first. For example, Result := TMyClass.MyClassFunction; Oh, that is so cool! I suppose that probably means that class methods can only reference class variables/methods/properties. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hardware information: Linux and Windows
in linux... just google list hardware linux. Below are some results. Probably not all of them will be available, but you should be able to work with whatever is available on your machine. lshal lshw lspci lsusb lsscsi systool fdisk -l dmidecode cat /proc/cpuinfo cat /proc/meminfo dmesg | egrep ‘(SCSI|scsi0|ide0|hd[a-z]|sd[a-z]|serio|mice|eth[0-9])’ ~David. On Tue 19 Jan 2010, Osvaldo Filho wrote: > How do I get information about the hardware in Linux and Windows? > - Identification of the processor: model, manufacturer, serial number > - Identification of Hard Disk: model, manufacturer, physical serial number > - Identification of Memory: model, manufacturer, size, type > - Identification of Motherboard: model, manufacturer > ___ > 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] Unsolicited messages
Jonas Maebe wrote: > Of course, this remedy will only work for a short while, since nothing > prevents the spammers to set up similar new domains... I don't know a > real remedy against this sort of stuff, unless some people start > setting up blacklists for these things too and we get a way to > integrate them with mailman. Could some sort of captcha system be integrated into the mailman subscription process? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointers
On Thu 11 Feb 2010, Rainer Stratmann wrote: > How can I have access to position 4 of a pointer? > > var > p : pbyte; > c : char; > s : ansistring; > x : longint; > > s := 'Hello'; > p := @s; > x := 4; // 4th position > c := [p+x]^ ??? how to get access to the 'o' c := (p+x)^; // why would someone use square brackets for that? Of course, if you are actually working with a string, there is no need to use pointers. c := s[5]; // remember strings are 1-indexed You can also increment... inc (p, 4); c := p^; I might make a second pointer, q, and increment that, so p can stay in place. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] some new features to delphi prisem
On Sat 20 Feb 2010, Jürgen Hestermann wrote:
>
> > y := case Other of
> > bla : 'hello';
> > foo : 'bye';
> > baz : 'adius';
> >end;
>
> What do you gain with this?
> Doesn't look much different to
>
> case Other of
>bla : y := 'hello';
>foo : y := 'bye';
>baz : y := 'adius';
>end;
or this...
type foo_type = (bla, foo, baz);
var foo_names : array [foo_type] of string = ('hello', 'bye', 'adius');
y := foo_names[other];
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] error on compilation
On Tue 16 Mar 2010, leledumbo wrote: > > How do you install fpc? Do you instal the rtl as well? Yes, you definitely need the rtl. Nowadays I install everything, as required by lazarus. In the past I used to install the barebones minimum, which if I recall correctly was the compiler and the rtl, and I think either the utils or units-base. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit v0.7-rc1 for FPC 2.4
On Tue 16 Mar 2010, Schindler Karl-Michael wrote: > Hi > > has there been already been work on a carbon backend of fpGUI? > > Michael The best place to ask about this is on the fpgui newsgroups, which are hosted by opensoft.homeip.net Discussions took place in the fpgui.support group in 2008 (June and December) and you can probably still access those messages from the news server. To summarize what was said there: - carbon was started but abandoned in favor of cocoa - cocoa was reported as "mostly working" but "very incomplete" in 2008, however there hasn't been any mention of it since ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] constructor as procvar
I'd like to pass a constructor as a procvar. Don't know if this is
possible. Here is some silly illustrative code that doesn't work:
{$mode objfpc}
uses classes, sysutils;
type
t_mammal = class
public
constructor create (color : byte); virtual;
end;
t_pig = class (t_mammal)
// some fields, methods
end;
// the following fails:
t_mammal_creator = t_mammal.constructor (color : byte) of object;
// a list of animals...
t_barnyard = class
public
function find_or_create_animal (color : byte;
pass_create : t_mammal_creator) : t_mammal;
end;
constructor t_mammal.create (color : byte);
begin
end;
function t_barnyard.find_or_create_animal (color : byte;
pass_create : t_mammal_creator) : t_mammal;
begin
// look for the animal within the list. if not found:
result := pass_create (color);
end;
const
brown = 18;
var
pig_pen : t_barnyard;
brown_pig : t_pig;
begin
pig_pen := t_barnyard.create;
brown_pig := t_pig (pig_pen.find_or_create_animal
(brown, @t_pig.create));
end.
As you can (probably) see, I would like t_barnyard to be able to create
any descendant of t_mammal. In the above example, I want it to create a
brown pig if it doesn't find one, so I tried to pass the t_pig
constructor, along with the brown parameter that said constructor will
require. But I can't figure out the syntax. Perhaps this kind of thing
is not supported?
Thanks!
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] constructor as procvar
Florian Klaempfl wrote: > Constructor procvars are indeed not supported but the way to achieve > what you want is to use class type variables > > t_mammal_class = class of t_mammal; > > function find_or_create_animal (color : byte; > pass_mammal_type : t_mammal_class) : t_mammal; > > brown_pig := t_pig (pig_pen.find_or_create_animal (brown, t_pig)); ah, that is exactly what I need. Works perfectly. Thanks much. ~D. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] constructor as procvar
How can I obtain a class type variable from an instance? I want to create a second instance of the same descendant class (via the constructor, which will take some parameters and make the new instance unique) Tobject.classtype returns TClass (class of TObject) which I first assumed would work great. However I cannot seem to do a type conversion from TClass to t_mammal_class (class of t_mammal)! So I am stuck here. I tried just using TClass and skipping t_mammal_class, but then I can't use my overriden constructor that takes special parameters. Thanks in advance, David. On Fri 19 Mar 2010, David Emerson wrote: > Florian Klaempfl wrote: > > Constructor procvars are indeed not supported but the way to achieve > > what you want is to use class type variables > > > > t_mammal_class = class of t_mammal; > > > > function find_or_create_animal (color : byte; > > pass_mammal_type : t_mammal_class) : t_mammal; > > > > brown_pig := t_pig (pig_pen.find_or_create_animal (brown, t_pig)); > > ah, that is exactly what I need. Works perfectly. Thanks much. > > ~D. > > ___ > 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] constructor as procvar
> Tobject.classtype returns TClass (class of TObject) which I first > assumed would work great. However I cannot seem to do a type > conversion from TClass to t_mammal_class (class of t_mammal)! So I am > stuck here. well, I got this working, not sure why I had so much trouble with a simple type conversion. sorry for the noise. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] dynamic array contents and system.move
I have a class that has a field, f_data : array of byte; // a dynamic array Within a method of this class (which takes as a parameter "src", another instance of the class) I have the following code: move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte)); It appears that this move operation is going far beyond the length of self.f_data, and overwriting other data. Is there something obviously wrong here? thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
cobines wrote: > David Emerson wrote: > > move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte)); > > I think it should be: > > SetLength(self.f_data, length(src.f_data)); > move (src.f_data[0], self.f_data[0], length(self.f_data) * sizeof(byte)); Well, the setlength is not necessary, and very nearly prevented me from noticing the real solution here, f_data[0] -- thanks very much, it is working now. (I have this feeling like I have asked this question before. d'oh.) ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
I *am* checking sizes before the move, which is why it surprised me that things were going out of bounds -- the trouble is I forgot the array index [0] On Sat 24 Apr 2010, Martin wrote: > On 24/04/2010 22:01, Andrew Brunner wrote: > > David, > > > > I don't see how you are not getting memory leaks by doing a move > > before making sure that the destination buffer has the memory > > allocated. You see, in Delphi and FPC, move d/n actually move the > > memory... It just copies it. > > > > You were warned :-) > > > > On Sat, Apr 24, 2010 at 3:01 PM, David Emerson wrote: > > > >> cobines wrote: > >> > >>> David Emerson wrote: > >>> > >>>> move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte)); > >>>> > >>> I think it should be: > >>> > >>> SetLength(self.f_data, length(src.f_data)); > >>> move (src.f_data[0], self.f_data[0], length(self.f_data) * sizeof(byte)); > >>> > >> > No he doesn't get leaks. If at all he would get crashes, by overwriting > random memory. > > But in this case, it's (almost !) save. > He uses " length(self.f_data)* sizeof(byte)" => so he never copies, more > bytes to the target than the target can hold. > > He may however copy bytes from behind the source, reading random memory > behind the source. He does not modify this random memory, so far so good > => as long as the random meory behind the source is accesible to his > process. If it's not accessible, then access violation. > > Martin > ___ > 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] dynamic array contents and system.move
Florian Klaempfl wrote: > If you mess with move and have no clue about internals, then you get > burned. Period. Proper dyn. array code uses copy(...) instead of move. I wish there was a type-checked equivalent to what move does. copy creates a new array, and I don't want to do that: I already have a big block of memory reserved in the dynarray. I just want to move some data into that space -- sometimes only a part of it. Is there any alternative? It would be nice if move would give a compiler warning or note if it receives a pointer-pointer. I guess that would require move doing type-checking... but at compile-time, is there anything wrong with move doing such a type-check and issuing a warning? ~D. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] State of FPC docs.rant
On Mon 26 Apr 2010, Graeme Geldenhuys wrote: > Florian Klaempfl het geskryf: > > > > No git mirror ;)? I think the docs are one of the fpc related > > repositories where using a dvcs might be useful. > > Apparently I am banned for life mentioning the "product that may not be > named" in FPC or Lazarus mailing lists. :-) > > As for moving to such a DVCS... why bother? I think I can count on two > hands the amount of commits per year. As for it being a "pilot" of a DVCS - > that would be a pointless exercise with such a slow moving repository. I would love to contribute to the documentation -- I fancy myself good at writing, explaining, and making examples -- but as noted earlier in the thread, the barrier to entry is quite high. I'm far more comfortable using git than svn, and if there was such a repo it would help lower the barrier to entry for me at least. The lack of a simple tutorial on how to add to the documentation still remains a significant barrier, however. Graeme, I have to ask... on the one hand, you noted that having fragmented documentations over various locations is unhelpful; and on the other hand, I've heard you talk quite a bit about your DocView / INF project; I note in particular that you mentioned rewriting the FPC language reference in IPF. How is this not an example of the fragmentation you refer to? Don't get me wrong -- based on your explanations, I think DocView is a great idea, and I have been looking forward to trying it out, but I continue to wonder how well it will integrate with the present doc system and if it might lower the barrier to entry for contributing to the documentation. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann wrote: > Where are "the usage, internals and purpose of dyn. arrays" documented? I dunno. But I find them incredibly useful. they have some quirks, and over the years I've been using dynarrays, I've documented these on my own computer -- I even have a dynamic array test program that I periodically use to test for dynarray quirks. They're weird and unpredictable. However I'll take all the quirks, for the convenience of being able to call setlength (rather than getmem or whatever) -- and moreso, for the even larger convenience of automatic freeing of memory -- including automatically freeing embedded dynarrays and ansistrings! Those two points alone are, to me, worth all the quirks that I have to carefully test and document, and the occasional usage error (e.g. the mistake I made that caused me to start this thread). When I started using dynamic arrays instead of making calls to getmem/freemem, my main project (about 25k LOC now) became substantially simpler and easier to maintain. If you're curious about some of the quirks you can look at my test program, which includes some notes I made to myself after running other tests. http://david9.freepgs.com/fpc/dynamic-arrays.pas But if you don't like them for all their quirks and impurity, then don't use them. I'll be the first to admit that I frequently forget aspects of how they work, and have to refer back to my test program. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question about Deleting elements in Dynamic Array
Vincent Snijders wrote: > Bihar Anwar schreef: > > I've tried to use Move() instead of Copy(). Any objection with the following > > code? > > Yes, at first glance without much thinking, I don't think it is safe. Did you > think through the consequences of copying reference counted types (ansistring > in this case presumably)? > > > System.Move(a[3], a[0], 2 * SizeOf(string) ); > > SetLength(a, 2); > The above works great for me for non-reference counted types; I use it extensively (most common usage is adding an element into the middle of a sorted list. Incidentally, if doing this, it's also good to manage the length intelligently, so it does not need to reserve memory each time it adds one element. anyway..) For ref-counted types, a couple extra operations are needed in order to keep all the reference counts correct. Before the move: for all the data that is going to be destroyed, set it to nil (setting an ansistring/dynarray to nil does the same thing as setlength to 0 -- namely, it adjusts the reference count, and frees it if needed) for i := 0 to 2 do a[i] := nil; System.Move(a[3], a[0], 2 * SizeOf(ansistring) ); After the move: duplicated data will now have an inaccurate ref-count (e.g. ref count = 1 instead of the actual 2), so we have to use fillbyte to zero out the old refs. fillbyte (a[2], 3*sizeof(ansistring), 0); SetLength(a, 2); Note: you're playing with fire here, be really really careful. If you make the tiniest error, your data will become corrupt and your program will crash, and there will be no warnings or anything to help you fix the horrific mess you've created. And I haven't tested the code above... I've written the same stuff many times, but I always scrutinize it super-carefully and test the living crud out of it. Consider whether your potential performance increase will be worth hours of debugging -- I have spent those hours!! -- and potential crashes from unauthorized memory accesses. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
Jürgen Hestermann wrote: > Although I would have expected that special procedures exist to insert > and remove array elements so that there is no need to do such things > manually ... These must be written on a case-by-case basis, for each type of array element. Perhaps I'll tackle this someday as my first contribution to the fpc codebase. As for the rest, I have addressed these very issues in the last week... > ... which also requires knowledge of the exact handling of dynamic > arrays which is not fully documented so you are never sure. See my test program, http://david9.freepgs.com/fpc/dynamic-arrays.pas also: http://lists.freepascal.org/lists/fpc-pascal/2010-April/024840.html You can figure out how all this stuff works relatively easily -- if it is so important to you to be able to use system.move on dynamic array contents. > For example, in the above example, a[10] still exists and > points to the same data as a[9], correct? And how do I *insert* elements? > I would need to extend the allocated memory but how to do that without > distroying reference counters etc.? http://lists.freepascal.org/lists/fpc-pascal/2010-April/024845.html Of course you need to use setlength to extend allocated memory. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] IDE and programming woes
First, a descriptive subject header is much appreciated. As for your IDE troubles, I don't know how many people actually use that old FreeVision-based IDE... many of us use either Lazarus or some other more modern editor. Is there some reason you can't or don't want to try Lazarus? > Tirdly, once I was programming a program (the source code is below) good of you to include the source! > when I input about 100 data the program occured a error ,then it > terminated. I don't why ,and I can't understand the Error Code it gives > to me.Can you find my error and fix it for me? I can't imagine how we could help you without the errors. The data would definitely be useful too. Lacking that, we can't reproduce the error. The error might even be in your data, which would make it impossible for anyone to detect by just looking at your source. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] identifier scope problem
On Mon 3 May 2010, leledumbo wrote: > In the code above, equals will refer to tobject.equals instead of equals > defined in the unit. How can I refer to that one instead? I'm unable to reproduce your error. Real code that I could actually compile and run would make this a lot easier. That said, have you tried unitname.equals? Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] question about class
I'm no expert so these answers may be a bit off, but I figure any help is nice during US business hours... > Are there somewhere more or less pedagogic examples of class code? I've never found any. I've learned largely by studying (and occasionally fixing) fpgui code. > *self* > Do i need to explicitely name self as param? Depends on context? I use 'self' for the following: - if I am inside a 'with' context, and there is another data type with an identical field name, I'll reference self.field_name - even without a 'with' context I'll sometimes use it to make things easier to read - to call a procedure which takes a class as a parameter. A particularly common example would be a constructor that requires a parameter which will be its owner: e.g. within a method of a 'window' object I might call Tscrollbar.create (self); so that the window is the owner of the scrollbar... and the scrollbar can look at the window to get its size. > Is self actually a pointer? If yes, do I need to treat as such, or is this > magically handled by the language? Eg self^.prop or self.prop? I'm not sure, but self.method and self.field have always worked fine for me. Never tried to put a caret into the syntax. > *destructor* > Is a destructor required? What is it supposed to do? Deallocation? (but then > self disappears in the middle of a method it is the target of...). Do you mean, are you required to *write* a destructor? No, but you can. I use them to destroy child objects. Or, do you mean, do you need to *call* a destructor? Yes, you do. You should call "Free" rather than "Destroy". I don't recall why. > Isn't it garbage collected when dereferenced? No, classes are not automatically deallocated when dereferenced. They are pointers, and there may be several references to them (and they are not reference-counted) so there is no automatic deallocation. You need to call Free. > *type mutual recursion* > One func method returns an object of another type (actualy a record, but I > guess it does not make any difference). But this record object holds a pointer > to an object of the first type... Similar issue with a param of another > method. There was no issue in the non-class version of the same code, since > pseudo-methods (and their params and return values) did not need to be > pre-declared. I'm not sure I understand your question but maybe this is your answer: a_type = class; b_type = class; a_type = class b : b_type; end; b_type = class a : a_type; end; > By the way: why do we need to pre-declare methods, since they are bound to > their type anyway by their name prefixes? (I mean so-called "qualified names" > of the form type.methodName). You mean ... as opposed to a non-class procedure, which could simply be defined in the implementation section of a unit, without any mention in the interface? I don't know all the proper terminology, but my best guess is this: when the compiler creates the framework for the class, it needs to have everything available. Once it gets to the implementation section, it's too late to be adding more methods into that framework, or VMT, or whatever the thing is called. Hope this was helpful and not terribly incorrect! Cheers, David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
Spir wrote: > I need the simplest and most efficient version, because the type I'm now > designing will be the elementary building block of a rather big system. If you design your class hierarchy well, it ought to be possible to switch the base later on. Personally, I reinvented the wheel by creating my own list framework that suits my needs. If you're interested I'd be happy to share it, although really my first comment ought to trump much interest therein. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
> element := C(list[index]); // casting back
> text := element.text;
> I cannot do that, even if elements all are *indirect* instances of C, because
> this calls C.text instead of the element's own proper text method.
If you use virtual methods then C.text should call the descendant's method.
This
is what polymorphism, the most powerful concept in object oriented programming,
is all about.
> Side-question: it seems, when subclassing, that methods with same name and
> same parameters do not need any modifier keyword (such as "override"
> or "overload"). Eg I can have
> function text;
> in both a superclass C0 and a subclass C1 work as expected. Correct?
This is likely your problem. If you are not using virtual methods then you are
not going to get polymorphism.
Here's a sample program to illustrate:
{$mode objfpc}
type
C0 = class
procedure statictext;
procedure virtualtext; virtual;
end;
C1 = class (C0)
procedure statictext;
procedure virtualtext; override;
end;
procedure C0.virtualtext;
begin
writeln ('C0 virtual');
end;
procedure C0.statictext;
begin
writeln ('C0 static');
end;
procedure C1.virtualtext;
begin
writeln ('C1 virtual');
end;
procedure C1.statictext;
begin
writeln ('C1 static');
end;
var
a : C0;
b : C1;
p : pointer;
t : tobject;
begin
b := C1.create;
p := b;
a := C0(p);
a.statictext; // output: C0 static
a.virtualtext; // output: C1 virtual
// let's add another degree of removal
t := tobject(p);
C0(t).statictext;
C1(t).statictext;
C0(t).virtualtext;
C1(t).virtualtext;
end.
Cheers,
David
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On Sat 29 May 2010, spir ☣ wrote: > I cannot do that. C0 (and all classes) instances need a text method. I also > cannot have 2 methods (one static, one virtual) with different names. So make a virtual method called text. Don't use a static method at all. In my example I was trying to demonstrate the difference between static methods and virtual methods. I was not trying to suggest that you change your method names, or use both static and virtual methods. I can't be sure without seeing your code, but based on reading your messages three times, it appears to me that you are using static methods (i.e. without the virtual and override keywords) and expecting them to behave like virtual methods. Cheers & good luck, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {SOLVED} casting back a pointer to original type
> OK, I lurred myself by taking words too literally. I thought "virtual" meant > unimplemented, to be implemented in sub-classes. unimplemented = abstract virtual method type something = class procedure do_something; virtual; abstract; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PChar & AnsiString
> > >> This is not correct. Many strings are simply referenced several > > >> times. > > > > > > May I ask in which typical cases? In an earlier version of our database (before we had things properly typed) many things were stored as strings. Thus a common ansistring may have had a reference count in the hundreds or even thousands. Most of the time, if I changed one of them, I would not want to change them all! But it saved a lot of memory to not be redundantly storing the same string. > > The most common one is probably assigning a function result to a > > variable or field. > > Is there increment of ref count (I think it does +1-1)? If no, passing the ref > cannot have any side-effect, so the copy_on_write scheme does not apply -- or > rather does not make any change if applied. This is plain reference copy. > The issue is rather for parameter passing, since here the original var > survives the call (see Martin's post). I believe it depends on the circumstance. It's been a while since I tested this, but IIRC, when a variable is passed-by-value the ref count is incremented, whereas if it is passed-by-reference the ref count is not incremented... as one should hope. In the case of the latter, this means that if the ref count is one, then copy-on-write is not needed, as there is only the one instance of the string-- so that can save some processor time. Back when I was dealing with enormous ansistrings that were frequently being changed, I spent considerable time researching this so as to figure out how to avoid unnecessary copy-on-writes. What I found is that the compiler's treatment of them is quite intuitive: there were no unpleasant surprises. I ended up changing a number of functions which took a value parameter and returned a result to instead take a reference parameter and change that. Have fun... ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Crosscompile FPC from Win32 to Linux
Andreas Berger wrote: > I have a stable cgi program running in windows (no libraries - simple > writeln). However, our web host is in linux. Is there a simple way for > me to cross-compile the app? I haven't ever cross-compiled anything, but here's a start... Looking here: http://wiki.lazarus.freepascal.org/Cross_compiling http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux_2 ...it looks like it may be tricky to do win->linux. I am guessing it is possible... hopefully someone more knowledgeable will give you some tips on this list... and perhaps the wiki will get fleshed out some day. > or is it easier to learn how to use linux and do it there? honestly, this may be the easiest option. If you have ssh access to the web host and an fp compiler is (or can be) installed there, then you could just upload your sources to the host and compile them there. Check out putty or ttssh. Alternately you could just install linux on a machine somewhere, or if that's tricky, install virtualbox with a linux guest and use that. > I saw a page how to crosscompile lazarus, but it seamed very complex. Well, lazarus is very complex, so cross compiling it will be complex. Your program will probably be easier to cross compile if it does not use so many of fpc's and LCL's capabilities and libraries. > P.S. fp.exe lets you select a linux output, but it doesn't work. probably because some other stuff needs to be configured, some of which is noted in the cross compiling wiki instructions above. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linking name issue
Try deleting testunit.o and/or testunit.a, testunit.ppu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
> Wouldn't it be nice if we had a try..except..finally statement > supported in FPC. All-in-one. We do: it is called "try try" try try // ... except // ... finally // ... Okay, so maybe that's slightly nonstandard, but I'd rather use this awkwardness than add an even more awkward extra indentation level ~D. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] crash in tobject.free
Hi all, I'm encountering a consistent crash, and I'm not sure how to address the problem. using: - laz 0.9.28.2-8 beta, svn 22277, from debian testing -- a rather outdated one, because at this point upgrading lazarus requires updating debian - fpc 2.4.0-2 [2010/02/20] for i386 - fpgui commit e01c52a650bfdcce0bb1c8bbceefeb4e8dd46764 The lazarus popup error message says: Project Swindow raised exception class 'External: SIGSEGV'. The top of the lazarus call stack shows: #0 : ?? at :0 #1 :08058BC2 SYSTEM_TOBJECT_$__FREE at :0 #2 is my own call: if assigned (f_image) then f_image.free; I broke up the line, and it's crashing on the "then f_image.free" part, rather than on the "if assigned(f_image)" part. Any ideas? Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] crash in tobject.free
Thanks Matthias, FreeAndNil solved my problem! I was assuming that calling Free would also nil out the variable holding the reference to the object, but obviously it does not. Cheers, David On Thu 9 Dec 2010, Matthias Klumpp wrote: > Hi! > On Thu, 9 Dec 2010 11:42:20 -0800, David Emerson > wrote: > > I'm encountering a consistent crash, and I'm not sure how to address the > > > problem. > > > > using: > > - laz 0.9.28.2-8 beta, svn 22277, from debian testing -- a rather > outdated > > one, > > because at this point upgrading lazarus requires updating debian > > - fpc 2.4.0-2 [2010/02/20] for i386 > > - fpgui commit e01c52a650bfdcce0bb1c8bbceefeb4e8dd46764 > > > > The lazarus popup error message says: > > > > Project Swindow raised exception class 'External: SIGSEGV'. > > > > The top of the lazarus call stack shows: > > > > #0 : ?? at :0 > > #1 :08058BC2 SYSTEM_TOBJECT_$__FREE at :0 > > > > #2 is my own call: if assigned (f_image) then f_image.free; > > > > I broke up the line, and it's crashing on the "then f_image.free" part, > > rather > > than on the "if assigned(f_image)" part. > > > > Any ideas? > Have you initialized f_image? If not, do f_image := nil; and the error > will be gone. (Assigned need this to check if the object exists) > You could also use if assigned (f_image) then FreeAndNil(f_image); > Hope this works! > Matthias Klumpp > > > ___ > 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
[fpc-pascal] generics class hierarchy
Hi all, How can I use inheritance with generics? e.g. type generic gt_point<_num> = class ... end; generic gt_box<_tpoint,_num> = class (_tpoint) ... end; The above gives me an error; I've tried some other variations but haven't yet found anything that works Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
I'll give a little more detail... Right now I have these non-generic types: t_point = class f_left, f_top : longint; // so named for descendents // several fields and methods to manage it as I need end; t_box = class (t_point) f_width, f_height : longint; // more fields and methods to manage it as I need end; They've been great. Now I have need for a point and box that use real coordinates. The structure would be identical -- simply replacing "longint" with "single" -- which is why I thought generics would be perfect. However, t_box inherits from t_point, and this appears to be a sticking point. My code looks like this: generic gt_point<_num> = class f_left, f_top : _num; // other fields, methods end; generic gt_box<_t_point,_num> = class (_t_point) f_width, f_height : _num; // other fields, methods end; t_real_point = specialize gt_point; t_real_box = specialize gt_box; Thanks all! ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
Well, I'm guessing generics aren't really ready to be fully used... I'm getting an error "There is no method in an ancestor class to be overridden" where the ancestor class was a specialized generic. Doesn't seem very promising for actual use. So I'm abandoning generics for now. Hopefully they'll become more usable in the future! Keep up the good work, guys Cheers, David ...here's what I couldn't do: generic gt_point<_num> = class f_left, f_top : _num; procedure set_lt (l, t : _num); virtual; end; procedure gt_point.set_lt (l, t : _num); begin f_left := l; f_top := t; end; generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( f_width, f_height : _num; end; t_real_point = specialize gt_point; t_real_box = specialize gt_box; t_special_real_box = class (t_real_box) procedure set_lt (l, t : single); override; // FAILS :-( end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
err... my mistake. the error message was referring to a different problem, which I was blind to in my hurry. Sorry for all the messages. I'll shut up now. :) On Thu 16 Dec 2010, David Emerson wrote: > Well, I'm guessing generics aren't really ready to be fully used... I'm getting > an error "There is no method in an ancestor class to be overridden" where the > ancestor class was a specialized generic. Doesn't seem very promising for > actual use. > > So I'm abandoning generics for now. Hopefully they'll become more usable in the > future! > > Keep up the good work, guys > > Cheers, > David > > > ...here's what I couldn't do: > > generic gt_point<_num> = class > f_left, f_top : _num; > procedure set_lt (l, t : _num); virtual; > end; > > procedure gt_point.set_lt (l, t : _num); > begin > f_left := l; > f_top := t; > end; > > generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( > f_width, f_height : _num; > end; > > t_real_point = specialize gt_point; > > t_real_box = specialize gt_box; > > t_special_real_box = class (t_real_box) > procedure set_lt (l, t : single); override; // FAILS :-( > end; > > > ___ > 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] generics class hierarchy
> Would you please state your FPC version the next time? (If you have > stated I, but I haven't seen it: I'm sorry) Some problems might be fixed > in the development version while they aren't in the latest release. I tried with both 2.4.2 and 2.5.1 (fetched via svn and compiled. Took me quite some time to figure out how to get it to run properly without installing it as root) The main error was the same in both: genericstest.pas(22,50) Error: Identifier not found "_t_point" line 22, in "type" context: generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
Sven Barth wrote:
> I've now looked at your example code in more detail (I was working the
> last time I wrote you). Where did you define "_t_point"? I only found a
> "t_point" in your second mail.
_t_point is part of the template list.
I guess it's a limitation. Conceptually it doesn't seem that different to be
specifying a class to inherit from in the template list, but the compiler isn't
handling it yet.
> Would you please post (or at least attach) your complete test unit? In
> the meantime I'll try to test it with the code pieces you wrote.
unit genericstest;
{$mode objfpc}
interface
uses
classes,
sysutils;
type
generic gt_point <_num> = class
f_left, f_top : _num;
procedure set_lt (l, t : _num); virtual;
end;
type
generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-(
f_width, f_height : _num;
end;
t_real_point = specialize gt_point;
t_special_real_point = class (t_real_point)
procedure set_lt (l, t : single); override;
end;
implementation
procedure gt_point.set_lt (l, t : _num);
begin
f_left := l;
f_top := t;
end;
procedure t_special_real_point.set_lt (l, t : single);
begin
inherited;
end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generics class hierarchy
On Sat 18 Dec 2010, Honza wrote: > 2010/12/19 David Emerson : > > type > > generic gt_box<_t_point,_num> = class (_t_point) // FAILS :-( > > f_width, f_height : _num; > > end; > > I think it should fail according to the docs, see: > > http://www.freepascal.org/docs-html/ref/refse42.html > > "There is a single placeholder _T. It will be substituted by a type > identifier when the generic class is specialized. The identifier _T > *may not be used for anything else than a placehoder*. " Well, IMO the docs are a bit vague as to the definition of "placeholder". However, according to experience: - a placeholder _can_ be used for a type identifier that is used as a field within the class - a placeholder can't be used for a type identifier that is used to specify the ancestor class to inherit from Maybe "placeholder" is also referring to something that's going on internally to the compiler -- when the generic is defined, its class structure and VMT and everything must be known. I'm no compiler writer, but I guess it makes sense from that perspective. I was thinking of "placeholder" from the other perspective, in terms of words: the specialization substitutes these words into those places, and those places can by any type identifiers. More like what I'd expect from e.g. a scripting language. But it doesn't work like that. > The bold part is IMO violated by the declaration. Anyway, it could be > perhaps (not tested) written as: > > type > TBoxProxy = class(_t_point); > generic gt_box<_t_point, _num> = class(TBoxProxy) > f_width, f_height : _num; > end; no, this is completely not right at all. _t_point is a placeholder. I want to use a placeholder to specify the ancestor class. In your example here you're treating _t_point as an already-defined class which TBoxProxy can inherit from. _t_point doesn't exist, it never exists, it's just a placeholder for a proper type identifier. > Another strange point is, that the declaration of gt_box doesn't use > the formal specialization paramater `_t_point` at all (in the posted > code) yes it does. It is used to specify the ancestor class. But I think I have now beaten the issue to death. I am curious, though, if e.g. delphi allows this syntax? Cheers, David > , so the same the other way around should also work: > > type > generic gt_box<_num> = class<_t_point> > f_width, f_height : _num; > end; > > A 3rd note is that your code can't compile as _t_point is not declared > when gt_box is declared, but the declaration wants to inherit from > _t_point, so IMO also for this the code is rightfully rejected the > compiler. > > HTH > -- > bflm > freepascal-bits.blogspot.com > ___ > 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] generics class hierarchy
> @David: Maybe you can restructure your class hierarchy to something like > this (you'll need to be a bit creative here ^^): heh, no, my solution is to abandon generics :-) I used a find/replace script to make alternate classes with real values. Thanks for all your input, though. Thanks to you, too, Honza ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] commutative operators
suppose I define an operator: operator + (a: one_type; b: another_type) : one_type; Is there any way to specify that it should be "commutative", so I don't have to additionally define the reverse: operator + (a: another_type; b: one_type) : one_type; Thanks ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] commutative operators
On Wed 29 Dec 2010, Honza wrote: > 2010/12/29 David Emerson : > > suppose I define an operator: > > > > operator + (a: one_type; b: another_type) : one_type; > > > > Is there any way to specify that it should be "commutative", so I don't > > have to > > additionally define the reverse: > > > > operator + (a: another_type; b: one_type) : one_type; > IIRC you don't have to. well... I do have to. I get "can't determine which overloaded function to call" because I have a lot of similar-looking functions and := operators it's not such a big deal, really. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] commutative operators
On Wed 29 Dec 2010, Jetcheng Chu wrote: > I think you need to make sure that `a' and `b' are in the same algebraic > system before making the commutativity of the operator meaningful. You know, that makes a lot of sense. I should have thought about it that way before asking. Thanks. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] constant records as default parameters
I'd like to use a constant record as a default parameter. Is there some way to
do this? Here's my use case:
type
lt_ints = record
left, top : longint;
end;
const
lt_zero : lt_ints = (left:0; top:0);
procedure do_something (const offset_lt : lt_ints = lt_zero);
The procedure declaration gives an error ("illegal expression").
I assume the trouble is that lt_zero cannot be used as a default parameter
value, because it is not truly a constant: it is an initialized variable.
Perhaps my real question is: how do I make a constant record which is truly
constant, rather than an initialized variable?
Thoughts?
Thanks :-)
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] commutative operators
Mark Morgan Lloyd wrote:
> Can I have a reality check on this please: in this context is the
> overloaded := effectively an implicit cast as well as an explicit operator?
looks like. Below is some sample code which illustrates the fact.
> Is the availability of overloaded + and := operators necessary and
> sufficient for += to work correctly?
looks like. also illustrated below.
From the documentation, in reference to C-style += operators: "Remark: These
constructions are just for typing convenience, they don’t generate different
code."
In other words, a += b; is equivalent to a := a + b. So indeed, := and + are
the
requirements for +=
At least that's what I gather from the documentation, and the test program
below.
Using fpc 2.4.2
Warning: for mathematical purists, these operators are absurd. However, they
are
illustrative. Enjoy.
{$mode objfpc}
type
ta = record
a : longint;
end;
tb = record
b : longint;
end;
operator := (a : ta) : tb;
begin
result.b := a.a+1;
end;
operator := (b : tb) : ta;
begin
result.a := b.b+10;
end;
operator + (a, aa : ta) : ta;
begin
result.a := a.a + aa.a;
end;
operator + (a : ta; x : longint) : ta;
begin
result.a := a.a + x;
end;
const
spc = ' ### ';
var
a : ta;
b : tb;
procedure write_before_op (true_for_a : boolean);
begin
if true_for_a
then write ('a=', a.a, spc)
else write ('b=', b.b, spc);
end;
procedure write_after_op (s : string; true_for_a : boolean);
begin
write (s, spc);
if true_for_a
then writeln ('a=', a.a)
else writeln ('b=', b.b);
end;
begin
a.a := 2;
writeln ('a.a := 2');
write_before_op (true);
a += 1;
write_after_op ('a += 1', true); // 3
write_before_op (true);
a += a;
write_after_op ('a += a', true); // 6
write_before_op (true);
writeln ('tb(a).b=', tb(a).b); // 7
write_before_op (true);
b := a;
write_after_op ('b := a', false); // 7
write_before_op (false);
a := b;
write_after_op ('a := b', true); // 17
b.b := 1;
writeln ('b.b := 1');
write_before_op (false);
a := b + b; // each b must be typecast to ta, thus adding 10.
write_after_op ('a := b + b', true); // 22
write_before_op (false);
b := b + b; // as above, but typecasting the result to tb adds another 1
write_after_op ('b := b + b', false); // 23
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] constant records as default parameters
> AFAIK default parameters can only be simple types, not complex types
> like records.
Well... it certainly appears to be so...
> Although, I did get the following program using a default
> class parameter to compile and run.
Kinda defeats the purpose (low overhead). I'll stick with two simple params
with
defaults. (The other way would be to write more overloaded functions, but
that's cumbersome, and has overhead of its own)
You know, it's just occurring to me that I wouldn't be saving anything anyway:
any parameter with a default value must be passed-by-value, not by reference.
So I'm passing two longints either way. Whether they're adjacent doesn't really
make any difference at all.
> (And I thought you could not have var default parameters).
You can't. Here is a much shorter example:
{$mode objfpc}
procedure s (var a : longint = 0);
begin
inc (a);
end;
begin
s; // Error: Variable identifier expected
end.
Perhaps it's a compiler bug that it doesn't complain about the indication of a
var default parameter; however it definitely complains when you actually try to
put that default parameter to use. I guess the default parameter part in the
function header is simply being ignored.
Thanks for your input, though! I've got a more definitive answer now.
Although I still continue to wonder about constant records and record default
params, even if they can't pass-by-ref.
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString
Luis Fernando Del Aguila Mejía wrote: > The documentation > (http://www.freepascal.org/docs-html/prog/progsu146.html#x189-1990008.2.7) > says: > -8 Longint current string with size. > -4 Longint with reference count. > But, when I want access to that structure, I have to do it backwards. >-8 Longint with reference count. >-4 Longint current string with size. > Do these positions are different, depending on microprocessor being used ? I'm fairly certain that is an error in the documentation, and that it SHOULD always be as you discovered it to actually be. As an aside, a tip for doing pointer arithmetic... var s : ansistring; p : ptruint; p := pointer(s); dec(p); // equivalent to p:=p-4 because p is a typed pointer. Using typed pointers in this way will likely make it easier to adapt your code to a 64-bit conversion in the future. Also note that, in this case, dec(p,2) would do p:=p-8, as (hopefully) expected I use these types of constructs frequently, and it makes it much easier to change types, if that is ever necessary, or adapt constructs to new types. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] freetype unit + unicode
I am using the freetype unit (with linux) and would like to display some interesting unicode characters. However when I pass a string containing say U+2265 to GetStringGray, it doesn't display the unicode character at all; it shows 3 other characters in its place. What to do? btw I'm still using fpc 2.4.2 in case this is an issue that has been recently addressed Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Mon 3 Oct 2011, Graeme Geldenhuys wrote: > On 03/10/2011 21:51, David Emerson wrote: > > I am using the freetype unit (with linux) and would like to display some > > interesting unicode characters. However when I pass a string containing say > > U+2265 to GetStringGray, it doesn't display the unicode character at all; > > it > > shows 3 other characters in its place. What to do? > > What freetype API function are you calling? Not sure if it applies to > freetype, but with Xft (as implemented and used in fpGUI), there are > various versions of the same API. You need to call the correct one based > on the encoding type of you text. freetype.GetStringGray I've tried tweaking all kinds of things but the sad truth is that I am really pathetic at figuring out libraries when no documentation is given, and I sure can't find any documentation. I see that the fpgui helloworld program handles unicode nicely. I guess I'll try and imitate whatever's happening there. Thanks again, Graeme! ~D. > > procedure XftDrawStringUtf8(...); cdecl; external libXft; > procedure XftDrawString8(...); cdecl; external libXft; > procedure XftDrawString16(...); cdecl; external libXft; > > > Regards, > - Graeme - > > -- > fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal > http://fpgui.sourceforge.net/ > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
> > What freetype API function are you calling? Not sure if it applies to > > freetype, but with Xft (as implemented and used in fpGUI), there are > > various versions of the same API. You need to call the correct one based > > on the encoding type of you text. > > freetype.GetStringGray > > I've tried tweaking all kinds of things but the sad truth is that I am really > pathetic at figuring out libraries when no documentation is given, and I sure > can't find any documentation. > > I see that the fpgui helloworld program handles unicode nicely. I guess I'll > try and imitate whatever's happening there. Easier said than done... the reason I've been using freetype.GetStringGray (oops, excuse me -- freetype.TFontManager.GetStringGray) is that it returns TStringBitmaps, which I can use within my framework. It looks like the behavior of XftDrawStringUtf8 is to draw something on the screen, whereas I need to access the individual character glyphs and do the drawing later. hum. Is there some secret, hidden documentation for fpc's freetype unit? (and so many other units?) :P ~David. > > procedure XftDrawStringUtf8(...); cdecl; external libXft; > > procedure XftDrawString8(...); cdecl; external libXft; > > procedure XftDrawString16(...); cdecl; external libXft; > > > > > > Regards, > > - Graeme - > > > > -- > > fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal > > http://fpgui.sourceforge.net/ > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Tue 4 Oct 2011, michael.vancann...@wisa.be wrote: > > Is there some secret, hidden documentation for fpc's freetype unit? (and so > > many other units?) :P > > No. > > But you are in luck: this is open source, and the Lazarus IDE lets you jump > and look around in the FPC code very easily :-) > > If you need some UTF8 extensions to the freetype unit, feel free to make > some suggestions, and we'll see what we can do. > > When the unit was made, unicode support was a thing of the distant future. > (a future which of course crept up on us faster than we imagined) Ah, this is the answer I was looking for! Well this looks like a place where I might actually be able to contribute some code to the fpc project, which is something I've been wanting to be able to do for a long time. We'll see how that goes. Of course the first task is to get fpc and lazarus configured to use the svn version, something I've attempted and abandoned countless times. Hmmm. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Tue 4 Oct 2011, michael.vancann...@wisa.be wrote:
> If you need some UTF8 extensions to the freetype unit, feel free to make
> some suggestions, and we'll see what we can do.
>
> When the unit was made, unicode support was a thing of the distant future.
> (a future which of course crept up on us faster than we imagined)
attached is a patch, which (if applied correctly...) seems to work, yay! Here
is
a picture:
http://david9.freepgs.com/i/spline-unicode-text.png
I copied a few UTF8 string functions from the LCLProc unit, so that is kind of
sloppy but there it is. I'm not sure if analogs exist within fpc.
Surprisingly little needed to be changed!
diff --git a/packages/fcl-image/src/freetype.pp b/packages/fcl-image/src/freetype.pp
index 92ba876..4a17dae 100644
--- a/packages/fcl-image/src/freetype.pp
+++ b/packages/fcl-image/src/freetype.pp
@@ -36,6 +36,7 @@ uses sysutils, classes, freetypeh, FPImgCmn;
{$endif}
type
+ chartype = cardinal;
FreeTypeException = class (exception);
@@ -71,7 +72,7 @@ type
PMgrGlyph = ^TMgrGlyph;
TMgrGlyph = record
-Character : char;
+Character : chartype;
GlyphIndex : FT_UInt;
Glyph : PFT_Glyph;
end;
@@ -117,8 +118,8 @@ type
procedure GetSize (aSize, aResolution : integer);
function CreateSize (aSize, aResolution : integer) : PMgrSize;
procedure SetPixelSize (aSize, aResolution : integer);
- function GetGlyph (c : char) : PMgrGlyph;
- function CreateGlyph (c : char) : PMgrGlyph;
+ function GetGlyph (c : chartype) : PMgrGlyph;
+ function CreateGlyph (c : chartype) : PMgrGlyph;
procedure MakeTransformation (angle:real; out Transformation:FT_Matrix);
procedure InitMakeString (FontID, Size:integer);
function MakeString (FontId:integer; Text:string; size:integer; angle:real) : TStringBitmaps;
@@ -526,13 +527,13 @@ begin
end;
end;
-function TFontManager.CreateGlyph (c : char) : PMgrGlyph;
+function TFontManager.CreateGlyph (c : chartype) : PMgrGlyph;
var e : integer;
begin
new (result);
FillByte(Result^,SizeOf(Result),0);
result^.character := c;
- result^.GlyphIndex := FT_Get_Char_Index (CurFont.font, ord(c));
+ result^.GlyphIndex := FT_Get_Char_Index (CurFont.font, c);
//WriteFT_Face(CurFont.Font);
e := FT_Load_Glyph (CurFont.font, result^.GlyphIndex, FT_Load_Default);
if e <> 0 then
@@ -547,7 +548,7 @@ begin
CurSize^.Glyphs.Add (result);
end;
-function TFontManager.GetGlyph (c : char) : PMgrGlyph;
+function TFontManager.GetGlyph (c : chartype) : PMgrGlyph;
var r : integer;
begin
With CurSize^ do
@@ -569,11 +570,126 @@ begin
UseKerning := ((Curfont.font^.face_flags and FT_FACE_FLAG_KERNING) <> 0);
end;
+function UTF8CharacterLength(p: PChar): integer;
+begin
+ if p<>nil then begin
+if ord(p^)<%1100 then begin
+ // regular single byte character (#0 is a character, this is pascal ;)
+ Result:=1;
+end
+else if ((ord(p^) and %1110) = %1100) then begin
+ // could be 2 byte character
+ if (ord(p[1]) and %1100) = %1000 then
+Result:=2
+ else
+Result:=1;
+end
+else if ((ord(p^) and %) = %1110) then begin
+ // could be 3 byte character
+ if ((ord(p[1]) and %1100) = %1000)
+ and ((ord(p[2]) and %1100) = %1000) then
+Result:=3
+ else
+Result:=1;
+end
+else if ((ord(p^) and %1000) = %) then begin
+ // could be 4 byte character
+ if ((ord(p[1]) and %1100) = %1000)
+ and ((ord(p[2]) and %1100) = %1000)
+ and ((ord(p[3]) and %1100) = %1000) then
+Result:=4
+ else
+Result:=1;
+end
+else
+ Result:=1
+ end else
+Result:=0;
+end;
+
+function UTF8Length(p: PChar; ByteCount: PtrInt): PtrInt;
+var
+ CharLen: LongInt;
+begin
+ Result:=0;
+ while (ByteCount>0) do begin
+inc(Result);
+CharLen:=UTF8CharacterLength(p);
+inc(p,CharLen);
+dec(ByteCount,CharLen);
+ end;
+end;
+
+function UTF8Length(const s: string): PtrInt;
+begin
+ Result:=UTF8Length(PChar(s),length(s));
+end;
+
+function UTF8CharacterToUnicode(p: PChar; out CharLen: integer): Cardinal;
+begin
+ if p<>nil then begin
+if ord(p^)<%1100 then begin
+ // regular single byte character (#0 is a normal char, this is pascal ;)
+ Result:=ord(p^);
+ CharLen:=1;
+end
+else if ((ord(p^) and %1110) = %1100) then begin
+ // could be double byte character
+ if (ord(p[1]) and %1100) = %1000 then begin
+Result:=((ord(p^) and %0001) shl 6)
+or (ord(p[1]) and %0011);
+CharLen:=2;
+ end else begin
+Result:=ord(p^);
+CharLen:=1;
+ end;
+end
+else if ((ord(p^) and %) = %1110) then begin
+ // could be triple byte character
+ if ((ord(p[1]) and %1100) = %1000)
+ and ((ord(p[2]) and %1100
Re: [fpc-pascal] Reading and writing char
On Wed 5 Oct 2011, Thomas Young wrote:
> Hi,
>
> I'm trying to read and write ascii characters using FPC. I had no problems
> doing this years ago with Think Pascal & Code Warrior.
>
> For some reason I'm not able to read and write ascii characters above ascii
> 127 with FPC. Can someone explain this to me?
>
> Thanks in advance!
The world has changed, and globalization has reached your computer. Your
computer is almost definitely using a different character set today than it was
back in those days long ago. read this:
http://www.joelonsoftware.com/articles/Unicode.html
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know
About Unicode and Character Sets (No Excuses!)
~D.
>
> Using this code:
> for i:= 33 to 226 do
> writeln('Character: ', chr(i), ' Ascii value: ', i:1);
>
> Character: ! Ascii value: 33
> Character: " Ascii value: 34
> Character: # Ascii value: 35
> Character: $ Ascii value: 36
> Character: % Ascii value: 37
> Character: & Ascii value: 38
> Character: ' Ascii value: 39
> Character: ( Ascii value: 40
> Character: ) Ascii value: 41
> Character: * Ascii value: 42
> Character: + Ascii value: 43
> Character: , Ascii value: 44
> Character: - Ascii value: 45
> Character: . Ascii value: 46
> Character: / Ascii value: 47
> Character: 0 Ascii value: 48
> Character: 1 Ascii value: 49
> Character: 2 Ascii value: 50
> Character: 3 Ascii value: 51
> Character: 4 Ascii value: 52
> Character: 5 Ascii value: 53
> Character: 6 Ascii value: 54
> Character: 7 Ascii value: 55
> Character: 8 Ascii value: 56
> Character: 9 Ascii value: 57
> Character: : Ascii value: 58
> Character: ; Ascii value: 59
> Character: < Ascii value: 60
> Character: = Ascii value: 61
> Character: > Ascii value: 62
> Character: ? Ascii value: 63
> Character: @ Ascii value: 64
> Character: A Ascii value: 65
> Character: B Ascii value: 66
> Character: C Ascii value: 67
> Character: D Ascii value: 68
> Character: E Ascii value: 69
> Character: F Ascii value: 70
> Character: G Ascii value: 71
> Character: H Ascii value: 72
> Character: I Ascii value: 73
> Character: J Ascii value: 74
> Character: K Ascii value: 75
> Character: L Ascii value: 76
> Character: M Ascii value: 77
> Character: N Ascii value: 78
> Character: O Ascii value: 79
> Character: P Ascii value: 80
> Character: Q Ascii value: 81
> Character: R Ascii value: 82
> Character: S Ascii value: 83
> Character: T Ascii value: 84
> Character: U Ascii value: 85
> Character: V Ascii value: 86
> Character: W Ascii value: 87
> Character: X Ascii value: 88
> Character: Y Ascii value: 89
> Character: Z Ascii value: 90
> Character: [ Ascii value: 91
> Character: \ Ascii value: 92
> Character: ] Ascii value: 93
> Character: ^ Ascii value: 94
> Character: _ Ascii value: 95
> Character: ` Ascii value: 96
> Character: a Ascii value: 97
> Character: b Ascii value: 98
> Character: c Ascii value: 99
> Character: d Ascii value: 100
> Character: e Ascii value: 101
> Character: f Ascii value: 102
> Character: g Ascii value: 103
> Character: h Ascii value: 104
> Character: i Ascii value: 105
> Character: j Ascii value: 106
> Character: k Ascii value: 107
> Character: l Ascii value: 108
> Character: m Ascii value: 109
> Character: n Ascii value: 110
> Character: o Ascii value: 111
> Character: p Ascii value: 112
> Character: q Ascii value: 113
> Character: r Ascii value: 114
> Character: s Ascii value: 115
> Character: t Ascii value: 116
> Character: u Ascii value: 117
> Character: v Ascii value: 118
> Character: w Ascii value: 119
> Character: x Ascii value: 120
> Character: y Ascii value: 121
> Character: z Ascii value: 122
> Character: { Ascii value: 123
> Character: | Ascii value: 124
> Character: } Ascii value: 125
> Character: ~ Ascii value: 126
> Character:Ascii value: 127
> Character: ? Ascii value: 128
> Character: ? Ascii value: 129
> Character: ? Ascii value: 130
> Character: ? Ascii value: 131
> Character: ? Ascii value: 132
> Character: ? Ascii value: 133
> Character: ? Ascii value: 134
> Character: ? Ascii value: 135
> Character: ? Ascii value: 136
> Character: ? Ascii value: 137
>
> truncated for brevity.
>
>
> Thomas Young
> mobile email: tygraph...@me.com
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freetype unit + unicode
On Thu 6 Oct 2011, michael.vancann...@wisa.be wrote: > On Wed, 5 Oct 2011, David Emerson wrote: > > On Tue 4 Oct 2011, michael.vancann...@wisa.be wrote: > >> If you need some UTF8 extensions to the freetype unit, feel free to make > >> some suggestions, and we'll see what we can do. > > > > I copied a few UTF8 string functions from the LCLProc unit, so that is kind > > of sloppy but there it is. I'm not sure if analogs exist within fpc. > > Yes, but the problem with this is that it only works with UTF-8 now. indeed my inexperience shows (and american mindset!) > So I would have preferred it if you had created an overloaded or even > differently named version of the existing functions, and left the existing > functions intact. The way it is now, we'd force everyone to use UTF-8. > > I'll see if I can modify the patch. > > Michael. I'd be happy to help in this regard if you want to give me some sort of instructions to go by. Now that you bring up the issue, numerous solutions come to mind. Of course the task is not that big, but I'm eager to help if it would save you any trouble (although tonight it's past my bedtime now...) ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] alias a function + overload 'in'
two little questions 1. Is it possible to make an alias to a function ... so rather than just re-calling with the same parameters, it's actually the same thing? like the way we can do, e.g., type natural = cardinal, or const GG = 6, but with a function? 2. is it possible to overload the 'in' operator, so that it may work (using supplied code) on things that are not a pascal set? Thanks! ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] debian control files for fpc
I'd like to roll my own fpc-2.4.4 .deb for in-house development The lazarus sources seem to include a debian directory with all the control files, which is wonderful! Where can I find debian control files for fpc? Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] debian control files for fpc
> > Where can I find debian control files for fpc? > > In the fpcbuild svn repository: > http://svn.freepascal.org/svn/fpcbuild/trunk/install/debian/ > > Vincent Thanks much!! I wish it worked :( I copied all the debian control files from the 2.4.4 release: http://svn.freepascal.org/svn/fpcbuild/tags/release_2_4_4/install/debian/ and, putting that debian directory into my own source directory... (which I got from sourceforge, http://sourceforge.net/projects/freepascal/files/Source/2.4.4/fpc-2.4.4.source.tar.gz) debuild -us -uc keeps complaining about a directory called "fpcsrc". I tried all kinds of crazy things to remedy this but it's a no-go, I cannot get it to work at all. Ignoring the debian stuff, I can run "make clean all" and it works great!! but this debian/rules thing is super-lame in its non-working behavior. Any ideas? This must have worked for somebody, because the packages exist... Thanks, David following are extensive notes of all the crazy things I tried! Thank goodness for long terminal histories! I hope you are not so bored as to want to read them, but they're here. First I got this error: Applying patch version.diff can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |This patch adds Debian build version to compiler full version. | |--- fpc-2.2.4~/fpcsrc/compiler/version.pas |+++ fpc-2.2.4/fpcsrc/compiler/version.pas -- No file to patch. Skipping patch. 2 out of 2 hunks ignored Patch version.diff does not apply (enforce with -f) make: *** [debian/stamp-patched] Error 1 So I just deleted the whole patches directory. It is strange the the version is wrong, too (2.2.4 instead of 2.4.4) Then I got this error: # Remove auto-generated version file. rm -rf fpcsrc/compiler/version.inc # Add version.inc: echo \'2.4.4-0\' > fpcsrc/compiler/version.inc /bin/sh: fpcsrc/compiler/version.inc: No such file or directory Well, the file version.inc doesn't exist anyway, so I took all instances of it out of debian/rules Then I got this error: --- Cleaning dh_testdir dh_testroot /usr/bin/make -C fpcsrc compiler_distclean make: *** fpcsrc: No such file or directory. Stop. So I changed the name to fpc, but that didn't fix it at all: /usr/bin/make -C fpc compiler_distclean make: *** fpc: No such file or directory. Stop. So I tried taking out the -C parameters altogether, but that also didn't work: /usr/bin/make compiler_distclean make[1]: Entering directory `/Docs/fpc/Debian/fpc' make[1]: *** No rule to make target `compiler_distclean'. Stop. I gave up on getting debian/rules to work and thought, maybe there is something wrong with my fpc sources, like, some naming could be off? So I tried downloading the svn version from http://svn.freepascal.org/svn/fpc/tags/release_2_4_4 This also did not come with the debian controls included. And a comparison showed that the svn 2.4.4 release sources are identical to the ones I already had. Part of me was kind of expecting that to be the case, but of course part of me was also hoping that *something* would work. But since they're identical, obviously it won't. find -name '*fpcsrc*' comes up empty. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alias a function + overload 'in'
Thank you, Tomas, those are all excellent suggestions! I am glad I asked. On Sun 18 Dec 2011, Tomas Hajny wrote: > On 17 Dec 11, at 21:07, David Emerson wrote: > > > two little questions > > > > 1. Is it possible to make an alias to a function ... so rather than just > > re-calling with the same parameters, it's actually the same thing? like the way > > we can do, e.g., type natural = cardinal, or const GG = 6, but with a function? > . > . > > There are multiple solutions possible: > > 1) Making the functions public and creating the aliases as external: > > procedure X; public name 'X'; > begin > WriteLn (1); > end; > > procedure Y; external name 'X'; > > begin > X; > Y; > end. > > > 2) Using procedural variables / constants: > > type > TProc = procedure; > > procedure X; > begin > WriteLn (1); > end; > > const > Y: TProc = @X; > > begin > X; > Y; > end. > > > 3) Using inlining: > > procedure X; > begin > WriteLn (1); > end; > > procedure Y; inline; > begin > X; > end; > > begin > X; > Y; > end. > > Tomas > > ___ > 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] alias a function + overload 'in'
On Sun 18 Dec 2011, Jürgen Hestermann wrote: > David Emerson schrieb: > > 2. is it possible to overload the 'in' operator, so that it may work > > (using supplied code) on things that are not a pascal set? > > I do not know whether it is possible but I hate such overloading. An > operator defined by the Pascal language should not become a chimera. It > destroys the logic of the language. If every identifier and every > operator can get an arbitrary meaning then what is the grounding of the > language? Hiding details with such mechanism does not help understanding > the code, just the opposite. > > Why not simply use a function for such things? I should know better than to debate this with you, Jürgen, but it's too tempting! It's because, to me, Pascal is an extension of mathematics and logic; and in the languages of math and logic, such constructs make perfect sense. The fact that I cannot use 'in' on certain types of things in Pascal makes it less elegant than mathematical language. But anyway... my guess is that it's not happening anytime soon ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] News from MSEide+MSEgui
Congratulations, Martin! Keep up the good work. (is that your own custom-built git gui?) On Mon 12 Dec 2011, Martin Schreiber wrote: > Hi, > > MSEide+MSEgui 2.8rc1 for FPC 2.6 has been released: > > http://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/2.8rc1/ > > There is also a new beta for MSEgit: > > http://gitorious.org/mseuniverse/mseuniverse/trees/msegit_release_0_8_2/tools/msegit > > A screenshot is here: > > http://mseide-msegui.sourceforge.net/pics/msegit.png > > Havwe a lot of fun! > > Martin > ___ > 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] debian control files for fpc
I solved this problem by downloading the sources from debian, which apparently have a different directory structure layout. ~D. On Sun 18 Dec 2011, David Emerson wrote: > > > Where can I find debian control files for fpc? > > > > In the fpcbuild svn repository: > > http://svn.freepascal.org/svn/fpcbuild/trunk/install/debian/ > > > > Vincent > > Thanks much!! > > I wish it worked :( > > I copied all the debian control files from the 2.4.4 release: > http://svn.freepascal.org/svn/fpcbuild/tags/release_2_4_4/install/debian/ > > and, putting that debian directory into my own source directory... > (which I got from sourceforge, > http://sourceforge.net/projects/freepascal/files/Source/2.4.4/fpc-2.4.4.source.tar.gz) > > debuild -us -uc keeps complaining about a directory called "fpcsrc". I tried all > kinds of crazy things to remedy this but it's a no-go, I cannot get it to > work > at all. > > Ignoring the debian stuff, I can run "make clean all" and it works great!! > but > this debian/rules thing is super-lame in its non-working behavior. > > Any ideas? This must have worked for somebody, because the packages exist... > > Thanks, > David > > > following are extensive notes of all the crazy things I tried! Thank goodness > for long terminal histories! I hope you are not so bored as to want to read > them, but they're here. > > > First I got this error: > > Applying patch version.diff > can't find file to patch at input line 5 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |This patch adds Debian build version to compiler full version. > | > |--- fpc-2.2.4~/fpcsrc/compiler/version.pas > |+++ fpc-2.2.4/fpcsrc/compiler/version.pas > -- > No file to patch. Skipping patch. > 2 out of 2 hunks ignored > Patch version.diff does not apply (enforce with -f) > make: *** [debian/stamp-patched] Error 1 > > > So I just deleted the whole patches directory. It is strange the the version is > wrong, too (2.2.4 instead of 2.4.4) > > > Then I got this error: > > > # Remove auto-generated version file. > rm -rf fpcsrc/compiler/version.inc > # Add version.inc: > echo \'2.4.4-0\' > fpcsrc/compiler/version.inc > /bin/sh: fpcsrc/compiler/version.inc: No such file or directory > > > Well, the file version.inc doesn't exist anyway, so I took all instances of > it > out of debian/rules > > > Then I got this error: > > > --- Cleaning > dh_testdir > dh_testroot > /usr/bin/make -C fpcsrc compiler_distclean > make: *** fpcsrc: No such file or directory. Stop. > > > So I changed the name to fpc, but that didn't fix it at all: > > > /usr/bin/make -C fpc compiler_distclean > make: *** fpc: No such file or directory. Stop. > > > So I tried taking out the -C parameters altogether, but that also didn't work: > > > /usr/bin/make compiler_distclean > make[1]: Entering directory `/Docs/fpc/Debian/fpc' > make[1]: *** No rule to make target `compiler_distclean'. Stop. > > > I gave up on getting debian/rules to work and thought, maybe there is something > wrong with my fpc sources, like, some naming could be off? > > > So I tried downloading the svn version from > http://svn.freepascal.org/svn/fpc/tags/release_2_4_4 > > This also did not come with the debian controls included. > And a comparison showed that the svn 2.4.4 release sources are identical to the > ones I already had. Part of me was kind of expecting that to be the case, but > of course part of me was also hoping that *something* would work. But since > they're identical, obviously it won't. find -name '*fpcsrc*' comes up empty. > > ___ > 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
[fpc-pascal]trouble with {$IF ...}
I would like to do some very basic boolean operations within compiler directives. $IF
does not seem to work reliably. See below:
C:\fpc\test>fpc directive_test -Sm
Free Pascal Compiler version 1.0.10 [2003/06/27] for i386
[...]
User defined: =
User defined: $define x:=17
User defined: !!! (x=5) = TRUE even though i set x:=17
User defined: . (x>50) = false (good, x=17)
User defined: !!! (x<50) = FALSE even though i set x:=17
User defined: !!! ($if 1 AND 0) = TRUE
User defined: =
User defined: $define zero:=0
User defined: !!! ($if zero) = TRUE
User defined: !!! ($if 0) = TRUE
User defined: and now the exact same test again...
User defined: . ($if 0) = false
User defined: =
User defined: $define apples
User defined: !!! ($ifdef oranges or apples) = FALSE :-(
User defined: =
Linking directive_test.exe
68 Lines compiled, 1.2 sec
I know boolean operators are not supported for $ifdef, but it would sure be nice.
The most baffling part is where {$IF 0} = true and then the same {$IF 0} = false. It
seems to be related to the test done just prior to it -- If I follow the 'zero' test
with the {$IF 0} test, the latter doesn't work.
Here is the source:
begin
{$info =}
{$define x:=17}
{$info $define x:=17}
{$if x=5}
{$info !!! (x=5) = TRUE even though i set x:=17}
{$else}
{$info . (x=5) = false (good, x=17)}
{$endif}
{$if x>50}
{$info !!! (x>50) = TRUE even though i set x:=17}
{$else}
{$info . (x>50) = false (good, x=17)}
{$endif}
{$if x<50}
{$info . (x<50) = true (good, x=17)}
{$else}
{$info !!! (x<50) = FALSE even though i set x:=17}
{$endif}
{$if 1 AND 0}
{$info !!! ($if 1 AND 0) = TRUE}
{$else}
{$info . ($if 1 AND 0) = false}
{$endif}
{$info =}
{$define zero:=0}
{$info $define zero:=0}
{$if zero}
{$info !!! ($if zero) = TRUE}
{$else}
{$info . zero returned false}
{$endif}
{$if 0}
{$info !!! ($if 0) = TRUE}
{$else}
{$info . ($if 0) = false}
{$endif}
{$info and now the exact same test again...}
{$if 0}
{$info !!! ($if 0) = TRUE}
{$else}
{$info . ($if 0) = false}
{$endif}
{$info =}
{$define apples}
{$info $define apples}
{$ifdef oranges or apples}
{$info . ($ifdef oranges or apples) = true}
{$else}
{$info !!! ($ifdef oranges or apples) = FALSE :-( }
{$endif}
{$info =}
end.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]blockread in a procedure
Hi there,
I'm having trouble using blockread. It was working for... oh, a year... and all of a
sudden it's not working. I'm getting a runtime error 87 in win32/i386 (fpc 1.0.10) and
an error 217 in linux/i386 (fpc 1.0.6). Since I always compile with -gl it tells me
it's failing right at blockread. Here's the code...
const
test_file_name = 'test.txt';
the_source : ansistring = '';
procedure read_source_file;
const
bufsize = 2048;
var
source_file : file;
buf : array [1..bufsize] of char;
count_read : longint; // longint required by blockread
begin
write ('Reading source file.');
assign (source_file, test_file_name);
reset (source_file);
the_source := '';
repeat
blockread (source_file, buf, bufsize, count_read);
the_source := the_source + copy (buf, 1, count_read);
until count_read = 0;
close (source_file);
the_source := the_source + chr(255);
writeln ('Source file successfully read');
end;
begin
read_source_file;
end.
If I get rid of the procedure read_source_file and put its code directly into the main
"begin end." then it works. So for some reason, suddenly it can't stand having
blockread inside a procedure. I haven't touched the procedure or any of the
constants/variables associated with it in a long time, so it's bizarre that it
suddenly decided to fail.
Incidentally, fpc 1.0.10 rpm failed to install on redhat. I struggled with it for a
good hour. Any tips? Does the gz work better than the rpm?
Cheers,
David
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]blockread + rpm install
Thanks for your help with blockread. Giving the blocksize with reset (myfile, 1) fixed it! >> Incidentally, fpc 1.0.10 rpm failed to install on redhat. I struggled with it for a >> good hour. Any tips? Does the gz work better than the rpm? > >What error do you get ? What version of rpm do you use ? Installation worked fine with the tar + script, so I'm set for now. Re: rpm error... The installer prompted me for a root password, and then brought up a little box that said "calculating package dependencies". Then the box disappeared, without any error message or indication of status. Inspection revealed that it had not installed anything. Now that I think about it, I realize I couldn't have spent nearly an hour on it. I don't really know what version of rpm I use... if you're really curious, and can tell me where to look for the version info, I'll get it for you. I'm really an amateur with linux. The best answer I can give you right now is: "whatever comes with the RedHat 8.0 that the computer manufacturer pre-installed for me" :-) Thanks! -David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]ansistrings
Hey all, I've been poking around the sources and documentation for some insight into the details of how ansistrings are implemented, and I am left with some questions. It would be nice if, when comparing two ansistrings, fpc would first check to see if these two pointers are pointing to the same spot in memory, i.e. the same TAnsiRec. If they happen to be pointing to the same, a potentially long operation is reduced to a simple comparison of two memory addresses which probably only takes one processor cycle. Looking at fpc_ansistr_compare in astrings.inc, and at cgadd.addstring (the only function that seems to call fpc_ansistr_compare), it appears not to do this. Perhaps I'm wrong? I don't _really_ understand what the code is doing. I believe the sources I'm looking at are 1.0.10. If this quick comparison is in fact not implemented, I'd like to do it myself. (There are a number of places where I am checking long ansistrings for equality, and there is a reasonable chance that both pointers are pointing to the same address.) ( @s1[1] = @s2[1] ) seems to give the right result. is this the best way? or is it quicker/slower to use ( pointer(s1) = pointer(s2) ) (no doubt more elegant) Now on to the second question... getting those ansistrings pointed to the same address! (Some of them already are, but I'd like to get more...) I was kind of surprised to find that s1 := 'hello'; s2 := 'hello'; writeln ( pointer(s1) = pointer(s2) ); ...writes FALSE Thus I assume that readln (s1); readln (s2);... would NEVER point them at the same address Of course, checking every string against every other string would comprise an absurd performance hit in most cases. What I'd really like is to have a relatively small number of constant strings that could be compared against, and only when reading in a data file, or perhaps certain fields in a data file. (yeah, reading will take longer)... Then if my data file (and thus my filled pascal array) has 1,000 instances of "some_complex_but_often_identically_repeated_data_value", I get the following: - lots of memory savings - operator "=" gives a very fast TRUE result when they are pointing to the same In fact, all the string comparison operators return a particular value if the two are equal, so they could all give a fast result in this case. This could happen both when comparing datum values against each other, and when comparing them to a constant string in my code. Do resource strings offer this kind of intelligence, or are they designed for a completely different purpose, and offer no performance improvement for this special application? Is there some special mode or compiler directive that does more string uniqueness checking, including at compile time (e.g. to find my two identical 'hello' assignments)? Or shall I bite the bullet and decide whether I need to implement some of this stuff myself? (( Typcasting my data into something that's not literal strings would of course be the best thing to do. However, I'm not quite ready for it yet, and would like to do what I can to help performance until I get to the point where I can put my data in pascal records. )) Cheers! -David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]rpm install
For the record: RPM version 4.1 >Re: rpm error... The installer prompted me for a root password, and then brought up a >little box that said "calculating package dependencies". Then the box disappeared, >without any error message or indication of status. Inspection revealed that it had >not installed anything. Now that I think about it, I realize I couldn't have spent >nearly an hour on it. -David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]feature request: enhanced "pos"
Dunno if this is the right place to post such a message, but here goes...
I would love to see a "pos" function that takes an additional parameter, being the
position in the string where it should START scanning. e.g.:
my_str = 'Hello, everybody... Hello, world!';
//123456789012345678901
x := pos ('Hello', my_str, 6);
So it starts scanning at position 6 (after the first Hello) and finds the second Hello
at position 21; returns 21. (not 21-6)
Passing it a starting position 2 (instead of 6) would also skip the first Hello, and
return the same 21.
(( Of course, passing it a starting position greater than the length(str) -
length(target) should return 0; also it should return 0 if the target is not found
between startpos and the end of the string. ))
This would save so much processing time spent doing delete and copy!
Cheers,
David
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]little questions and notes: 1.9.2, bugs db, cfg, win32 make cycle
Hi there, Whenever I compile anything with fpc, the first thing that the compiler puts on the screen is: Hint: End of reading config file c:\fpc\192\bin\win32\fpc.cfg This happens with 1.9.2 and 1.0.10. What is the purpose of this message? The bugs database interface doesn't seem to have an option to search for 1.9.2 / 1.9.3 bugs. Using 1.0.10 and win32, I did a make cycle on 1.9.3 (why? curiousity was a leading factor) Re: Build Faq: I guess the Makefile didn't recognize "make cycle", so I had to use "make compiler_cycle" It crashed out early on when it tried to do as.exe. The reason was that the 1.0.10 makew32.zip contained the name asw.exe - i.e. before the rename to as.exe happened. Copying asw.exe to as.exe fixed that. (I also copied arw and ldw while I was at it) It failed on the comparison of ppc3 and ppc386 (char 1316627, line 4963) ... I'll get back with more info if I can't get it working myself. ~David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]RTF
>But if you just need to create a single kind of document,
>perhaps with some data changed, then you can often solve the
>problem much more simply by: (1) create an RTF document in
>your favorite software; (2) Insert tags like ##ADDRESS1## where
>you want to substitute text; (3) read in the template and
>replace the tags with the text of your choice.
I recently wrote a program that does this. My primary problem
arose from microsoft word being stupid (big surprise, huh?)
Suppose I inserted a tag such as the above example, ##ADDRESS1##
(I think I used greater-than/less-than brackets rather than
pound symbols -- but those don't email well!) MS Word would
sometimes insert rtf tags right in the middle of the word, for
no obvious reason. So I would get something like:
##ADDR{\bizarre rtf tag, sometimes
containing carriage returns in the middle} ESS1##
My solution was to save as Word version 2, close and reopen,
then save as rtf. It might not be a bad idea to go with the XML
or LaTeX. But if you'd like a copy of the program I wrote, let
me know and I'll post it or email it to you.
~David
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Why is FP Win32 Version running and compiling much slower?
Try holding down the SHIFT key while your program is executing. (?!) I discovered this while doing intense text output to the console (where the speed increase is easy to observe directly). Win98 console text output consistently goes twice as fast or faster while holding the shift key, particularly if the program has been executing for a while (5-10 seconds). I haven't tried this during compilation (or during execution of programs which don't do intense text output) but it's worth a shot. My hypothesis is that win98 gives the console low priority for system resources. If you hold down the shift key while executing, windoze concludes that you're interacting with the console, and thus will give the console more processor cycles (instead of using them on background processes). ~David (I have this image in my mind of a rock resting on top of a shift key to hold it down) ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Known issue with 1.9.4 [2004/05/30] for i386 on Linux?
I believe that your code is being interpreted as: (NOT fmt[i]) in ['0'..'9'] instead of the intended NOT (fmt[i] in ['0'..'9']) Pascal's rules for parsing logical expressions differ from the standard rules of the propositional calculus (i.e. modern symbolic logic). Thus, this behavior is "by design" -- you'll have to use those extra parens -- and don't bother filing a bug. Incidentally, I happen to agree with your assesment that this is a bug, in the philosophical sense -- but it was designed that way by Nicklaus Wirth, so we're stuck with it. It's one of a few flaws in what's really a very beautiful programming language. ~David. At 10:46 PM 9/28/04, you wrote: >I don't know if this is really a bug or whether it's known... I have >this line of code: > > while ( (i<=Length(fmt)) and (NOT fmt[i] IN ['0'..'9']) ) do >inc(i); > >It compiles fine but I get a RTE: > >An unhandled exception occurred at 0x0807B180 : >EVariantError : Invalid variant operation > $0807B180 > $B980 > >Funny thing is, I enabled line numbers with '-gl'... And the error >message makes no sense to me.. After staring at that line of code for >a while, I put parens around the "fmt[i] IN ['0'..'9']" and all was >well: > > while ( (i<=Length(fmt)) and (NOT (fmt[i] IN ['0'..'9'])) ) do >inc(i); > >So, that seems to be a bug to me... Shall I report it or is it known >(or am I wrong that it's a bug)? > >-Alan ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ansistrings, exceptions, pascal call stack and access violations
Hi all,
We've got a sophisticated system which relies heavily on the power of ansistrings. I'm
now introducing exception handling into the system, and am running into problems with
the pascal call stack.
Without exception handling, I get a nice pascal stack, such as the following (produced
by a test program, source below):
Runtime error 200 at $004010A8
$004010A8 TEST_DIVISION_BY_ZERO, line 13 of e:/c/test/t.pas
$00401179 PLAY_WITH_STRINGS, line 23 of e:/c/test/t.pas
$004011B1 main, line 28 of e:/c/test/t.pas
However, if I include the sysutils unit, and catch (and reraise) all exceptions, I get
the following -- which not only lacks the complete call stack, but includes lots of
junk:
An unhandled exception occurred at 0x004010A8 :
EDivByZero : Division by zero
$004010A8 TEST_DIVISION_BY_ZERO, line 13 of e:/c/test/t.pas
$666F2033
An unhandled exception occurred at 0x004088FB :
EAccessViolation : Access violation
$004088FB
$00406278
$005CFDA0
$666F2033
An unhandled exception occurred at 0x004088FB :
EAccessViolation : Access violation
$004088FB
$00406278
$005CFB30
$00406278
$005CFDA0
$666F2033
An unhandled exception occurred at 0x004088FB :
EAccessViolation : Access violation
$004088FB
$00406278
$005CF8C0
$00406278
$005CFB30
$00406278
$005CFDA0
$666F2033
An unhandled exception occurred at 0x004088FB :
EAccessViolation : Access violation
$004088FB
$00406278
$005CF650
$00406278
$005CF8C0
$00406278
$005CFB30
$00406278
$005CFDA0
$666F2033
I noticed in my test program that if I change the ansistring_param to a normal string
I get the call stack back:
An unhandled exception occurred at 0x00401078 :
EDivByZero : Division by zero
$00401078 TEST_DIVISION_BY_ZERO, line 13 of e:/c/test/t.pas
$004010F3 PLAY_WITH_STRINGS, line 23 of e:/c/test/t.pas
$0040116B main, line 30 of e:/c/test/t.pas
(compared to the first: notice exception handling is now working, and the third line
has changed from "main, line 28" to line 30 -- where raise is called, rather than
where play_with_strings is called)
Here's the test source:
{$mode objfpc} // (line 1)
uses sysutils;
procedure do_nothing_with_an_ansistring (ansistring_param : string);
begin end;
procedure test_division_by_zero;
var
zero : integer;
begin
zero := 0;
write (5 div zero);
end;
procedure play_with_strings;
var
short_string : string;
begin
short_string := 'HELLO';
if (lowercase(short_string)='hello')
then do_nothing_with_an_ansistring (short_string);
test_division_by_zero;
end;
begin
try
play_with_strings; // (line 28)
except
on exception do raise; // (line 30)
end; // try
end.
The only change I've made to fpc.cfg is uncommenting the -gl switch.
Perhaps there's another switch that I need to set in order to make ansistrings and
exceptions work harmoniously?
Thanks,
David
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ansistrings, exceptions, pascal call stack and access violations
Peter wrote: >The problem is that the call to the empty ansistring routine will create a >temp ansistring for the parameter. And ansistring variables or temps need >to be finalized. This call to finalize() destroyes the backtrace since it >writes at the same location in the stack that was also used by >test_division_by_zero. We can't solve easily. I was afraid it might be something like this! Interestingly, even if I move the test_division_by_zero function to be BEFORE the call to the do_nothing_with_an_ansistring function, I still get the same behavior -- so it seems to be creating that temp ansistring param even before it gets to the call to the function that needs it. (( Perhaps this has something to do with threading or jumping or whatever you call it when the program starts a new task before it's finished with the old one in order to use resources efficiently. )) Marco wrote: >I get: (1.9.5 as of today) > >-bash-2.05b$ ./exectest >An unhandled exception occurred at 0x0806CBFC : >EDivByZero : Division by zero > $0806CBFC TEST_DIVISION_BY_ZERO, line 14 of exectest.pp > $0806CC81 PLAY_WITH_STRINGS, line 24 of exectest.pp > $0806CCFF main, line 31 of exectest.pp > >-bash-2.05b$ this is rather encouraging... however, I'm using 1.9.4, and am a little hesitant to step out on the bleeding edge of cvs with the project :-) but I may give it a shot. >If I change all occurances of "string" to "ansistring", then: > >-bash-2.05b$ ./exectest >An unhandled exception occurred at 0x0806CC1C : >EDivByZero : Division by zero > $0806CC1C TEST_DIVISION_BY_ZERO, line 14 of exectest.pp > $BFBFF994 main, line 22 of /home2/marcov/cvs/devel/fpc/rtl/inc/heap.inc > >Are you sure you compiled all units with -gl? >(...) >it sounds like your sysutils is not compiled -gl, however it could also >be a FPC version thing (I'm using a current versioN) I get the same behavior if I change all the strings to ansistrings (PLAY_WITH_STRINGS function call is missing from the stack trace.) For the test program (and for my project) I always have the -gl flag in fpc.cfg. However I haven't compiled the sysutils unit, so I'm going to try that and see if it makes a difference. I'm a little skeptical due to Peter's comment, but the sources.tar just finished downloading, so I'll try my luck... Thanks, David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ansistrings, exceptions, pascal call stack and access violations
Compiling sysutils with -gl gave the call stack seen below... insightful, I suppose, but not necessarily useful ;) It definitely points to what Peter said about the ansistring finalize writing to the same place in the stack. Examining the stack, it seems that dump_stack calls get_caller_addr, and then I assume the access violation is about the address being unfindable since it's been overwritten. 1.9.5 (today's w32 binary) didn't work any better re: Peter's last comment: so I guess the finalization of that temp ansistring is done at the end of play_with_strings, rather than being done within play_with_strings just after completion of the call to do_nothing_with_an_ansistring ... but it still irks me that the temp ansistring is created even if the function requiring it is not called. Oh well. Has this been filed as a bug? (Is it considered a bug? I should hope so) ... for now, I guess I'm condemned to always be recompiling with a directive to either handle exceptions or see a call stack. I can live with that (as if I have a choice!) Thanks, guys... keep up the good work, I'm sure this problem will be solved eventually :-) ~David. Here's the stack with the debug version of sysutils (1.9.4): An unhandled exception occurred at 0x004275D8 : EDivByZero : Division by zero $004275D8 TEST_DIVISION_BY_ZERO, line 13 of t.pas $702E7420 line 1 of windows.pp An unhandled exception occurred at 0x00415B8F : EAccessViolation : Access violation $00415B8F GET_CALLER_ADDR, line 1207 of e:/c/194/src/rtl/i386/i386.inc $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FDA0 line 1 of windows.pp $702E7420 line 1 of windows.pp An unhandled exception occurred at 0x00415B8F : EAccessViolation : Access violation $00415B8F GET_CALLER_ADDR, line 1207 of e:/c/194/src/rtl/i386/i386.inc $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FB2C line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FDA0 line 1 of windows.pp $702E7420 line 1 of windows.pp An unhandled exception occurred at 0x00415B8F : EAccessViolation : Access violation $00415B8F GET_CALLER_ADDR, line 1207 of e:/c/194/src/rtl/i386/i386.inc $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066F8B8 line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FB2C line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FDA0 line 1 of windows.pp $702E7420 line 1 of windows.pp An unhandled exception occurred at 0x00415B8F : EAccessViolation : Access violation $00415B8F GET_CALLER_ADDR, line 1207 of e:/c/194/src/rtl/i386/i386.inc $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066F644 line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066F8B8 line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FB2C line 1 of windows.pp $00420B58 DUMP_STACK, line 779 of e:/c/194/src/rtl/inc/system.inc $0066FDA0 line 1 of windows.pp $702E7420 line 1 of windows.pp ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ansistrings, exceptions, pascal call stack and access violations
Peter wrote: >The quick fix for it will be to disable the dump_stack call after an unhandled >exception is found. That gets rid of the junk, but I still lose the call stack. >Alternative solution is to retrieve the caller stack at the time an exception is >raised. But that will take more cpu time and more memory. Regarding the system resources -- it would only take that extra cpu time / memory at the time the exception is raised, correct? (( Our own project does not raise exceptions extensively, but we do want to be able to handle them when they come up, rather than crash out. Maybe we will have one exception in five minutes of execution. )) Also, I assume this would only work if I raise the exception. If I encounter, e.g., a stack overflow, I guess there wouldn't be a way to get the backtrace until the bug is taken care of? Or can I get it within my exception handling code before reraising? I'm working on the "alternative solution" ... how do I get my hands on the Relevent Address and frame? Writeln (backtrace_text, BackTraceStrFunc(Addr -- ???) ); Dump_Stack (backtrace_text, frame - ???); Thanks, David ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
re: [fpc-pascal] Find error?
When you compile with -gl you need to make sure that you recompile all the units, as well as the main program, with the -gl flag. Passing a -B flag will recompile all units (whose sources are found in the path), so: fpc -gl -B myprogram If, after doing so, you still lack line info, it's probably because it's hitting an error in the rtl or some other part of the fpc system, in which case you ought to be able to trace the erroneous call back to the last call made by your code. If you'll be running in debug mode for any appreciable length of time, you might consider putting -gl in your fpc.cfg, so fpc will always compile all your programs with the line info. The drawback is that the executables are bigger; I don't know if there are any speed considerations. Of course, as Peter suggested, you could also use the IDE or Lazarus or some other gdb-supporting editor, which can take you straight to the error from the address, rather than needing the line info in english. ~David. Original Message > From: Alan Mead <[EMAIL PROTECTED]> > Sent: Tuesday, November 09, 2004 8:58 AM > To: free pascal <[EMAIL PROTECTED]> > Subject: [fpc-pascal] Find error? > > Turbo Pascal used to have a "find error" function... Is there a > similar function in Free Pascal (I'm using 1.9.4)? I compiled the > executable with -gl but I get the below: > > An unhandled exception occurred at 0x08071049 : > EOutOfMemory : Out of memory > $08071049 > $080705FD > $08068B2A > $08068E30 > $4D664F74 P$LSA2_finalize_implicit, line 683 of lsa2.pas > > -Alan > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
re: [fpc-pascal] Find error? ... memory
> Regarding the EOutOfMemory exception, is that thrown only when all
> (physical+virtual) memory is exhausted?
I don't know, but perhaps you need a bigger stack and/or heap. (We've had to
increase ours a couple times; I don't know what the defaults are)
From the programmer's manual:
{$M StackSize, HeapSize}
where StackSize and HeapSize are integer values, greater than 1024. [...]
(Stack setting is ignored under linux, netbsd and freebsd)
Although in my experience, the stack setting is not ignored under linux. We
have hit stack overflow errors which went away after increasing the stack size
with this setting. So maybe it depends on the kernel or the version of fpc...
dunno. Incidentally, we were recently having some trouble with stack overflows
with the 2.6.7 kernel, and went back to 2.4.26, which seems to work fine.
~D.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] reporting bugs? ... fpc 1.9.4 crash
Is there a better place to post bugs, outside the list? Well, regardless, here it is... fpc 1.9.4 crashes with the following source. Of course, my bug was easy enough to find/fix, but it looks bad when the compiler crashes! Not a bug in 1.0.10. Synopsis: index variable "ix" has not been declared. Try to access an array element via this index, and write said element to a file. var array_of_longint : array [0..5] of longint; longint_file : file of longint; begin for ix := 0 to 5 do write (longint_file, array_of_longint[ix]); // line 7 end. Free Pascal Compiler version 1.9.4 [2004/05/30] for i386 Copyright (c) 1993-2004 by Florian Klaempfl Target OS: Win32 for i386 Compiling test.pas test.pas(6,6) Error: Identifier not found "ix" test.pas(7,41) Error: Identifier not found "ix" Compilation aborted test.pas:7 Runtime error 216 at $00472D7B $00472D7B $00474F32 $004C95E0 $004C96A1 $0046B074 $0046A501 $0046C445 $0046C456 $0046C456 $0046C456 ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
re: [fpc-pascal] using units in units...
You need to put your "uses" list inside either the interface or the implementation of the unit. You can even put different lists in the interface and implementation sections (though you can't list the same unit in BOTH lists). Usually the implementation section will have a longer uses list; the interface only needs a uses list for types, including object types, etc., which appear in the interface. I'm not sure about it, but it may even be possible to put a uses list inside initialization and/or finalization sections. ~David. Original Message > From: Ron Weidner <[EMAIL PROTECTED]> > Sent: Tuesday, December 07, 2004 2:30 PM > To: Agustin Barto <[EMAIL PROTECTED]>, FPC-Pascal users discussions > <[EMAIL PROTECTED]> > Subject: [fpc-pascal] using units in units... > > I'm looking for a little syntax help please. How do > you use units in a unit? The following doesn't work. > > unit unit_test; > uses crt; > interface > function make_line(): String; > > implementation > function make_line(): String; > begin > make_line := 'This is a string returned'; > end; > end. > > What I'm trying to accomplish in my program is I want > to create a file called defs.pas. this would contain > all the constants for all the units that make up the > prgram. For example, there might be a constant > SCREEN_WIDTH or SCREEN_HEIGHT. Now I want to be > able to use those varibles in the units, Collide.pas > and Draw.pas. How is this done in Pascal. > > Ron_W > > > > > > > __ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] terminal width/height
Hi all, Is there a function to query the terminal width and height, as a number of characters? For example, in windows 98, the terminal is always 80 characters wide, but the height varies; in linux, the height and width can both change, even while the program is running. I'm throwing some text up on the screen and would like to be able to format it to fit the terminal width and height. Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
re: [fpc-pascal] Variants vs. Variant Records
keep in mind that when Pascal stores a variant record, each record is the same size -- the maximally sized variant. So, for example, if you have type my_variant_record = record case rec_type : longint of 1: ( my_bool : boolean ); 2: ( p_to_ss : ^shortstring ); 3: ( x, y : longint ); end; Then All records of this type will be the maximum size, which would be three longints: rec_type, x, y (for the case 3). So even when you only have case 1, a boolean and the first longint, that record size would be the maximum size 3 * sizeof (longint) = 3 * (4 bytes) = 12 bytes. Then, you could also do something like type primitive_value_type = (prim_value_1_shortstring, prim_value_2_real, etc...); my_variant_array_element = record elem_type : primitive_value_type; p : pointer; // points to a variable of type elem_type; I don't know if the above will work. It may be that you would have to structure it as a variant record: my_variant_array_element = record case elem_type : primitive_value_type of prim_value_1_shortstring : ( shortstring_pointer : ^shortstring ); prim_value_2_real : (real_pointer : ^real ); etc... end; (Note: my syntax for those pointers might not be correct; I don't use pointers much.) Last I checked (fpc 1.9.4) it was not possible to give variant array elements of the same size and position duplicate names, so even though they're all pointers, you could not give the same name, e.g. "p" to "shortstring_pointer" and "real_pointer". This should not be too big a deal, because you really ought to know what you're working with all the time anyway. But there was one time when I had a record type that was somewhat similar to three variants like (x, a) (x, b) (q, r, s, t) and I just had to bring x out of the variant types even though it would have been sensible in this case to have x address the first longint in variants type 1 and 2. Oh well. The nice thing about the latter two methods is that you get an array with relatively small elements, so if your arrays are sizeable, it should save memory. If the arrays are not too big, the first one might be the way to go, since it ought to be slightly faster (saving only dereferencing a pointer in some variant cases) I guess I don't actually know what you mean by "variant arrays"! ~David. Original Message > From: Agustin Barto <[EMAIL PROTECTED]> > Sent: Saturday, July 23, 2005 5:57 PM > To: FPC-Pascal users discussions > Subject: [fpc-pascal] Variants vs. Variant Records > > I have to build some container classes (like java Vector) for a > project. I was thinking on how to store some primitive values (so far > I only need to store Integer, Real or Extended and ShortString) and I > can't decide between variants (variant arrays) and variant records > (dynamic arrays of variant records). Any hints? > > ___ > 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] About reset(aFile, FileNameString)
I usually just make a wrapper function, and keep it in a utility unit with some
other similarly useful stuff. Here's my code:
type reset_or_rewrite_enum_type = (resetit, rewriteit);
function open_file (var f : file; file_name : ansistring; whattodo :
reset_or_rewrite_enum_type) : boolean;
var
io_result : integer;
begin
assign (f, file_name);
if whattodo = resetit
then {$I-} reset (f) {$I+}
else {$I-} rewrite (f); {$I+}
io_result := ioresult;
if io_result = 0 then open_file := true
else begin
open_file := false;
write ('Error: ');
if whattodo = resetit
then write ('Reset ')
else write ('Rewrite ');
writeln (file_name, ' returned ', io_result, ': ',
error_description(io_result));
end;
end;
function reset_file (var f : file; file_name : ansistring) : boolean;
begin
reset_file := open_file (f, file_name, resetit);
end;
function rewrite_file (var f : file; file_name : ansistring) : boolean;
begin
rewrite_file := open_file (f, file_name, rewriteit);
end;
~David.
Original Message
> From: "Lance Boyle" <[EMAIL PROTECTED]>
> Sent: Tuesday, September 13, 2005 2:39 AM
> To: "FPC-Pascal users discussions"
> Subject: [fpc-pascal] About reset(aFile, FileNameString)
>
> "Official" Pascal for opening a file and associating a name with it
> (e.g., a disk file) goes like this:
>
> assign(aFile, FileNameString);
> reset(aFile); {or rewrite, etc.}
>
> All of the Pascals that I have used allowed the following shorthand,
> an extension:
>
> reset(aFile, FileNameString); {or rewrite, etc.}
>
> At least one of these Pascals was not a Macintosh Pascal, so I never
> considered it a "Mac" extension. Yet, I can find no possibility of
> this in FPC, in spite of its various compatibility modes.
>
> I tried overloading reset() (newbie alert on the overloading thing)
> but it didn't work.
>
> What say ye?
>
> Lance
>
> ___
> 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] Suspected Strange Error in FPC
> [...] first I will get a problem, > then sometimes if I add comments, all of a sudden the problem vanishes > and I get clean compiles that do work. First thing that comes to mind: uninitialized local variables? That's almost always the cause when I have problems that change or vanish with comments or monitoring. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
re: [fpc-pascal] Runetime errors
Put into your fpc.cfg file: -gl to generate the line numbers (that's the really relevant one, right?) It will also say what procedure it's inside, as well as a backtrace of calling procedures, and their line numbers. You can also find in fpc.cfg a number of other flags to generate debugging info. I don't know if it's possible to generate a line like "the number -4 is not between 0 and 3000" ... although that would be kind of nice, come to think of it. ~David. Original Message > From: "Carsten Bager" <[EMAIL PROTECTED]> > Sent: Wednesday, October 05, 2005 8:13 AM > To: FPC-Pascal users discussions > Subject: [fpc-pascal] Runetime errors > > When a runtime error happens, I would like to display all > possible information > The compiler we are using today can give a message like > this > Runtime error 27 > Index out of range > The value -4 is not in the range o 0 .. 3000. > Near line 103 > Procedure Test > > Would it be possible to do something like this if I write a new > exit procedure? > > If this is not possible how about the Turbo Pascal way using the > map file to track the Procedure Name and the source code line > number. I do not think this is possible with FPC because of the > separate assembler and linker, but maybe there is a way around > this. > I am running the FPC code on an embedded ARM platform > without any operating system. > -- > Carsten Bager > Bøvlingbjerg El-automatik > Brørupvænget 10 > 7650 Bøvlingbjerg > Tlf. +4597885222 Fax +4597885434 > http://www.beas.dk > > ___ > 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] Questions on Documentation
Thanks, Tomas! This list is terrific. Whenever I need a function, I'm usually aching for something like this to help me find what I want. While searching is great, sometimes I don't know what word to search for, and I can spend 40 minutes doing various searches through the documentation, without a clue of which unit I should be using. Then I get frustrated and post to the list, and more often than not, I just didn't know the correct search term, and if I'd had a way of knowing which units to narrow my search down to, I probably could have found what I wanted. It's just invaluable to have such a summarization-- I think I'm going to print this out. I'd really like to see more of this helpful summarization in the documentation. If it were more prevalent, I think we would get fewer very basic questions posted to the list, and people could use the documentation more effectively to find the information they need. ~David. Original Message > From: "Tomas Hajny" <[EMAIL PROTECTED]> > Sent: Tuesday, October 11, 2005 6:02 AM > To: "FPC-Pascal users discussions" > Subject: Re: [fpc-pascal] Questions on Documentation > > Well, to be honest, I don't think this is a complete answer. It's > certainly true that you can achieve similar effects by using different > functions stored in different units. From this point of view, some kind of > categorization of supplied units would probably help, in fact - as it is > now, it's a list of units without providing any hint what to search where. > I don't think that it makes sense to try to list e.g. "all disk I/O > functions", because different things would be mixed together and it > probably wouldn't help either. > > Such categorization should probably include different programming models > (procedural, TP/BP style OOP, Delphi style OOP), whether ansistrings are > used or not (default with -Mdelphi/$MODE DELPHI or $H+), cross-platform > and platform specific units (with information about their > availability/useability for different targets), basic information about > type of functionality to be found there (similar to the "Overview" chapter > in individual unit descriptions, which is unfortunately little bit > uncomplete regarding information about categories mentioned above and even > missing altogether for many units) and availability of this unit in other > Pascal compilers (at least TP/BP, Delphi and FPC specific). Something like > this should probably appear at the beginning of the unit reference. From > this point of view, I'd suggest to fill your comment as a "Wishlist" type > bug record for area "Documentation" in our bug repository, so it doesn't > get forgotten. > > My (simplified) categorization to get you started (before we manage to get > it to our documentation): > > 1) procedural programming, short strings, cross-platform: > > - System - basic type definition, execution control, parameter processing, > string handling, type conversions, mathematic operations, memory > management, basic routines for console and disk I/O, constants and > variables describing the particular platform and/or current environment > (available in TP/BP and Delphi) > > - Strings - operations with PChar strings (available in TP/BP) > > - Matrix - vector and matrix routines (FPC specific) > > - UComplex - operations with complex numbers (FPC specific) > > - GetOpts - routines for more advanced access to program parameters > > - Keyboard - low-level access to keyboard (FPC specific) > > - Mouse - mouse support (FPC specific) > > - Video - routines for low-level access to screen (FPC specific) > > - Printer - very basic access to printer (available in TP/BP) > > - Sockets - basic support for TCP/IP socket communication (FPC specific) > > - CMem - replacement memory manager based on C run-time library to allow > easier integration with some code written in C (FPC specific) > > - CTypes - definition of C language types for easier integration with > routines written in C (FPC specific) > > - InitC - some functions required for linking of some libraries written in C > > - MacPas - special unit supporting constructs formerly available in some > Pascal compilers for Mac OS platform (ThinkPascal, Metrowerks etc.); > available for all platforms with FPC to support -Mmacpas/$MODE MACPAS (FPC > specific) > > - HeapTrc - debugging support unit for tracing of incorrect memory > allocation (more or less FPC specific, at least not available with TP/BP > and probably Delphi either) > > - LineInfo - debugging support unit to allow displaying of location (line) > in source files in case of an error based on debug information linked to > executable file (FPC specific) > > - Crt - more advanced console (keyboard and screen) routines (TP/BP > compatibility unit plus some FPC specific functions) > > - Dos - more advanced disk I/O, execution flow (including running of other > programs), date and time handling and access to environment variables, > plus some co
[fpc-pascal] Lazarus and FPC integration
I think the time has come to integrate (the installations of) FPC and Lazarus more fully. I'll first use myself as an example as to why; then I'll present the reasons I suspect such an integration has not already taken place, and suggest an implementation of the integration (mostly from the end-user's perspective). As a nearly 3-year user of FPC, I have never tried Lazarus. Why not? Well, every time I visit the Lazarus site, I find it a little confusing, and I'm concerned about conflicts with my current FPC, and am not sure which version of Lazarus to download. Based on my own experience, I suspect that many potential users are often confused by the FPC and Lazarus websites and the download procedure. I suspect several reasons for the current lack of integration: - Historically, Lazarus was borne out of FPC. In the minds of some of the core developers (and many others) they remain as separate entities that should be installed and thought of as independant projects (though they do integrate well together.) This may be the most significant block to the integration effort!! (Come on guys, let's acknowledge the success of the Lazarus effort by integrating the installer!) - Some users may want to run FPC from the command-line only (or other IDE, e.g. SciTE or Vim) and not bother with the Lazarus IDE - Some users may already have FPC installed and not want to re-download it when installing Lazarus - other reasons? So I hope to address all of these concerns with my proposal. I have a lot of ideas in my mind that I'd like to propose and discuss, but for now I will only present what I think is by far the most important one: 1. The primary download, that probably 90% of visitors to the FPC site would download, should be a single, integrated Lazarus-and-FPC package. So, what do I mean by this? I mean that, when you go to www.freepascal.org and hit the big "download Free Pascal" button (link), there should be two options: one to download the integrated FPC/Lazarus environment, and the other to do something special. This makes it EASY for new (and old!) users to get up and running with the most appropriate development environment. WE CAN STILL ACCOMODATE those users who want, e.g., a command-line-only compiler, or an older version, or to not download all the units or get documentation in a different format. But remember, those 10% are likelier to be the expert users. They are capable of navigating a few more web pages or download sites in order to figure out how to get just what they want, when the primary download does not suit them. Let the primary download serve the masses. What I haven't really discussed here is how, or whether, to integrate the websites freepascal.org and lazarus.freepascal.org. I think they should be more integrated than they are, but the starting point is to make sure that people who navigate to either site can download what it is they really want -- an IDE with compiler included. Oh yeah, okay, I lied ... one more little suggestion: 2. If I direct my web browser to freepascal.org, it can't find it. The site is one of the very few I encounter that requires me to type the www prefix. This is a pain in the butt and I bet it deters many potential users. ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] memory management with open arrays and classes
Hi all,
I'm pretty new to both "open arrays" and OOP, and am feeling a bit
concerned about memory management and leaks in my code. I will jump
straight into examples and questions:
type
T_my_object = object (TObject)
{...}
end;
T_my_class = class (TComponent)
{...}
end;
type
str_array_type = array of ansistring;
int_array_type = array of integer;
obj_array_type = array of T_my_object;
cls_array_type = array of T_my_class;
var
str_arr : str_array_type;
int_arr : int_array_type;
obj_arr : obj_array_type;
cls_arr : cls_array_type;
begin
{...}
setlength(str_arr, some_maximum);
setlength(int_arr, some_maximum);
setlength(obj_arr, some_maximum);
setlength(cls_arr, some_maximum);
{...}
First: what does setlength do about initialization? There are a couple
different cases here...
1. If the setlength function is creating an array of things which happen
to be stored as pointers (ansistrings in str_arr or class instances in
cls_arr) then will the pointers be initialized to nil by setlength? Or
do I need to manually initialize all pointers to nil, after calling
setlength? (I guess for ansistrings that would require using
fillchar ... but maybe setlength is already doing this?)
2. Of course the primary concern is cleaning up. For the ansistring
case, can I simply call:
setlength (str_arr, 0);
...and expect that the ansistring references will be properly
decremented and cleaned up?
Or do I need to explicitly clear them myself?
for i := 0 to high(str_arr) do str_arr[i] := '';
setlength(str_arr, 0);
3. Similarly for the cls_arr, do I need to explicitly call the
destructor?
for i := 0 to high(cls_arr) do
if cls_arr[i] <> nil then cls_arr[i].Destroy;
setlength(cls_arr, 0);
...or will setlength call the destructor when the array is shrunk?
(Assumably only for non-nil pointers :)
As for the other types... for int_arr it must be a non-issue, and for
obj_arr ... objects DO need to be destroyed! Although this is only a
matter of curiousity, since I'm not using any objects that aren't
classes
And of course the "array in array" example comes to mind:
var
str_arr_arr : array of str_arr;
begin
setlength (str_arr_arr, 5);
setlength (str_arr_arr[3], 17);
{...}
// is it necessary to free all of the members as seen below?
for i := 0 to high(str_arr_arr) do setlength (str_arr_arr[i], 0);
// or will setlength silently do the job anyway?
setlength (str_arr_arr, 0);
Conversely, do open arrays get automatically cleaned up as part of an
object destruction, or do I need to write that into the destructor?
type
T_my_other_class = class (TComponent)
private
str_arr : str_array_type;
int_arr : int_array_type;
cls_arr : cls_array_type;
public
constructor Create (my_owner : TComponent; pass_size :
integer); override;
destructor Destroy;
end;
constructor T_my_other_class.Create (my_owner : TComponent; pass_size :
integer);
begin
inherited Create (my_owner);
setlength (str_arr, pass_size);
setlength (int_arr, pass_size);
end;
destructor T_my_other_class.Destroy;
begin
for i := 0 to high(str_arr) do str_arr[i] := ''; // again :)
setlength (str_arr, 0);
setlength (int_arr, 0);
// and what about cls_arr, even more messy of course :)
inherited Destroy;
end;
4. Is the above destructor actually doing anything that doesn't happen
automatically?
And the last case, objects embedded in objects:
type
T_my_third_class = class (TComponent)
embedded_cls : T_my_other_class;
bool_arr : bool_array_type;
{...}
end;
5. Do I need to override the destructor with one that explicitly calls
embedded_cls.Destroy?
Of course, I didn't ask until I was already knee-deep in several layers
of this stuff...
type
third_class_array_type = array of T_my_third_class;
T_group_array = class(TComponent)
third_arr : third_class_array_type
{...}
end;
var
g_arr : array of T_group_array;
... and so on. Actually, I think that's as many layers as I've got!
whew.
Happily the program runs! I am doing a lot of this cleanup manually,
though, and am now wondering if I should cut some of my cleanup code
out as extraneous, or if I rather need to triple-check it and perhaps
reinforce it with yet more cleanup code.
Thanks!
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] memory management with open arrays and classes
Thanks, Joost, for all of your answers! It looks like I need to write *more* cleanup code, and double-check it all. One question remains: > After calling setlength, the items in the array are not initialised. > > [...] > > Initialising the strings you can do by setting them to an empty > string. (s := '') I had the impression that an ansistring is essentially a special kind of pointer. Since the *pointer* contains random (not nil) data, then ... if I assign it to empty-string, wouldn't fpc treat the old random pointer reference as an ansistring that needs to have its reference count decremented? For this reason, I have previously used fillchar to nil those out. Thanks, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] small bug with pass-by-reference on array elem
I would post this directly to the bugs database, but I've never received
my confirmation email (I've tried a couple times now, perhaps my ISP
greylisting is blocking it?)
- If a param is passed-by-reference to a function without being
initialized first, a warning is issued by the compiler.
- If the function defines the param as "out" rather than "var" (mode
objfpc) then (usually) no such warning is issued.
- If, however, the param passed happens to be an array element, then an
errant warning is issued. See the example:
{$mode objfpc}
procedure assign_it (out x : longint);
begin
x := 7;
end;
var
a : array [0..1] of longint;
b : longint;
begin
assign_it (b); // no warning
assign_it (a[1]); // errant warning issued
end.
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] assigning a local function to a var
I'd like to store an address of a local function in a variable, and call
that local function, but I don't know how to define a variable of
type "local function". Here's the error I'm stuck on, with sample code:
Error: Incompatible types:
got ""
expected ""
procedure test;
function func_a (pass_str : ansistring) : boolean;
begin
writeln (pass_str, 'A');
func_a := true;
end;
function func_b (pass_str : ansistring) : boolean;
begin
writeln (pass_str, 'B');
func_b := false;
end;
var
// what should this be??
my_func : function (pass_str : ansistring) : boolean;
begin
my_func := @func_a;
my_func('hello, ');
end;
Thanks!
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Thanks Lourival, Joao, Chris, for your responses.
It looks like what I'm attempting is not possible. FWIW, I've included a
more illustrative example at the end of this message.
Thus, I would ask of the devs, has this functionality been considered?
Is there some particular reason that anyone is opposed to implementing
it? Or is it just difficult to implement, and/or not considered useful?
There is a part of me that wants to jump in and try to implement this in
the compiler, although I suspect I would be in well over my head.
Before I consider making such an attempt (or looking for someone to do
it) it'd be nice to get a feeling for whether such an extension would
be welcome.
I am hard-pressed to detect any drawback or conflict, although of course
that's largely because I have no idea how this stuff is actually
implemented.
Lourival wrote some code which included:
> var
> my_func : TProcedure;
> begin
> my_func:= TProcedure(@func_a);
> my_func('hello, ');
> end
Lourival: while your suggestion to typecast the local function to
TProcedure did compile and run, the procedure is no longer "local"!
Thus the parent function's variables are no longer in scope, which was
the principal reason to use a local function. I neglected to include
that in my original example, so I rewrote the example below.
Chris: It seems like you're saying what I want to do is impossible.
Thanks for pointing out that citation in the reference manual. It would
be nice to hear a more definitive answer, though :) For now, I've made
the functions external, which unfortunately requires passing many
(local) parameters to them, within a loop that should go fast. :(
Chris wrote, among other things:
> This is for a reason - think what would happen if you were able to
> assign a local procedure to a global variable!
Perhaps my subject line should have read "assigning a local function to
a LOCAL var" -- that is, after all, what I'm after. ((Just because it's
possible to do something stupid with a feature, doesn't mean the
feature is a bad idea: I can think of all sorts of stupid/absurd things
to do with pointers, which compile without hint or warning.))
Joao: creating a named type isn't a solution, as it only moves the
problem of declaration into the "type" section, where the very same
problem persists. Thanks for responding, though.
On Wednesday 09 July 2008 9:31 am, David Emerson wrote:
> I'd like to store an address of a local function in a variable, and
> call that local function, but I don't know how to define a variable of
> type "local function".
Here's a revised version that better illustrates the need:
test.pas(20,14) Error: Incompatible types:
got ""
expected ""
procedure test;
var
what_to_say : ansistring;
procedure proc_a;
begin
writeln ('A says, "', what_to_say, '"');
end;
procedure proc_b;
begin
writeln ('B says, "', what_to_say, '"');
end;
var
my_proc : procedure; // need to specify "local". impossible?
begin
what_to_say := 'hello, world!';
my_proc := @proc_a; // won't compile! proc_a is local.
my_proc();
end;
Cheers,
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Hi Joao,
You're missing the point -- those functions, func_a and func_b, should
be embedded within another function. The behavior I would like to see
concerns local functions, not global functions. In your executable,
func_a and func_b are global functions (within the unit) not local
functions (embedded within another function).
As a sidenote, the type declaration is still superfluous -- when dealing
with global functions, the following will work equally well:
var my_fnc: function(pass_str: ansistring): boolean;
(Although I'm not sure if there might be compiler switches that would
enable/disable this functionality, possibly requiring the type
definition. My fpc.cfg may have something enabled that yours doesn't.)
At any rate, global functions work fine, with or without the type
definition. The reason I posted was to ask about local functions.
~David.
On Thursday 10 July 2008 12:33 pm, Joao Morais wrote:
> David Emerson wrote:
> > Joao: creating a named type isn't a solution, as it only moves the
> > problem of declaration into the "type" section, where the very same
> > problem persists. Thanks for responding, though.
>
> Did you test? I did and it works.
>
> ==
procedure parent_procedure;
var parent_var_available_to_local_functions; // ;)
> function func_a(pass_str: ansistring): boolean;
> begin
>writeln(pass_str, ' A');
>func_a := true;
> end;
>
> function func_b(pass_str: ansistring): boolean;
> begin
>writeln(pass_str, ' B');
>func_b := false;
> end;
>
> type
>tmy_fnc = function(pass_str: ansistring): boolean;
>
> var
>my_fnc: tmy_fnc;
// my_fnc : function(str:ansistring):boolean; // works equally well
>
> begin
>my_fnc := @func_a;
>my_fnc('hello');
> end.
// this is a procedure, so 'end' should be followed by a semicolon,
// not a period.
> ==
>
> Joao Morais
> ___
> 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] assigning a local function to a var
On Friday 11 July 2008 5:36 am, Florian Klaempfl wrote: > David Emerson schrieb: > > Or is it just difficult to implement, and/or not considered useful? > > The procvar handling code is one of the ugliest parts of the > compiler :) Well, I would *clearly* be in well over my head, as I expected. Thanks to everyone for your responses. Looks like I will have to use external procs with lots of params for now. Cheers, ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
