Re: [Lazarus] Mac OS X : Revision 19889 not compiling under 10.4
On Sun, May 10, 2009 at 07:56, domini...@savagesoftware.com.au wrote: Hi all, I just grabbed the latest SVN - 19889 and a build of bigide is not working. The error occuring is... Free Pascal Compiler version 2.3.1 [2009/05/09] for powerpc Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Darwin for PowerPC Compiling tachartlazaruspkg.pas Compiling taseries.pas Compiling tagraph.pas tagraph.pas(1368,40) Error: range check error while evaluating constants tagraph.pas(1368,50) Error: range check error while evaluating constants tagraph.pas(1503) Fatal: There were 2 errors compiling module, stopping The line in question contains DoubleRect(Infinity, Infinity, NegInfinity, NegInfinity) call, so range check error makes some sense. Still, I think it is a compiler bug, especially since an absurd attached patch fixes it. If FPC developers think the range check is correct, then it should be disabled for this one line and returned to previous state afterwards -- is there a way to do this? Cc'ing fpc-devel list. -- Alexander S. Klenin Index: tagraph.pas === --- tagraph.pas (revision 19825) +++ tagraph.pas (working copy) @@ -1359,13 +1359,15 @@ end; +const + ninf: Double = NegInfinity; + inf: Double = Infinity; var i: Integer; begin if FIsZoomed then exit; Extent.CheckBoundsOrder; - - FCurrentExtent := DoubleRect(Infinity, Infinity, NegInfinity, NegInfinity); + FCurrentExtent := DoubleRect(inf, inf, ninf, ninf); for i := 0 to SeriesCount - 1 do with Series[i] do if Active then ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]
On Thu, May 7, 2009 at 20:55, Martin Friebe laza...@mfriebe.de wrote: They should be merged together in a single list with appropriate filtering capabilities. another thing with combining them, is that the amount of Locals keeps changing (watches just display unavailable). This means that (unless locals are last in the list), everything keeps changing position, and you have to adjust where to look for it. Agree, thy should be the last. (OT: Would be a great feature to bind watches to a stackframe, and have them changing automatically...) +1 What kind of long values do you watch? Mainly structures/records/classes... Of course that would be better solved, by having each member on a line of it's own. Agree. You also have to find a way how to deal with different properties that watches can have (not yet, but in future: mem-dump, hex, dec, ... hust see the property window). In princible they can be applied to locals, as long as you can find a way to match them, each time locals had been updated. Because if you change stack frame you may have a local with the same name, but it is a different variable. So how to you bind those properties to a local value? Well, since the display format is per-value, this issue is totally orthogonal to the window consolidation. In fact, if display format is going to be controlled by e.g. context menu, then said consolidation might save some duplicated code. Not sure if those props make sense for registers Well, dec/hex definitely do. I actually looked at registers at the first time during this discussion and was surprised that some values are in decimal -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Wed, May 6, 2009 at 18:28, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Wed, May 6, 2009 at 2:44 AM, Alexander Klenin kle...@gmail.com wrote: FWIW, I often use Quick search (Ctrl+E) for code navigation, How does quick search work? I highlighted an identifier I want to seach for, pressed Ctrl+E. It showed seaching in the editor status bar, but nothing further. Sometimes it highlights a whole bunch of stuff like the letter e. I'm a bit lost. :-( It is like Firefox built-in search: start typing, and it moves to the next occurrence of the typed string. The wiki pages is trying to give greater exposure as well - visually with animation. Yes, documentation is good. But it is well-known fact that users do not read documentation ;-) 1) Find procedure should be merged into Code explorer I don't know Find procedure where is that? I used the filter in key mappings and found find procedure definition and find procedure method using the age old Ctrl+shift+Up/Down. I would have expected everybody to know the latter key mapping - it's what makes the Lazarus and Delphi IDE such a pleasure compared to other programming editors. Sorry, I meant Procedure List. 2) Find in files, Messages and Code observer should be merged together, with interface most resembling Find in files I can't see how these can be combined. They are totally different features. Maybe the result windows could be docked though. Although different in implementation, they are very similar in output: they all display a hierarchial list of strings, each string tied to a code location. Look how it is done in Visual Studio 2005 and later. 3) Unit list (Ctrl+F12) should be merged into Project Inspector I guess, but I simply have the project Inspector window always open. So I simply click a unit to open it. Yes, just add keyboard shortcut and searching feature from unit list to project inspector, then unit list becames a strict subset of it and can be safely removed. As Paul suggested. I think docking is the key here... it will make many feature or windows more manageable. I very much agree that docking is important. However, even with docking one can manage only a limited number of open windows. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
2009/5/6 Mattias Gärtner nc-gaert...@netcologne.de: 2) Find in files, Messages and Code observer should be merged together, with interface most resembling Find in files I can't see how these can be combined. They are totally different features. Maybe the result windows could be docked though. All floating windows should be dockable. We have already a docking manager. The missing part is to finish the save/restore of the layout. I started to look at fixing save/restore once, but dropped it since docking is being rewritten by Hans-Peter Diettrich -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
1) Find procedure should be merged into Code explorer Ok by me. (I never used it :) ) It's partly there anyway. Lets discuss it first - I use procedure list a *lot*. And at the moment it's behaviour is different to code explorer. Of course, no need to rush. But notice how even many people on this list do not know about procedure list -- merging with code explorer should help that. On Wed, May 6, 2009 at 22:10, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Other differences between Procedure List and Code Explorer. * Procedure List jumps to Implementation section. Code Explorer to Interface section. I would prefer to always jump to implementation, but it can be made an option. * Procedure list can filter by Class, non-class or All methods. I don't think Code Explorer can. * Procedure List can filter by method starting with text or method containing text. Not sure what Code Explorer does. Yes, filtering should be added to code explorer. * Procedure List, when launched puts focus where it must be - in the filter edit box. Code Explorer - I have no idea where the focus is, I think the treeview (filter box might be a better idea). Yes, after the merge Alt+G shortcut should put focus in similar field in code explorer. * In procedure list, when you press Enter to jump to a method, Procedure List closes and gets out of the way. Code Explorer hangs around taking up screen space. Well, I have Code Explorer always open anyway, but I guess it can be made an option too. So yes, there are plenty to discuss before any merge is to be considered. Please. Do not worry, the goal it to make everything better ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus IDE Tools - wiki page
On Thu, May 7, 2009 at 00:02, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Mattias just mentioned the following page in anther message thread. I thought it's worth mentioning it in it's own message thread. http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools WOW!!! I have learnt quite a few new tricks by reading that page. Ctrl+Shift+C is so much more powerful that I thought. Excellent stuff! :) Lazarus is even a little bit better than this page -- e.g. it mentions Identifier completion does not complete keywords, but at the recent SVN versions, it already does ;-) Also, IDE now does basic class completion. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Wed, May 6, 2009 at 13:40, Paul Ishenin i...@kmiac.ru wrote: Please create a wiki page. After few revisions it can become a part of roadmap. http://wiki.freepascal.org/IDE_UI_Consolidation -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
2009/5/7 Bogusław Brandys bran...@o2.pl: In fact we see here old problem of two rights - both groups are right , partially. While it would be nice to have as many nice features placed in one Code explorer as possible - that WILL double windows, because someone not using docking (due to limited free memory for example) will find faster to use Ctrl+F12 to show not bloated window with unit names then bloated code explorer. So what would show Ctrl+F12 shortcut in such case ? Ctrl+F12 is a shortcut for unit list, not procedure list Graeme was talking about. To me, this confusion is yet another argument that number of windows should be reduced ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Thu, May 7, 2009 at 02:25, Hans-Peter Diettrich drdiettri...@aol.com wrote: Graeme Geldenhuys schrieb: The problem with Code Explorer and FPDoc Editor type windows is that they use processing power as you navigate or switch units. Apropos switch units: who made the editor tab shifting almost useless? IMO the scroll buttons should scroll the editor tabs by pages, not activate the next left/right tab. I prefer the current way. I guess that depends on the number of units opened a once -- I usually try not to have too many. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]
On Thu, May 7, 2009 at 08:56, Martin Friebe laza...@mfriebe.de wrote: To heat the discussion up: From the wiki: Watches/Local variables/Registers All three are a lists of name/value pairs used at debug time. They should be merged together in a single list with appropriate filtering capabilities. That would make debugging so much harder. Let's assume merging those 3 does *not* mean a window with 3 tabs (as all 3 must be visible at once), but rather a window with splitters, so you can set how much of each you want to see... Actually, I meant a single list without any splitters, but with a filter to show/hide some values based both on kind (watch/local/register) and a substring. Besides reducing the windows count, this will also allow those developers who actually need them all to see all interesting values at a glance. Still I often use watches to show local variables which have a very long value. In this case I can have a narrow Local window (left to the code), and a very wide (but only a few lines high / below the code) watches window. Of course, If I am the only one who uses this in such a way, then it's not a reason. Interesting, but I guess this is indeed rather rare case. What kind of long values do you watch? 2) 99% of the time I don't need the register window = with them all showing in the same window, I will be very busy hiding it (move the splitter to 0 size) And I really can't imagine, that everyone else is using the registers at all times. Sure, the window should remember its configuration, and I agree that by default, Registers should be hidden. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Wed, May 6, 2009 at 07:48, Mattias Gaertner nc-gaert...@netcologne.de wrote: Well, power users don't scroll, they fly via shortcuts. Casual users use PgUp/PgDown. That's putting it nicely. My business model units are all fairly big. PgUp/PgDn will just take to long. I the procedure list feature 1000's of times a day. FWIW, I often use Quick search (Ctrl+E) for code navigation, since I remember some arbitrary piece of code to jump to, not necessarily a function name. IMO it is more important what features/functions are not used and would help the user most. AFAIK there was a Delphi plugin that did that. For example: If you use the Search dialog often to search for procedures, then you probably don't know the Ctrl+Shift+Up/Down and procedure list. If you type keywords then you probably don't know word completion. If you often add manually local variables then you probably don't know code completion. And so forth ... I think that while Lazarus IDE has many great features, they are not well organized. Various Lazarus developers added convenience features with a separate user interfaces, so the features are dispersed all over UI and hard to discover. IMHO the good way forward is to consolidate some feature groups into a common UI, thus giving greater exposure to all included features. I realize that may be a controversial topic, as developers might defend their pet features from consolidation, stating that consolidated UI is less convenient than specialized ones, but I think there should be a balance of uniformity versus specialization, and right now this balance is tipped far on the specialization side. If there is a general agreement, I can prepare detailed proposal for consolidation, but as a quick sketch: 1) Find procedure should be merged into Code explorer 2) Find in files, Messages and Code observer should be merged together, with interface most resembling Find in files 3) Unit list (Ctrl+F12) should be merged into Project Inspector 4) Find unused units should be merged into Unit dependencies ... and so on -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [patch] ModalResult documentation update
2009/4/28 Graeme Geldenhuys graemeg.li...@gmail.com: As discussed in another message thread. Here are some doc updates which I have tested locally. See attached patch file. Yes, much better. instead a few standard constants are used I'd say usually, since some application use different ModalResults -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 20:50, Mattias Gaertner nc-gaert...@netcologne.de wrote: About (4d) - single line begin..end Maybe you can give an example when this is not about code formatting? I just mean that removing non-whitespace characters is not formally 'formatting'. I agree it is gray area. A good formatter is very flexible and has a lot of options to fine tune indentation and line break. IMO complex expressions which can not be automatically broken nicely, should be changed anyway. Maybe the code explorer should show deeply nested expressions. Or simply expressions with too many tokens, regardless of nesting. Long lines depends on right margin and this heavily depends on programmers choice. For example if you set your right margin to 80 and you open a unit of other programmers the code explorer will easily list thousands of long lines. A performance killer. Is not it O(total number of lines) anyway? I do not see how a performance could depend on that. If you are worried about the number of items found, then I suggest to implement a generic limit of, say, 100 items. 100'th item should contain 'too many items found' text. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 21:27, Martin Friebe laza...@mfriebe.de wrote: Mattias Gaertner wrote: So the code explorer can scan for lines 'do' and 'then' lines where the following line is indented less or equal. Of course some programmers will switch off the equal. while a nice idea, even this is not that easy How about this general rule: foldable blocks content should be indented? Some exceptions are necessary, of course. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Code Observer notes
1) The name is good, if somewhat reminiscent of market-speak.
Buy our Lazarus -- now with Code Observer (tm) ;-)
2) The body of empty procedure is superfluously detected as empty block.
3) Perhaps 'Create' and 'CreateFmt' should be added to the list of
functions ignoring constants?
raise Exception.Create('Error text') is a common construct.
4) I still think ' ' (space) should be added to the list of ignored constants --
for those who prefer to turn single-char constant detection on.
5) 'Show Code observer' group box should better be named 'Show observations'
6) Some kind of sorting is necessary for the observations in the box.
Perhaps at least alphabetical?
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Observer notes
On Tue, Apr 21, 2009 at 14:49, Paul Ishenin i...@kmiac.ru wrote:
Alexander Klenin wrote:
3) Perhaps 'Create' and 'CreateFmt' should be added to the list of
functions ignoring constants?
raise Exception.Create('Error text') is a common construct.
No. Create and CreateFmt strings needs to be translatable even for
exceptions.
This is true, but unrelated.
First, naming a string constant does not make it translatable,
it should be made resourcestring (so perhaps it should be a separate
observation --
message is not translatable, where message is defined as string
constant containing at least one word)
Second, there are different means of i18n, and some of them, like dxgettext,
do not depend on resourcestrings.
Third, this same argument can be applied to Fromat, write/writeln and
other functions already present on ignore list.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Figures in code explorer
New figures feature is an excellent addition, thanks Paul and Mattias!
It already motivated be to fix some stylistic problems in one of my projects ;-)
A few questions/suggestions for improvement:
1) Where did the name came from? It is totally meaningless for me.
Maybe 'Stylistic notes' or 'Style' or something along these lines?
2) What is wrong with published properties without default?
3) I also like that codeexplorer options are now integrated with the
common dialog, however:
3a) Maybe 'Enable figures' checkbox should be moved to or duplicated on
the 'Figures' page?
3b) Maybe option 'parameters', lice line/procedure counts, should be placed near
the corresponding checkboxes?
3c) What is the reason for 'search char constants' option? I think it
should just be always on.
3d) I think '' (empty string) should be added to the default list of
ignored constants.
4) A few wishes/feature requests:
4a) 'Empty procedures' should not trigger if the procedure has comment
in the body,
to take care of a common idiom:
procedure TMyClass.Proc;
begin
// do noting
end;
4b) Add 'Unsorted procedures' similar to 'unsorted members'
4c) Add 'Empty begin..end' block, probably with the same check for the
comments as in (4a)
4d) Add 'Single statement in begin..end block'
4e) Add 'Too many nesting statements' and 'Too many nesting procedures'
4f) Add 'Line loo long' with default limit of perhaps 80 or 90 characters.
4g) Add 'Incorrect indentation' for the cases where indentation does
not correctly represent
statement nesting.
4h) Add 'Fixme' similar to 'TODO'
4i) This is probably an unrelated issue, but 'TODO' is only recognized
inside multi-line {} comments,
not inside single-line (//) ones.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Sun, Apr 19, 2009 at 22:02, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
A few questions/suggestions for improvement:
1) Where did the name came from? It is totally meaningless for me.
See http://www.askoxford.com/concise_oed/figure?view=uk
Hm. I'll quote that:
figure, noun:
1 a number or numerical symbol.
2 an amount of money.
3 a person’s bodily shape, especially that of a woman.
4 a person seen indistinctly.
5 an artistic representation of a human or animal form.
6 a shape defined by one or more lines.
7 a diagram or illustrative drawing.
8 (Music) a short succession of notes producing a single impression.
Not one meaning correspond to 'a hint about possible problem in the code'.
Maybe 'Stylistic notes' or 'Style' or something along these lines?
Not all are about style.
At least it will give user a vague idea what it is ;-)
How about simply 'hints'?
2) What is wrong with published properties without default?
See
http://wiki.freepascal.org/User_Changes_2.2.4#Default_property_values
If a property is streamed without need it
1. increases the size of the lfm
2. makes updating error prone, because even useless properties are
streamed. For example if a property was introduced and later
removed/renamed it is still in the lfm and the compiler does not notice.
The LCL had the last case a few times in the last years and every time
you have to check all lfm files. Therefore the LCL has a built in list
of ignored properties.
These are all good arguments, but _against_ the removal of 'default default'
property values. IMHO the FPC's team decision is wrong, but I think it
is too late ;-(
Now I have to to bloat my code with 'default false' lines, which were not
necessary before.
I see the reason for the hint now -- but I think it should be made a
FPC warning then.
3b) Maybe option 'parameters', lice line/procedure counts, should be
placed near the corresponding checkboxes?
3c) What is the reason for 'search char constants' option? I think it
should just be always on.
IMO char constants like #10, #13, 'a' or ' ' don't need to be
listed.
Maybe, but how about #34 or 'ё'? Char constant may be just as magical
as any other ;)
3d) I think '' (empty string) should be added to the default list of
ignored constants.
IMO no one wants to see empty string constants in this list, so no
need for an option.
But it _is_ shown now.
4b) Add 'Unsorted procedures' similar to 'unsorted members'
I rarely have seen units where all procedure are sorted alphabetically.
Same for enums, types, variables and constants.
Well, same for methods and properties.
Does LCL have one unit where 'unsorted members' list is empty?
Still, this list is IMO useful and so it is for procedures.
4c) Add 'Empty begin..end' block, probably with the same check for the
comments as in (4a)
4d) Add 'Single statement in begin..end block'
4e) Add 'Too many nesting statements' and 'Too many nesting
procedures'
4f) Add 'Line loo long' with default limit of perhaps 80
or 90 characters.
4g) Add 'Incorrect indentation' for the cases where
indentation does not correctly represent
statement nesting.
Are you joking or are you a grammar nazi?
Well, 'grammar nazi' can not exist for a compiled language, since
compiler will simply reject grammatically incorrect source.
So you probably mean 'stylistic nazi'. Well, yes, actually I am ;-)
However, the checks I suggested are very far from 'nazi' level.
Truly nazi-checks would include things as 'no double empty lines',
'all local variables start from lower case', 'begin statement
never/always alone on the line',
'no underscores in identifiers', 'try.. finally..Free..end for each
locally created object'
and many, many others.
The ones I suggested are in fact very conservative and some are in
direct analogue with already existing ones:
Empty begin..end = Empty class section
Too many nesting levels = Too long procedure/Too many nested procedures.
Incorrect indentation is IMO hard to implement, but it will probably
be the most useful
of all checks, since it will with 99% probability indicate an actual
bug (even if merely the code formatting bug).
4h) Add 'Fixme' similar to 'TODO'
AFAIK the todo list is not yet customizable. If you extend it, the code
explorer will be extended too.
Fair enough.
'TODO' is only recognized inside multi-line {} comments,
not inside single-line (//) ones.
Fixed.
Thanks.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 01:10, Marco van de Voort mar...@stack.nl wrote: On Mon, Apr 20, 2009 at 12:00:07AM +1100, Alexander Klenin wrote: However, the checks I suggested are very far from 'nazi' level. Truly nazi-checks would include things as 'begin statement never/always alone on the line', Funny that you think that is extreme. begin always alone on a newline, is about the only convention I insist on. The problem with this particular convention it that it is probably the hottest holy war topic in all Pascal stylistics discussions. For example, I (and company I work at) insist on the opposite ;-) So if it is ever implemented, it should include 'always/never' switch. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 01:28, Paul Ishenin webpi...@mail.ru wrote: Martin Friebe wrote: Hm, while some of them probably are most likely to be used to find possible issues, there is no need to see them as an problem indicator only. So point 1 is correct as they are a collecion of numbers figures Still, maybe they would be better named as statistics? (maybe analytics ?) I would call them IDE Hints or Code Hints. But Figures are also ok for me. My main point with the name is usability. The name should convey at least something about the named object to an unprepared reader -- this is an important rule both in programming and interface design. So yes, 'code hints', 'analytics' -- anything suggested in this thread is better than 'figures'. (Not 'statistics', however, which, by the way, would be another interesting feature) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 09:29, Mattias Gaertner nc-gaert...@netcologne.de wrote: Theoretically you can define 'hint' very generic: some message about a pascal source. But then the term 'hint' becomes almost meaningless But you propose to define 'figure' as an even more generic thing: number, place, line, structure or fact, so it will have even less meaning. every time a user user reads about 'hint' he doesn't know whether it means fpc hint or lazarus hint. And this is not a bad thing IMO -- these hints could just as well be in FPC, since their usefulness has nothing to do with Lazarus itself. FPC just moves too slowly. Conversely, it would be useful to display FPC hints in the same list and with the same grouping. Another argument for 'figures' is this: At the moment the items are listed in the tree. Eventually the lists should be moved to a second tree below, where some context buttons are shown. Additionally this would waste less space and update time. Then the current tree will only list the available categories and the total numbers, which is afaik often called in English 'figures'. We need a native English speaker to resolve this ;-) Yes, 'figures' may mean 'totals', but this word does not convey anything at all to the user who does not already know they are actually hints. You can call them 'things', 'items' or 'jabberwacks' -- it will not make any difference. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Figures in code explorer
On Mon, Apr 20, 2009 at 10:19, Mattias Gaertner nc-gaert...@netcologne.de wrote: 4c) Add 'Empty begin..end' block, probably with the same check for the comments as in (4a) 4d) Add 'Single statement in begin..end block' 4e) Add 'Too many nesting statements' and 'Too many nesting procedures' 4f) Add 'Line loo long' with default limit of perhaps 80 or 90 characters. 4g) Add 'Incorrect indentation' for the cases where indentation does not correctly represent statement nesting. Are you joking or are you a grammar nazi? Well, 'grammar nazi' can not exist for a compiled language, since compiler will simply reject grammatically incorrect source. So you probably mean 'stylistic nazi'. Well, yes, actually I am ;-) ;) And you want the IDE to be a stylistic nazi like yourself. Well in some way I understand you. I don't like macros and I will eventually add a category to list all macros. But IMO it is more important to provide a tool to help fixing these things. Which means for the examples you gave ... [...code formatting like indentation, empty or long lines...] ... a code formatter. Please note that stylistic-nazi examples I gave are different from the checks I proposed to add. One difference, which I considered while making the latter list, is whether code formatter will be able to fix it. Let's review: (4c) and (4d) are in principle fixable automatically, but the tool to do that should definitely not be called 'formatter'. (4e) has nothing to do with formatting (4f) seems like a no-brainer, but it has issues too: 1) there are times when slightly overlong lines are the lesser of two evils, like e.g. DebugLn lines in Lazarus or some list-formatted array initialization. 2) line splitting, sepecially for complex expression, seriously affects readability, so the choice of the optimal line break position can not be automated. (4g) again seems simple, but 'auto-fixing' can in this can make things _worse_ by hiding the problem. Consider the code (idented by '~' characters): for i := 0 to High(A) do ~~if A[i] m then Writeln(A[i]); The actual error is a missing 'm := i' line after the if, but formatter would change it to for i := 0 to High(A) do ~~if A[i] m then Writeln(A[i]); Obtaining correctly formatted but semantically wrong code. Hint, on the other hand, will simply point programmer to the problematic location where he will hopefully notice and fix it. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Repository commit statistics. :-)
On Wed, Apr 15, 2009 at 22:37, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Patches submitted to Mantis is applied by other users that have read/write access to the repository. So only those read/write users are shown. Yes, properly preserving author info in commits is another thing Git gets right, and Subversion does not. 2704 lazarus Hm, I wonder who he is ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] revision numbers of each SVN tag?
On Thu, Apr 16, 2009 at 00:02, Florian Klaempfl flor...@freepascal.org wrote: Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built. Why not tag it x.y.z-pre1 then, and if all went well, additionally tag the same revision as x.y.z, otherwise create x.y.z-pre2 etc.? At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?) Git (and Subversion too) can, in principle, lock branches using pre-commit hook. However, note that in git the whole problem does not exist, since in the normal workflow nobody except release manager can commit to release branch anyway. Also, it you _do_ move a tag in git, everybody updating from your repository will get a big fat warning ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] revision numbers of each SVN tag?
On Thu, Apr 16, 2009 at 00:02, Florian Klaempfl flor...@freepascal.org wrote: Very difficult. If a release is created from a branch, nobody can ensure that all release builders built the release candidate from exactly the same revision, if they don't, things might be broken when the final release should be built. Why not tag it x.y.z-pre1 then, and if all went well, additionally tag the same revision as x.y.z, otherwise create x.y.z-pre2 etc.? At cvs times we did this for fpc and we had to lock the branch to prevent commits (btw: can git lock branches ;)?) Git (and Subversion too) can, in principle, lock branches using pre-commit hook. However, note that in git the whole problem does not exist, since in the normal workflow nobody except release manager can commit to release branch anyway. Also, it you _do_ move a tag in git, everybody updating from your repository will get a big fat warning ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Notes on 'remove unused units' codetool
On Sun, Apr 12, 2009 at 16:26, Mattias Gaertner nc-gaert...@netcologne.de wrote: Fixed. Fixed. Added. Thanks. 4) Icons used are strange. I think standard 'unit' icon should be used instead of current one. Same icons as in the code explorer. Make a proposal. Hm... I proposed to use 'images/codeexplorer/ce_unit.png' which AFAIU is from code explorer. 5) I think this should be a project-wide feature, not unit-wide. Beware: The algorithm does not check recursively (e.g. the inherited initialization sections) and the .lpr file contains a lot of 'unused' units. For example the thread manager, the memory manager or the 'interfaces' unit of the LCL. If someone uses this dialog and simply removes all 'unused' he will make his program unrunnable. Well, perhaps do not show units used by .lpr as unused then? I am not sure how hard it is to implement, I know a good IDE. I do not understand. What IDE? 5a) (Preferably) A common tree of all units in project, with subtrees for each unit. Sounds like the unit dependencies window. Yes, I think joining both into a single interface is a sensible idea. Anyway, to show I am not just whining: http://bugs.freepascal.org/view.php?id=13501 ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal version 2.2.4 released
On Mon, Apr 13, 2009 at 03:19, Joost van der Sluis jo...@cnoc.nl wrote: The Free Pascal team is pleased to announce that version 2.2.4 has been released and is available for download for all major platforms: Congratulations to FPC team. The link to user changes from the announcement on freepascal.org site is pointing to a changes from previous release. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
On Sat, Apr 11, 2009 at 22:39, Luiz Americo Pereira Camara luiz...@oi.com.br wrote: Alexander Klenin escreveu: OTOH, the hint is not _entirely_ useless and can in some rare cases point to a real bugs. The solution is to enable per-variable hint suppression. It is done in C/C++ by omitting variable name, but I think a better way would be a compiler directive. Are you aware that fpc trunk already implemented an option to disable hints? See: http://bugs.freepascal.org/view.php?id=8690 As you can see from the part of my original post quoted above, this solution is, unfortunately, not useful . -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Notes on 'remove unused units' codetool
I tried a new 'remove unused units' refactoring, and in general I like it. A few nits: 1) Tree nodes should not be editable. 2) After removing first unit in the uses clause, the extraneous space is left before the next unit name. 3) A 'select all' button would probably be useful 4) Icons used are strange. I think standard 'unit' icon should be used instead of current one. 'Implementation' icon is good, but 'Interface' icon is totally unrecognizable for me. 5) I think this should be a project-wide feature, not unit-wide. I am not sure how hard it is to implement, but I see two interface variants: 5a) (Preferably) A common tree of all units in project, with subtrees for each unit. 5b) A combobox to select a unit, with a tree for the unit selected. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] update [Re: Code Folding mess and Code Divider feature]
On Fri, Apr 10, 2009 at 22:10, Martin Friebe laza...@mfriebe.de wrote: 3) 'Folding'/'Divider' buttons are slightly confusing. Maybe it is better to make common list of language constructs with additional 'Fold' checkbox, and make it visible only when needed? Alternatively, how about at least using PageControl instead of two buttons? I don't like the page control to much, I tried it The more likely solution (and feedback shows it will be needed) is to have 2 complete independent pages in the tree on the left. Patches are welcome, I have some other stuff that I currently prioritise at a higher level Sorry, no patch from me, but I can create an issue if you want. I have no problems with a separate page, but why do you reject a common list? It seems the best solution to me. 4) Some combinations result in two dividers drawn separated by and empty line (e.g. after the last procedure and before the initialization section). IMHO in such cases only one divider should be drawn [skip] Simple drop them would not work for people who have them in different colors (ok ,I do not honestly believe this is an issue) BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient? An other way, would be not to determine if we already drawn some other divider, but instead to end those blocks always in front of any empty lines (as long as those empty lines are at the end of this block). It would however mean that (if differently colored) the end of a type-block is drawn over the end of a class-block, hiding the end of the class I am not yet sure, If, when or which way I will do that. These are minor things, nothing to worry about too much. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability
On Sat, Apr 11, 2009 at 07:17, Christian Iversen
chriv...@iversen-net.dk wrote:
Ok, I can see what you're doing there. In my opinion, it's not very
pretty. How about something like this:
procedure SilenceHint(const A); inline;
begin
end;
I still prefer compiler-level solution, but if Lazarus team agrees,
I can use that method too. Anything for hints-free compilation ;-)
My original point is that the uninitialized variable hint is so common
that it becomes practically useless in certain applications -- for
example lazarus ones. If you could say, e.g:
{$HINT UNUSED_PARAMETER OFF}
Then that would make it easier for you to spot the real problems.
Maybe it is not salvageable, but then IMHO the hint should disabled by default
in fpc.cfg.
Granted, it wont catch the maybe 1-in-1000 actual unused parameter
problems, but littering the code with UseParameter() calls seems, in
my opinion, quite ugly, and a lot of work for a small gain.
One way to combat ugliness would be to use keyword, as in
procedure TMyForm.Button1Click(unused ASender: TObject);
which is very nice and readable, but the price is probably too steep.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability
On Sat, Apr 11, 2009 at 07:53, Alexander Klenin kle...@gmail.com wrote: On Sat, Apr 11, 2009 at 07:17, Christian Iversen chriv...@iversen-net.dk wrote: Ok, I can see what you're doing there. In my opinion, it's not very pretty. How about something like this: procedure SilenceHint(const A); inline; begin end; BTW, did you actually try this? It does not work at least on FPC 2.2.4: Warning: formal parameter not yet supported inside inline procedure/function Warning: Inlining disabled -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] update [Re: Code Folding mess and Code Divider feature]
On Sat, Apr 11, 2009 at 01:56, Martin Friebe laza...@mfriebe.de wrote: Sorry, no patch from me, but I can create an issue if you want. I have no problems with a separate page, but why do you reject a common list? It seems the best solution to me. Dividers initially could only be set at places where a fold ended. Now they can be set at places, even if the place is not configured as the end of a fold. So they are a separate feature. Divider-Locations also is a different list than Fold-Locations, so sharing the same list, would be confusing. Well, there are already two divider sub-kinds -- nested and normal ones. They already display different controls (spin editor vs checkbox, second color picker). I suggest to add 'Fold' checkbox, in the same vein -- it will be displayed only for foldable locations. BTW, don't you think that per-type divider coloring is an overkill? Perhaps a single color on Colors page would be sufficient? Not necessarily. For Example (I use this) I have a normal grey (same as right/80-column border) for procedures (procedures at top-level. But I use a lighter grey for nested procedures. So I can see the difference between nested and top level procs. No problem, but how do I globally change divider color then? Do I have to change it for every kind of location? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
On Wed, Apr 8, 2009 at 18:36, Mattias Gaertner nc-gaert...@netcologne.de wrote: In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you. As I already written some time ago, the solution is to introduce a hint/warning for the circular dependencies in implementation sections. This hint should probably be disabled by default, for compatibility reasons. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
2009/4/9 Mattias Gärtner nc-gaert...@netcologne.de:
As I already written some time ago, the solution is to introduce a
hint/warning for the circular dependencies in implementation sections.
This hint should probably be disabled by default, for compatibility reasons.
Yes, a hint would be nice.
But a hint won't be enough. It would go unnoticed too easy.
This is another important problem. Easily unnoticed hints are just useless.
There are two related causes here:
1) The message window interface of Lazarus is currently very weak.
(And it hides most of the hints by default, which I consider a bug in design).
This interface is one thing I think is worth borrowing from Visual Studio.
2) The compiler produces _many_ extraneous hints, which is very harmful --
it is impossible to produce hints-free code, so new hints has much
more chances
to go unnoticed.
First point is IMO of patches welcome category (and perhaps I will
provide some,
but don't count on that), but the second one is more fundamental.
There are two main sources of harmful hints now:
1) Parameter unused.
This is by far the main culprit. There are many cases when parameters are
unused deliberately -- e.g. basic implementations of virtual
functions, most events etc.
OTOH, the hint is not _entirely_ useless and can in some rare cases
point to a real bugs.
The solution is to enable per-variable hint suppression. It is done in C/C++
by omitting variable name, but I think a better way would be a
compiler directive.
I see two variants:
a) procedure TMyForm.Button1Click(ASender {$UNUSED}: TObject);
b) procedure TMyForm.Button1Click(ASender: TObject); {$UNUSED ASender}
The first one is slightly messy in case of many unused arguments,
while the second one avoids duplicating their names, so I am not sure
which is better.
Implementing either of them will fix the problem.
2) Uninitialized variable for auto-initialized strings.
See http://bugs.freepascal.org/view.php?id=0013341 and
http://bugs.freepascal.org/view.php?id=13370.
Both issues were resolved as won't fix which IMHO was done without
considering full picture.
Here is my argument:
There are two possible approaches to non-initialized warning:
a) Do not guarantee anything about non-initialized variables, complain
on their usage.
This is C/C++ route. It is not entirely consistent there as well
(global variables of simple types
are still auto-initialized to zero), but that is their problem.
b) Makes some guarantees about variable initialization and complain only for the
variables which are not initialized automatically. This is Object
Pascal/Delphi route.
It does not warn about global variables, object fields, strings and
interfaces since they are guaranteed
to be auto-initialized in a consistent way (and programmers rely on that).
FPC seems to take the third route -- it inconsistently warns[1] about
globals, strings and interfaces but
not object fields. This is the worst of both worlds and should be
fixed one way or another.
Compatibility and language tradition dictate retaining
auto-initialization, but I am not principle
opposed to removing it -- this, however, should be a loudly declared
lack of feature/incompatibility
and have a good reason.
[1] FPC issues this warning even in Delphi mode, which is an outright bug.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Fri, Apr 10, 2009 at 03:30, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Thu, Apr 9, 2009 at 5:55 PM, Henry Vermaak henry.verm...@gmail.com wrote: tortoisegit needs msysgit to be installed. I see no problem... why double the work of implementing two native versions of Git. I have successfully cloned the repo with msysgit. Everything seems to work at the first glance. Will play with it more and report the results. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Thu, Apr 9, 2009 at 23:14, Graeme Geldenhuys graemeg.li...@gmail.com wrote: The Git mirror is hosted on GitHub at the following URL and is sync'ed with Lazarus SubVersion trunk every 15 minutes. git://github.com/graemeg/lazarus.git Hm, apparently sync is not working. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ide enhancement - method or cursor location belongs to what class?
On Fri, Apr 3, 2009 at 00:13, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Thu, Apr 2, 2009 at 12:28 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Code explorer can follow the cursor. Can you explain how? I tried all the settings in Code Explorer and nothing allows the following the cursor behaviour. Perhaps Mattias wanted to say that Code Explorer _could_ be made to follow cursor? FWIW, I have many ideas for Code Explorer, and perhaps will even implement some of them -- but for now, my hands are full. Highlighting current cursor position is one of those. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] BoxRect
On Mon, Mar 30, 2009 at 03:43, Jesus Reyes jesus...@yahoo.com.mx wrote: --- El dom 29-mar-09, Carlos German Tejero german_tej...@yahoo.com.ar escribió: The delphi 7 helps says: Returns the screen coordinates of a specified set of cells. Delphi syntax: function BoxRect(ALeft, ATop, ARight, ABottom: Longint): TRect; is it public? protected? Protected, defined in TCustomGrid. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Fri, Mar 27, 2009 at 11:22, Hans-Peter Diettrich drdiettri...@aol.com wrote: [critique of Graeme's iterators] Since Graeme did not wish to post his article in the open, perhaps he also did not wish it to be cited? Anyway, I understood his design from the quote and agree with some of your critique. Please see the code I send to the list for my take on iterators. Note that it is only a proof-of-concept, without complete set of methods. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Fri, Mar 27, 2009 at 10:02, Hans-Peter Diettrich drdiettri...@aol.com wrote: Note that I said with defined equality. The reason 'case' should not include floating point numbers is that equality if not usefully defined for them. The same for strings, where mere binary (case sensitive) equality often is useless. Well, we should get rid of 'operator = (String, String)' then ;-) Seriously, I think you are exaggerating here. Furthermore Pascal 'case' supports ranges, which deserve a stricter order than only equality. Then the sort order of strings also depends on the encoding (codepage, MBCS, UTF...). Heh, I indeed forgot about ranges. Their existence actually allows to implement a useful 'case' for floating point types, so I now support a 'case of real' also. As for sorting order -- just do what built-in inequality does, there is no reason to deviate. And last not least strings IMO are complex types (array of char), as they have been in Wirth Pascal. Yes, but Object Pascal choose to _not_ follow Wirth's design here, so in Object Pascal strings are not 'array of char'. The order of a comparison of ordinals is O(1), whereas string comparison is O(n). Still, to compare given string with length n with m constant strings, O(n + m) time is sufficient, which, as I already stated, is another reason to implement string 'case' ;-) [regarding 'case of string'] Yes. But since this is not a simple type, but a complex type, it goes to a different class. If that is your argument, make sure it works for arrays, records, classes, interfaces and the other complex types too. I definitely agree that 'case' should work for classes -- perhaps even more important than for strings. For records and static arrays it could be implemented, but the value of such feature would be truly marginal. There is indeed a problem with ranges of classes. Maybe interpret them using inheritance as a partial ordering? E.g. TPersistent..TComponent is ok, but TButton..TDataset is error? I.e. what's the literal value and representation of the case label for an record? Record constant of course. What for 'RecA..RecX:'? I'd say it is RecA.F .. RecX.F for each record field, field recursively. As I already said, I am not really in favor of 'case of record', although you have already convinced me to support the 'case of real'. Still, here is a possible usage sample for the former: case MyPoint of (x:-1, y:-1): ProcessEmptyPoint; (x:0, y:0)..(x:100, y:100): ProcessPoint; else InvalidPoint; end. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Fri, Mar 27, 2009 at 18:49, Graeme Geldenhuys graemeg.li...@gmail.com wrote: The article was written for a magazine so I do not have the rights to publicly publish it myself. I you want to read it, buy the Toolbox magazine (German translation) and back-order Toolbox 1'2009 or ask and I will email you in private the original English version. It is not that, I just wanted to note that citing it might be also forbidden/illegal, sorry for being unclear. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Thu, Mar 26, 2009 at 17:56, Hans-Peter Diettrich drdiettri...@aol.com wrote: Alexander Klenin schrieb: Since string was introduced as built-in scalar type with defined equality, lack of 'case' support can be viewed as a design bug. IMO strings are similarly scalar as are floating point numbers, with regards to 'case'. Note that I said with defined equality. The reason 'case' should not include floating point numbers is that equality if not usefully defined for them. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Thu, Mar 26, 2009 at 18:59, Marco van de Voort mar...@stack.nl wrote: On Thu, Mar 26, 2009 at 10:28:50AM +1000, Alexander Klenin wrote: What problem does for in really solve? Lack of iterators. No it doesn't IMHO. This is really nice argument ;-) Well, it _should_ solve it. If it does not, it must be extended of implemented differently. I definitely do not argue in favor of blindly copying Delphi features. And I assume that by lack of iterators you mean in-language iterators? Of course. What else? One can give this handy moniker to every randomly thought up with an example that shortens some random code fragment. IMHO it is meaningless. As I said, I agree that the case for 'strict' visibility is rather weak. However, it still has practical uses. For a recent example: Lazarus contains some extremely overbloated source files, some more than 1 lines long, with dozens of classes. The task of refactoring them into a reasonable set of units is daunting. It would be made easier if I were able to first isolate classes inside the unit with 'strict' visibility specifiers to make sure nothing breaks when I move those classes away. I'm also not entirely happy with the way dynamic arrays are set up. They seem to be made mostly for COM use, the mandatory 0-basedness is unpascal like etc. 0-basedness, althout indeed unpascal is just a nuisance. The real problem of dynamic arrays is O(n^2) growing time. Is they, like TList, contained separate 'Length and 'Capacity' fields, they would be much more useful -- to the point that TList could be totally superseded. I can live with such an argumentation. However, if I take the case of string as example, I see only very rare occasions, and I wouldn't even use case of string because it is so limited. If suddenly the cases wouldn't be compiletime anymore (because they become user configurable or localised values) you have to morph the entire block. If they are not constants, the user should use 'if', this is obvious. And of course cases should not be localised. I am talking about such use cases as tokenizers and protocol handlers. What is the real use of duplicating const type and var as nested variants inside classes? Namespace management. They copied it from languages that have class as the only namespace. However the unit based Pascal concept already has units and the unit namespace to identify between similarly global symbols. When the codebase becomes big enough, more than one level of hierarchy becomes useful. Like for ... in? I never used in under Delphi except to iterate over sets. Well, you have missed some opportunities to enhance your code then ;-) Consider following use cases: 1) Iterating over array property, where and item should be stored in a temporary variable to avoid rereated calls to GetItem method inside the loop iteration: var i: integer; item: TItem; ... for i := 0 to obj.ItemCount do begin item := Items[i]; ... item ... item ... end; versus var item: TItem; ... for item in obj.Items do begin ... item ... item ... end; the latter is safer, simpler and more clear code. 2) Iterating over characters in string -- at first, it seems no different from any other array, but consider UTF-8 strings. Using s[i] notation in a loop will lead to O(n^2) time, while 'for ... in' can generate linear-time code. 3) Iterating over hash, tree, dataset, or really anything more complex than an array -- there is currently no language support for that, which leads to many awkward, buggy and incompatible implementations. [regarding 'case of string'] Yes. But since this is not a simple type, but a complex type, it goes to a different class. If that is your argument, make sure it works for arrays, records, classes, interfaces and the other complex types too. I definitely agree that 'case' should work for classes -- perhaps even more important than for strings. For records and static arrays it could be implemented, but the value of such feature would be truly marginal. For the other types, including class objects and dynamic arrays, 'case' is useless since equality semantics for them involves reference comparison, and the references will never be the same. I don't see string as a scalar type. It is an array or complex type IMHO. It should be an 'array of char' then. I agree that the latter would be a better design decision, but it is too late to change. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Thu, Mar 26, 2009 at 23:07, Marc Weustink marc.weust...@cuperus.nl wrote: Alexander Klenin wrote: 1) Iterating over array property, where and item should be stored in a temporary variable to avoid rereated calls to GetItem method inside the loop iteration: var i: integer; item: TItem; ... for i := 0 to obj.ItemCount do begin item := Items[i]; ... item ... item ... end; versus var item: TItem; ... for item in obj.Items do begin ... item ... item ... end; the latter is safer, simpler and more clear code. ehm, what if I want it reversed ? Reverse iteration might be common enough to warrant a special syntax, but in general all non-standard iteration orders should fall back to indexing. and how should the compiler know that there are Count items ? It should not. Iterators are usually based on end-of-items condition, not counting (since the latter might be unavailabe or inefficient for some containers). -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Fri, Mar 27, 2009 at 00:22, Paul Ishenin webpi...@mail.ru wrote: FOR s IN list DO WriteLn(s); extended: FOR s IN list USING my_reverse_iterator DO WriteLn(s); In upper case I wrote keywords and in lower case identifiers. I think the extension can be avoided like so: FOR s IN reverse(list) DO where reverse is a standard (or user-defined) function returning iterator. FOR s IN list DO will be a syntax sugar for FOR s IN default_iterator(list) DO where default_iterator is defined for built-in containers and can be redefined for user-defined ones. This can _almost_ be emulated at the library level -- look at the attached example. However, few problems exist: 1) overloading of operator := was designed without thinking, it should be a procedure with 'var' parameter instead of a function, because assignment often requires access to a previous state of l-value. So, rather ugly 'property V' is required. 2) 'while ForEach(a, r) do' is IMO less clear syntax than 'for a in r do' 3) user have to declare 'a: TIntegerArrayIterator' instead of simply 'a: Integer' 4) Note that I overloaded operator + only. In practice, all relevant operators should be overloaded, which is bulky. 5) Finally, all this code have to be written for every container/element combination. Generics might or might not help here -- but at this stage built-in implementation would actually be simpler then library-based one. -- Alexander S. Klenin iter.pp Description: Binary data ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Tue, Mar 24, 2009 at 22:40, Florian Klaempfl flor...@freepascal.org wrote: Alexander Klenin schrieb: You can rant about it if we reject a patch adding case with strings ;) I'am quite sure, a good patch (clear definition of the scope, support for all string types, clear definition how the strings are interpreted, tests) to implement it won't be rejected. That's refreshing, thanks ;-) From other answers I've got a feeling that such a patch would be rejected in principle. Well, I definitely do not have resources for that now, but maybe in a few months... -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Easiest way to case strings
On Sun, Mar 22, 2009 at 05:36, Hans-Peter Diettrich drdiettri...@aol.com wrote: Alexander Klenin schrieb: There exist too many options with string comparison. In a table lookup the compare method can be supplied by the application, in a case statement this would require another syntax extension. There are also many ways to implement strings and dynamic arrays -- but this did not stopped Object Pascal author from adding them, and I think he was right, even if some of his design decisions are suboptimal. This consider all roads then choose none approach will, obviously, never allow you to get anywhere ;-) Many Delphi extensions to the Pascal language break fundamental design rules. It's bad enough that FPC (and Lazarus) has to support such aberrations for compatibility reasons, I agree that some extensions were suboptimally designed, in particular dynamic arrays, but aberrations? Can you give an example? but further extensions should be added very carefully, Yes, but still they should be added -- that was my point. taking into account the design and experiences with the successor languages (Modula, Oberon...). While I deeply respect Wirth's contributions to programming language design, I think Modula and especially Oberon are not the best sources for inspiration. Object Pascal has log ago taken different direction -- for example, if we take into account Oberon, then we should, as a first step, remove strings, classes, virtual functions and for loop. I do not think this is a good way to evolve FPC ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Help to find cause of crash in IDE after revision 19044
As a general design note, I think that PropertyEditor.GetAttributes function should be split into static and dynamic parts, where static part supplies type-specific attributes, and dynamic -- value-specific ones. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Help to find cause of crash in IDE after revision 19044
On Sun, Mar 22, 2009 at 16:37, Alexander Klenin kle...@gmail.com wrote: 1) apply the attached patch I somehow managed to save incorrect patch. Please use this version instead. -- Alexander S. Klenin Index: propedits.pp === --- propedits.pp (revision 19058) +++ propedits.pp (working copy) @@ -6811,7 +6811,7 @@ if not (propList^[i]^.PropType^.Kind in AFilter + [tkClass]) then continue; edClass := GetEditorClass(propList^[i], A.GetComponent(0)); if edClass = nil then continue; - ed := edClass.Create(nil, 1); + ed := edClass.Create(AEditor.FPropertyHook, 1); try ed.SetPropEntry(0, A.GetComponent(0), propList^[i]); ed.Initialize; ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Help to find cause of crash in IDE after revision 19044
On Sun, Mar 22, 2009 at 20:37, Luiz Americo Pereira Camara luiz...@oi.com.br wrote: FYI, VTV does not define any custom property editor. Ok, I was too lazy to download and install VirtualTree and so shot in the dark. How can i know what is the property giving problem? Call GetName or GetPropertyPath. i tried to get the name through calling GetValue in Initialize method of the TListPropertyEditor but returned Unknown. Hm, I do not see a way TListPropertyEditor.GetValue can return 'Unknown'... Are you sure there is no inherited class? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Help to find cause of crash in IDE after revision 19044
On Sun, Mar 22, 2009 at 23:22, Luiz Americo Pereira Camara luiz...@oi.com.br wrote: Luiz Americo Pereira Camara escreveu: Columns is a TCollection descendant but is using a TList property editor. The crash probably is due to the cast to TList (TheList:=TList(GetObjectValue);) in TListPropertyEditor.ReadElementCount I'm looking at the same piece of code now, but this seems unlikely to me. Columns should use TCollectionPropertyEditor unless it is specifically overridden by VTV. Debug printing seems to confirm that. Anyway, stacktrace points at Result:=ReadElementCount like, which is totally insane. Is seems that virtual function table is broken?! -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Help to find cause of crash in IDE after revision 19044
After IRC discussion the fix was submitted to Mantis as http://bugs.freepascal.org/view.php?id=13381 -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Exception dialog
On Mon, Mar 16, 2009 at 23:44, Paul Ishenin webpi...@mail.ru wrote: Michael Van Canneyt wrote: Is there a reason why the default exception dialog has a cancel button to kill the application ? We often use an exception to signal wrong entry of data or so, because it stops all further processing. If the user then uses the cancel button, the program is simply ended, which is not what we (or better: the users) want. And I imagine many others use this technique. This is strange for me too and I also often clicked cancel to just cancel that notification but it closed my application :) I suggest to replace it with simple notification dialog with one button (like ShowMessage). Terminating application on exception is useful sometimes too, so please do not drop this functionality. I agree that it should not be the default. I suggest to rename buttons Continue and Terminate, with first being _both_ default and cancel, so neither pressing Enter not Esc would terminate application. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
On Fri, Mar 13, 2009 at 22:16, Martin Friebe laza...@mfriebe.de wrote: There is a general plan/idea to add some configuration (have to see how much) to define what you want to have foldable and what not. It wasn't seen as urgent yet (at least not by me...) Most (if not all) of the places that allow folding now, do so in Delphi as well. this is part of why they have been added, to make it easier for (ex-) Delphi users. Actually, at least in Delphi 2007 code folding works only down to classes and procedures, not below. Still, I think it is a good feature. IMHO most of the new ones are reasonable? - Except maybe for: Program / Unit and Implementation / interface; but they don't occur very often in a normal unit. - Maybe discussable are var Canost type blocks? Think is they can be very useful for bigger var sections (but I agree they can be irritating with just on line in it) - Folding at class / private / public = IMHO should be ok? - Folding at procedure in addition to the begin = arguable, if it should be instead of the begin? I'd say that such deep nesting should have very detailed configuration. I suggest to replace current numeric setting with a grid of checkboxes controlling code folding and divider drawing separately at logical levels: Level | Folding | Divider Unit/Program | Off | Off Section (interface/implementation/...) | On | Off Class/Object/Record Type Definition | On | On Class Visibility Specifier (public/private/...) | Off | Off Other Type Definition | On | Off Uses statement | On | Off Global var/property/const | On | On Procedure/Function/Method implementation | On | On Nested Procedure/Function | On | Off Local var/const | Off | Off Begin/end blocks | Off | Off Additionally, maybe for begin/end blocks a separate setting to turn folding on for blocks longer that N lines. The settings I above are my preferences, and I hope also reasonable defaults. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Folding mess and Code Divider feature
On Sat, Mar 14, 2009 at 02:03, Martin Friebe laza...@mfriebe.de wrote: Not yet. this will at earliest be implemented, when individual folds can be configured. The same applies for repeat/until It may also have to wait fro some more/other refactoring on the folding. The highlighting currently depends on the detection for folding. I thought about it too when I composed the list in the previous message, but considered them overkill. If single-statement folds, like for 'case', 'with', 'if' etc. will be implemented, they should be able to merge with begin/end folds for their bodies, to avoid useless almost-duplicate folds. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How about new State in Mantis ?
On Thu, Mar 12, 2009 at 05:45, Marc Weustink m...@dommelstein.net wrote: That is what resolved means. We (devels) think the issue is solved after some tests of our own. If you, the reporter, thinks it is not solved, then you can reopen the issue. If it is ok with you then you can close. If we cannot test the case, we ask you, the reporter, to test it throgh the request feedback status. BTW, is it possible to allow comments on resolved issues? For now reporters have to use mail list to comment on them, which is inconvenient and breaks discussion flow. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Patch for improved window layout
2009/3/1 Kostas Michalopoulos badsec...@slashstone.com: 1. The component bar (MainIDEBar)'s height is calculated to match the contents and current window size. This is a good idea in general, however your patch IMHO has some flaws, which I'll list in order from least to most significant: 1) CalcMainIDEBarHeight function has inconsistent indenting and no try-finally block 2) I am not sure how this code takes into account MainMenu height 3) It certainly does not take into account possibility for more than a single row of components on the tab (which, I presume, was the main reason for original large height). Perhaps a better suggestion would be to measure sizes of real components, instead of creating a fake ones. 2. Line up the windows so they don't appear inconsistent and they don't overlap each other. 3. Make the default new form size to cover a large area made up of the area left by the object inspector, the main bar and the messages window. 4. Resize the source editor window to be smaller than the default new form size but similar in aspect. These are merely a tweaks for magic constants. I have nothing against it, but I think this is, at best, a workaround until docking code is finished. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fw: New Features for source editor
On Wed, Feb 25, 2009 at 04:41, Lee Jenkins l...@datatrakpos.com wrote: -Autocompletion in real-time (no type Ctrl+Space) This by far, is one of the most productive enhancements that any code editor can have. It is just amazing how fast you can code with this feature as well as reduce typo's. While I am not against adding this to Lazarus, I would like to note that this is one Delphi 2007 feature I actively do not like, and always turn off. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fw: New Features for source editor
On Thu, Feb 26, 2009 at 22:17, Lee Jenkins l...@datatrakpos.com wrote: Alexander Klenin wrote: While I am not against adding this to Lazarus, I would like to note that this is one Delphi 2007 feature I actively do not like, and always turn off. Hmmm. I didn't think Delphi had this feature. I'm talking about Code Insight/helper that shows suggestions as you type. I type tstr and TString, TSTringList, etc is shown. I had to use CNWizards to get this functionality. Ah, then I misunderstood it too, I think the feature I talked about is called living templates or some such. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 22:55, Luca Olivetti l...@wetron.es wrote: En/na Florian Klaempfl ha escrit: How did you solve the problem of MQ with win32 line endings? I don't remember how I set it up (it was a while ago), but under windows I have this in mercurial.ini [extensions] hgext.win32text= [encode] *.pas = dumbencode: [skiped the rest] Although the posted config did not work for me, I re-researched th problem and now found the solution! The clue is here: http://www.selenic.com/mercurial/wiki/index.cgi/Win32TextExtension?action=diffrev2=9rev1=8 Notice how even Mercurial documentation authors were confused initially ;-) To recap, stars must be _doubled_ in encode and decode sections, like that: **.pas = dumbencode: -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 03:52, Florian Klaempfl flor...@freepascal.org wrote: Do you know you can fix up commits in DVCS as long as nobody pulled your changes yet? (And even after that, but at a risk of confusing others). What do you mean with fix up? I mean to change so it is not broken any more. Unlike svn, DVC systems allow to change history -- go back and modify old commits. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugger problems
On Wed, Feb 18, 2009 at 22:03, Alex du Plessis alexdu...@telkomsa.net wrote: Any pointers on how to get the debugger going? Currently a debugger in Lazarus is barely usable. However, if you submit a bug report http://bugs.freepascal.org/ and attach a sample project to demonstrate a bug, there is a chance it will be fixed. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Debugger problems
On Fri, Feb 20, 2009 at 22:44, Marc Weustink marc.weust...@cuperus.nl wrote: I wonder too what you do differently. How do you think I develop lazarus myself ? I agree that issues Graeme mentioned are tolerable, although inconvenient. For me, however, debugger, just crashes of freezes after 2-3 runs. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart child/parent control integration: request for review
If any core developer has time, please have a look at commits made for http://bugs.freepascal.org/view.php?id=13214 , in particular r18774. It works as far as I can test, but is that an 'official' way to create parent-child relation between components? Things such as ReadState override seem hackish to me. I will close issue in a few days if either no reviews or no problems will be found ;-) -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 01:09, Florian Klaempfl flor...@freepascal.org wrote: How did you solve the problem of MQ with win32 line endings? I did not :-( I resorted to manually converting files back and forth. It is not hard, but tedious. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
By the way, Mercurial mirror seems to be stuck again since r18773. What is the problem with it? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 02:23, Florian Klaempfl flor...@freepascal.org wrote: Alexander Klenin schrieb: By the way, Mercurial mirror seems to be stuck again since r18773. What is the problem with it? Here it is at 18780? Works for me now, too. What is the update interval? It seems some commits appear immediately, while others lags for few minutes to an hour. On Sat, Feb 21, 2009 at 02:28, Florian Klaempfl flor...@freepascal.org wrote: Alexander Klenin schrieb: I resorted to manually converting files back and forth. It is not hard, but tedious. So we cannot recommend this really to people :( Actually, I think we still can. The DVCS model itself is so powerful that I will probably use Mercurial for Lazarus even though I can now commit to svn directly and even despite all the warts of Mercurial's interface. See e.g. a comment about patch management I made in issue 13214. Another important thing for me is speed -- just to view a diff for _one file_ for some commit in the history with TortoiseSVN takes from 1 to 10 minutes, depending on file size and connection speed fluctuations. The blame is so slow it is out of question. OTOH, with Mercurial both operations are instantaneous, since they are local. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 03:17, Florian Klaempfl flor...@freepascal.org wrote: On Sat, Feb 21, 2009 at 02:28, Florian Klaempfl flor...@freepascal.org wrote: Actually, I think we still can. The DVCS model itself is so powerful It should first solve the awkwardness of line ending problem, it feels so rcs/cvs like. Well, the problem for me is actually from trying to use both svn and hg at once. So if one either: 1) Uses only svn 2) Uses only hg 3) Uses both, but without svn:eol-style=native property then all is well. Recently I even suggested to drop svn:eol-style, but apparently it is important for some Windows users. Another important thing for me is speed -- just to view a diff A lot of my diffs were full diffs when trying hg for a small project because of the line ending issue so the fast diffs got useless ;) Do you know you can fix up commits in DVCS as long as nobody pulled your changes yet? (And even after that, but at a risk of confusing others). I must admit, however, that the interface for doing that in Mecrurial is bad -- it is much better in git. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Delphi mode removal planned
On Wed, Feb 18, 2009 at 17:51, Alexander Klenin kle...@gmail.com wrote:
On Wed, Feb 18, 2009 at 16:27, waldo kitty wkitt...@windstream.net wrote:
Alexander Klenin wrote:
I plan to remove {$MODE DELPHI} and {$IFDEF fpc} from TAChart code,
since it is useless for Delphi anyway.
See http://bugs.freepascal.org/view.php?id=13201
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart: Delphi mode removal planned
I plan to remove {$MODE DELPHI} and {$IFDEF fpc} from TAChart code,
since it is useless for Delphi anyway.
Is there any objection?
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Delphi mode removal planned
On Wed, Feb 18, 2009 at 16:27, waldo kitty wkitt...@windstream.net wrote:
Alexander Klenin wrote:
I plan to remove {$MODE DELPHI} and {$IFDEF fpc} from TAChart code,
since it is useless for Delphi anyway.
Is there any objection?
i can't speak to objections but what, if any, side-effects might there be??
;)
There should be none from POV of Lazarus users.
TAChart source code will be converted from Delphi syntax to FPC syntax,
wich will make it more uniform with the rest of LCL.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] RadialPie angles
Currently, TCanvas.RadialPie function takes parameters StartAngle and EndAngle, documented as starting and ending angles of a circle segment to draw. However, it actually draws a segment from StartAngle to StartAngle + EndAngle. Is it a bug in code or documentation? I tried to look at the history of Pie/RadialPie/RadialPileWithAngles code, but it is rather messy, in particular confusing comments mentioning both angle1, angle2 and Angle,AngleLength were introduced together with the very first incarnation of Pie method. Additional complication is TPostScriptPrinterCanvas, which translates RadialPie directly into PostScript 'arc' operator (http://www.tailrecursive.org/postscript/operators.html#arc). Lastly, docs\xml\interfacebase.xml and lclinf.xml contain some totally different definitions of RadialPie's arguments. All in all, it seems that nobody uses RadialPie, or they would immediately notice this? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Mercurial mirror not updating
Since SVN r18698, about 35 hours ago. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Space preference for assignment
On Mon, Feb 9, 2009 at 11:17, Hans-Peter Diettrich drdiettri...@aol.com wrote: Micha Nelissen schrieb: How can I specify I prefer spaces around assignment operators? In the options window I can select several tokens, but not assignment operator, or did I miss it? You can selecet symbols, including the assignment operator. Unfortunately a couple of other tokens (punctuators, parentheses...) are also classified as symbols. I suggest to separate true operators from other symbol tokens, and to add an according option. Parentheses should already be separated since http://bugs.freepascal.org/view.php?id=12781 I did this precisely for the reason you stated. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart: request for review
Darius, if you are still around, could you please review TAChart patches in http://bugs.freepascal.org/view.php?id=12377 and http://bugs.freepascal.org/view.php?id=13119 Otherwise, can someone else do that? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LCL based image viewer like ACDSee?
On Fri, Jan 30, 2009 at 18:07, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Has anybody implemented a ACDSee (v2.x or v3.x style) clone using Lazarus yet? Free Pascal's fpImage units support various image file formats, so it should be relatively easy to accomplish. While it is not what you want, AFAIK a popular FastStone Image Viewer is implemented in Delphi. It is, unfortunately, closed course and Windows-only. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Mercurial mirror is down?
http://florianklaempfl.de:8000/lazarustrunk returns 404 error to me. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] MaskEdit: question on how it should behave
On Sun, Dec 28, 2008 at 09:43, Bart bartjun...@gmail.com wrote: I am not sure how modern Delphi behaves, but I'd say that Lazarus way is correct here -- this is clearly a programmes's error. OTOH, I think it would be useful to provide a separate function like 'TrySetText' which whould return false instead if saising an exception. In D3, D4 and Kylix1 ValidateEdit is only called if either the user presses Enter in the control, or the control looses focus. I still would like someone to test this in D7 or higher. Ok, I tested it -- D7 does the same. Actually, ValidateEdit only fires if the text was modified. (Or always at the design time). -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SQLite: How to create lookup fields?
On Fri, Dec 26, 2008 at 11:28, User usuarioanonimomy...@gmail.com wrote: Hi again, my TSQLite3Dataset components: My new code: [skip] but nothing happen. Why? Because, as I already pointed out: On Thu, Dec 25, 2008 at 21:05, Alexander Klenin kle...@gmail.com wrote: It seems to be implemented in SQLdb (TBufDataset). So, in addition to the above, original poster should indeed drop sqlitedataset. Perhaps TSQLite3Connection can be ised instead? -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] MaskEdit: question on how it should behave
On Sat, Dec 27, 2008 at 10:07, Bart bartjun...@gmail.com wrote: Question 1: If I set the text of a MaskEdit to some value that does not match the mask (e.g. EditMask = '' and then MaskEdit.Text := 'ABCD'), in D3 no exception is raised and the text in the control is set. Is this still the case in current Delphi's? (In Lazarus ATM an Exception is raised if you try to do that) I am not sure how modern Delphi behaves, but I'd say that Lazarus way is correct here -- this is clearly a programmes's error. OTOH, I think it would be useful to provide a separate function like 'TrySetText' which whould return false instead if saising an exception. Question 3: In the EditMask you can specify if the mask will be saved as pasrt of the data (again: what data?). For instance, if your EditMask is '000;0;_' then maskdata is not saved (the first 0 after the colon ( ; ) sets this value). I cannot really figure out what it does. I see noe effect n Text or EditText at all. If you mask includes non-special characters, those are displayed in the editor as-is, e.g. if mask is 000-00-00 and the user enters 1234567, the editor would contain 123-45-67. Depending on the value of the flag, the actual Text property will contain either 1234567 or 123-45-67. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SQLite: How to create lookup fields?
I do it:
procedure TForm1.FormCreate(Sender: TObject);
begin
with DatasetSales do
begin
Open;
DatasetItems.Open;
FieldByName('Item').FieldKind := fkLookup;
FieldByName('Item').LookupDataSet := DatasetItems;
FieldByName('Item').LookupKeyFields := 'Code; Description';
FieldByName('Item').LookupResultField := 'Code';
end;
end;
1) You forgot to set KeyFields
(or, rather, FieldName -- it should be different form KeyFields or
DBGrid might be confused)
2) You probably mixed up LookupKeyFields with LookupResultField
3) If you want the lookup field to be editable, you will need
to use Lazarus version later then http://bugs.freepascal.org/view.php?id=12347
and to set LookupCache := true
4) Even after this, there is some problems in SQLdb which I did not
yet found time
to diagnose and fix properly. They cause AVs while scrolling DBGrid.
On Thu, Dec 25, 2008 at 12:08, Luiz Americo Pereira Camara
luiz...@oi.com.br wrote:
It's not implemented in TSqlite3Dataset. In fact i don't know in which
layer (TDataset / TDataset descendant / TDbGrid) should be implemented.
It's up to TDataset descendants implement this?
Does some descendant already implemented ?
It seems to be implemented in SQLdb (TBufDataset).
So, in addition to the above, original poster should indeed drop sqlitedataset.
Perhaps TSQLite3Connection can be ised instead?
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Mercurial patches
On Tue, Dec 23, 2008 at 01:38, Florian Klaempfl flor...@freepascal.org wrote: Alexander Klenin schrieb: Just as a side note: http://florianklaempfl.de:8000/lazarustrunk/ is a mercurial mirror of lazarus. It might help you to maintain your patches. Mercurial works fine on windows as well and isn't a posix/unix centric hack as git is. Ok, I installed Mercurial and used it to generated a series of patches (to Object Inspector). Let us see how it goes. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mercurial patches
On Wed, Dec 24, 2008 at 19:04, Florian Klaempfl flor...@freepascal.org wrote: Alexander Klenin schrieb: Ok, I installed Mercurial and used it to generated a series of patches (to Object Inspector). Let us see how it goes. I guess what you need are the mercurial queues. Let us know how things work. Sorry if I was unclear -- I already did this, so it is now your turn to see how things work ;-) Patches are attached to issues http://bugs.freepascal.org/view.php?id=2007 http://bugs.freepascal.org/view.php?id=12851 http://bugs.freepascal.org/view.php?id=12852 in that order. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How should delete to end of word behave
On Sun, Nov 9, 2008 at 02:39, Alexander Klenin kle...@gmail.com wrote: Just found another minor glitch. Given text: abc def cursor xyz Ctrl+T results in abc defxyz i.e. spaces _to the left_ of cursor are deleted. Since there was no reaction, I closed original issue http://bugs.freepascal.org/view.php?id=12583 and created a new one about this particular bug: http://bugs.freepascal.org/view.php?id=12822 -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: double-buffering (issue 0012377) questions
On Sat, Dec 13, 2008 at 11:46, Alexander Klenin kle...@gmail.com wrote:
So this question remains. Or should I protect double-buffering with
{$IFDEF WIN32}?
Since noone is commenting, I assume my patch is ok ;-)
(http://bugs.freepascal.org/view.php?id=12377)
Can someone review/apply it? It is again holding further TAChart work.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 18:41, Mattias Gärtner nc-gaert...@netcologne.de wrote: Zitat von Alexander Klenin kle...@gmail.com: I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. The IDE is structured in a hierarchy. mainide: the top level of the IDE and the central nerve system. Because of its size it's splitted into several units. Oh, hierarchy is good in itself -- it is not what I am ranting about. (Although I'd say that main.pp, at 15000 lines, is in dire need of further splitting). However, to add another event to SynEdit, I had to add two useless events and two useless event handlers, totally containing more code then the original event -- simply to marshal the call through the hierarchy (see patch in the issue for details). This is IMHO not optimal design ;-) -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TAChart: double-buffering (issue 0012377) questions
In issue http://bugs.freepascal.org/view.php?id=12377, reporter said:
Painting to an Bitmap and paint this on the Canvas would be much faster
This assertion is, of course, incorrect. I assume that the reporter's problem is
actually that the TChart flickers when repainted.
The flickering is caused by two sources:
1) The TChart is TGraphicControl, so Parent control erases chart's background
before every repaint.
2) TChart itself draws directly to screen, first clearing the canvas.
First source obviously needs fixing, and I attached to the issue a
patch which fixes it.
The only caveat is that TChart is now TWinControl -- can it lead to some
undesirable consequences I am not aware of?
The second source can also easily be fixed by double-buffering, but
before I do that,
I have two questions:
1) TWinControl.WMPaint already contains double-buffering code, but it
is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there some
ongoing work to implement double-buffering globally?
2) If double-buffering will be implemented in TAChart itself, it will
have some negative
performance impact. So, should I make it optional via DoubleBuffer property?
--
Alexander S. Klenin
Insight Experts Ltd.
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 20:38, Martin Friebe laza...@mfriebe.de wrote: I haven't seen the patch? Can you check you really attached it. Sorry, attached now. It is a pity Mantis does not allow to attach a patch and add a note within a single operation. As for the events... There is probably (I haven't seen the code) another way: Pass the callback through to synedit. IDE gives a callback to SourceNotebook. But that does not mean that SourceNotebook has to be the one who calls it. It can just pass the Method-Reference to SourcEditor, which passes it to SynEdit. Source Notebook still needs to keep a copy, as it may open further SourceEditors. Yes, this would be slightly better way. Since I am not familiar with this part of code, I just implemented it the same way other similar calls work. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 21:36, Joost van der Sluis jo...@cnoc.nl wrote: Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list. I meant attached to an issue: http://bugs.freepascal.org/view.php?id=12785 Anyway, I'll attach it to this message too, just in case ;-) -- Alexander S. Klenin Insight Experts Ltd. synedit_mouselink_allowed_only.patch Description: Binary data ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
On Fri, Dec 12, 2008 at 21:37, Martin Friebe laza...@mfriebe.de wrote: In The current structure SynEdit is the Visual control, and therefore also the control that takes all events such as mouse/key down/up/move. Often it is SynEdits work to react to this, but often it also needs to call back to SourceEditor. It is at least worth reviewing if this order could/should be changed (I am not sure about it): - SourceEditor could be a visual component with all the Key/Mouse event handlers. - It would *not* inherit from SynEdit, but same as now it would have a SynEdit instance that it can make calls to. This SynEdit would not paint on it's own canvas, but rather paint on the SourceEditors canvas - Instead of SynEdit making all the callbacks to SourceEditor, now all events go to SourceEditor first, and SourceEditor can decide what to forward. Sigh, if we are dreaming anyway, here is my dream: 1) Logic should be separated from the presentation, so first there should be 'TAbstractSynEdit' class, concerning itself purely with text manipulations, such as text insertion/deletion, cursor position changes, text attribute calculation, save/loading, codetools etc. TAbstractSynEdit should not depend on any visual code, in partucular it should descend from TObject/TPersistent, not TControl. 2) Logic should be covered by automated tests, e.g. using fpcunit framework. 3) Presentation and user interaction should be the concern of TSynEdit class, aggregating TAbstractSynEdit and delegating all actual logic to the latter. 4) SourceEditor should be removed (or converted into a trivial wrapper), TSourceNotebook should reference TSynEdit directly. On the other hand, it is probably not worth the amount of work. Well the future will show, if there is a use case for it... True. Proper design requires lots of effort, and (especially short-term) benefits might not outweight the costs. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: double-buffering (issue 0012377) questions
On Sat, Dec 13, 2008 at 09:57, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 12 Dec 2008 19:38:55 +1000
Alexander Klenin kle...@gmail.com wrote:
The only caveat is that TChart is now TWinControl -- can it lead to
some undesirable consequences I am not aware of?
All direct TWinControl descendants must be implemented in all widgetsets.
You can use TCustomControl.
Sorry, I mixed up the mail (but not the patch). I already used TCustomControl.
1) TWinControl.WMPaint already contains double-buffering code, but it
is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there
some ongoing work to implement double-buffering globally?
It was an idea to implement double buffering, but it does not work on
all platforms. Gladfully most widgetsets have double buffering themselves.
But, apparently, not Win32, at least on WindowsXP.
2) If double-buffering will be implemented in TAChart itself, it will
have some negative
performance impact. So, should I make it optional via DoubleBuffer
property?
So this question remains. Or should I protect double-buffering with
{$IFDEF WIN32}?
--
Alexander S. Klenin
Insight Experts Ltd.
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Sat, Dec 13, 2008 at 05:20, Martin Friebe laza...@mfriebe.de wrote: Thanks for the patch, looks good to me. A few things: - Originally you had the condition NewX1NewX2 moved into IsLinkable. Now it is omitted? May be right, because codetools may (or may not) return false for those. Yet it means an unnecessary call to code tools. I agree. - You probably accidentally included changes to the lfm file of source-editor? Not quite so. The lfm change I included was, IIUC, done by IDE automatically simply because I opened and saved SourceEditor unit. This happens often for me, usually since lfm format changed slightly since the last time anybody touched the lfm in question. I see three ways to deal with this: 1) Include such changes in commits, since they will inevitably show up later. 2) Ignore them, and let them pile up, and then either 2a) Include them all in bulk when some essential changes to the lfm is needed 2b) Periodically (and automatically, if possible) open and re-save all lfm's and commit the result. I do not know what the policy in Lazarus is [judging by my previous policy questions, there is probably no policy ;-)]. So I opted for (1). - The unlucky bit is that your patch gets affected by a known bug. if you got a string with multibyte utf8 chars (like german umlauts) then anythink behind the umlauts is not linkable. This is already the case now (SynEdit does currently not follow valid links, behind umlauts), so you patch isn't wrong. The issue is, I can not test it, until I fixed the umlauts. I will see, if I can look at this during the weekend. I see that you already committed some fix. FWIW, I tested with Russian characters in comments -- it works for me. - And last not least (not a stopper, but would be nice), the current solution does call Codetools each time you move the mouse. It may be possible for UpdateControlMouse to cache the boundaries of the current linkable word, and trust this cache instead of calling codetools from CalculateCtrlMouseLink again? Good idea, I was concerned with the speed too, but testing showed it to be ok (maybe my PC is too fast). So for now I filed an issue http://bugs.freepascal.org/view.php?id=12790 -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Code Structure / SourceEdit and SyneEdit [Re: Mouse Link in SynEdit (only link-able items)]
On Sat, Dec 13, 2008 at 06:26, Flávio Etrusco flavio.etru...@gmail.com wrote: My vision deviates a bit from this in the sense that TAbstractSynEdit would just be an abstraction (or dedicated implementation) of a cleaner text manipulation interface (as TStrings won't cut it), which would also implement transparent/automatic/implicit 'undo' handling. Then each command would be a class, probably inheriting from TAction. It is not a deviation as much as detalization ;-) However, it is also important not to overdo abstractions -- perhaps a separate class for every command is too much. Anyway, I am glad that you (and Martin) agree with the general concept. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Request to review/apply patch 12758
I really wonder how a DVCS would solve this or what would be different? You just apply it to your local working copy and you've it in your builds? Yes. The most important difference in this case is that DVCS would preserve local history. This is similar to every developer having his own branch in SVN (or even arbitrary number of local branches), with merges being almost as trivial as SVN's commits. I.e. my specific problem can be solved in SVN by creating a branch of TAChart component and giving me commit access to it, but then similar branch should be created for my patches to DBGrid, and yet another one for patches to SynEdit (both stalled for about a month now), etc. Obviously, this is not a scalable solution for many developers ;-) -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Request to review/apply patch 12758
On Thu, Dec 11, 2008 at 20:16, Florian Klaempfl [EMAIL PROTECTED] wrote: Alexander Klenin schrieb: I.e. my specific problem can be solved in SVN by creating a branch of TAChart component and giving me commit access to it, but then similar branch should be created for my patches to DBGrid, and yet another one for patches to SynEdit (both stalled for about a month now), etc. Obviously, this is not a scalable solution for many developers ;-) But isn't the problem that the patches don't get into the central repository? They will get there eventually. The key thing is that patches can be 'batched' for review/application and not spoon-fed one by one. Look at what is going on at kernel.org -- a feature can be implemented as a series of 10 or even 100 patches -- imagine how much time it would take to submit and review each patch sequentially. Though I've write access to the fpc repository ;) I've also several local branches (actually plain copies of my fpc checkout) with some changes in it. But this is limited to one change per sub a branch. But if it's not feasible for you, you can still use git-svn, no? I'd like to. Unfortunalely, I use Lazarus on Windows, and git still has some troubles here. BTW: An fpc/lazarus git repository would be really no fun: due to the flaky connection a git clone of a converted repository is from svn.freepascal.org basically not possible, at least not for me from germany. Sorry, I can not parse this sentence. how does a DVCS scale better in this regard for small and medium sized projects (100 developers)? DVCS does not require any central administration to create branches for every developer/feature. It also does not require network connection for doing commits, which is important to some contries/regions where Internet is still not cheap or reliable enough. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] SynEdit patches [Re: TAChart: Request to review/apply patch 12758]
On Thu, Dec 11, 2008 at 23:49, Martin Friebe [EMAIL PROTECTED] wrote: Alexander Klenin wrote: and yet another one for patches to SynEdit (both stalled for about a month now), etc I just saw this, and consequently found your patches on this mailing list too. As for the SynEdit patches (is-link-able), If you can submit them to mantis, I will take them and look at them. Ok, see http://bugs.freepascal.org/view.php?id=12785 Note that I posted two patches, and apparently you only found the older one ;-) My initial approach was not optimal, as you noted, but neither is the second one, and my questions about the best route were not answered. So if you have time and expertise, please read the mail threads mentioned in the bug report and provide me with insight ;-) -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Request to review/apply patch 12758
On Fri, Dec 12, 2008 at 11:39, Paul Ishenin i...@kmiac.ru wrote: Same for Alexander Klenin - if you need to update TAChart very often then ask about write access to svn/lazarus/trunk/components/tachart Yes, it can be a workaround for my particular case, so whom should I ask? In general, though, patch review is a good thing too -- e.g., while applying my latest patch to TAChart, Darius made a compatibility fix, which could be missed if the code went straight to trunk. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TAChart: Request to review/apply patch 12758
On Fri, Dec 12, 2008 at 01:32, Jesus Reyes jesus...@yahoo.com.mx wrote: If it gets applied it has to be temporal and as such, we need a patch for fpc also and another taking in count the patched fpc (but that can wait of course), if the fpc patch doesn't make it, it's unlikely the crack will be commited. Of course, see http://bugs.freepascal.org/view.php?id=12787 I did not produce the patch since it is trivial and will likely become outdated when the time will come to apply it. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mouse Link in SynEdit (only link-able items)
On Fri, Dec 12, 2008 at 02:12, Martin Friebe laza...@mfriebe.de wrote: Alexander Klenin wrote: So if you have time and expertise, please read the mail threads mentioned in the bug report and provide me with insight ;-) I'll look further into it. A few things: - GetHighlighterAttriAtRowColEx may not be the best idea. It can be quite useful to be able to click on words in comments to. (Which works at current). Indeed, I missed that. - The highlighter is overall not the best solution to find linkable text. Because even a valid bit of code, may be unresolvable to codetools. Another way would be to ask codetools them self. Similar like SynEdit calls SourceEditor, which calls SourceNoteBook and then MainIDE.OnSrcNoteBookClickLink line 2952 in ide/main.pp ( see also line 1778: SourceNotebook.OnClickLink := @OnSrcNoteBookClickLink; ) Now _that_ is what I wanted to hear when I started the original thread ;-) Good idea, I attached a new version of patch to the http://bugs.freepascal.org/view.php?id=12785. I should note that I was horrified by the amount of glue code needed to route an event through main form, source notebook, source editor and SynEdit. -- Alexander S. Klenin Insight Experts Ltd. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
