Re: [Lazarus] Mac OS X : Revision 19889 not compiling under 10.4
On Sun, May 10, 2009 at 07:56, 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 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] Watches/Local variables/Registers [Re: IDE UI consolidation (was: Re: lfm as pascal)]
On Thu, May 7, 2009 at 08:56, Martin Friebe 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
Re: [Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Thu, May 7, 2009 at 02:25, Hans-Peter Diettrich 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] IDE UI consolidation (was: Re: lfm as pascal)
2009/5/7 Bogusław Brandys : > 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 Wed, May 6, 2009 at 13:40, Paul Ishenin 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] Lazarus IDE Tools - wiki page
On Thu, May 7, 2009 at 00:02, Graeme Geldenhuys 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)
>>> 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 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] IDE UI consolidation (was: Re: lfm as pascal)
2009/5/6 Mattias Gärtner : >>> 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)
On Wed, May 6, 2009 at 18:28, Graeme Geldenhuys wrote: > On Wed, May 6, 2009 at 2:44 AM, Alexander Klenin 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
[Lazarus] IDE UI consolidation (was: Re: lfm as pascal)
On Wed, May 6, 2009 at 07:48, Mattias Gaertner 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 : > 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] Online LCL docs - Error 404
On Tue, Apr 28, 2009 at 19:39, Vincent Snijders wrote: > > Better use > http://lazarus-ccr.sourceforge.net/docs/lcl/stdctrls/tcustombutton.modalresult.html BTW, this docs page is wrong, ModalResult is not a boolean as it implies. -- 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 19:45, Mattias Gaertner wrote: >> 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. > > Why ' ' and not #10 or #13 or #0? It is by far the most common. Also, unnamed #10 and #13 might indicate platform-dependent line endings usage. >> 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? > > A patch is welcome. http://bugs.freepascal.org/view.php?id=13551 BTW, can you please also review http://bugs.freepascal.org/view.php?id=13501 ? It followed from our previous discussion. -- 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 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] 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] "Figures" in code explorer
On Mon, Apr 20, 2009 at 21:27, Martin Friebe 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
Re: [Lazarus] "Figures" in code explorer
On Mon, Apr 20, 2009 at 20:50, Mattias Gaertner 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 10:19, Mattias Gaertner 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] "Figures" in code explorer
On Mon, Apr 20, 2009 at 09:29, Mattias Gaertner 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 01:28, Paul Ishenin 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 01:10, Marco van de Voort 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 Sun, Apr 19, 2009 at 22:02, Mattias Gaertner
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
[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] Repository commit statistics. :-)
On Wed, Apr 15, 2009 at 22:37, Graeme Geldenhuys 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 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 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] Interesting TextMate and RedCar feature
2009/4/15 Mattias Gärtner : > in place renaming can be done for simple things like an identifier in a script > or with a *lot* of effort in bigger scopes. IMO it can be done for live > templates but not for real 'renames'. I think auto-renaming makes sence for only local variables, generally for the cases where all instances fit into the screen. Otherwise it may come as a nasty surprise to a user. Anyway, the linked demo seems to be about a very particular case of auto-renaming, Notice that identifiers are different, though with the common structure. An actual analogue for FPC/Lazarus would be an option to rename 'TMyClass' to 'TMyNewClass', while simulatneously updating variable names lile 'FMyClass', 'AMyClass', 'myClass'. -- 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 Wed, Apr 15, 2009 at 03:30, Florian Klaempfl wrote: > Graeme Geldenhuys schrieb: >> On Tue, Apr 14, 2009 at 3:31 PM, Florian Klaempfl >> wrote: >>> And what if someone realizes that one patch is missing? >> >> Well, is that not what "release canditate" or stable branches are for? >> Users at least expect updates and backports of patches in a branch. >> Then test, test and test! Once everything is working, create a release >> tag based on that branch. > > If you think it's so easy, be our guest to coordinate an fpc release :) I think this particular case is nothing to worry about. It is clear that tag moving is an exception made due to unfortunate coincidence. As a general issue, IMO the "Discussion" section of git-tag manpage summarizes the case for correct tag usage very nicely ;-) http://www.kernel.org/pub/software/scm/git/docs/git-tag.html -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Modified .po files after each build
On Wed, Apr 15, 2009 at 00:18, Graeme Geldenhuys wrote: > Hi, > > Recently it started to happen that every time I build Lazarus IDE > after a clean checkout, after the build I have many modified .po > files. Yes, this bothers me too. Additionally, many makefiles aloso get modified. -- 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 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] Notes on 'remove unused units' codetool
On Sun, Apr 12, 2009 at 16:26, Mattias Gaertner 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
[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] 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 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
Re: [Lazarus] update [Re: Code Folding mess and Code Divider feature]
On Sat, Apr 11, 2009 at 01:56, Martin Friebe 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] Hints usability
On Sat, Apr 11, 2009 at 07:53, Alexander Klenin wrote: > On Sat, Apr 11, 2009 at 07:17, Christian Iversen > 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] Hints usability
On Sat, Apr 11, 2009 at 07:17, Christian Iversen
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] update [Re: Code Folding mess and Code Divider feature]
On Fri, Apr 10, 2009 at 22:10, Martin Friebe 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] update [Re: Code Folding mess and Code Divider feature]
On Mon, Apr 6, 2009 at 08:45, Martin Friebe wrote: > Configuration has now been added. So you can fine tune which element you > like to be able to fold, and which elements you don't. I played with it, and it generally works very well, thanks ;-) Some minor issues: 1) When 'Code folding' is unchecked, other controls should probably be disabled. Also, 'Enable code folding' is IMO a better name. 2) Language dropdown should probably have a label. 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? 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. -- 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 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] Git mirror of Lazarus SubVersion repository is available
On Fri, Apr 10, 2009 at 03:30, Graeme Geldenhuys wrote: > On Thu, Apr 9, 2009 at 5:55 PM, Henry Vermaak 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
[Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
2009/4/9 Mattias Gärtner :
>> 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] Large program size - 1.8 MB for empty GUI project
On Wed, Apr 8, 2009 at 18:36, Mattias Gaertner 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
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
On 2009-04-07, Mattias Gärtner wrote: >> I strongly agree with Alexey here. The bug in FPC should be fixed and >> Lazarus source updated to remove unnecessary units from 'uses' >> clauses. >> >> Not so much for executable size, but for mantainabilty of the source. > > Yes. Avoid uses sections in implementations. This golden rule is true since > the > start of FPC. > Using implementation uses sections is asking for trouble. Eh... you mean 'no'? Because I argue _for_ 'uses' sections in implementation. 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 2009-04-03, Marc Weustink wrote: > Alexey S. Smirnov wrote: >> SmartLink problem is quite simple. It seems that all units, mentioned in >> "Interface->Uses" section will be fully linked. Only units mentioned in >> "Implementation->Uses" section can be checked during SmartLink. >> So, to enhance linking process and to reduce binary size we shell >> check all Interface sections of all LCL units to reduce units list. > > We have all units listed in the interface section to avoid unit circles. > This is needed since the compiler will fail to compile the LCL sooner > or later if there are to many circles. I strongly agree with Alexey here. The bug in FPC should be fixed and Lazarus source updated to remove unnecessary units from 'uses' clauses. Not so much for executable size, but for mantainabilty of the source. -- 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 wrote: > On Thu, Apr 2, 2009 at 12:28 PM, Mattias Gaertner > 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 05:36, Jesus Reyes wrote: > I implemented BoxRect method in grid in r19156, initally public, needs > testing. I do not use this method, so I do not know how important it is, but it seems that Delphi returns "empty rect" (0, 0, 0, 0) if arguments are either unsorted or totally outside viewing area. Additionally, I would suggest to use IntersectRect function for computing intersection instead of open-coding it. -- 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 wrote: > --- El dom 29-mar-09, Carlos German Tejero > 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] Clipboard.HasFormat issue
On Sun, Mar 29, 2009 at 07:43, Michael Van Canneyt wrote: > The HasFormat() function calls EnumClipboardFormats, among other things. > I'll investigate how it behaves if I call EnumClipboardFormats directly. While at it, could you reproduce http://bugs.freepascal.org/view.php?id=11548 ? I still get this error occasionally, and from my investigation it has something to do with HasFormat / EnumClipboardFormats and timing. -- 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 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 Fri, Mar 27, 2009 at 10:02, Hans-Peter Diettrich 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 11:22, Hans-Peter Diettrich 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 00:22, Paul Ishenin 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 Thu, Mar 26, 2009 at 23:07, Marc Weustink 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 Thu, Mar 26, 2009 at 18:59, Marco van de Voort 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 17:56, Hans-Peter Diettrich 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 00:23, Marco van de Voort wrote: > > Since we are close to 20 stringtypes + conversions now, I doubt that this is > really the problem. Yes, I agree that the string types in FPC are a mess, and judging by recent discussion, they are planned to became worse. It is fortunate that Lazarus introduces a little bit of sanity here. > What problem does "for in" really solve? Lack of iterators. > Is having 6 levels of information > hiding (private,public,strict protected, strict private,protected,published) > or are the strict* ones just to stop the whining of people that come from > other languages? No, it is not necessary, but handy sometimes. I agree that these are not a big deal, and FPC can live without them quite fine, but they do not break anything either. > What is the function of being able to add methods to records? Not much, I agree, given the existence of objects. It would be better to do that instead of introducing 'object' keyword, but that decision was made back in the days of Borland Pascal. > What is the real use of duplicating const type and var as nested variants > inside classes? Namespace management. > Have a look at: > http://www.stack.nl/~marcov/delphilater.txt Thanks, that is interesting discussion. I will post my thoughts on that in a separate mail. > The old rule used to be that > - it should make something possible that is not doable otherwise. Like strict private/protected? > - _or_ it should be a construct that is used so much that timesavings are > noticable Like for ... in? > And string-case for my feeling belongs in neither. It is just about racking > up bullet lists in language wars. Well, there is another important design principle. It is sometimes called "orthogonality" -- it means that existing language features can be combined in any way, with as little limitation as possible. Since string was introduced as built-in "scalar" type with defined equality, lack of 'case' support can be viewed as a design bug. -- 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 Tue, Mar 24, 2009 at 22:40, Florian Klaempfl 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 Tue, Mar 24, 2009 at 07:03, Marco van de Voort wrote: > Well, you can nearly impossibly miss the sliding slope there. First just > strings, then hashing to speed it up, then wildcards, then demand for regex > etc. This is generic argument applicable to any language feature. "Sliding slopes" are everywhere, so the safest course of action is not to move at all. This is what I am ranting about, excessive conservatism leading to a stagnation. > And everytime the same references to other interpreted languages that do such > things. Eh, "other interpreted"? Pascal is compiled, as you surely know. > In general the Wirthian philosophy was limitation to the basics, and > Pascal's direct successor language (modula2) is actually smaller. I already answered this. Modula and Oberon are a direct successors of Pascal, but so is Object Pascal. For better or worse, Object Pascal has taken another course, and I don't think it is a good move to retrofit minimalist philosophy to Object Pascal now. Otherwise, we should start by removing built-in Strings -- they are against this philosophy too (and were criticized for that). -- 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] Help to find cause of crash in IDE after revision 19044
BTW, perhaps it would be easier to use IRC? I'm _Ask_ on #lazarus-ide. -- 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 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
On Sun, Mar 22, 2009 at 22:03, Luiz Americo Pereira Camara wrote: Ok, I have installed VTV (by the way, it needs not only LCLExtensions, but MultiLog package). I can reproduce the issue, but this time I am inclined to say this is VTV bug, since similar properties, like StringGrid.Columns and SdfDataSet.FieldDefs work fine. Also, if I disable IsIntresting function, the IDE stops crashing, I can still see anomalies with Columns property -- for example, TreeView part of object inspector displays garbage after invoking Columns editor for VTV component. > The problem is that Columns is a property of Header > (TVirtualStringTree.Header.Columns). > > Previously Columns where streamed as a direct child of > TVirtualStringTree using DefineProperties method as a workaround to > Delphi bug. I removed this hack and now Columns is streamed as child of > Header. > Is there any method, other than DefineProperty, that can change a > property hierarchy? > > FYI Columns.GetOwner returns the Header instance. Streaming child properties correctly is, unfortunately, undocumented and clumsy process. See e.g. r18774 for a sample of changes required (note overrides for TBasicChartSeries class). If you will use that code, take into account a possible differences in requirement -- TChart displays its series as child nodes in Object Inspector's treeview. You might or might not want this for VisualTreeView columns. -- 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 20:37, Luiz Americo Pereira Camara 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] Easiest way to "case" strings
On Sun, Mar 22, 2009 at 18:07, Hans-Peter Diettrich wrote: > Delphi 2 (or 3?) was the last version with a grammar for the language. > After that version the supplied "OPL grammar" is neither correct nor > complete, the language is no more LL(1). It is historically interesting, but does it really matter? The important characteristic of the syntax is its convenience to humans, and if that requires slightly more work from the compiler, then so be it. AFAIK, most modern compilers moved to recursive descent parsers due to similar reasons. >> While I deeply respect Wirth's contributions to programming language design, >> I think Modula and especially Oberon are not the best sources for >> inspiration. > I dare to disagree. Present your examples then ;-) >> 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 ;-) > > Please note that I don't ask for Modula or Oberon compatibility, even if > it were fine to have such modes. Of course, I understand that. My examples were aimed not at direct compatibility, but the spirit of minimalism that was the driving force of the Modula/Oberon design. Besides that, what useful features do you think Object Pascal / FPC might take from Oberon? -- 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 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
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
2009/3/22 Luiz Americo Pereira Camara : > Starting from revision 19044, when i put a TVirtualStringTree control in a > form the IDE crashes (see attached log). I could not reproduce with other > controls and i'm not sure if the problem is in the changes introduced in > 19044 or if just revealed a TVirtualStringTree bug. > > The VTV code can be obtained from: > https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/virtualtreeview-new > It requires LCLExtension package: > https://luipack.googlecode.com/svn/trunk/lclextensions > > > Any help is appreciated. This code was introduced recently by me. This is either my bug or yours, depending on how we decide ;-) > $00641C2A TLISTPROPERTYEDITOR__GETELEMENTCOUNT, line 3394 of propedits.pp > $0064218A TLISTPROPERTYEDITOR__DOSAVEELEMENTS, line 3501 of propedits.pp > $00641EBD TLISTPROPERTYEDITOR__SAVEELEMENTS, line 3436 of propedits.pp > $006426D1 TLISTPROPERTYEDITOR__INITIALIZE, line 3608 of propedits.pp > $0064AEEC REC, line 6817 of propedits.pp > $0064ACE2 ISINTERESTING, line 6832 of propedits.pp > $0062979D TOICUSTOMPROPERTYGRID__EDITORFILTER, line 2169 of > objectinspector.pp This code does: ed := edClass.Create(nil, 1); try ed.SetPropEntry(0, A.GetComponent(0), propList^[i]); ed.Initialize; note the "nil" hook parameter. So you have to do one of the following: 1) apply the attached patch (but note that the hook it will pass might be not the right one -- I am not sure) 2) check for nil hook in your Initialize function 3) explain to me how to obtain the correct hook ;-) If (1) helps, please apply the patch to Lazarus, if you have commit rights. -- Alexander S. Klenin Index: propedits.pp === --- propedits.pp (revision 19044) +++ 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(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] Easiest way to "case" strings
On Sun, Mar 22, 2009 at 08:57, Howard Page-Clark wrote: > IndexStr() and AnsiIndexStr() were introduced in the then new StrUtils > unit that shipped with BDS 3.0 (Delphi 2005). There is no StrUtils > unit, or access to these functions in my Delphi 5 installation. Are you sure? I did not found Delphi 5 installation, but managed to install Delphi 6 -- StrUtils unit is at C:\Program Files\Borland\Delphi6\Source\Rtl\Common\StrUtils.pas and it does contain AnsiIndex* functions. Copyright header says "1995-2001" which I think dates at least the unit itself all the way back to Delphi 1. -- 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 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] Easiest way to "case" strings
2009/3/22 Michael Van Canneyt : > Even so, there are some serious issues with a string 'case' as a language > construct: > - What about encodings ? Nothing about them, just compare byte-by-byte, as usual string comparison do. > - Should it be case sensitive or not ? Of course no. > I don't think that these can be solved in a satisfying manner on a language > level. Generally, I feel that FPC is a bit too conservative. I understand that a healthy dose if skepticism is a good thing for language design, but IMHO it was taken too far lately. -- 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 00:28, Lee Jenkins wrote: > Can anyone say why there is no string case statement in Object Pascal? I've > always wondered about this as sometimes it hard to avoid 10-20 If..then..else > if statements. I'd say it is because nobody contributed it ;-) > Would the compiled code of a string case statement even be any more efficient > or > is the benefit mostly in code readability? Both. It can be implemented as prefix tree, giving O(MaxLength) instead of O(MaxLength*NumberOfCases) time _and_ a much better readability/maintainability. -- 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 Sat, Mar 21, 2009 at 23:37, Marc Weustink wrote: > At the time I wrote StringCase, AnsiIndexStr / AnsiIndexText were > unknown to me. I wonder even if they existed at that time. When did > delphi introduce them ? (just a coincidence, I just "discovered" them > last week) > They definitely exist in Delphi 7. Google search suggests they were introduced around Delphi 5. -- 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 Sat, Mar 21, 2009 at 20:03, Vincent Snijders wrote: > Reenen Laurie schreef: >> Hi, >> >> I'm sure most of you have had this... is there an easy way to have a >> case statement that's based on "strings" rather than ordinal types. Is >> there somewhere a shortcut? >> > > You can use stringcase: > http://lazarus-ccr.sourceforge.net/docs/lcl/lclproc/stringcase.html > > Unfortunately without example. It is used in the Lazarus sources, so > maybe you find out how to use it from there. Hm, this function duplicates AnsiIndexStr / AnsiIndexText which are Delphi-compatible. Is there a reason for its existence? -- 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 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 Sat, Mar 14, 2009 at 02:03, Martin Friebe 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] Code Folding mess and Code Divider feature
On Fri, Mar 13, 2009 at 22:16, Martin Friebe 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] How about new State in Mantis ?
On Thu, Mar 12, 2009 at 05:45, Marc Weustink 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 :
> 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 Thu, Feb 26, 2009 at 22:17, Lee Jenkins 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] Fw: New Features for source editor
On Wed, Feb 25, 2009 at 04:41, Lee Jenkins 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] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 03:52, Florian Klaempfl 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] TAChart child/parent control integration: request for review
On Sat, Feb 21, 2009 at 22:55, Luca Olivetti 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=diff&rev2=9&rev1=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:17, Florian Klaempfl wrote: >> On Sat, Feb 21, 2009 at 02:28, Florian Klaempfl >> 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 child/parent control integration: request for review
On Sat, Feb 21, 2009 at 02:23, Florian Klaempfl 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 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
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 01:09, Florian Klaempfl 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
[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] Debugger problems
On Fri, Feb 20, 2009 at 22:44, Marc Weustink 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
Re: [Lazarus] Debugger problems
On Wed, Feb 18, 2009 at 22:03, Alex du Plessis 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] TAChart: Delphi mode removal planned
On Wed, Feb 18, 2009 at 17:51, Alexander Klenin wrote:
> On Wed, Feb 18, 2009 at 16:27, waldo kitty 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
Re: [Lazarus] TAChart: Delphi mode removal planned
On Wed, Feb 18, 2009 at 16:27, waldo kitty 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] 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
[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
[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
Re: [Lazarus] Space preference for assignment
On Mon, Feb 9, 2009 at 11:17, Hans-Peter Diettrich 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 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 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
