Re: [fpc-pascal] download link on viewvc pages is missing
On Wed, 13 Feb 2013, LacaK wrote: Hi, the (download) link (together with the (as text)) link that used to be next to (view) and (annotate) in viewvc revisions logs are missing, can this be enabled, please? Yes it will be good to have it back ;-) Send your patches to the viewvc maintainers. We operate a standard viewvc installation. If it is gone, it means they removed it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the feeling
that Giuliano thinks that he has to decide to use try-finally OR try-except but
there are situations where you need both. One of the criteria is if the object
is local or global since for a global object it is likely that you place the
.Free (or for a global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program in case of
an error and not continue showing just a dialog) so you'll need only the
try-except if you want to catch the exception. In case of a local object you'll
ALWAYS have the lines
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
I tried to make that point but I'm not sure the message reached its mark.
It's possibly unfortunate that Borland chose to use try for both
constructs, rather than having distinct try-except-end and
start-finally-end forms.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the feeling
that Giuliano thinks that he has to decide to use try-finally OR try-except
but there are situations where you need both. One of the criteria is if the
object is local or global since for a global object it is likely that you
place the .Free (or for a global object better FreeAndNil()) into a
destructor or finalization section (which means that you have to stop the
program in case of an error and not continue showing just a dialog) so you'll
need only the try-except if you want to catch the exception. In case of a
local object you'll ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put try-except
extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
(in other words: a try-*-end construct where * can be 'finally', or 'except',
or BOTH.)
fit into Pascal philosophy?
Advantages is mainly:
- one less indent level ('oh, I need try-except around all THAT, bugger.') to
care about;
(yeah, even with all the good tools to manage the code, it stings, that the
two
have to be separately declared and one needs to remember that...)
Would it be very complicated?
Lukasz
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download link on viewvc pages is missing
Michael Van Canneyt wrote / napísal(a): On Wed, 13 Feb 2013, LacaK wrote: Hi, the (download) link (together with the (as text)) link that used to be next to (view) and (annotate) in viewvc revisions logs are missing, can this be enabled, please? Yes it will be good to have it back ;-) Send your patches to the viewvc maintainers. We operate a standard viewvc installation. If it is gone, it means they removed it. Reading help: *File Download (Checkout View)* - Retrieves the unaltered contents of a file revision. Browsers may try to display the file, or just save it to disk. /This view is disabled in the default ViewVC configuration. So I think, that it can be enabled using viewvc.conf configurtion file ... May be there is : /allowed_views = ... adding here co will solve problem ;-) /-Laco. / ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Compiled program is a virus (seems to be internallinker problem)
On 12/02/2013 21:45, Sven Barth wrote: Note: If anyone wants to answer to this anti virus thread that was off topic to begin with, we should move over to fpc-other. Regards, Sven My apologies, I should have added [OT] to my reply. Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Lukasz Sokol wrote:
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
(in other words: a try-*-end construct where * can be 'finally', or 'except',
or BOTH.)
fit into Pascal philosophy?
Advantages is mainly:
- one less indent level ('oh, I need try-except around all THAT, bugger.') to care about;
(yeah, even with all the good tools to manage the code, it stings, that the two
have to be separately declared and one needs to remember that...)
I think this complicates things unduly. As it is case-else and then-else
are about the only places where there is this sort of composite block,
and finally-except-end is even uglier since parts of all three blocks
may be executed.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download link on viewvc pages is missing
On Wed, 13 Feb 2013, LacaK wrote: Michael Van Canneyt wrote / napísal(a): On Wed, 13 Feb 2013, LacaK wrote: Hi, the (download) link (together with the (as text)) link that used to be next to (view) and (annotate) in viewvc revisions logs are missing, can this be enabled, please? Yes it will be good to have it back ;-) Send your patches to the viewvc maintainers. We operate a standard viewvc installation. If it is gone, it means they removed it. Reading help: File Download (Checkout View) - Retrieves the unaltered contents of a file revision. Browsers may try to display the file, or just save it to disk. This view is disabled in the default ViewVC configuration. So I think, that it can be enabled using viewvc.conf configurtion file ... May be there is : allowed_views = ... adding here co will solve problem ;-) Ah. Hard to find without docs. I had tried default_file_view = co but that didn't help. But now I added allowed_views. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13.02.2013 09:58, Mark Morgan Lloyd wrote:
Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use try-finally
OR try-except but there are situations where you need both. One of the
criteria is if the object is local or global since for a global object
it is likely that you place the .Free (or for a global object better
FreeAndNil()) into a destructor or finalization section (which means
that you have to stop the program in case of an error and not continue
showing just a dialog) so you'll need only the try-except if you want
to catch the exception. In case of a local object you'll ALWAYS have
the lines
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
I tried to make that point but I'm not sure the message reached its mark.
It's possibly unfortunate that Borland chose to use try for both
constructs, rather than having distinct try-except-end and
start-finally-end forms.
Other languages did the same, so I don't see the problem here...
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the feeling
that Giuliano thinks that he has to decide to use try-finally OR try-except but
there are situations where you need both. One of the criteria is if the object
is local or global since for a global object it is likely that you place the
.Free (or for a global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program in case of
an error and not continue showing just a dialog) so you'll need only the
try-except if you want to catch the exception. In case of a local object you'll
ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put try-except
extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
In any case the semantics need to be defined correctly. E.g. in the
first case what happens if an exception is raised inside the finally
block? In the second case what happens if an exception is raised inside
the except block? Do they work like nested try try except end finally
end or try try finally end except end blocks or do they have the same
rules?
Keep this FAQ entry in mind when suggesting features:
http://www.freepascal.org/faq.var#extensionselect
(Note: I personally would have nothing against such a feature, but the
details need to be defined!)
(in other words: a try-*-end construct where * can be 'finally', or 'except',
or BOTH.)
fit into Pascal philosophy?
Advantages is mainly:
- one less indent level ('oh, I need try-except around all THAT, bugger.') to
care about;
(yeah, even with all the good tools to manage the code, it stings, that the
two
have to be separately declared and one needs to remember that...)
Would it be very complicated?
I don't know how complicated it would be (we now also need to take into
account Win64 SEH and possibly in the future also Win32 and WinCE SEH),
but it should at least be doable...
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 09:39, Mark Morgan Lloyd wrote:
Lukasz Sokol wrote:
To developers: How would a generalized/packed construct like
try [code block] finally [code block] except [code block] end;
(in other words: a try-*-end construct where * can be 'finally', or
'except', or BOTH.)
fit into Pascal philosophy? Advantages is mainly: - one less indent
level ('oh, I need try-except around all THAT, bugger.') to care
about; (yeah, even with all the good tools to manage the code, it
stings, that the twohave to be separately declared and one
needs to remember that...)
I think this complicates things unduly. As it is case-else and
then-else are about the only places where there is this sort of
composite block, and finally-except-end is even uglier since parts of
all three blocks may be executed.
With the traditional construct there could be another place that
poses a potential pitfall:
[use fixed width font to see below comfortably]
try vs try
try [...]
[...] finally
finally [...]
[...] except
end;[...]
//(*1*) end;
except
[...]
end;
Using the composite one, protects the user of this construct from putting code
into *1* place
where it may not be executed if exception happens in the try..finally block;
I'm not saying, this is not sometimes that one wants, but (at least in my case,
YMMV)
putting code in *1 is a result of a thinko/PEBKAC. There, this I think is
another (better?)
argument in favor of composite try...finally...except...end;
I still think the latter (single-level, composite) is nice to have.
And acknowledges that the two are in effect used together most of the time.
And lets one to easily add a 'finally' or 'except' section if need arises,
without
loosing any code to *1* black hole.
Regards,
Lukasz
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 11:01, Sven Barth wrote:
On 13.02.2013 10:11, Lukasz Sokol wrote:
[...]
To developers: How would a generalized/packed construct like
try [code block] finally [code block] except [code block] end;
or what about
try [code block] except [code block] finally [code block] end;
In any case the semantics need to be defined correctly. E.g. in the
first case what happens if an exception is raised inside the
finally block? In the second case what happens if an exception is
raised inside the except block? Do they work like nested try try
except end finally end or try try finally end except end blocks or
do they have the same rules?
I'd imagine it should work exactly like try try ... finally ... end; except ...
end;
so if exception happens in 'finally' block, 'except' is executed,
if no exception happens anywhere, only 'finally' happens.
Keep this FAQ entry in mind when suggesting features:
http://www.freepascal.org/faq.var#extensionselect
Nice, thanks!
(Note: I personally would have nothing against such a feature, but
the details need to be defined!)
(in other words: a try-*-end construct where * can be 'finally', or
'except', or BOTH.)
fit into Pascal philosophy? Advantages is mainly: - one less indent
level ('oh, I need try-except around all THAT, bugger.') to care
about; (yeah, even with all the good tools to manage the code, it
stings, that the two have to be separately declared and one needs
to remember that...)
Would it be very complicated?
I don't know how complicated it would be (we now also need to take
into account Win64 SEH and possibly in the future also Win32 and
WinCE SEH), but it should at least be doable...
Regards, Sven
I was imagining something in or just before the parser, detecting the
'composite'
construct and 'mechanically' (string for string even) substituting it for
two-level
traditional, putting the 3 code blocks into the proper places.
No ifs, no buts, same semantics, just flattened.
Write once, compile everywhere ;) Unfortunately I don't have
enough compiler knowledge to even imagine where this could be happening.
That would have all cases covered then...?
Lukasz
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] OT a bit - Planet Object Pascal
Hello, I'ved created an RSS aggregation site for Object Pascal related blogs: http://planet.objpas.org/ This is a test run, and the look and feel will be changed in the feature. If you have a blog or can provide RSS for FPC/Lazarus news please send me an email with the feed details and I'll add you. Ido ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 11:01, Sven Barth wrote: Keep this FAQ entry in mind when suggesting features: http://www.freepascal.org/faq.var#extensionselect (Note: I personally would have nothing against such a feature, but the details need to be defined!) Well I guess unless someone is ready to have a precedent of relaxing rule 2 here 'Anything that is only a shorter notation does not apply ...' this won't happen :( But it's not just 'shorter', it's relatively 'safer' too, and doesn't forbid anybody from using traditional constructs either, at all, if they wish so/need so. Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download link on viewvc pages is missing
Michael Van Canneyt wrote / napísal(a): On Wed, 13 Feb 2013, LacaK wrote: Michael Van Canneyt wrote / napísal(a): On Wed, 13 Feb 2013, LacaK wrote: Hi, the (download) link (together with the (as text)) link that used to be next to (view) and (annotate) in viewvc revisions logs are missing, can this be enabled, please? Yes it will be good to have it back ;-) Send your patches to the viewvc maintainers. We operate a standard viewvc installation. If it is gone, it means they removed it. Reading help: File Download (Checkout View) - Retrieves the unaltered contents of a file revision. Browsers may try to display the file, or just save it to disk. This view is disabled in the default ViewVC configuration. So I think, that it can be enabled using viewvc.conf configurtion file ... May be there is : allowed_views = ... adding here co will solve problem ;-) Ah. Hard to find without docs. I had tried default_file_view = co but that didn't help. But now I added allowed_views. Thanks now it is perfect. -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13.02.2013 12:41, Lukasz Sokol wrote: On 13/02/2013 11:01, Sven Barth wrote: Keep this FAQ entry in mind when suggesting features: http://www.freepascal.org/faq.var#extensionselect (Note: I personally would have nothing against such a feature, but the details need to be defined!) Well I guess unless someone is ready to have a precedent of relaxing rule 2 here 'Anything that is only a shorter notation does not apply ...' this won't happen :( Precedent: case of String If the other reasons are compelling enough or someone even provides a patch for the feature I personally see no problem. Of course the opinions of the other core developers matter as well... But it's not just 'shorter', it's relatively 'safer' too, and doesn't forbid anybody from using traditional constructs either, at all, if they wish so/need so. That's for example a reason that speaks for the feature. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist. [OT]
On 13/02/2013 12:31, Sven Barth wrote: On 13.02.2013 12:41, Lukasz Sokol wrote: [...] But it's not just 'shorter', it's relatively 'safer' too, and doesn't forbid anybody from using traditional constructs either, at all, if they wish so/need so. That's for example a reason that speaks for the feature. Regards, Sven Thanks, your acceptance made me shed a tear of joy and made my day brighter :) Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist. [OT]
On 13.02.2013 13:44, Lukasz Sokol wrote: On 13/02/2013 12:31, Sven Barth wrote: On 13.02.2013 12:41, Lukasz Sokol wrote: [...] But it's not just 'shorter', it's relatively 'safer' too, and doesn't forbid anybody from using traditional constructs either, at all, if they wish so/need so. That's for example a reason that speaks for the feature. Regards, Sven Thanks, your acceptance made me shed a tear of joy and made my day brighter :) It's mostly because I want that feature for a long time myself. :) You'll nevertheless have to convince at least a few more core devs that this feature would be useful or/and implement it yourself... [mostly because I'm currently busy with other projects, either FPC related or not ^^] Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use try-finally
OR try-except but there are situations where you need both. One of
the criteria is if the object is local or global since for a global
object it is likely that you place the .Free (or for a global object
better FreeAndNil()) into a destructor or finalization section (which
means that you have to stop the program in case of an error and not
continue showing just a dialog) so you'll need only the try-except if
you want to catch the exception. In case of a local object you'll
ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except, just
try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a path
to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.
What fpc developers think about that?
Giuliano
--
Giuliano Colla
Before activating the tongue, make sure that the brain is connected
(anonymous)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use try-finally OR
try-except but there are situations where you need both. One of the
criteria is if the object is local or global since for a global object it
is likely that you place the .Free (or for a global object better
FreeAndNil()) into a destructor or finalization section (which means that
you have to stop the program in case of an error and not continue showing
just a dialog) so you'll need only the try-except if you want to catch
the exception. In case of a local object you'll ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except, just
try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a path to a
code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful features.
What fpc developers think about that?
Else is used in Except already to select between various classes:
try
..
except
on E : MyType do
begin
end
else
// exception is not MyType
end;
so that is a problem.
I see no problem in adding finally, if you define carefully when it is executed.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Tree structure
Ah... finally somebody needs it. Please use the gtree unit, I would like to see whether it's really worth developing the unit for other people (than myself) :) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Tree-structure-tp5712850p5712887.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Tree structure
- Original Message - From: leledumbo leledumbo_c...@yahoo.co.id To: fpc-pascal@lists.freepascal.org Cc: Sent: Wednesday, February 13, 2013 10:14 AM Subject: [fpc-pascal] Re: Tree structure Ah... finally somebody needs it. Please use the gtree unit, I would like to see whether it's really worth developing the unit for other people (than myself) :) Hi Leledumbo, I think it will work. I take the opportunity to ask you for a little example on how can I traverse a nested tree, I need this for populating a TTreeView from a generic TTree. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Tree structure
I can't find the unit gtree...where is it located or downloadable from ? Thanks, R# 2013/2/13 Leonardo M. Ramé martinr...@yahoo.com - Original Message - From: leledumbo leledumbo_c...@yahoo.co.id To: fpc-pascal@lists.freepascal.org Cc: Sent: Wednesday, February 13, 2013 10:14 AM Subject: [fpc-pascal] Re: Tree structure Ah... finally somebody needs it. Please use the gtree unit, I would like to see whether it's really worth developing the unit for other people (than myself) :) Hi Leledumbo, I think it will work. I take the opportunity to ask you for a little example on how can I traverse a nested tree, I need this for populating a TTreeView from a generic TTree. Leonardo M. Ramé http://leonardorame.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] Re: Tree structure
On 13.02.2013 15:27, Roberto P. wrote: I can't find the unit gtree...where is it located or downloadable from ? If you have a current checkout of FPC's trunk or a recent snapshot the unit is located in $fpcsr/packages/fcl-stl/src. It's currently only provided in trunk. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Tree structure
From: Roberto P. padovan...@gmail.com To: Leonardo M. Ramé martinr...@yahoo.com; FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Wednesday, February 13, 2013 11:27 AM Subject: Re: [fpc-pascal] Re: Tree structure I can't find the unit gtree...where is it located or downloadable from ? Thanks, In FPC SOURCES/packages/fcl-stl/src you'll have to update your svn trunk repository. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Make TStringList.ExchangeItems virtual?
On 13.02.2013 15:43, Bart wrote: Hi, Is it at all feasible to make TStringList.ExchangeItems a virtual method? Reason: In Lazarus we have a component (TValueListEditor) that has a TStringList descendant as one of it's properties. This particular list needs te bee in sync with another list of objects. For Insert, Delete, Exchange and Clear that is easily done. However sorting is a problem, because CustomSort calls QuickSort which internally uses ExchangeItem() and not Exchange (which is virtual). For now I just duplicated the QuickSort and replaced ExchangeItem with (the overridden) Exchange. This however has the distinct disadvantage of having duplicate code. And it calls OnChanging and OnChange and notifies the observers each time an item is swapped... (at least if the Sort is not done inside a BeginUpdate/EndUpdate pair...) So in that case I'd prefer the virtualisation of ExchangeItems as well... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Make TStringList.ExchangeItems virtual?
On Wed, 13 Feb 2013, Sven Barth wrote: On 13.02.2013 15:43, Bart wrote: Hi, Is it at all feasible to make TStringList.ExchangeItems a virtual method? Reason: In Lazarus we have a component (TValueListEditor) that has a TStringList descendant as one of it's properties. This particular list needs te bee in sync with another list of objects. For Insert, Delete, Exchange and Clear that is easily done. However sorting is a problem, because CustomSort calls QuickSort which internally uses ExchangeItem() and not Exchange (which is virtual). For now I just duplicated the QuickSort and replaced ExchangeItem with (the overridden) Exchange. This however has the distinct disadvantage of having duplicate code. And it calls OnChanging and OnChange and notifies the observers each time an item is swapped... (at least if the Sort is not done inside a BeginUpdate/EndUpdate pair...) Currently it is not, in fact this should be done automatically. So in that case I'd prefer the virtualisation of ExchangeItems as well... We can do that, but it wouldn't do much good, since it is private. So I guess we'd have to make it protected too. The disadvantage is that making it virtual will make it slower, since an additional VMT lookup must be done. The reason that it is a separate routine is exactly to make it faster, otherwise quicksort could just have used Exchange().. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13/02/2013 13:14, Michael Van Canneyt wrote: I see no problem in adding finally, if you define carefully when it is executed. Michael. I second that, we don't need no pythonisms here ;) (or is it pythonosis?) I'd rephrase what I discussed with Sven Barth: this construct (the packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version - - should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end; Legend: (1,2,3): code blocks (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block - except, it will not have the HOLEs. Because [maybe some statistics needed here] this is probably the main (most advocated ?) use of them both at the same time. - It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be used exactly the same way with the same meaning. The new way will: -flatten the source code (one indent level less) -shorten the source code (one 'try' and one 'end;' less) -provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection) (this is most important here I think). Note that I'm not advocating for this to replace the traditional constructs; Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably know what they are doing. Hope this makes sense, Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Make TStringList.ExchangeItems virtual?
On 13.02.2013 16:14, Michael Van Canneyt wrote: On Wed, 13 Feb 2013, Sven Barth wrote: On 13.02.2013 15:43, Bart wrote: Hi, Is it at all feasible to make TStringList.ExchangeItems a virtual method? Reason: In Lazarus we have a component (TValueListEditor) that has a TStringList descendant as one of it's properties. This particular list needs te bee in sync with another list of objects. For Insert, Delete, Exchange and Clear that is easily done. However sorting is a problem, because CustomSort calls QuickSort which internally uses ExchangeItem() and not Exchange (which is virtual). For now I just duplicated the QuickSort and replaced ExchangeItem with (the overridden) Exchange. This however has the distinct disadvantage of having duplicate code. And it calls OnChanging and OnChange and notifies the observers each time an item is swapped... (at least if the Sort is not done inside a BeginUpdate/EndUpdate pair...) Currently it is not, in fact this should be done automatically. Than this could be adjusted at least... So in that case I'd prefer the virtualisation of ExchangeItems as well... We can do that, but it wouldn't do much good, since it is private. So I guess we'd have to make it protected too. I have silently assumed this :) The disadvantage is that making it virtual will make it slower, since an additional VMT lookup must be done. The reason that it is a separate routine is exactly to make it faster, otherwise quicksort could just have used Exchange().. Exchange additionally contains checks and two further method calls that do complex stuff if BeginUpdate was not called, so one can argue what is faster here :) We could maybe adjust the string list in so far that at the beginning of QuickSort we determine whether ExchangeItem was overridden, if it was we call the now virtual, protected ExchangeItem and if it was not overriden we call a private non virtual version (which could be called by the default implementation of ExchangeItem as well). Just a stupid idea to make the code more complex :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Can't configure fppkg
Hi,
I'm trying to configure fppkg, because seems that this is only way to
install GeckoPort version 2 (wiki.freepascal.org/GeckoPort_version2). I'm
using thos tips: wiki.freepascal.org/fppkg#Configuration . I have
CodeTyphon 4.0 so paths to FPC are different and can't configure it
What I did:
1. I added path to fpc binaries in linux PATH:
/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
2. First call of fppkg list created .fppkg directory (with /config
subdir) and .config/fppkg.cfg file
3. Changed .config/fppkg.cfg to:
[Defaults]
ConfigVersion=4
LocalRepository={UserDir}.fppkg/
BuildDir={LocalRepository}build/
ArchivesDir={LocalRepository}archives/
CompilerConfigDir={LocalRepository}config/
RemoteMirrors=http://www.freepascal.org/repository/mirrors.xml
RemoteRepository=auto
CompilerConfig=fpconf.cfg
FPMakeCompilerConfig=fpc.cfg
Downloader=lnet
4. I created file .fppkg/config/fpconf.cfg with values:
[Defaults]
ConfigVersion=4
GlobalPrefix=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
LocalPrefix={LocalRepository}
Compiler=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
OS=linux
CPU=x86_64
Version=2.7.1
5. And finally copy file /usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc.cfg
to .fppkg/config/fpc.cfg
6. Now calling fppkg list return me:
Name Installed Available
embweb - 0.9.0-926
gecko - 2.9.0-3
jquery - 0.9.0-842
lazmkunit - 0.9.3-1
lnet - 0.6.4-2534
webdesign - 0.9.0-906
So it looks like it is working, but command fppkg install gecko return:
The FPC Package tool encountered the following error:
[gecko] Package rtl none is not available
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Michael Van Canneyt ha scritto:
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use
try-finally OR try-except but there are situations where you need
both. One of the criteria is if the object is local or global since
for a global object it is likely that you place the .Free (or for a
global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program
in case of an error and not continue showing just a dialog) so
you'll need only the try-except if you want to catch the exception.
In case of a local object you'll ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except,
just try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a
path to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.
What fpc developers think about that?
Else is used in Except already to select between various classes:
try
..
except
on E : MyType do
begin
end
else
// exception is not MyType
end;
so that is a problem.
I didn't think of that, because I never use it. It would be nice to use
it the other way, but I understand it would break existing code. A
different keyword like nonexcept?
I see no problem in adding finally, if you define carefully when it is
executed.
IMHO the try..except..finally construct should provide exactly the same
functionality as a nested
try
try
[code]
except
[code]
end;
finally
[code]
end;
i.e. it should be executed whatever happened in the sections between try
and finally (except if somewhere there was an Application.terminate!).
Any exception not handled shoud be re-raised after the finally block has
been executed.
The advantage would be to get rid of one level of nesting, making the
code more readable and less error prone.
This would guarantee both proper error handling and freeing of global
resources, even in presence of errors.
Giuliano
--
Giuliano Colla
Before activating the tongue, make sure that the brain is connected
(anonymous)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
Lukasz Sokol ha scritto: On 13/02/2013 13:14, Michael Van Canneyt wrote: I'd rephrase what I discussed with Sven Barth: this construct (the packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version - I would be in favor of try..except..finally, as opposed to try..finally..except, because I believe it better to handle exceptions before, and clean-up after. Exception handling doesn't consist only in showing an error box, it may involve also providing a remedy to some errors, and hopefully passing to finally a cleaner situation to handle. I'm ready to change advise if proved wrong. - should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end; Legend: (1,2,3): code blocks (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block - except, it will not have the HOLEs. Because [maybe some statistics needed here] this is probably the main (most advocated ?) use of them both at the same time. - It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be used exactly the same way with the same meaning. The new way will: -flatten the source code (one indent level less) -shorten the source code (one 'try' and one 'end;' less) -provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection) (this is most important here I think). Note that I'm not advocating for this to replace the traditional constructs; Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably know what they are doing. If one is left free not to use the new construct, he can use the old one, and put in as many holes as he want. After all one is free to insert anywhere in the code a few assembler lines and to break anything fpc developers had in mind.. Giuliano -- Giuliano Colla Before activating the tongue, make sure that the brain is connected (anonymous) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13.02.2013 17:50, Giuliano Colla wrote: Python provides the following: try [code block] except [code block] else [code block] finally [code block] end; which can be used in any reasonable combination: just try..except, just try..finally just try..except..else etc. The except..else is a very useful construct, because it provides a path to a code block to execute only if there were no previous errors. This wouldn't break any existing applications, just add very useful features. What fpc developers think about that? Else is used in Except already to select between various classes: try .. except on E : MyType do begin end else // exception is not MyType end; so that is a problem. I didn't think of that, because I never use it. It would be nice to use it the other way, but I understand it would break existing code. A different keyword like nonexcept? I don't see the point of a else or nonexcept branch. If I want code to be executed in the case that no exception happened (e.g. a Commit for a database transaction) then I put in the block started by the try... One might argue that an additional branch would increase readability, but I personally don't see a real use for it... I see no problem in adding finally, if you define carefully when it is executed. IMHO the try..except..finally construct should provide exactly the same functionality as a nested try try [code] except [code] end; finally [code] end; i.e. it should be executed whatever happened in the sections between try and finally (except if somewhere there was an Application.terminate!). Application.Terminate is not special. It merely sets a FTerminated to True which will trigger a leave of the application main loop once the event handler returns. The only function that would be special in that regard is Halt, but that already works that way that any handlers are skipped. Any exception not handled shoud be re-raised after the finally block has been executed. The advantage would be to get rid of one level of nesting, making the code more readable and less error prone. This would guarantee both proper error handling and freeing of global resources, even in presence of errors. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
On 13.02.2013 18:07, Giuliano Colla wrote: Lukasz Sokol ha scritto: On 13/02/2013 13:14, Michael Van Canneyt wrote: I'd rephrase what I discussed with Sven Barth: this construct (the packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version - I would be in favor of try..except..finally, as opposed to try..finally..except, because I believe it better to handle exceptions before, and clean-up after. Exception handling doesn't consist only in showing an error box, it may involve also providing a remedy to some errors, and hopefully passing to finally a cleaner situation to handle. I'm ready to change advise if proved wrong. As the proposed construct is a mere syntactic sugar anyway I see no problem in allowing both cases (after all you can do both ways with the original constructs as well)... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can't configure fppkg
Still same error ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can't configure fppkg
On 13.02.2013 16:49, Krzysztof wrote:
Hi,
I'm trying to configure fppkg, because seems that this is only way to
install GeckoPort version 2 (wiki.freepascal.org/GeckoPort_version2
http://wiki.freepascal.org/GeckoPort_version2). I'm using thos tips:
wiki.freepascal.org/fppkg#Configuration
http://wiki.freepascal.org/fppkg#Configuration . I have CodeTyphon 4.0
so paths to FPC are different and can't configure it
What I did:
1. I added path to fpc binaries in linux PATH:
/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
2. First call of fppkg list created .fppkg directory (with /config
subdir) and .config/fppkg.cfg file
3. Changed .config/fppkg.cfg to:
[Defaults]
ConfigVersion=4
LocalRepository={UserDir}.fppkg/
BuildDir={LocalRepository}build/
ArchivesDir={LocalRepository}archives/
CompilerConfigDir={LocalRepository}config/
RemoteMirrors=http://www.freepascal.org/repository/mirrors.xml
RemoteRepository=auto
CompilerConfig=fpconf.cfg
FPMakeCompilerConfig=fpc.cfg
Downloader=lnet
4. I created file .fppkg/config/fpconf.cfg with values:
[Defaults]
ConfigVersion=4
GlobalPrefix=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
I have read the configuration article again and it seems that you need
to use the path which contains the FPC units here. I don't use
CodeTyphon, but it could be /usr/lib/codetyphon/fpc.
LocalPrefix={LocalRepository}
Compiler=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
OS=linux
CPU=x86_64
Version=2.7.1
My suggestion regarding fpconf.cfg from my other mail is still valid
though ;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can't configure fppkg
On 13.02.2013 21:35, Sven Barth wrote:
On 13.02.2013 16:49, Krzysztof wrote:
Hi,
I'm trying to configure fppkg, because seems that this is only way to
install GeckoPort version 2 (wiki.freepascal.org/GeckoPort_version2
http://wiki.freepascal.org/GeckoPort_version2). I'm using thos tips:
wiki.freepascal.org/fppkg#Configuration
http://wiki.freepascal.org/fppkg#Configuration . I have CodeTyphon 4.0
so paths to FPC are different and can't configure it
What I did:
1. I added path to fpc binaries in linux PATH:
/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
2. First call of fppkg list created .fppkg directory (with /config
subdir) and .config/fppkg.cfg file
3. Changed .config/fppkg.cfg to:
[Defaults]
ConfigVersion=4
LocalRepository={UserDir}.fppkg/
BuildDir={LocalRepository}build/
ArchivesDir={LocalRepository}archives/
CompilerConfigDir={LocalRepository}config/
RemoteMirrors=http://www.freepascal.org/repository/mirrors.xml
RemoteRepository=auto
CompilerConfig=fpconf.cfg
FPMakeCompilerConfig=fpc.cfg
Downloader=lnet
4. I created file .fppkg/config/fpconf.cfg with values:
[Defaults]
ConfigVersion=4
GlobalPrefix=/usr/lib/codetyphon/fpc/bin/x86_64-linux/fpc
I have read the configuration article again and it seems that you need
to use the path which contains the FPC units here. I don't use
CodeTyphon, but it could be /usr/lib/codetyphon/fpc.
Make sure to add a / at the end and then a fppkg list should show
not only the few online packages, but also the builtin packages
provided by fpc installation.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download link on viewvc pages is missing
--- El mié 13-feb-13, Michael Van Canneyt mich...@freepascal.org escribió: Ah. Hard to find without docs. I had tried default_file_view = co but that didn't help. But now I added allowed_views. Michael. Thank you. Jesus Reyes A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
