Re: [fpc-devel] type PPGdkScreen = PGdkScreen;

... but PPGdkScreen definition should be fixed anyways. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] type PPGdkScreen = PGdkScreen;

On Saturday, May 20, 2023, Juha Manninen wrote: > which is used in LCL function TGtk2TrayIconHandle.GetPosition: TPoint; > gtk_status_icon_get_geometry(FStatusIcon, @AScreen, @AArea, > @AOrientation); > where > AScreen: PGdkScreen; > OK, actually the @AScreen in L

[fpc-devel] type PPGdkScreen = PGdkScreen;

In gtkstatusiconh.inc there is a type definition PPGdkScreen = PGdkScreen; It is most likely a bug. I guess it should be PPGdkScreen = ^PGdkScreen; It is used for : gtk_status_icon_get_geometry : function(status_icon:PGtkStatusIcon; screen:PPGdkScreen; area:PGdkRectangle;

Re: [fpc-devel] Gaps in a non-contiguous enum

On Thu, Aug 11, 2022 at 9:37 PM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > fpc code is still "unexpected". > It takes into account the MinValue > > type TMyEnum = (a=5, b=7); > > GetEnumName(pt, 5) // a > GetEnumName(pt, 6) // b // should be 7 > > if it is just the nth

Re: [fpc-devel] Gaps in a non-contiguous enum

On Thu, Aug 11, 2022 at 4:44 PM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Because you are not supposed to use MaxValue > Instead use GetEnumNameCount > > for I := MinValue to MinValue + GetEnumNameCount(...) - 1 do begin > > The unit name is returned because the

[fpc-devel] Gaps in a non-contiguous enum

I was able to fix issue https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39832 about TEnumPropertyEditor in Lazarus IdeIntf. Explanation: function GetEnumName() in FPC's rtl/objpas/typinfo.pp returns the enum's unit name for one gap in a non-contiguous enum, and an empty string for the

Re: [fpc-devel] Fix CamelCase in unit and method names

On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov wrote: > Please do... It has caused enough eye (OCD) stress over the years ;) +1 Yes, it has bothered also me a lot. I use code completion to get the unit names correctly. Most of them are CamelCase but some are lowercase. The

Re: [fpc-devel] TCollection.FOwner

On Wed, Dec 27, 2017 at 6:39 PM, Michael Van Canneyt wrote: > I don't want to burden TCollection with a field that will rarely be used. > > The proper solution is to implement GetOwner correctly for all cases that > need it. That's why it is there. > > So if you report all

[fpc-devel] TCollection.FOwner

I am proposing to add a private FOwner: TPersistent; to TCollection and remove it from derived classes which already have it. At least TParams has it but it is not used. The next step would be to assign a proper owner for derived TCollection instances, case by case. Lazarus has code to go up in

Re: [fpc-devel] CUPS support for FPC libs

On Sun, Jun 4, 2017 at 1:07 PM, Michael Van Canneyt wrote: > As far as I know, it does not. I don't see any evidence of it, but if you > create a ticket and assign it to me, I will add it. Finally I created a ticket for moving cupsdyn.pp to FPC sources:

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Thu, Jun 8, 2017 at 3:22 AM, Denis Kozlov wrote: > I can't control what values other users/developers may supply, nor I > restrict the use of different compiler versions and build flags. Compiler flags have nothing to do with the fundamental issue here. If other developers

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Wed, Jun 7, 2017 at 2:04 AM, Denis Kozlov wrote: > You suggest that only Convert3 function should raise "uninitialized result" > warning, while Convert1 and Convert2 should not. I find this less useful, > and, again, you can rightfully disagree, but it won't change the fact

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Mon, Jun 5, 2017 at 9:37 PM, Denis Kozlov wrote: > I just wanted to highlight that these cases as legal and I presume not > uncommon, particularly if values are deserialized and typecasted. No they are not legal. Why you write this nonsense? Values outside the range dictated

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On Monday, June 5, 2017, Denis Kozlov wrote: > I have just created a new GUI application, enabled range checking "-Cr" > and executed the following: > ShowMessage(IntToStr(Form1.BorderSpacing.GetSpace(TAnchorKind(-1; > The displayed value is a semi-random integer. No

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

For some reason my reply went only to Denis first. Another try here... On Mon, Jun 5, 2017 at 7:46 PM, Denis Kozlov wrote: > Result is undefined if caller passes an out of range value. > An example: TControlBorderSpacing.GetSpace(TAnchorKind(-1)); > Result is indeed not

[fpc-devel] Data flow analysis (dfa) and "case ... of"

Wiki tells about problems the dfa encounters: http://wiki.freepascal.org/FPC_New_Features_3.0#Node_dfa_for_liveness_analysis In this code if "b" is true in the first test, it will be true also in the second test, thus using "i" is safe and valid. ... if b then i:=1; writeln; if b

[fpc-devel] CUPS support for FPC libs

Regarding issue: https://bugs.freepascal.org/view.php?id=31245 Could cupsdyn.pp be moved to FPC packages? In Lazarus printer4lazarus package it is wrongly tied to widgetset instead of OS. It prevents using CUPS with QT widgetset for example. FPC's OS dependent libs are logically the right place

Re: [fpc-devel] UTF-8 string literals

On Wed, May 10, 2017 at 7:00 PM, Martok wrote: > I just searched for "Unicode". I wanted to delete the old page http://wiki.freepascal.org/LCL_Unicode_Support completely but I don't know how to do it so I just made it empty. Anybody knows how to delete it? I also

Re: [fpc-devel] UTF-8 string literals

On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner wrote: > 1. When using a character outside BMP FPC stops with: > Error: UTF-8 code greater than 65535 found > For example: > const Eyes = ''; I copy a related post from Lazarus list by myself and Sven Barth. It belongs

Re: [fpc-devel] Sven commit (r34087) breaks casting an object to an interface

On Fri, Jul 15, 2016 at 2:22 PM, Maciej Izak wrote: > Change for the AForm's type to IDesignedForm is impossible in mentioned > context. IDesignedForm means not only "TForm" but is used also to handle > forms for TFrame and TDataModule. IDesignedForm is way to unify usage of >

Re: [fpc-devel] Sven commit (r34087) breaks casting an object to an interface

On Fri, Jul 15, 2016 at 2:01 PM, Dimitrios Chr. Ioannidis wrote: > AFAIU, unless the AForm ( a TCustomForm descendant which explicitly list > IDesignedForm ) doesn't has the IDesignedForm in it's list of supported > interfaces, then it's a bug in the compiler, because,

Re: [fpc-devel] Sven commit (r34087) breaks casting an object to an interface

On Fri, Jul 15, 2016 at 12:51 PM, Maciej Izak wrote: > constructor TDesignFormData.Create(AForm: TCustomForm); > begin > FForm := AForm as IDesignedForm; // won't work anymore. FForm is an > interface I have not studied the context of this code but to me it looks

Re: [fpc-devel] Assembler reading style, 32-bit versus 64-bit compiler

Ping... No replies. Anyway, the issue is now reported by Arlen B Taylor: http://bugs.freepascal.org/view.php?id=30339 Please look at it somebody. It affects directly the "all options" GUI in Lazarus. Juha ___ fpc-devel maillist -

[fpc-devel] Assembler reading style, 32-bit versus 64-bit compiler

Regarding this forum thread: http://forum.lazarus.freepascal.org/index.php/topic,33199 It looks like 64-bit version of FPC 3.0 only lists "-Rdefault Use default assembler for target" in its "Assembler reading style" help output (fpc -h). 32-bit version lists also "intel" and "att". Is it a

Re: [fpc-devel] FPC 3.0.2 release target

On Sun, May 29, 2016 at 11:33 AM, Michael Van Canneyt wrote: > We're set to create the branch at the end of May, which is about now. > The last merges have been performed. I assume Marco will tag somewhere this > week, and then building starts. That is good news! Thanks.

Re: [fpc-devel] FPC 3.0.2 release target

Is there any estimate for FPC 3.0.2 release? FPC 3.0.0 was released already at November 26, over half a year ago. Fixes branches of both FPC and Lazarus have lots of important commits. Lazarus 1.6.2 + FPC 3.0.2 would make a nice and solid combination. Juha

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

On Wed, Jan 27, 2016 at 12:32 PM, Maciej Izak wrote: > about compatibility and bugs: > https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf Yes, that is about your Generics.Collections compatibility. I was more interested why fcl-stl is

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

On Wed, Jan 27, 2016 at 9:57 AM, Sven Barth wrote: > As long as it's not in the bootstrapping RTL I don't really care where we > put it ;) So it could be added to FPC trunk soon? This issue has been open for a long time. I hope some decision can be made. I don't

Re: [fpc-devel] Generics.Collections as package for Lazarus or package for FPC RTL

Hey guys ... Now this Generics.Collections is completely hijacked by a namespace discussion. Does it mean the original issue is again buried and forgotten for another year or two? You could easily move the unrelated discussion to another thread by indicating this thread in the subject, like:

Re: [fpc-devel] simpleipc issues

On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt wrote: > I am not proposing to make a new class. > I want a property "SingeInstance" in CustApp which activates this > automatically. I had the very same idea when this was discussed a long time ago in Lazarus list.

Re: [fpc-devel] simpleipc issues

On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny wrote: > Juha, I changed the advancedipc.pas unit (this one from the mailing list is > newer than from the bug report). I can prepare a new patch for the bug > report. No need for a new patch if it did not change otherwise. I

Re: [fpc-devel] simpleipc issues

On Tue, Sep 29, 2015 at 4:35 PM, Michael Van Canneyt wrote: > For simpleIPC, yes. But the new implementation has no dependencies except > sysutils, classes. So the argument becomes void. It adds extra code to every application. Maybe not too much though. > ... > That is

Re: [fpc-devel] simpleipc issues

On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny wrote: > Michael Van Canneyt & Tomas Hajny & everybody who wants to test: > > I prepared a fully compatible AdvancedIPC unit. See the attachment. > ... Michael and Tomas, I am planning to copy AdvancedIPC temporarily to Lazarus

Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch

On Fri, Jul 17, 2015 at 10:00 AM, Maciej Izak hnb.c...@gmail.com wrote: New modern Pascal dialect is subject of this topic. Do you mean your Generics.Collections would compile only with the new mode? Sounds very bad to me. Juha ___ fpc-devel maillist

[fpc-devel] What means -Oodfa ?

Referring to this old issue : http://bugs.freepascal.org/view.php?id=20907 I was told that compiling with -Oodfa reports uninitialized String result values. Indeed it does, I spotted many of them in Lazarus sources. However fpc -h does not mention these options. What do they mean? There is :

Re: [fpc-devel] What means -Oodfa ?

There are some false positive warnings. For example this construct can be found in Lazarus IDE code frequently. function IDEDirectiveNameToDirective(const DirectiveName: string): TIDEDirective; begin for Result:=Low(TIDEDirective) to High(TIDEDirective) do if

Re: [fpc-devel] What means -Oodfa ?

On Sun, Mar 22, 2015 at 5:55 PM, Florian Klaempfl flor...@freepascal.org wrote: Trunk or fixes? Fixes. This should be fixed in trunk. Ok, thanks. I will test with fpc trunk later. Now my goal is to make sure Lazarus works well with the future fpc 3.0. Juha

Re: [fpc-devel] What means -Oodfa ?

On Sun, Mar 22, 2015 at 12:17 PM, Florian Klämpfl flor...@freepascal.org wrote: DFA ^ ? See the svn version of the docs for its meaning ;) Damn right, it is there! I think I was looking for 3 separate one-letter options. It means: Enable Data Flow Analysis. (normally included -O3)

Re: [fpc-devel] Future of FPCUP tool

On Sat, Feb 21, 2015 at 11:55 AM, Tomas Hajny xhaj...@hajny.biz wrote: However, if there is someone else willing to take it over, it's probably fine as well, isn't it? My thoughts exactly. FPC devels have hands full of work already. It is rare that new people are interested to improve a tool,

Re: [fpc-devel] Future of FPCUP tool

On Sat, Feb 21, 2015 at 12:17 PM, Marco van de Voort mar...@stack.nl wrote: My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to that. FPCUP also has a GUI frontend. Can it be maintained there as well? I start to think this tool should be maintained somewhere else. FPC

Re: [fpc-devel] Future of FPCUP tool

On Sat, Feb 21, 2015 at 3:13 AM, Michael Thompson mike.cornfl...@gmail.com wrote: That's not how I interpreted his posts, particularly his last one which he might have posted after you sent this email... He wrote By no means I am pushing myself as the new maintainer which I interpreted as I

Re: [fpc-devel] Future of FPCUP tool

On Sat, Feb 21, 2015 at 2:38 PM, Michael Van Canneyt mich...@freepascal.org wrote: So, if there is any interest, I can set up a repo for it. How easily would a new maintainer get commit rights there? Juha ___ fpc-devel maillist -

[fpc-devel] Future of FPCUP tool

I remember FPC developers had a plan to maintain the late Reinier's FPCUP tool. What is the situation now? There is at least one active fork, see : http://forum.lazarus.freepascal.org/index.php/topic,27429.msg169490.html#msg169490 DonAlfredo appears to have motivation to maintain it. It may be

Re: [fpc-devel] fpc -h and fpc -i

On Sun, Nov 9, 2014 at 4:51 PM, Tomas Hajny xhaj...@hajny.biz wrote: I've finished implementation of solution for easier parsing of supported values for certain options and the solution _does_ match the compiler capabilities because the values come from the particular compiler itself. Thanks.

Re: [fpc-devel] fpc -h and fpc -i

On Wed, Nov 12, 2014 at 11:32 PM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: Is there an exclusion for -P option in the parser? After all the flag make sense for fpc but not ppcXXX. No but IMO it should be excluded from the user choices. The parser calls the compiler with

Re: [fpc-devel] Exception while creating process: Could not detect X-Terminal program / Fedora 20

It may be a duplicate of #19708, although I marked it as related. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc -h and fpc -i

On Sunday, November 9, 2014, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: On Sat, Nov 8, 2014 at 2:15 PM, Juha Manninen juha.mannine...@gmail.com javascript:_e(%7B%7D,'cvml','juha.mannine...@gmail.com'); wrote: On Fri, Nov 7, 2014 at 1:13 AM, Tomas Hajny xhaj...@hajny.biz javascript

Re: [fpc-devel] fpc -h and fpc -i

On Sunday, November 9, 2014, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: Pardon me, but I actually opposed the idea to put any kind of changes to FPC help system. My reasoning - it would be an additional and annoying burden to fpc-team. As bug reports showing, help is not in sync with

Re: [fpc-devel] fpc -h and fpc -i

On Fri, Nov 7, 2014 at 1:13 AM, Tomas Hajny xhaj...@hajny.biz wrote: If you mean that FPC itself should use a JSON file for generating the help, that doesn't sound like a good idea to me (see below). I think it is a good idea if only somebody implemented it. It is not a trivial thing to

[fpc-devel] fpc -h and fpc -i

Lazarus has a GUI for all FPC options, parsed directly from fpc -h and fpc -i. Project Options - Compiler Options - Other - All Options ... It was temporarily broken with FPC trunk but works now. I had to hard-code some things in the parser because fpc -h output does not give enough data. 1.

[fpc-devel] Another bug or feature

This is related to issue #24907. In the comment I explain the problem : http://bugs.freepascal.org/view.php?id=24907#c71475 but I copy it also here below. Now, is it a bug or feature? Otherwise not a big deal but CodeTools follow FPC behavior and the Delphi converter uses CodeTools. Apparently

Re: [fpc-devel] Another bug or feature

On Mon, Nov 25, 2013 at 8:18 PM, Sven Barth pascaldra...@googlemail.com wrote: Neither global operators nor symbolic (, , etc.) operator names are supported by Delphi. You are right. Now looking more carefully at the example critterchess code : http://sourceforge.net/projects/critterchess it

[fpc-devel] SimpleIPC and TWinMsgServerComm.PeekMessage

I am testing SimpleIPC with components/chmhelp/lhelp and components/chmhelp/democontrol/lhelpconnectiondemo1 The latter works as a master application, sending a file name to lhelp and starting it if not running already. On Linux this works perfectly. The return message status is always Success.

[fpc-devel] Re: SimpleIPC and TWinMsgServerComm.PeekMessage

On Wed, Oct 9, 2013 at 11:40 AM, Juha Manninen juha.mannine...@gmail.com wrote: I am testing SimpleIPC with components/chmhelp/lhelp and components/chmhelp/democontrol/lhelpconnectiondemo1 These are in Lazarus sources obviously. Juha ___ fpc-devel

Re: [fpc-devel] SimpleIPC and TWinMsgServerComm.PeekMessage

On Wed, Oct 9, 2013 at 2:52 PM, Sven Barth pascaldra...@googlemail.com wrote: You might want to take a look at WaitForInputIdle. MSDN entry: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687022%28v=vs.85%29.aspx Informative blog entry:

Re: [fpc-devel] SimpleIPC and TWinMsgServerComm.PeekMessage

On Wed, Oct 9, 2013 at 6:10 PM, Sven Barth pascaldra...@googlemail.com wrote: I've looked at the code a bit more and the problem must be something else. MsgWaitForMultipleObjects waits on a FHWND which it created itself and additionally waits for the reception of a message through SendMessage.

Re: [fpc-devel] SimpleIPC and TWinMsgServerComm.PeekMessage

Forgot to mention, I am testing with Windows 7, but I don't think it makes much difference. Those API calls are old and widely used. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Bug in StrUtils.ReplaceStr and ReplaceText

On Tue, Mar 26, 2013 at 3:36 PM, Flávio Etrusco flavio.etru...@gmail.com wrote: functions ReplaceStr and ReplaceText don't set their results (in trunk). The bug is also present in 2.6.2. True. They just call AnsiReplaceStr and AnsiReplaceText, without setting Result. A workaround is to use the

Re: [fpc-devel] FreePascal Git Repo and 2_6 branch

On Sat, Apr 28, 2012 at 8:23 PM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: To do it the correct way, is a lot of work, hence the reason I stopped mirroring the fixes branches. What I mean by correct way, is cherry-picking the commits from Trunk (master) and applying them in the fixes

Re: [fpc-devel] Are C style operators default or not?

On Tue, Mar 27, 2012 at 11:08 AM, Gennadiy Poryev c...@barvinok.net wrote: As far as I can see from the source the default should be not enabled. It is fixed in Lazarus svn r36376 by explicitly specifying -Sci in makefile. Sorry for raising the question here, I didn't anticipate it to be

Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

2011/9/13 Graeme Geldenhuys graemeg.li...@gmail.com Not at all! The debugger I am working on ONLY reads the debug information embedded in the executable - in my case DWARF info supplied by FPC. Graeme, are you working on Duby or some new debugger? I found your old mails that mentioned a

[fpc-devel] Compilation error in fgl.pp

I have a rather old version of FPC 2.5.1. I tried to update it but got this: --- /home/juha/lib/fpc/2.5.1/ppcx64 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 - Fi../unix -Fix86_64 -FE. -FU/home/juha/SW/freepascal/fpc/rtl/units/x86_64- linux -Cg -dx86_64 -dRELEASE ../objpas/fgl.pp fgl.pp(128,38)

Re: [fpc-devel] Compilation error in fgl.pp

Vincent Snijders kirjoitti tiistai 04 tammikuu 2011 15:53:41: Should I install FPC 2.4.2 first and try again? Yes. Thanks, works now. Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Alternative parsers

On Wednesday 20 October 2010 11:53:02 Marco van de Voort wrote: Again: Combining two languages into one compiler doesn't magically make them interoperable. And the only existing example doesn't exactly have a crack record on using C++ FROM Delphi (the otherway around is different, I'm told,

Re: [fpc-devel] Alternative parsers

On Wednesday 20 October 2010 13:08:15 Marco van de Voort wrote: That is exactly the kind of circle reasoning that haunts these discussions. The actual target is a constant flux, and adapts to suit the reasoning: MS We need a C++ frontend MV Why ? MS porting to Pascal is such a horror, and

Re: [fpc-devel] Alternative parsers

On Wednesday 20 October 2010 13:52:58 Marco van de Voort wrote: In our previous episode, Juha Manninen (gmail) said: Still, C would be doable, for porting SOME existing code to co-operarate directly with pascal code. If the C code uses lots of library calls it can't be used directly

Re: [fpc-devel] Alternative parsers

On Tuesday 19 October 2010 11:10:29 Matt Emson wrote: On 19 Oct 2010, at 06:50, Alexander Klenin kle...@gmail.com wrote: On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich drdiettri...@aol.com wrote: So there's left nothing what I could do for FPC. I suggest you start a

Re: [fpc-devel] Alternative parsers

On Tuesday 19 October 2010 14:44:38 Florian Klaempfl wrote: Am 19.10.2010 11:08, schrieb Juha Manninen (gmail): First Pascal-like languages and later C. FPC's main developer doesn't see a need for it. Indeed. Please tell what a C front end to FPC helps? FPC has no advantage over existing

[fpc-devel] Re: [Lazarus] Syntax highlighting anomalies

On Saturday 09 October 2010 09:51:59 Alexander Klenin wrote: On Sat, Oct 9, 2010 at 14:24, Hans-Peter Diettrich drdiettri...@aol.com wrote: break, continue and exit are not keywords. They could be redefined. I'd appreciate when, at least in mode FPC, these words would become keywords.

Re: [fpc-devel] Dynamic Arrays as Static class variables

On Tuesday 05 October 2010 01:00:19 Willibald Krenn wrote: Hi, I just tried and can reproduce this with fpc rev. 16078 on win64. Same thing here on Linux , AMD64, few days old FPC trunk version. Juha ___ fpc-devel maillist -

Re: [fpc-devel] FPC/Lazarus Rebuild performance

On Saturday 11 September 2010 09:55:14 Martin Schreiber wrote: On Friday 10 September 2010 17:43:59 Adem wrote: Sometime ago, there was a brief mention of multi-threading FPC would be counter productive because compilation process was mostly disk IO bound --this is what I understood anyway.

Re: [fpc-devel] FPC/Lazarus Rebuild performance

On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote: And why does the Delphi commandline compiler (dcc32) not need this IDE assistance? My guess is that dcc32 works as an integrated make program + compiler and thus doesn't start external processes for each file. Or, if it starts an

Re: [fpc-devel] Parallel processing in the compiler

On Sunday 05 September 2010 13:29:38 Graeme Geldenhuys wrote: Reading Jonas's comments and your reply above, it seems a git mirror (or a subversion/git dual setup) would be much better suited for your working style. git allows local commits and local branches. Ideal for cases like so those

Re: [fpc-devel] SVN error

Adem kirjoitti lauantai, 24. heinäkuuta 2010 14:28:22: I am using the latest TortoiseSVN to get a full local copy of FPC, but --even thought I tried several times, with 'cleanup's-- I keep getting this error: GET of '/svn/fpc/!svn/bc/9386/trunk/rtl/inc/wustrings.inc': Checksum invalid for

Re: [fpc-devel] Access violation building the compiler : r15585

Hi Actually I got exactly the same error from the same system.pp file. I tried to compile FPC trunk on my Acer/E-machines mini-laptop, Intel Atom CPU, having OpenSuse Linux OS. First I had some snapshot version of the compiler to start with. It gave the error. Then I updated to fpc 2.4.0.1 (?),

Re: [fpc-devel] Need advice for refactoring

Hi If merging the rapidly diverging branches becomes a real problem, and if Git really can merge so much better (which I haven't compared much myself), you can always use a local Git repository, then commit and merge (actually rebase) there. Like: git checkout DoDi_branch ... edit ... git

Re: [fpc-devel] Need advice for refactoring

Hi Hardy Heron: $ git --version git version 1.5.4.3 OpenSuse 11.3: $ git --version git version 1.7.1 Works here. Time to update Ubuntu. :-) Juha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FPC/Delphi/FastMM4/TopMemory speed test

Adem wrote: BTW, is there some way of having both 32bit and 64bit FPC/Lazarus coexist in the same machine? With Lazarus it is easy. You just compile it and rename the binary. It does not need to be installed. With FPC you could do two local installations and then switch between two versions

Re: [fpc-devel] fcl-web example and new testsuite website

Joost van der Sluis wrote: Sigh: http://www.freepascal.org/~joost/wwwroot/testsuiteweb.cgi Looks good except for one rendering problem with my Firefox 3.5.9 on Linux, screen resolution 1280*1024. The grid and other contents don't fit into the browser window and the browser creates scrollbars,

Re: [fpc-devel] procedure ... message(); in Linux

Hi, All these are very interesting options I was not aware of, but unfortunately no search for identifiers. You must first select the error saying identifier not found and then right click on it. I tested it with some broken code and it gave no feedback at all. I think it should always give

Re: [fpc-devel] procedure ... message(); in Linux

Hi, What gave no feedback? Ok, I tested again with a non-typical situation. I worked with lazarus.lpi and built Lazarus from tools - Configure Build Lazarus. The error messages show up just like when compiling a normal project but search identifier does nothing. Now I tested with a normal

Re: [fpc-devel] Semicolon before else

in programming are somewhere else than in the use of a semicolon. Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Semicolon before else

Because FPC does not support semicolon before else :-) Ok, I remembered it connects to the first IF when there is semicolon. Apparently I remembered wrong... It means there is no ambiguity and the patch can be applied without breaking any code. Or, is there some detail I have missed? Juha

Re: [fpc-devel] Semicolon before else

. (This would be another improvement for Pascal const array syntax, too, but let's not go there now. It need its own thread.) Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc

Re: [fpc-devel] Semicolon before else

Excellent example and perfectly showing where the new behaviour would break existing code without notice. I vote against this feature too, purely because it is inconsistent in behaviour. The original inconsistency is that ELSE is reused in CASE statement. If it used OTHERWISE or something and

Re: [fpc-devel] Semicolon before else

. You can perfectly use a library compiled with gcc in a gpc-compiled program. You just have to translate the headers Right. That is the limitation. And the object oriented classes (in C++) you can't really translate except for making them flat functions. Regards, Juha Manninen

Re: [fpc-devel] Semicolon before else

with such change. How does your patch handle this? : if a then if b then DoSomething; else DoOtherThing; Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Semicolon before else

must change it yourself. Ok, it is a small thing but still, this language is otherwise clean and intuitive. Using BEGIN END blocks always solves the problem but they are not used always. Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel

Re: [fpc-devel] Semicolon before else

this language less popular for big projects. There was another mail thread about it. Regards, Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Semicolon before else

between begin and end. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Circular references and forward declarations

On keskiviikko, 6. tammikuuta 2010 03:08:35 Nikolai ZHUBR wrote: Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: Then do the same as in C++ and put it in different include files. Right, include files could solve

Re: [fpc-devel] Circular references and forward declarations

depends on the application. Abstract base classes and interfaces are recommended by many but actual projects end up copying everything into one file. Surprising... :-) I must try include files for this problem sometimes. Does FPC really treat them differently than Delphi. Juha Manninen

Re: [fpc-devel] Circular references and forward declarations

On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote: Juha Manninen schrieb: Still, best solution has been to put everything into one big file. And still, I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's

Re: [fpc-devel] Circular references and forward declarations

. It may be a culture or convention also, technically it should be possible with Delphi as well. I must change my mindset for those include files. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman

[fpc-devel] Circular references and forward declarations

a surprise! If I create a feature request issue for this, does it have any chance of being implemented? I think it would be EASY to implement. Some other features like generics and closures (anonymous functions) need much more effort. Yours, Juha Manninen

Re: [fpc-devel] Circular references and forward declarations

On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote: Juha Manninen schrieb: If I create a feature request issue for this, does it have any chance of being implemented? No. Well thanks, that was a quick answer. According to timestamp you answered my mail before I sent

Re: [fpc-devel] Circular references and forward declarations

On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote: On 05 Jan 2010, at 17:07, Juha Manninen wrote: Forward declaration of a class is allowed inside a unit. There can be a reference to a class before it is defined! Like: TMyClass = class; Why is it not allowed from another unit

Re: [fpc-devel] Circular references and forward declarations

file. I mentioned 2 examples, Virtaual TreeView and Lazarus that have huge source files. My own programs suffer from the same thing (but they are not published, can't show them now). Juha Manninen ___ fpc-devel maillist - fpc-devel

Re: [fpc-devel] Circular references and forward declarations

a programmer to make a 34 000 lines source file (like VirtualTreeView has). Programmer should have a choice to split it if he wants. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo

Re: [fpc-devel] Circular references and forward declarations

that. Juha Manninen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

  1   2   >