Hi,

After lots of browsing and debugging I figured out how keyboard shortcuts are handled in Lazarus code. So complicated! They are just keypresses.

My goal was to get Form Designer receive the undo-command. Currently it is sent only to source editor. There are already Undo and Redo commands mapped under CommandCommand (!?) category. They are kind of global commands which could be used in many places but the supporting code was not ready. So, I modified TmainIDE.DoCommand + some other methods, effectively implementing one ToDo item:

  // ToDo: Send Command to form editor/designer

Copy, Cut and Paste are logically similar commands, meaning that they can be used in many places and they use the same shortcuts everywhere. However they were implemented differently. One set of commands was under source editor category and one set under form designer category. After my change there is only one set under CommandCommand (!?) category and they are forwarded to the right editor correctly.

There are now skeleton methods DoUndo and DoRedo in Designer and they are called properly. Rest of the undo functionality should be easy now... :-)

I hope this patch is accepted already although it doesn't bring any new functionality or even fix bugs. It enables future work with Designer Undo and also cleans the shortcut dispatch code. And, it decreases the total amount of code unlike most code improvements.

I created issue # 0015481 with a patch.

Juha Manninen

P.S.

There was discussion of const array syntax in another thread. I really could use a new syntax in IDECommands unit, like:
const
IDECommandStrs: array[0..] of TIdentMapEntry = (

The array has about 200 elements. During testing I added and removed items from it and then tried to compile. Uhhhh...
Counting the elements should really be the compiler's work, not mine.

Should be Groundwork, not Groudwork.
Spell checking isn't working in title.

Juha

+1

At least the error message could mention the actual number of entries, as found in source code. This doesn't require any change to the language or compiler, only an change to the error message generation.

DoDi

Hans-Peter Diettrich wrote

At least the error message could mention the actual number of entries, as found in source code. This doesn't require any change to the language or compiler, only an change to the error message generation.

lol, something like this?! :) sorry, my vds is down can't publish the whole patch...

Index: ptconst.pas
=================================================================== --- ptconst.pas (revision 14581)
+++ ptconst.pas (working copy)
@@ -843,14 +843,25 @@

           else if try_to_consume(_LKLAMMER) then
             begin
               hr.offset:=0;

- for i:=def.lowrange to def.highrange-1 do
- begin
- read_typed_const_data(hr,def.elementdef);
- Inc(hr.offset,def.elementdef.size);
- consume(_COMMA);
- end;
- read_typed_const_data(hr,def.elementdef);
- consume(_RKLAMMER);
+ try
+ //for i:=def.lowrange to def.highrange-1 do
+ i:=def.lowrange;
+ while i<def.highrange do
+ begin
+ read_typed_const_data(hr,def.elementdef);
+ Inc(hr.offset,def.elementdef.size);
+ consume(_COMMA);
+ inc(i);
+ end;
+ except
+ Message2( scan_f_not_enough_const_array_elements, intToStr(i), IntToStr(def.highrange-def.lowrange+1));
+ end;
+ read_typed_const_data(hr,def.elementdef);
+ try
+ consume(_RKLAMMER);
+ except
+ Message1( scan_f_too_many_const_array_elements, IntToStr(def.highrange-def.lowrange+1));
+ end;

             end
           { if array of char then we allow also a string }
           else if is_char(def.elementdef) then

Index: msg/errore.msg
=================================================================== --- msg/errore.msg (revision 14581)
+++ msg/errore.msg (working copy)
@@ -362,6 +362,10 @@
scan_w_multiple_main_name_overrides=02086_W_Overriding name of "main" procedure multiple times, was previously set to "$1" % The name for the main entry procedure is specified more than once. Only the last
% name will be used.
+scan_f_not_enough_const_array_elements=02087_F_Not enough elements in constant array. Only $1 of $2 are delcared
+% Only part of array of constant is declared
+scan_f_too_many_const_array_elements=02088_F_Too many constant array elements. Only $1 required
+% Only part of array of constant is declared
% \end{description}

ok, here's the full patch: http://havefunsoft.com/fpc/errormsg.zip

thanks,
dmitry

Wow, that would be surely better than the current message: ')' expected but ',' found (or something).
It seems to be reasonably easy to implement.

But still it feels little half-baked. The real solution would be to change language syntax. Do you have an idea how much work the compiler (parser and such) would need to implement the proposed syntax? I feel an itch already to study FPC's code to find out.

Juha Manninen

[...]

yes, something alike.

IMO it's a stupid idea to mix up syntax and semantics. Both the array dimension expression (in the declaration part) and the number of supplied entries (in the definition part) can be parsed and determined independently, based only on syntax. Then a semantical check can be appended, whether both amounts are different, and finally it's sufficient to show in the error message:
... expected $1 values, found $2.

This procedure also would eliminate the need for any error recovery, required otherwise to skip over unexpected additional entries in the actual source code.

I didn't want to go into implementation details here, since it's an FPC issue, not a Lazarus one.

DoDi

:-)

But still it feels little half-baked. The real solution would be to change language syntax. Do you have an idea how much work the compiler (parser and such) would need to implement the proposed syntax?

IMO a syntax change is not necessary, and it wouldn't help when the array dimensions are described by an enumerated type, e.g. array[TMyEnum] of ...

DoDi

Sorry but I couldn't follow your thoughts here.
Earlier in this thread you gave support for this new syntax:

const
  IDECommandStrs: array[0..] of TIdentMapEntry = (

So what about semantics. The semantics here is that you don't need to define the upper bound for a const array.
From another message:

IMO a syntax change is not necessary, and it wouldn't help when the array dimensions are described by an enumerated type, e.g. array[TMyEnum] of ...

Right, when using enumerated type there is no problem. The problem comes when the number of items in an array is not relevant, or is not logically limited anyhow.
I copy the whole IDECommandStrs array below to demonstrate the problem. Original upper bound was 201. Then I removed 3 items from the end of the array (+ made other changes in code) and tried to compile. Uhh... Then I had to go 200 lines up in code to change the upper bound. I calculated like: "I removed 3 items, 201 - 3 ... must be 198." Then I deleted "201" and typed "198". Then I could compile the code. Then I added the original entries again to test more. Again I forgot to change the bound and tried to compile. Uhh...
I went 200 lines up in code again to change the upper bound. I deleted "198" and typed "201". Then the code compiled. I changed this array many times, sometimes forgetting the bounds and sometimes not, but even if I didn't forget it I still had to move 200 lines up in code to change the upper bound. I was pissed off!
This syntax is SOOOO from 1970. Only good thing is that you don't need to edit const arrays very often but when you do it is really irritating!

I even started studying FPC's own code to see if I could fix it.

So, the error message you proposed does not solve the problem. In a way it would make it more irritating because the compiler then reminds you about how easily it can count the elements but still forces you to type the number.

About semantics, we could make an analogy to enum type definitions here. You
can write:
type
  TMyEnum = (meFirst, meAnother, meYetanother);

without defining bounds.

Juha Manninen

-----------------------

const
IDECommandStrs: array[0..198] of TIdentMapEntry = (

    // search
    (Value: ecFind;                     Name: 'ecFind'),
    (Value: ecFindAgain;                Name: 'ecFindAgain'),
    (Value: ecFindNext;                 Name: 'ecFindNext'),
    (Value: ecFindPrevious;             Name: 'ecFindPrevious'),
    (Value: ecReplace;                  Name: 'ecReplace'),
    (Value: ecIncrementalFind;          Name: 'ecIncrementalFind'),
    (Value: ecFindProcedureDefinition;  Name: 'ecFindProcedureDefinition'),
    (Value: ecFindProcedureMethod;      Name: 'ecFindProcedureMethod'),
    (Value: ecGotoLineNumber;           Name: 'ecGotoLineNumber'),
    (Value: ecFindNextWordOccurrence;   Name: 'ecFindNextWordOccurrence'),
    (Value: ecFindPrevWordOccurrence;   Name: 'ecFindPrevWordOccurrence'),
    (Value: ecFindInFiles;              Name: 'ecFindInFiles'),
    (Value: ecJumpBack;                 Name: 'ecJumpBack'),
    (Value: ecJumpForward;              Name: 'ecJumpForward'),
    (Value: ecAddJumpPoint;             Name: 'ecAddJumpPoint'),
    (Value: ecViewJumpHistory;          Name: 'ecViewJumpHistory'),
    (Value: ecJumpToNextError;          Name: 'ecJumpToNextError'),
    (Value: ecJumpToPrevError;          Name: 'ecJumpToPrevError'),
    (Value: ecProcedureList;            Name: 'ecProcedureList'),

    // search code
    (Value: ecFindDeclaration;          Name: 'ecFindDeclaration'),
    (Value: ecFindBlockOtherEnd;        Name: 'ecFindBlockOtherEnd'),
    (Value: ecFindBlockStart;           Name: 'ecFindBlockStart'),
    (Value: ecOpenFileAtCursor;         Name: 'ecOpenFileAtCursor'),
    (Value: ecGotoIncludeDirective;     Name: 'ecGotoIncludeDirective'),
    // edit selection
    (Value: ecSelectionUpperCase;       Name: 'ecSelectionUpperCase'),
    (Value: ecSelectionLowerCase;       Name: 'ecSelectionLowerCase'),
    (Value: ecSelectionTabs2Spaces;     Name: 'ecSelectionTabs2Spaces'),
    (Value: ecSelectionEnclose;         Name: 'ecSelectionEnclose'),
    (Value: ecSelectionComment;         Name: 'ecSelectionComment'),
    (Value: ecSelectionUncomment;       Name: 'ecSelectionUncomment'),
    (Value: ecSelectionSort;            Name: 'ecSelectionSort'),
    (Value: ecSelectionBreakLines;      Name: 'ecSelectionBreakLines'),
    (Value: ecSelectToBrace;            Name: 'ecSelectToBrace'),
    (Value: ecSelectCodeBlock;          Name: 'ecSelectCodeBlock'),
    (Value: ecSelectWord;               Name: 'ecSelectWord'),
    (Value: ecSelectLine;               Name: 'ecSelectLine'),
    (Value: ecSelectParagraph;          Name: 'ecSelectParagraph'),
    (Value: ecSelectionConditional;     Name: 'ecSelectionConditional'),
    (Value: ecToggleComment;            Name: 'ecToggleComment'),
    // insert text
    (Value: ecInsertCharacter;          Name: 'ecInsertCharacter'),
    (Value: ecInsertGPLNotice;          Name: 'ecInsertGPLNotice'),
    (Value: ecInsertLGPLNotice;         Name: 'ecInsertLGPLNotice'),
    (Value: ecInsertUserName;           Name: 'ecInsertUserName'),
    (Value: ecInsertDateTime;           Name: 'ecInsertDateTime'),
    (Value: ecInsertChangeLogEntry;     Name: 'ecInsertChangeLogEntry'),
    (Value: ecInsertCVSAuthor;          Name: 'ecInsertCVSAuthor'),
    (Value: ecInsertCVSDate;            Name: 'ecInsertCVSDate'),
    (Value: ecInsertCVSHeader;          Name: 'ecInsertCVSHeader'),
    (Value: ecInsertCVSID;              Name: 'ecInsertCVSID'),
    (Value: ecInsertCVSLog;             Name: 'ecInsertCVSLog'),
    (Value: ecInsertCVSName;            Name: 'ecInsertCVSName'),
    (Value: ecInsertCVSRevision;        Name: 'ecInsertCVSRevision'),
    (Value: ecInsertCVSSource;          Name: 'ecInsertCVSSource'),
    (Value: ecInsertModifiedLGPLNotice; Name: 'ecInsertModifiedLGPLNotice'),
    (Value: ecInsertTodo;               Name: 'ecInsertTodo'),
    (Value: ecInsertGUID;               Name: 'ecInsertGUID'),
    // source tools
    (Value: ecWordCompletion;           Name: 'ecWordCompletion'),
    (Value: ecCompleteCode;             Name: 'ecCompleteCode'),
    (Value: ecIdentCompletion;          Name: 'ecIdentCompletion'),
    (Value: ecSyntaxCheck;              Name: 'ecSyntaxCheck'),
    (Value: ecGuessUnclosedBlock;       Name: 'ecGuessUnclosedBlock'),
    (Value: ecGuessMisplacedIFDEF;      Name: 'ecGuessMisplacedIFDEF'),
    (Value: ecConvertDFM2LFM;           Name: 'ecConvertDFM2LFM'),
    (Value: ecCheckLFM;                 Name: 'ecCheckLFM'),
    (Value: ecConvertDelphiUnit;        Name: 'ecConvertDelphiUnit'),
    (Value: ecConvertDelphiProject;     Name: 'ecConvertDelphiProject'),
    (Value: ecConvertDelphiPackage;     Name: 'ecConvertDelphiPackage'),
    (Value: ecConvertEncoding;          Name: 'ecConvertEncoding'),
    (Value: ecMakeResourceString;       Name: 'ecMakeResourceString'),
    (Value: ecDiff;                     Name: 'ecDiff'),
    (Value: ecExtractProc;              Name: 'ecExtractProc'),
    (Value: ecFindIdentifierRefs;       Name: 'ecFindIdentifierRefs'),
    (Value: ecRenameIdentifier;         Name: 'ecRenameIdentifier'),
    (Value: ecInvertAssignment;         Name: 'ecInvertAssignment'),
    (Value: ecShowCodeContext;          Name: 'ecShowCodeContext'),
    (Value: ecShowAbstractMethods;      Name: 'ecShowAbstractMethods'),
    (Value: ecRemoveEmptyMethods;       Name: 'ecRemoveEmptyMethods'),
    (Value: ecRemoveUnusedUnits;        Name: 'ecRemoveUnusedUnits'),
    (Value: ecFindOverloads;            Name: 'ecFindOverloads'),
    // file menu
    (Value: ecNew;                      Name: 'ecNew'),
    (Value: ecNewUnit;                  Name: 'ecNewUnit'),
    (Value: ecNewForm;                  Name: 'ecNewForm'),
    (Value: ecOpen;                     Name: 'ecOpen'),
    (Value: ecRevert;                   Name: 'ecRevert'),
    (Value: ecSave;                     Name: 'ecSave'),
    (Value: ecSaveAs;                   Name: 'ecSaveAs'),
    (Value: ecSaveAll;                  Name: 'ecSaveAll'),
    (Value: ecClose;                    Name: 'ecClose'),
    (Value: ecCloseAll;                 Name: 'ecCloseAll'),
    (Value: ecCleanDirectory;           Name: 'ecCleanDirectory'),
    (Value: ecRestart;                  Name: 'ecRestart'),
    (Value: ecQuit;                     Name: 'ecQuit'),
    // IDE navigation
    (Value: ecToggleFormUnit;           Name: 'ecToggleFormUnit'),
    (Value: ecToggleObjectInsp;         Name: 'ecToggleObjectInsp'),
    (Value: ecToggleSourceEditor;       Name: 'ecToggleSourceEditor'),
    (Value: ecToggleCodeExpl;           Name: 'ecToggleCodeExpl'),
    (Value: ecToggleFPDocEditor;        Name: 'ecToggleFPDocEditor'),
    (Value: ecToggleMessages;           Name: 'ecToggleMessages'),
    (Value: ecToggleWatches;            Name: 'ecToggleWatches'),
    (Value: ecToggleBreakPoints;        Name: 'ecToggleBreakPoints'),
    (Value: ecToggleDebuggerOut;        Name: 'ecToggleDebuggerOut'),
    (Value: ecViewUnits;                Name: 'ecViewUnits'),
    (Value: ecViewForms;                Name: 'ecViewForms'),
    (Value: ecViewUnitDependencies;     Name: 'ecViewUnitDependencies'),
    (Value: ecViewUnitInfo;             Name: 'ecViewUnitInfo'),
    (Value: ecToggleLocals;             Name: 'ecToggleLocals'),
    (Value: ecToggleCallStack;          Name: 'ecToggleCallStack'),
    (Value: ecToggleSearchResults;      Name: 'ecToggleSearchResults'),
    (Value: ecViewAnchorEditor;         Name: 'ecViewAnchorEditor'),
    (Value: ecToggleCodeBrowser;        Name: 'ecToggleCodeBrowser'),
    (Value: ecToggleCompPalette;        Name: 'ecToggleCompPalette'),
    (Value: ecToggleIDESpeedBtns;       Name: 'ecToggleIDESpeedBtns'),
    (Value: ecViewComponents;           Name: 'ecViewComponents'),
    (Value: ecToggleRestrictionBrowser;  Name: 'ecToggleRestrictionBrowser'),
    (Value: ecViewTodoList;             Name: 'ecViewTodoList'),
    (Value: ecToggleRegisters;          Name: 'ecToggleRegisters'),
    (Value: ecToggleAssembler;          Name: 'ecToggleAssembler'),
    // sourcenotebook commands
    (Value: ecNextEditor;               Name: 'ecNextEditor'),
    (Value: ecPrevEditor;               Name: 'ecPrevEditor'),
    (Value: ecMoveEditorLeft;           Name: 'ecMoveEditorLeft'),
    (Value: ecMoveEditorRight;          Name: 'ecMoveEditorRight'),
    (Value: ecToggleBreakPoint;         Name: 'ecToggleBreakPoint'),
    (Value: ecRemoveBreakPoint;         Name: 'ecRemoveBreakPoint'),
    (Value: ecMoveEditorLeftmost;       Name: 'ecMoveEditorLeftmost'),
    (Value: ecMoveEditorRightmost;      Name: 'ecMoveEditorRightmost'),
    (Value: ecGotoEditor1;              Name: 'ecGotoEditor1'),
    (Value: ecGotoEditor2;              Name: 'ecGotoEditor2'),
    (Value: ecGotoEditor3;              Name: 'ecGotoEditor3'),
    (Value: ecGotoEditor4;              Name: 'ecGotoEditor4'),
    (Value: ecGotoEditor5;              Name: 'ecGotoEditor5'),
    (Value: ecGotoEditor6;              Name: 'ecGotoEditor6'),
    (Value: ecGotoEditor7;              Name: 'ecGotoEditor7'),
    (Value: ecGotoEditor8;              Name: 'ecGotoEditor8'),
    (Value: ecGotoEditor9;              Name: 'ecGotoEditor9'),
    (Value: ecGotoEditor0;              Name: 'ecGotoEditor0'),
    // marker
    (Value: ecSetFreeBookmark;          Name: 'ecSetFreeBookmark'),
    (Value: ecPrevBookmark;             Name: 'ecPrevBookmark'),
    (Value: ecNextBookmark;             Name: 'ecNextBookmark'),
    // compile menu
    (Value: ecBuild;                    Name: 'ecBuild'),
    (Value: ecBuildAll;                 Name: 'ecBuildAll'),
    (Value: ecQuickCompile;             Name: 'ecQuickCompile'),
    (Value: ecAbortBuild;               Name: 'ecAbortBuild'),
    (Value: ecRun;                      Name: 'ecRun'),
    (Value: ecPause;                    Name: 'ecPause'),
    (Value: ecStepInto;                 Name: 'ecStepInto'),
    (Value: ecStepOver;                 Name: 'ecStepOver'),
    (Value: ecRunToCursor;              Name: 'ecRunToCursor'),
    (Value: ecStopProgram;              Name: 'ecStopProgram'),
    (Value: ecResetDebugger;            Name: 'ecResetDebugger'),
    (Value: ecBuildLazarus;             Name: 'ecBuildLazarus'),
    (Value: ecBuildFile;                Name: 'ecBuildFile'),
    (Value: ecRunFile;                  Name: 'ecRunFile'),
    (Value: ecConfigBuildFile;          Name: 'ecConfigBuildFile'),
    (Value: ecInspect;                  Name: 'ecInspect'),
    (Value: ecEvaluate;                 Name: 'ecEvaluate'),
    (Value: ecAddWatch;                 Name: 'ecAddWatch'),
    // project menu
    (Value: ecNewProject;               Name: 'ecNewProject'),
    (Value: ecNewProjectFromFile;       Name: 'ecNewProjectFromFile'),
    (Value: ecOpenProject;              Name: 'ecOpenProject'),
    (Value: ecCloseProject;             Name: 'ecCloseProject'),
    (Value: ecSaveProject;              Name: 'ecSaveProject'),
    (Value: ecSaveProjectAs;            Name: 'ecSaveProjectAs'),
    (Value: ecPublishProject;           Name: 'ecPublishProject'),
    (Value: ecProjectInspector;         Name: 'ecProjectInspector'),
    (Value: ecAddCurUnitToProj;         Name: 'ecAddCurUnitToProj'),
    (Value: ecRemoveFromProj;           Name: 'ecRemoveFromProj'),
    (Value: ecViewProjectSource;        Name: 'ecViewProjectSource'),
    (Value: ecProjectOptions;           Name: 'ecProjectOptions'),
    // components menu
    (Value: ecOpenPackage;              Name: 'ecOpenPackage'),
    (Value: ecOpenPackageFile;          Name: 'ecOpenPackageFile'),
    (Value: ecOpenPackageOfCurUnit;     Name: 'ecOpenPackageOfCurUnit'),
    (Value: ecAddCurUnitToPkg;          Name: 'ecAddCurUnitToPkg'),
    (Value: ecPackageGraph;             Name: 'ecPackageGraph'),
    (Value: ecEditInstallPkgs;          Name: 'ecEditInstallPkgs'),
    (Value: ecConfigCustomComps;        Name: 'ecConfigCustomComps'),
    (Value: ecNewPackage;               Name: 'ecNewPackage'),
    // custom tools menu
    (Value: ecExtToolFirst;             Name: 'ecExtToolFirst'),
    (Value: ecExtToolLast;              Name: 'ecExtToolLast'),
    // option commmands
    (Value: ecRunParameters;            Name: 'ecRunParameters'),
    (Value: ecCompilerOptions;          Name: 'ecCompilerOptions'),
    (Value: ecExtToolSettings;          Name: 'ecExtToolSettings'),
    (Value: ecConfigBuildLazarus;       Name: 'ecConfigBuildLazarus'),
    (Value: ecEnvironmentOptions;       Name: 'ecEnvironmentOptions'),
    (Value: ecReserved1;                Name: 'ecReserved1'), // reserved
    (Value: ecEditCodeTemplates;        Name: 'ecEditCodeTemplates'),
    (Value: ecReserved2;                Name: 'ecReserved2'), // reserved
    (Value: ecCodeToolsDefinesEd;       Name: 'ecCodeToolsDefinesEd'),
    (Value: ecRescanFPCSrcDir;          Name: 'ecRescanFPCSrcDir'),
    // help menu
    (Value: ecAboutLazarus;             Name: 'ecAboutLazarus'),
    (Value: ecOnlineHelp;               Name: 'ecOnlineHelp'),
    (Value: ecReserved3;                Name: 'ecReserved3'), // reserved
    (Value: ecContextHelp;              Name: 'ecContextHelp'),
    (Value: ecEditContextHelp;          Name: 'ecEditContextHelp'),
    (Value: ecReportingBug;             Name: 'ecReportingBug'),
    // designer
    (Value: ecDesignerSelectParent;     Name: 'ecDesignerSelectParent'),
    (Value: ecDesignerMoveToFront;      Name: 'ecDesignerMoveToFront'),
    (Value: ecDesignerMoveToBack;       Name: 'ecDesignerMoveToBack'),
    (Value: ecDesignerForwardOne;       Name: 'ecDesignerForwardOne'),
    (Value: ecDesignerBackOne;          Name: 'ecDesignerBackOne')
  );

Althoug I agree with Juha that in general, it is a good idea to free programmer from the burden of hand-counting const array elements, I have a few notes:

1) Proposed syntax seems somewhat suboptimal. Historically, Pascal used redundancy and keywords to minimize the chance of errors and make diagnostics easier. In that spirit, I think some active indication of arbitrary upper bound is preferable to a mere omission:

IDECommandStrs: array[0..*] of TIdentMapEntry = (
IDECommandStrs: array[0..auto] of TIdentMapEntry = ( IDECommandStrs: array[0..end] of TIdentMapEntry = (

2) We should think through and specify how multi-dimensional arrays should work:
matrix: [1..auto, 1..auto] of Integer = ((1, 2, 3), (4, 5, 6));

I copy the whole IDECommandStrs array below to demonstrate the problem.

[skip]

[skip]

3) Finally, regardless of the preceeding discussion, that IDECommandStrs array seems
like a tiresome and pointless exercise in code duplication. Why not use

function IDECommandStr(ec: TIdentMapEntry): String;
begin
  WriteStr(ec, Result);
end;

instead?

I also miss badly a feature to definitely tell the compiler about arrays, that currently are implemented as C-style compiler magic on pointers. A dynamic array under control of the user could be identified by e.g.:

   MyArray: array[] of TWhatSoEver;

Then the compiler could allow for MyArray[index], and reject error prone MyPointer[index] expressions. Such arrays can be initialized by const expressions (as is), or by New or GetMem by the user. As with the existing semantics, the array indices should be zero based.

2) We should think through and specify how multi-dimensional arrays should work: matrix: [1..auto, 1..auto] of Integer = ((1, 2, 3), (4, 5, 6));

In such cases I would allow automatic dimensions *only* for the first dimension.

DoDi

Maybe it was not available at the moment of implementation?

Best regards,
Paul Ishenin.

IDECommandStrs: array[0..var] of TIdentMapEntry ?

var - stands for "variable number of elements"

thanks,
dmitry

I would vote for "auto". But beside finding a good syntax I am not sure whether it is so easy to implement such automatic border calculation. If the size is defined before the declaration, then the compiler can reserve the required space. With automatic calculation it would have to store the array data somewhere else with more or less infinite (at least unknown) space requirement. I am not sure whether this can be achieved easily and whether it's worth the effort.

2) We should think through and specify how multi-dimensional arrays should work: matrix: [1..auto, 1..auto] of Integer = ((1, 2, 3), (4, 5, 6));

Well, if it works with one dimension it should work with more too. The only problem would be, that after the first dimension is completed for the first time, the found size has to be fixed for all other levels:

matrix: [1..auto, 1..auto] of Integer = ((1, 2, 3), (1, 2, 3), (1, 2, 3));

would be ok but

matrix: [1..auto, 1..auto] of Integer = ((1, 2, 3), (1, 2), (1, 2));

has to be rejected (cause an error).

I wont, since the following would fail:

const
   auto = 10;
   arr: [1..auto] of Integer = (1, 2, 3);
I would go for
   arr: [1..] of Integer = (1, 2, 3);

Marc

I would be happy with any syntax, although I understood that some other Pascal compilers already support syntax: array[0..]

TIdentMapEntry is a record with Value and Name. Unfortunately "Value" is integer and all the constants listed in IDECommandStrs array are defined as const, not enum type.

"WriteStr(Result, ec.Value)" would return a numeric string like IntToStr does.

Now I tested enum type and WriteStr. It actually returns the original definition as string! I didn't know that. Where does the string come from at run-time? RTTI?

The commands in Lazarus are defined in many places, in many units. Then lookup functions (below) are registered (added to some list) and used later. It is actually rather complicated.
Using enums would make the code cleaner. It should be possible to define those constants in different enum types and finally cast to integer when needed.

function IdentToIDECommand(const Ident: string; var Cmd: longint): boolean;
begin
  Result := IdentToInt(Ident, Cmd, IDECommandStrs);
end;
function IDECommandToIdent(Cmd: longint; var Ident: string): boolean;
begin
  Result := IntToIdent(Cmd, Ident, IDECommandStrs);
end;

Regards,
Juha

That's an issue, yes. Although, in this case the constant "auto" could be independend from the keyword "auto". So it would not fail. Instead constant and array size would not be related in any way (although it appears like that).

I would go for arr: [1..] of Integer = (1, 2, 3);

Would be as good as any other. To me it makes sense too.

J?rgen Hestermann wrote

That's an issue, yes. Although, in this case the constant "auto" could be independend from the keyword "auto". So it would not fail. Instead constant and array size would not be related in any way (although it appears like that).

I can't. How compiler will decide whether this is a constant 'auto' or a keyword inside the const declaration?

> I would go for > arr: [1..] of Integer = (1, 2, 3);

Maybe, but this can lead to ocasional errors. What if developer forgot to write the paticular value on which program execution depends.

I would use arr[] of Integer as in C. This would also simplify code porting :)

Best regards,
Paul Ishenin.

Of course. 'auto' was a bad idea. Either 'end', 'var' or some other reserved keyword is preferable.

But also force lower bound to be always zero.
IMHO this is unnecessary restriction, although it might be ok if implemented in addition to the auto-calculated upper bound. I think having to write arr: [0..var] of Integer will not make porting much harder,
especially compared to the horror of manual counting required now ;-)

That's no problem. You also don't have to specify the number of variables or constants in a unit, for preallocation.

More critical are the many possible variations. Without a definite consent to one syntax, odds are good that nothing will be implemented.

DoDi

Well, then it could be made that if the constant is defined, it would be used, otherwise automatic caculation is used.
Nevertheless, even if it works it is not a good idea because it's confusing.

>> I would go for >> arr: [1..] of Integer = (1, 2, 3); Maybe, but this can lead to ocasional errors. What if developer forgot to write the paticular value on which program execution depends.

Then a runtime error would occur. Currently you can forget to add a value *and* the upper bounds too.

I would use arr[] of Integer as in C. This would also simplify code porting :)

I would not like to be forced using zero as starting index. If such changes are made it should be more Pascal-like.

Must confess, I feel "arr:[0..end] of " makes more sense to me than use of "var" or "..]" The latter suggests something forgotten or a typo.

Pascal isn't about forgetting things or typos, indeed one of the reasons it is the language it is, is because of it's clarity and attention to overall readability. Yes, there are some peculiarities to do with pointer dereferences, but generally things are very accessible without prior detailed knowledge.

:shrug:

Just another opinion into the mix..
DSP

Duncan Parsons wrote

Must confess, I feel "arr:[0..end] of " makes more sense to me than use of "var" or "..]" The latter suggests something forgotten or a typo.

I agree that just leaving out the ending limit is against the spirit of Pascal.

I can live with the syntax of MyArray:[0..var] or MyArray:[0..end] but I'd prefer a syntax that does not use a word, such as MyArray:[0..*] or MyArray:[0..?]. That way there is no confusion about a user-defined word and the use of the currently reserved words is not changed. In other words, this is a situation that is exactly why we have punctuation and not the cobol-ish "Declare MyArray to be from 0 to end of TSomeType"!

Since we already have an (dynamic) array syntax without any "[...]" clause, I'd choose an way in between "array", "array[rangetype]" and "array[from..to]", e.g. array[], array[const] or array[*] for arrays with automatic bounds. In detail the "const" keyword is used similarly in argument lists "array of const".

As already mentioned, I do not favor a [from..?] syntax, because then it also should be possible to construct [?..to] arrays, for syntax symmetry. When the array bounds are not named or literal constants, a For loop will have to look like:

   for i := low(MyArray) to high(MyArray) do

so that it doesn't matter which exact values low() and high() really represent in code. That's why IMO a fixed lower bound of zero does no harm. Any other loops, with fixed bounds, will either fail at compile time or - even worse - produce wrong results, when the bounds are changed in the array declaration but not in code.

DoDi

+1

All right, every one is having a go at this, so my suggestion is:

Option 1:

array(0..Some_constant key_word_or_directive ) of ....

So the Key word or compiler directive tells the compiler to create and set "Some_constant" to the number of elements, rather than to expect to find the constant existing already. (Or, if it suits the complier better, require the constant to be defined, just overwrite the value)

The point being that you have a definite instruction to set the value of the bounds, rather than just leaving something out, and you have a constant to use as an upper bound.

Option 2:

As it is just a convenience feature, do it in the IDE. Given

Some_constant = 0;
array(0..Some_constant) of .....

Then have a code completion feature to reset Some_constant to the correct value. (Maybe even write the Some_constant declaration if it doesn't exist, for that matter.)

This has the disadvantage that you have to use the Lazarus IDE (but then, why wouldn't you ?), and the major advantage that no one has to stuff around with the compiler at all - or it's specification or documentation, for that matter. Much better to load conveniences into the IDE and keep the compiler "clean".

Just my 2c worth.

John Sunderland

John wrote

array(0..Some_constant key_word_or_directive ) of ....

Option 1:
Reads much better as

   MyArray: calculated array of TMyType = (value1, value2, ..);

Option 2:
Having the IDE check the length of the array by counting the values and adjusting the upper bounds constant is a perfectly good idea. Like you said, it means the compiler remains intact without any required changes. it also enhances the value of the IDE.

Provided, of course, that it is a manually invoked operation and/or optional setting.

On the zero-lower-bond question: I personally have become totally used to 0 as a lower bound on arrays and use them all the time. I even name the variables used to index into the array XYZOffset since they are offsets from the beginning of the array. So, no problem for me to fix the lower bound at 0!

On the zero-lower-bond question: I personally have become totally used to 0 as a lower bound on arrays and use them all the time.

That reminds me of another problem:
The index type may not only be an integer, it can also be an enumeration type:

type MyEnumeration = (Home,Office,Iland,Remote);
var  MyArray:        array[Home..] of LongInt;

Then you need the first element to determine the type and there may be an overflow of available indixes.

Hi,

I haven't actually got any feedback about my patch, neither here nor in issue tracker. All the discussion was about const array syntax.

Designer Undo should be done in many steps.

1. Forward commands to right places. My patch does that.

2. Undo for move and resize. This should be easy because there is no dependency to other forms or controls. This covers already ~45% of use cases (number taken from my hat).

3. Undo for delete control. This is more difficult because of dependencies and because the deleted control can be a container with more controls in it. This covers another ~45% of use cases. Besides, Undo could really save your day when you delete controls by accident.

4. Rest of it. ~10% of use cases. Attribute changes triggered in different ways. Adding controls. Full undo support in every situation is not necessary, for example when reading / changing binary data in some property.

If I work with this feature I need my patches applied in steps. I have seen that Lazarus SVN gets many patches every day. Development is incremental. I don't want to build some isolated big patch either, which might finally get rejected because it clashes with the project's architecture in some way I didn't notice.
I understood from Mattias G?rtner's mail that he is busy. Is there anyone else that could check IDE related patches?

Currently I would have both time and motivation for open source stuff. Things can change if I get a new job or if my studies become more demanding.

Regards,
Juha Manninen

I have experienced the same frustration many times. Unfortunately, Lazarus uses centralized version control, which effectively prevents
non-core developers from developing sizeable features in reasonable time.

Still, there is a hope for you -- Lazarus has a Mercurial and Git mirrors:

http://wiki.freepascal.org/How_To_Help_Developing_Lazarus#Git_or_Mercurial_mirrors

I advise to use one of them and prepare your feature as a series of patches. This way, you do not have to wait for every patch, but for the whole series, which is much more tolerable.

I guess for lazarus applies the same as for fpc: everybody can get an own branch(es) to work on his stuff.

Hello.

@Alexander:

Still, there is a hope for you -- Lazarus has a Mercurial and Git mirrors: I advise to use one of them and prepare your feature as a series of patches. This way, you do not have to wait for every patch, but for the whole series, which is much more tolerable.

If I make my changes to a mirror DB, how does it help to get them finally to trunk? Maybe Mercurial and Git have features helping with series of patches, I don't know.
I have read about Git architecture and seen a video where Linus praises his Git and criticizes heavily both CVS and SVN.
I never used it myself though.

@Florian:

I guess for lazarus applies the same as for fpc: everybody can get an own branch(es) to work on his stuff.

How? My use of revision control has been quite primitive until now. I need some more info.

Regards,
Juha Manninen

This is the talk from Linus that I mentioned:

http://www.youtube.com/watch?v=4XpnKHJAok8

It is quite funny. He is not the most polite person but the technical points are strong and interesting.

Juha

Just ask one of the lazarus developers to get write access to an svn branch.

If you have, say, 10 patches and each requires a week to get approved and committed,
then you will spend 70 days on the whole feature.
Instead, you can create a patch series in maybe a week or two, and then it may require a couple of weeks for review as a whole. Thus, total development time may be cut in half or more.

Maybe Mercurial and Git have features helping with series of patches, I don't know.

They do -- a whole lot of features.

Juha Manninen wrote

I have read about Git architecture and seen a video where Linus praises his Git and criticizes heavily both CVS and SVN. I never used it myself though.

Be warned, once you try Git, you will never want to use another SCM again! This happened to me, and there was no returning to anything else. :-)

I've written an Introduction to Git article a year ago. That might get you started with the basics and a taster for some cool features it has. Email me in private if you are interested in the article (I can't publish it on the net yet).

BTW:
Linus made some very valid points in that is
really an excellent piece of engineering.

Sorry, I still don't get your idea.

The benefit of many intermediate commits is to allow other developers to test my changes and give feedback, and also to prevent changes from deviating too much from the main code-base thus making merging harder later. I thought it is a central idea of such community driven projects.

I don't see any benefit of creating 10 intermediate patches for some mirror server if nobody tests them.
If the results are finally reviewed as a whole, then I could as well make one big patch in the end. I don't want to do that.

I believe Git has good tools for branches but it doesn't help if nobody "pulls" from my Git branch.

Juha Manninen

It did not happen to me. I spent several days to get reasonably[1] working git repo, so I could use git as a client on the Lazarus svn repo, and I failed.

So, just trying is not enough, you must either be lucky or technical savvy or not using linux or not working with an existing SVN repo or ...

Vincent

[1] OS: windows xp, being able to commit to a master SVN repository, update from svn repository not more than twice as long.

Which developers ?

Marc

As you have already experienced, waiting for review of every commit is very inefficient.
This is even move true in an open-source project, where reviewers are volunteers who might, for example, have only one day per week available for the open-source project. So even if it only takes 10 minutes to review your patch, you might still have to wait a week for it.
Obviously, batching patches makes sense in such an environment.

I don't see any benefit of creating 10 intermediate patches for some mirror server if nobody tests them. If the results are finally reviewed as a whole, then I could as well make one big patch in the end. I don't want to do that.

One big patch is hard or impossible to review.
Look how it is done on LKML or git mailing list

I believe Git has good tools for branches but it doesn't help if nobody "pulls" from my Git branch.

No, you can export patches from git in a traditional format, so pulling from you is not necessary.

2010/1/16 Vincent Snijders :

It did not happen to me. I spent several days to get reasonably[1] working git repo, so I could use git as a client on the Lazarus svn repo, and I failed.

Not to rehash and old thread, but there is a big difference between the "convenience of Git wrapping a SVN repository" and a native true Git repository. With the first option, it is for convenience only (full history, search history, local commits, local branches etc. [1]), but you still loose a huge amount of the true Git features (all the previous features, plus use speed increase in pulling/pushing, much better branch history etc.). So never compare the two usages as the same thing. A native Git repository is very different in functionality.

[1]. Downsides of Git wrapping SVN repository: Slow communication speed, linear history only, etc...

2010/1/16 Alexander Klenin :

One big patch is hard or impossible to review.

Correct, and something I have a real issue with in tiOPF (svn) repository. With Git it is much easier to break such a large feature into smaller chunks with smaller specific "micro" features. With the 'git gui' and 'git commit -i' you can select specific hunks or lines of code which must go into the next commit (and still keep the rest of the changes for later commits) - very different to SVN which pretty much forces a everything or nothing commit.

Look how it is done on LKML or git mailing list

Yes, good examples. There workflow and usage of branches and promoting features is very efficient, and makes releases much easier and stable.

No, you can export patches from git in a traditional format, so pulling from you is not necessary.

Correct, and that is how I contribute patches to Lazarus project. For each bug fixes (mine or testing somebody else), or when implementing new features, I create a "feature" branch, that way I can instantly switch to a clean (trunk) branch if I need to.

> Look how it is done on LKML or git mailing list Yes, good examples. There workflow and usage of branches and promoting features is very efficient,

Fix one, break one :)?

Hi,

Obviously, batching patches makes sense in such an environment.

Right, if I know I am on the right track with my edits. Otherwise, if I miss some dependency in the code or not fully understand the design I could make some mistake.
Then finally, after creating lots of code, the feedback would be like: "Thanks but no thanks. We planned to make it differently." or: "You didn't consider that one detail. Your code must be re-designed."

That is why I wanted feedback.

One big patch is hard or impossible to review. Look how it is done on LKML or git mailing list

Ok, seems like I must learn more about this topic.

Regards,
Juha Manninen

Which developers ?

The ones who know the code base better than me and who have programmed parts of it themselves.

Apparently I don't know the work flow details here. SVN branch maybe?
Or, I will learn some Git next.

Juha Manninen

Hi.

[1] OS: windows xp,

My understanding is that Git is poorly supported in Windows. It is a big limitation of course.

Juha

Support is reasonably, performance isn't, or the performance of git-svn.

Vincent

I understand, but that it is nonsense to recommand git based on reports, reviews on using a native git reporitory to people who want to contribute to Lazarus, because then they have to comminucate to a SVN server somehow. So I admit: "Git is wonderful, as long as you don't want to use it with Lazarus SVN on windows".

Vincent

> Which developers ? The ones who know the code base better than me and who have programmed parts of it themselves.

Well, those who have shell access to the svn server and which create an account on the svn server for you. So you can commit the work you do to your private branch.

2010/1/17 Vincent Snijders :

Not necessarily true. My Lazarus contributions over the last year were all patches generated from my local Git repository wrapping the Lazarus SVN repository. Even though that is not the best use case for Git, it is still much better (for me personally) that using vanilla SVN repositories. Also, I'm a core developer of tiOPF and again, there all my development work is from Git (wrapping the tiOPF SVN repository), and in this case I have commit access to SVN too ('git svn dcommit' command).

As for Git on Windows vs Linux usage. I see no difference between the two and I use Git on both platforms. For Git on Windows, I use the Windows native Git implementation (msysGit), not the Cygwin based one. I know the latter was not very good or popular with Windows users.

2010/1/17 Juha Manninen :

My understanding is that Git is poorly supported in Windows. It is a big limitation of course.

Unlike Vincent, I don't see any problems or limitation or speed issues. [I don't know which Git implementation Vincent uses] I use the msysGit (native Windows) implementation, and not the Cygwin implementation. The latter was know to be slow, but the msysGit implementation is just as fast as far as I can see, compared to the Linux version.

Hello,

I would appreciate some help with getting a Lazarus application running under Linux.
I use the minimal distribution Tiny Core Linux.
My Lazarus application shows graphics and text.
All graphics are shown correctly but the text characters are rectangles.

To get the application running I installed all required libraries (see below).
After installing the libraries I got the message:
run pango-querymodules > '/etc/pango/i386/pango.modules' I ran #pango-querymodules-32 > /etc/pango/i386/pango.modules this created the file but it contains no data, comments only As stated above, the Lazarus application is running fine for graphics but text is presented as rectangles.
The message printed to the console before the GUI starts is:

---------------------------------------------------------------------------- Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0". Xlib: extension "Generic Event Extension" missing on display ":0.0".

(show_fonts:2271): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly.
This probably means there was an error in the creation of: '/etc/pango/i386/pango.modules'
You should create this file by running:
pango-querymodules > '/etc/pango/i386/pango.modules'

(show_fonts:2271): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin'

(show_fonts:2271): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' -----------------------------------------------------------------------------------------

Installed additional libraries:
=====================
libatk-1.0.so.0@
libatk-1.0.so.0.2809.1*
libcairo.so.2@
libcairo.so.2.10800.8
libfontconfig.so.1@
libfontconfig.so.1.4.4*
libgdk_pixbuf-2.0.so.0@
libgdk_pixbuf-2.0.so.0.1800.3*
libgdk-x11-2.0.so.0@
libgdk-x11-2.0.so.0.1800.3*
libgio-2.0.so.0@
libgio-2.0.so.0.2200.2*
libglib-2.0.so.0@
libglib-2.0.so.0.2200.2*
libgmodule-2.0.so.0@
libgmodule-2.0.so.0.2200.2*
libgobject-2.0.so.0@
libgobject-2.0.so.0.2200.2*
libgthread-2.0.so.0@
libgthread-2.0.so.0.2200.2*
libgtk-x11-2.0.so.0@
libgtk-x11-2.0.so.0.1800.3*
libpango-1.0.so.0@
libpango-1.0.so.0.2600.1*
libpangocairo-1.0.so.0@
libpangocairo-1.0.so.0.2600.1*
libpangoft2-1.0.so.0@
libpangoft2-1.0.so.0.2600.1*
libpcre.so.0@
libpcre.so.0.0.1*
libpixman-1.so.0@
libpixman-1.so.0.16.2*
libXcomposite.so.1@
libXcomposite.so.1.0.0*
libXdamage.so.1@
libXdamage.so.1.1.0*
libXfixes.so.3@
libXfixes.so.3.1.0*
libXinerama.so.1@
libXinerama.so.1.0.0*
libxml2.so.2@
libxml2.so.2.7.6*

Any assistance is very welcome.
Thanks, Anthony Vogelaar.

For reviews I personally prefer one unified diff (diff -U 5) of changed code (without code reformatting)
How you get this diff, I don't care. I certainly don't want to look in some other repro. It's simply to much work.

Marc

I use the minimal distribution Tiny Core Linux. My Lazarus application shows graphics and text.

The problem is some missing library or module, related to Pango, but I have no idea which one.
Did you try running other GTK2 programs?
Pango or Tiny Core Linux forums would be better places for this question.

In my opinion, minimal distros like Tiny Core Linux are not suitable for what you are doing now. It is like asking for trouble (which you have got already). GTK2 library + all required libs is a big amount of SW. When you install all that, your system is not so tiny any more. Why not install some mainstream distro with less effort and concentrate on "useful" challenges.

Minimal distros can be useful as a dedicated server. They can revive an old, otherwise obsolete PC.

I also like optimized code but with desktop GUI programs it is a difficult goal. For example, some people use a light, optimized window manager. Then they open Firefox and OpenOffice. After that, who cares if window manager is light and optimized.

Regards,
Juha Manninen

All those who are willing to contribute to Lazarus, and which want to have new or improved features. Like me :-)

DoDi

2010/1/17 Marc Weustink :

I certainly don't want to look in some other repro. It's simply to much work.

[NOTE: I'm not starting another Git vs SubVersion thread, simply explaining for general interest, the difference between a central repository and a distributed repository workflow]

Actually Marc, it wouldn't be much more work than what you already have to do by saving his patch from Mantis or his email, and then having to work through the patch and apply it to your repository to see it in action.

In the case of Git repositories (and probably other distributed SCM's too), both your repository and his repository will have the same development lines. Only differences would be your local changes and his local changes. You would simply have to pull his branch containing the new feature, which will bring back only patch information (not his whole repository) and automatically create that same feature branch in your repository (no reed to save the patch or apply it - Git does that all for you). There will also be NO patch conflicts because his branch would have the same parent in your repository (which normally predates your local changes). You would then simply switch to that branch to see his code or use 'gitk --all' to view his changes (commits) in that feature branch (without switching your current branch). All this would be accomplished with one single command: git pull
<his_repo_name_and_branch>

Hardly much work. But SubVersion being a central repository system, developers only used to SubVersion would probably thing like you - that a distributed SCM is a lot of extra work - which in fact it actually is less effort.

Talking about the amount of work is not talking about differences ;)

I still wonder why the DSCM advocates ignore the possibility of own branches for everybody interested. No need to publish anything: it is published; core developers know if something is committed; things can be easily reviewed; nothing commited can be lost due to central backups; etc.

We can talk about a DSCM if the active number of personal branches exeeds a certain
number (10?, 20?) but currently it causes only pain. And yes, I really feel pain about
completely meaning and useless output like "Updating a3bdad8..fad6345".

Hardly much work. But SubVersion being a central repository system, developers only used to SubVersion would probably thing like you - that a distributed SCM is a lot of extra work

For a small project, I tried once mercurial and learned that it is much more work. One easily gets lost with all those cloned repositories none being naturally canonical. All not mentioning the pain of line feed handling: it felt worse than cvs and git isn't better in this regard: nothing does prevent users from committing and pushing a full diff due to f.... up line feeds.

Nope, since for reviews, I only read the diff. I don't need to see the code in action. As soon as that is OK, typing "patch -p0 < somepatch" isn't the work anymore.
Therefore I need *one* diff and not a bunch of diffs

Marc

Are you going to track all repositories floating around, or wil you stick to trunk ?

Marc

Hi,

Are you going to track all repositories floating around, or wil you stick to trunk ?

Marc, I don't know if there is a misunderstanding but originally I asked for feedback about my patch which I sent using the "officially recommended" way, through bugtracker (issue tracker, Mantis, whatever it is called). My idea was to have feedback to know I am not doing something stupid and then continue editing after that.
Later the discussion spread to revision control systems but I don't see it as a problem here. The problem is more about if somebody has time to check my patches.
My own branch in SVN still sounds good. Who would be able to create it? The same problem of course remains with SVN branch: Who will have time to check it.

And yes, Git seems really cool but I guess it starts to shine with huge projects with hundreds of contributors.

Regards,
Juha Manninen

2010/1/17 Florian Klaempfl :

completely meaning and useless output like "Updating a3bdad8..fad6345".

It's all in the mind - looking at projects like KDE etc r350575 also doesn't tell me much plus you can't even use such large revision numbers as a Windows build number (like many people like to do) because it exceeds the build number value limit. Git generated patches or Git extracting patches from emails or alternative referencing of commits like (HEAD^ or HEAD~15 or '2 weeks ago' etc) makes it just as easy to reference a commit - that's if you really have a mental block against using shortened SHA1 values. I've been using Git for almost a year now and really don't see the issue - yes it was strange in the beginning coming from SubVersion, but that was simply because I was used to incremental numbers. With a DSCM incremental numbers simply cannot be used - something else is required. SHA1 fits the bill perfectly and provides other information to.

For a small project, I tried once mercurial and learned that it is much more work. One easily gets lost with all those cloned repositories none

Probably because Mercurial uses separate directory trees for each branch - Git uses the same directory structure for all branches. Also if you don't name your "feature" branches descriptively, the confusion is your own fault, not the product. Also Git works equally well in small and large projects, single and multiple developer teams.

nothing does prevent users from committing and pushing a full diff due to f.... up line feeds.

Like SubVersion is immune to that! I constantly have to fix EOL meta information or patch a file simply to fix EOL characters in files - all this in SubVersion repositories. (yes I still work on project that use SubVersion) If SubVersion developers don't setup there SVN clients correctly, they can just as easily commit files with incorrect EOL characters.

Why create a fixed array for this?
These items are registered, so you can do:

IDECommandList.FindIDECommand(ecFind).Name

Mattias

2010/1/17 Juha Manninen :

The same problem of course remains with SVN branch: Who will have time to check it.

That is a problem and quite annoying sometimes - but I do understand everybody is busy. I have also created patches before and it simply lies there for months and get forgotten. Unfortunately most of my patches is to fix something in Lazarus that REALLY bugs me.

At least now with my Git managed Lazarus repository, I have various "home improvement" branches. I can which to a clean "trunk" at any time and merge each of my own "home improvement" branches as I need the various features. If nobody else was interested in those fixes or improvements - tough sh*t for them, at least my Lazarus copy is how I like it. :-)

And yes, Git seems really cool but I guess it starts to shine with huge projects with hundreds of contributors.

I really don't understand why people think that? Could you explain why you do? I often write small projects and me being the only developer - Git works perfectly and doesn't get in the works in exactly the same way with big or small projects, 1 or 1000 contributors.

FPC and Lazarus are not KDE and r350575..r350699 is still more descriptive than some useless chars of a hash.

I did not talk about branches, just repositories on different machines.

No, they cannot (well, they can if they are cankered, but not by accident): just install a pre-commit hook and check if properties are set, nobody can commit then with wrong line ending by accident due to missing properties.

2010/1/17 Juha Manninen :

I can't agree more! And that is exactly why I created fpGUI Toolkit project (see my signature for details) - no requirements to large libraries etc, which makes deployment on such small distro no problem at all. As long as you have X11 running, you can run any fpGUI application - no GTK1, GTK2 or Qt required it just needs XLib which comes with X11.

Minimal distros can be useful as a dedicated server. They can revive an old, otherwise obsolete PC.

Or make you current PC feel like it is supposed too - VERY FAST! :-) With todays bloated GUI desktops or OSes, they simply max out current CPU's so you really don't get any speed gain. Install tiny linux distors or Win3.11 or Win95 on today's PC's if you want to see FAST computers.

[disclaimer: In no way am I suggesting your run Win3.11 again, but it is a laugh to see how fast applications of that time run using it on current systems. OS/2 2.1 and OS/2 3.0 absolutely flies on my current system. :-) ]

Hi!

I didn't create the array. It is in unit IDECommands and I just changed it little for my patch. The mapping is used at least for macro recording.

"IDECommandList.FindIDECommand(ecFind).Name"
doesn't return the same name as this array stores. (or how?) The array could be eliminated if Value were enum type instead of const.

I was already thinking of moving all constants in SynEditKeyCmds and IDECommands to one unit and changing them to enum type, and then getting rid of this array and the similar EditorCommandStrs array. "WriteStr" is able to return the string representation of an enum. Is there any fundamental problem against doing so? It would be a logical refactoring because some editor commands are now used globally (for designer) in my proposed patch, so they are in wrong place.

Juha Manninen

2010/1/17 Florian Klaempfl :

... and r350575..r350699 is still more descriptive than some useless chars of a hash.

Such a range on it's own in SubVersion would not mean anything to anybody either! You have no idea what exists (new feature, bug fix etc.) in that range. So how is that different to what Git uses? This is exactly why I say sequential numbers is simply a mind game. Humans are attracted to sequential values - a feeling of order. But in SCM's they really don't tell you much either, without further context. It's all a mind game. ;-)

No, they cannot (well, they can if they are cankered, but not by accident): just install a pre-commit hook and check if properties are set, nobody can commit then with wrong line ending by accident due to missing properties.

So you agree then that out-of-the-box you can screw with SubVersion EOL handling and if not correctly setup it still can and does cause problems. If you wanted, you could also setup pre/post commit hooks in Git (or simply enable EOL handling built into Git). At least with Git you can undo a local commit, fix the EOL issue and recommit before pushing to another repository or merging those changes to a public accessible branch. If a developer blindly commits a file without first self reviewing what he/she changed, that is their bad habits - again don't blame the tool, blame the stupid developer!

When I make changes to code, it often contains trial code or debug code too. So when I commit, I commit specific lines or specific hunks ('git gui' is awesome in this regard). NEVER do I simply commit the whole file without reviewing my changes first!

I know how much happened, when I see some revision numbers, when seeing an FPC revision number, I know approximatly by heart when it was committed etc.

This is exactly why I say sequential numbers is simply a mind game. Humans are attracted to sequential values - a feeling of order. But in SCM's they really don't tell you much either, without further context.

No, it's time saving: I can easily remember fpc svn revision numbers when diffing, merging, fixing bugs etc. due to mnemonics: currently, we're at 14xxx, so I need only to remember no more than three decimal numbers.

It's all a mind game. ;-)

So you use a text editor which doesn't number lines but calculated hashes on them ;)? Great, shall I make an FPC patch for you: my.pas(a56380bd3901,2c): Syntax error
;)?

It has a big advantage: even if you continued to edit the file in the mean time, you get the correct line if it wasn't changed itself.

You make the fault once, then you setup the server properly and nobody will make the fault anymore.

If you wanted, you could also setup pre/post commit hooks in Git (or simply enable EOL handling built into Git).

But I cannot set up it for other developers. For SVN, I did it once 5 years ago on the FPC server and it works for 5 years now.

If a developer blindly commits a file without first self reviewing what he/she changed, that is their bad habits - again don't blame the tool, blame the stupid developer!

1) A good tool helps me to do my work as convinent as possible and helps me to prevent mistakes (that's also why we use pascal and not C: we know that everybody makes faults and that's why we've e.g. range checking and a nut picking compiler)
2) When adding a new file, reviewing doesn't help to prevent line feed mistakes with git

Just keep in mind that the string is used in saving the editor preferences and must be kept stable, so old configs can be read. If you rename the constant, you can decide in the current situation to keep the string the same, but if it is an enum, you cannot.

Vincent

Florian Klaempfl wrote

I know how much happened, when I see some revision numbers, when seeing

No you don't. One patch could have been a one-liner fix, the next patch could have added full .NET support to FPC. So you know two commits happened, but the number two doesn't tell you how much has changed. If I wanted to know how many commits occurred between two commits (God only know why I would want to know that), Git could tell me that too.

Anyway, we are getting way off topic here and it's pointless discussing this further.

Regards,
- Graeme -

This is already a lot more of free info than git provides.

Well, I don't wonder, you always tell us how great git is but at every thing I look, it plainly sucks:
- git svn
- line feed handling (how can I do it failsafe?)
- merging (how do I merge blocking?)
- handling of empty directories
- tortoisegit (ever used tortoisesvn?)
Of course, it's all my fault that I don't see the use of the unix script hackery called git. So you can continue to ignore the concerns and we will continue to use svn :)

El 18/01/2010 8:47, Florian Klaempfl escribi?:

I wanna break a spear in favor to Graeme and his git-svn-crusade. (spanish expression, I do not know if it make sense or sounds good in english language)

I am using git from around 9 months. I need to handle git remote repositories (many thanks Graeme for Lazarus mirror at GitHub), svn remote repositories (for some projects I contribute) and my own projects. I had same issues at begining, I had to download two or three times the same remote svn history to obtain fully history because my fault: I do not read all documentation, so I could not build correct command. At begining I was using windows with cygwin implementation, was a testing compueter, git failed or was very slow, I never test git native implementation at windows and then I switched completly to linux. I do not know current support of Linux I never had any issue, once I read documentation ;-). Never had any issue with endline handling commiting at git remote repos or commiting to svn repos, other developers are at Windows and Mac and never reported that my changes break his builds. Git-svn is as fast as svn as far I can see. I had some local branches that I commit to upstream only the changes I want, very easily and without no problems. I have full history offline (I value this a lot).
I do not use usually gitg or gitk, I prefer command line access, gui is very ugly for me :-) Only when I want to see global state of branches. But when this happens, I prefer 'git rebase master _branch_' and then all changes to master are merged at _branch_ BEFORE local changes to _branch_. Really is like if I created a new branch from master, and merge all changes from _branch_ to new branch, this is very usefull when you prepare a 'git svn dcommit'!

Sumarizing: my developer life was changed a lot when I found git, and changed to a better life.

PS: Sorry for my very bad grammar.

Never had any issue with endline handling commiting at git remote repos or commiting to svn repos, other developers are at Windows and Mac and never reported that my changes break his builds.

Wrong line feeds usually don't break builds but cause full diff changesets and make code review very painfull.

Florian Klaempfl wrote

- git svn

SubVersion support was simply added as a convenience for SubVersion users. Of course it's going to have limitations, because git already pulls of miracles just giving this support to us. SVN only supports SVN, at least Git gives us more. And 'git svn' is limited to the crappy slow speed of SVN
- that's not Git's fault at all.

- line feed handling (how can I do it failsafe?)

You keep mentioning this, but we have Linux and Windows developers and all using Git. We have never noticed this issue or experienced it. I also transport repositories between work and home using a flashdrive and still no issues with line feed handling. You must be special. :)

- merging (how do I merge blocking?)

Git and DSCM's have a different non-linear workflow, so it makes such (SVN) issues obsolete. Simply don't pull or merge that offending branch. It's funny how only FPC (and you) has this issue. The Linux Kernel and Git projects are a lot more complex and fast paced yet never seem to have these issues you mention. Maybe the problem is your workflow.

- handling of empty directories

Git tracks content only. To get want you want is very easy. Simply create a .gitignore file in that "empty directory" and commit it. My repositories have many "empty" directories used for compiled unit or executable output.

And to keep them empty after builds I simply do 'git clean' and Git cleans out all files or directories not tracked by the repository. With SVN you need HUGE Makefiles and scripts etc... :-( At least Git gives me that out-of-the-box.

- tortoisegit (ever used tortoisesvn?)

I much prefer the command line tools (even with SubVersion) - thank you. This allows me to SSH to servers or switch operating systems and still continue working as normal. No need for relearning different tools on different platforms. But for the occasional GUI requirement like selective line/hunk commits or visualizing the repository history etc. I use the built-in GUI tools. gitk and 'git gui' - they are fast and do the job perfectly.

Of course, it's all my fault that I don't see the use of the unix script hackery called git.

Sheezz, you must be using a old version of Git. Git implemented as various scripts was ages ago! 99% of Git is now in the form of shared libraries and executables.

So you can continue to ignore the concerns and we will continue to use svn :)

I'm fine with that. :)

Regards,
- Graeme -

I tried to stay away from the flame, but just could not resist, sorry ;-)

Florian Klaempfl wrote

Well, I don't wonder, you always tell us how great git is but at every thing I look, it plainly sucks: - git svn

Well, I agree it is not the best part, I admit, but it sucks only slightly more then plain svn, since that is where most of "git svn"'s limitations come from.

- line feed handling (how can I do it failsafe?)

http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git In short, set core.safecrlf=true in your gitconfig Most importantly, if you accidentally commit file with wrong line endings, you can fix that
rather easily in git, nut with svn, you are screwed.

- merging (how do I merge blocking?)

That is meaningless concept in git, see e.g.
http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem

- handling of empty directories

Yes, that is a wart, but how many empty directories are there in Lazarus repository?

- tortoisegit (ever used tortoisesvn?)

Not only used, but was an active contributor:
http://www.ohloh.net/p/tortoisesvn/contributors?query=klenin&sort=commits&commit=Update However, I abandoned it in favor of git, and have no regrets ;-) I would recommend using built-in git tools (git gui and gitk) instead or tortoisegit.

Of course, it's all my fault that I don't see the use of the unix script hackery called git. So you can continue to ignore the concerns and we will continue to use svn :)

Well, script hackery is a good thing to many ;-)

I used svn for many projects and still continue to use it for the projects that did not move on (that's three projects now, counting Lazarus). And I liked (and still do), but I found out that there is an even better alternative.
Now, let me list some problems I have with svn:

1) It is slow to the point of being unusable.
Using TortoiseSVN, "Show log" on the root of Lazarus folder takes anywhere from 15 seconds to 2 minutes. (And yes, log cache is on). Diffing a file to see a change introduced by some commit takes from 30 seconds to 5 minutes (especially for gigantic files like main.pp). Both operations are instantaneous (<1 sec) in git.
2) Update is also slow, but less so and git is merely twice as fast, to 50 times.
3) You can not fix a mistake in history. Once I discovered the power of "git commit --amend"
and "git rebase --interactive", I would recommend git based on these two features alone.
4) You can not (easily) commit part of the file.
5) You can not (easily) manage more that one change concurrently, especially if they touch common files.
6) You can not experiment with a feature requiring more than one commit, that is, any non-trivial feature, without a commit access.

Thank you all for your reply.

I want to run a Lazarus GTK2 application within a minimal linux embedded systems with
1 GB flash, 256 MB Ram en 500 MHz VIA cpu.
I searched for live distributions, not writing to flash. Till now I used the Slax distribution.
For a new project it had an unacceptable boot time of 3 minutes = 180 seconds.
I went to Tiny Core Linux running in RAM = fast.

Now my Lazarus application is running on Tiny Core Linux. OS : 23.9 MByte
Libs : 5.1 MByte --> Total 29 MByte
Boot time power-on till grub : 12 sec
Boot time grub till GUI : 25 sec --> total 37 sec Start time Lazarus applicatie 2.8 MB : 7 sec

Boot time improvement 180 --> 37 Sec = 80%

Do you really think a mainstream distribution with fpGUI can beat this?

Anton Vogelaar

=================================================================

Yes, that's indeed the case (but shouldn't a good tool to be able to adapt to our workflow?). Do you volounteer to maintain solely the fixes branch so that we can adapt our workflow to the needs of git ;)? We simply don't have a dedicated maintainer of the fixes branch but everybody helps to keep it up-to-date: if I see that some change cannot be merged, I block it so nobody else wastes it's time looking at it a certain changeset again.

Sheezz, you must be using a old version of Git. Git implemented as various scripts was ages ago! 99% of Git is now in the form of shared libraries and executables.

This doesn't help, it still feels like an ugly hackery.

ajv wrote

Do you really think a mainstream distribution with fpGUI can beat this?

Yes. fpGUI apps are smaller than Qt, GTK or LCL applications. Uses less memory too.

fpGUI now supports Windows desktop OSes, WinCE devices, Linux, Linux/ARM embedded devices and *BSD systems. Installation of fpGUI applications is simply copying the executable and running it - no GUI library (GTK, QT, etc) installations required.

Regards,
- Graeme -

But you need X libraries on Linux, gdi libraries in Windows etc.., On Windows it always exists but not in Linux.

Ido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100118/0e60bca6/attachment.html>

About Git vs SVN
Sorry if i insert my self with my poor English .
But, When we say Linus use GIT and he prefer it, then why we stay using Pascal? And if we started to compare C/C++ with Pascal, we will have the same discusses here and After that we will keep using Pascal, if some one ask me why i am using Pascal or SVN, my answer will be "It is Love".

For me
SVN build to be team source control with central repository, while GIT build to be single local repository, and after that they make replications and improve it,
it is like compare Client Server SQL databases with Local kind database.

The fast and slow depend on the future, i will bet for SVN.

I spent 3 day try to use GIT but no chance to like it.

Florian Klaempfl wrote

Do you volounteer to maintain solely the fixes branch so that we can adapt our workflow to the needs of git ;)?

I already do for FPC and Lazarus - have a look at my repositories on GitHub. The fixes branches in both those projects are "native git" style by using cherry-pick. That means the original commit is simply referenced in the fixes branch which results in complete intact history and much reduced repository size.

What takes Vincent 30 minutes in Lazarus SVN fixes branch takes me around 5 minutes with Git. We timed merge sets before, so it's not values I'm sucking out of my thumb.

Regards,
- Graeme -

Well, you just merge the changesets we figured out :)

ik wrote

But you need X libraries on Linux,

If you install a bare-bones X11 on Linux, you already have the X libraries installed. This is NOT the case for Qt or GTK1/GTK2 based applications which have huge libraries dependencies and are not included in a bare-bones X11 install.

gdi libraries in Windows etc.

You cannot get Windows without GDI - it comes standard.

Regards,
- Graeme -

Yes, most sounds like cvs and the rest is typical fanboy attitude: it's not git's fault but a user fault.

In short, set core.safecrlf=true in your gitconfig

So all other people get it automatically ;)?

Most importantly, if you accidentally commit file with wrong line endings, you can fix that rather easily in git, nut with svn, you are screwed.

Well, usually one notices only if it is pushed/pulled.

> - merging (how do I merge blocking?) That is meaningless concept in git, see e.g. http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem

See my mail to Graeme, then git simply does not fit into FPC's workflow.

I'am also a command line guy (remember, I still use the fpc text mode ide), but I really like tortoisesvn.

DSCM's have their point but as long as they don't handle basic problems of our (FPC in this case) workflow well, they are useless for us.

I started using Mercurial some time ago, and I can say I'm really satisfied with it:
- our company uses svn, but (although I'm svn admin) I constantly need lot of branching and merging and since I do lot of work from home where Internet connection is slow, DVCS was my real need
- I primarily develop on windows, and TortoseHg is really good at its job - I even have Commit dialog opened all the time :-)
- as of line endings, there is win32text extension which conversions; there is also possibility to reject files with non-unix line endings; see http://mercurial.selenic.com/wiki/Win32TextExtension; I cannot comment on quality of this extension, all I can say is that it exists
- I do not clone full repositories, but rather use named branches (http://mercurial.selenic.com/wiki/NamedBranches) and bookmarks (http://mercurial.selenic.com/wiki/BookmarksExtension) depending on my need, and they work very well
- there are several possibilities of hg-svn integration, and I use hgsubversion which allows me to pull/push (update/commit) directly to svn server

Mercurial (as any other DVCS) definitely requires more technical knowledge than SVN, so if you do not have real need for DVCS, just stay with good-old SVN :-)

Hi!

I must comment on this because I did not experience such slowness with SVN. My SVN usage is very basic but I did svn diff for many files for my patch, one of them being main.pp.
It was fast, maybe 2 or 3 seconds, using command line in my oldish PC.

Thus, your problem must be caused by either TortoiseSVN or Windows, or both.

Linux seems to work better for everything. :-)

Regards,
Juha Manninen

Dear Graeme Geldenhuys,

The boot time realized now is acceptable for my project. I understand that I can squeeze out a few more seconds, estimating up to 5 seconds, by using fpGUI.
I hope I find time in the near future to investigate this, I will keep you informed.

Thanks, Anthony Vogelaar
=======================================================================

That only compares against the large revision (which is inside the hidden .svn directories on you system) - which explains the speed.

Doing a diff against older revisions or 'svn blame' on a file or doing a show log (eg: changes made in January 2009 or Lazarus repository) it needs to access the server and this is horribly slow in SubVersion!

Every Monday I update the "fixes" branches in the Git mirror repositories for FPC and Lazarus. I ask svn2.freepascal.org for a commit log between HEAD and the last revision (previous Monday)... I then go make a cup of coffee and often by the time I get back, it just completed the task. In Git, any such actions are <1 second.

Linux seems to work better for everything. :-)

Nope, I use SubVersion under Linux too. It still sucks! :)

Regards,
- Graeme -

git

I think the thread title is misleading.

Mattias

Then that developer will definitely not be in my team (or yours I hope). Because he/she doesn't review code before making it public.

> That is meaningless concept in git, see e.g. > http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem See my mail to Graeme, then git simply does not fit into FPC's workflow.

You play to the strengths of each tool. You guys use SubVersion different to the recommended way of the official SubVersion documentation (http://svnbook.red-bean.com/), by treading "tags" like branches and placing commits in them (just one such example). I have not come across other projects that do that, so FPC is unique in there workflow.

Just like Git saw the problems of previous SCM software it tried to improve those problem areas with new features and design. So it would make sense that if you switched to Git, you try those new features as recommended and then review your workflow accordingly. If everybody was as stubborn and afraid of change like you (or simply re-evaluating your workflow), we would all still be using .tar.gz or CVS as our repository systems.

I pretty sure you guys adjust your worflow when you moved from CVS to SubVersion. But please, I am not suggesting you guys change repositories, I am simply stating that just because your attempt at using Git failed, doesn't mean it will for everybody else too.

Regards,
- Graeme -

Hi!

I want to run a Lazarus GTK2 application within a minimal linux embedded systems

Why do you want to use GTK2 in your minimal, otherwise highly optimized system? GTK2 is big. It doesn't make sense.

Do you really think a mainstream distribution with fpGUI can beat this?

I think you confuse things now. Mainstream distributions already have big libraries like GTK2. They are not minimal systems. Thus, Graeme's light fpGUI library (or toolkit, whatever) doesn't give so much benefit on those distros. For your system it sounds like a perfect match though. I never used it myself so I can't recommend it personally but I understood it is used in "real" commercial SW.

Regards,
Juha Manninen

Aleksa Todorovic wrote

Mercurial (as any other DVCS) definitely requires more technical knowledge than SVN, so if you do not have real need for DVCS, just stay with good-old SVN :-)

Well said and I fully agree. I often need to look at old revisions of code (finding regression bugs etc.) and having to re-checkout complete revisions using SVN is just too damn slow (even on our office 4Mb connection). So I switched to using DSCM systems and it resolved all my issues I had with SubVersion. And like you said, with DSCM comes more power and features, so it makes sense to re-evaluate your workflow to see if you still have the most optimised workflow for the new toolchain. Florian fails to see this point.

Regards,
- Graeme -

One creates a new file my.pas with wrong line feeds, adds/commits/reviews/pushes it. How shall he recognize this? The next person working with the file will find out only. This is the simplest case, it gets more complicated if one works on samba shares and tortoisesvn with unix editided files like I do often :)

And yes, sometimes I forget the review, simply because I do a lot of other things while working (house keeping, parenting etc.) on fpc. Even more, since the most important point in fpc is regression testing before committing instead some useless "I've another stupid look at my code".

Possible, yes. Very few projects do also binary release building for such a number of different architectures as we do.

So make a recommendation for the fixes branch workflow instead of talking about the fix one, break one design of git. How shall we adapt the workflow so that nobody wastes it time with trying to merge stuff somebody else examined already?

Every Monday I update the "fixes" branches in the Git mirror repositories for FPC and Lazarus. I ask svn2.freepascal.org for a commit log between HEAD and the last revision (previous Monday)... I then go make a cup of coffee and often by the time I get back,

$ time svn log -r HEAD:14620
http://svn2.freepascal.org/svn/fpc/branches/fixes_2_4 > /dev/null

real 0m0.792s
user 0m0.010s
sys 0m0.020s

You must have a really fast coffee machine ;)

Guys, please stop. It is already impossible to distinct really problem mails which requires ansers from svn/git discussion which starts one per 2 months last time. Or rename the mail topic you are using so I can skip that mails from review.

Best regards,
Paul Ishenin.

Florian Klaempfl wrote

person working with the file will find out only. This is the simplest case, it gets more complicated if one works on samba shares and tortoisesvn with unix editided files like I do often :)

I use my flashdrive like that. I simply told git to always store files as LF in the repository. Any editor (worth using) can handle files with different end-of-line characters compared to the default OS.

If I really wanted to change my files to CRLF for usage under Windows, I can simply run 'git config core.autocrlf true' and then 'git reset --hard'. The first command doesn't change the eol characters in the repository (git repository storage always uses LF), but it will convert eol characters to CRLF when you checkout a branch/tag/revision etc... The second command simply forces git to re-get all files from the repository data storage, which causes all files to have their eol chars converted to CRLF.

The reverse is possible too, but like I said, with my existing repositories on my flashdrive, I just keep all source code with eol characters as LF, even under Windows. Even if I used Lazarus under Windows and check in a new unit, the unit might have CRLF, but the file stored in the git repository is always LF.

talking about the fix one, break one design of git. How shall we adapt the workflow so that nobody wastes it time with trying to merge stuff somebody else examined already?

Simply pull that feature branch from the developer that already did the merge. Also remember that Git is much better at auto resolving merges than SVN, so conflicts are less prone. Don't ask me how it works, I only know that it does. :)

It's a continuous boiling urn actually. :)

-------------------------------
$ time svn log -r HEAD:14620 \
http://svn2.freepascal.org/svn/fpc/branches/fixes_2_4 > /dev/null

real 0m22.514s
user 0m0.020s
sys 0m0.012s
-------------------------------

Today seems to be a good day, only took 22 seconds seconds.

Now here is another example, using the <lazarus>/ide/main.pp file.

First with Git:
-------------------------------------
$ time git blame -- main.pp > /dev/null

real 0m11.045s
user 0m10.945s
sys 0m0.100s
-------------------------------------

And now with SVN (SubVersion command line client): -------------------------------------
$ time svn blame http://svn.freepascal.org/svn/lazarus/trunk/ide/main.pp > /dev/null
real 4m38.046s
user 0m16.489s
sys 0m7.852s
-------------------------------------

More than enough time to make a cup of coffee. ;-)

Now imagine searching for a regression bug in Lazarus using SVN. Continuously checking out various revisions (high-low, test, high-low, test..) First of all, just a few such bugs and I would have depleted my home internet 500MB data limit per month. Also, the time it would take to checkout out a full copy of the repository each time will be huge (a few minutes for each checkout)! With Git such checkouts do not require network access and a checkout (any revision) will take <5 seconds.

There are many other such use-cases where DSCM's like Git and Mercurial will trump SubVersion every time. And like you said, you spend a lot of time doing regression tests. (did I mention you can automate regression bug tracking with Git using simple test projects like the ones used in FPC tests directory)

Regards,
- Graeme -

That's exactly my point: if somebody forgets it, things are screwed up and with every clone you've to play this game again.

You realize that fixes is not a feature branch but cherry picking? So what are the means to prevent that people look again and again to merge a certain changeset even if somebody already decided that this changeset will not be merged?

How does this decrease the runtime of 5-30min (depending of the platform) of the regression test suite?

I'd stick to the Lazarus trunk.

In all my previous attempts, with various projects, I had the same problem with branches: after a certain number of changes, to both the trunk and my branch, I found no way to merge an branch back into the trunk. I'd like to check whether this would be possible with Git repositories.

DoDi

Hello,

Going back to the original question ...

ajv wrote

I would appreciate some help with getting a Lazarus application running under Linux. I use the minimal distribution Tiny Core Linux. My Lazarus application shows graphics and text. All graphics are shown correctly but the text characters are rectangles.

It seams to me that you are having a Tiny Core Linux installation problem and not a Lazarus problem. Did you try asking in the Tiny Core Linux forum about installing pango? People here are (mostly) Lazarus developers, so we understand about Lazarus, but not necessarely about how to install pango in Tiny Core Linux.

thanks,

There you have a point. This topic went completely off topic, hiding the real issue.
Most of us developers have some areas where they have the most experience. The current way of keyhandling is iirc inherited from how synedit handles keys.
About your patch, although I agree on most reformatting parts, we try to separate functionality patches from reformatting patches. This makes understanding what changes easier (and not everybody agrees on my formatting).
In general it looks ok, and if it works it's fine with me.

Marc

Not sure if it applies in this case, but for any case in which it applies:

If the string is only required for saving options/xml files, then it should be defined in the editor options unit (maybe?). But IMHO in this case you can go with the enum to start with. If the enum is changed at any point in the future, the option-loader can have a translation table for old entries.

Martin