[fpc-pascal] Re: Compiling from and to memory
On 21-4-2012 2:22, waldo kitty wrote: > i'm old school so please forgive this if is is "out of bounds"... but... > how about a RAM disk? do the compiling on that and then copy off to > physical media when completed? Hi Waldo, You're not the only one that's old school - it was already suggested earlier ;) Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Commercial support for Lazarus/FPC
Hi all I am considering to subscribe to commercial support in FPC/Lazarus, but I don't have a clear picture what actually support is :) I am looking at http://www.lazarussupport.com/lazarus/Support and it is somewhat too abstract. I thought maybe it is easier to see what I am interested in and to give a concrete example. So if you don't mind, I'll try to describe a couple of alternatives. Personally, I am interested in maintenance in FPC/Lazarus existing functionality. But for objective reasons sometimes I am stuck with some bug in FPC/Lazarus. So I have several choices there. First one and the easiest - to report it and try to wait until the next stable version release. And yes, unfortunately it is too much time between releases currently. Furthermore if the reported bug is fixed, it is fixed only in trunk and no backporting occurs. Again no hard feelings, I fully understand that it is a open-source project and you do the best you can. Second one - try to follow FPC/Lazarus development in trunk every time something is fixed. That's the way I am currently following. Unfortunately, the trunks (FPC and Lazarus) can be unstable and when something is fixed, the other existing functionality stops working. Again - that's the fact of life and I can't demand anything here. Third alternative, which I wanted to discuss in more details, is bug-fix backporting to the last stable version. Yes, it is time-consuming and it is quite costly, but it guarantees the quality. Again, I could do it myself, keeping the patches I am interested in in a separate private repository, but : 1. I think a lot of people can be potentially interested in such repository, so the costs can be divided between the "stakeholders" and qualitative commercial support can be provided. 2. Some patches are too complex for me to maintain by myself. Please give your suggestion for dealing with my/similar problems. Again maybe Professional type of support can include backports service? -- Regards, Denis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Default font name
Hi, Most of controls (or canvas) have font name "default". How to get exact name of this font? There is GetFontData(Button1.Font.Handle).Name function but it works on QT widget set and on GTK not. Regards. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Commercial support for Lazarus/FPC
On 21.04.2012 12:12, denisgolovan wrote: Hi all I am considering to subscribe to commercial support in FPC/Lazarus, but I don't have a clear picture what actually support is :) I am looking at http://www.lazarussupport.com/lazarus/Support and it is somewhat too abstract. I thought maybe it is easier to see what I am interested in and to give a concrete example. So if you don't mind, I'll try to describe a couple of alternatives. Personally, I am interested in maintenance in FPC/Lazarus existing functionality. But for objective reasons sometimes I am stuck with some bug in FPC/Lazarus. So I have several choices there. First one and the easiest - to report it and try to wait until the next stable version release. And yes, unfortunately it is too much time between releases currently. Furthermore if the reported bug is fixed, it is fixed only in trunk and no backporting occurs. Again no hard feelings, I fully understand that it is a open-source project and you do the best you can. Second one - try to follow FPC/Lazarus development in trunk every time something is fixed. That's the way I am currently following. Unfortunately, the trunks (FPC and Lazarus) can be unstable and when something is fixed, the other existing functionality stops working. Again - that's the fact of life and I can't demand anything here. Third alternative, which I wanted to discuss in more details, is bug-fix backporting to the last stable version. Yes, it is time-consuming and it is quite costly, but it guarantees the quality. Again, I could do it myself, keeping the patches I am interested in in a separate private repository, but : 1. I think a lot of people can be potentially interested in such repository, so the costs can be divided between the "stakeholders" and qualitative commercial support can be provided. 2. Some patches are too complex for me to maintain by myself. Please give your suggestion for dealing with my/similar problems. Again maybe Professional type of support can include backports service? You do know that bug fixes are often backported if possible/feasible? E.g. currently we have the release 2.6.0, trunk is at 2.7.1 and there is the fixes branch 2.6.1 which is based on 2.6.0, but contains fixes (and often features) that were merged from trunk and will be in 2.6.2 then. The fixes branches are usually more stable than trunk (though trunk of at least FPC is usually rather stable as well). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Default font name
On 21.04.2012 16:50, Krzysztof wrote: Hi, Most of controls (or canvas) have font name "default". How to get exact name of this font? There is GetFontData(Button1.Font.Handle).Name function but it works on QT widget set and on GTK not. You should ask this on the Lazarus list. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Commercial support for Lazarus/FPC
On Sat, 21 Apr 2012 17:31:47 +0200 Sven Barth wrote: > On 21.04.2012 12:12, denisgolovan wrote: >[...] > > I am considering to subscribe to commercial support in FPC/Lazarus, but I > > don't have a clear picture what actually support is :) > > I am looking at http://www.lazarussupport.com/lazarus/Support and it is > > somewhat too abstract. >[...] > You do know that bug fixes are often backported if possible/feasible? > E.g. currently we have the release 2.6.0, trunk is at 2.7.1 and there is > the fixes branch 2.6.1 which is based on 2.6.0, but contains fixes (and > often features) that were merged from trunk and will be in 2.6.2 then. > The fixes branches are usually more stable than trunk (though trunk of > at least FPC is usually rather stable as well). Same for Lazarus, although the numbering is different. There is always a svn branch "fixes", while the svn "trunk" is the development version. The fixes receives only bug fixes. The release was 0.9.30. The development version was 0.9.31. Then came several minor releases 0.9.30.2,3,4,5 with fixes. Next version is 1.0 (fixes branch), development has version 1.1 (trunk). Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Commercial support for Lazarus/FPC
On 21 Apr 12, at 17:31, Sven Barth wrote: > On 21.04.2012 12:12, denisgolovan wrote: > > Hi all > > > > I am considering to subscribe to commercial support in FPC/Lazarus, but I > > don't have a clear picture what actually support is :) > > I am looking at http://www.lazarussupport.com/lazarus/Support and it is > > somewhat too abstract. > > > > I thought maybe it is easier to see what I am interested in and to give a > > concrete example. > > So if you don't mind, I'll try to describe a couple of alternatives. > > > > Personally, I am interested in maintenance in FPC/Lazarus existing > > functionality. > > But for objective reasons sometimes I am stuck with some bug in FPC/Lazarus. > > > > So I have several choices there. > > > > First one and the easiest - to report it and try to wait until the next > > stable version release. > > And yes, unfortunately it is too much time between releases currently. > > Furthermore if the reported bug is fixed, it is fixed only in trunk and no > > backporting occurs. > > Again no hard feelings, I fully understand that it is a open-source project > > and you do the best you can. > > > > Second one - try to follow FPC/Lazarus development in trunk every time > > something is fixed. > > That's the way I am currently following. Unfortunately, the trunks (FPC and > > Lazarus) can be unstable and when something is fixed, the other existing > > functionality stops working. > > Again - that's the fact of life and I can't demand anything here. > > > > Third alternative, which I wanted to discuss in more details, is bug-fix > > backporting to the last stable version. > > Yes, it is time-consuming and it is quite costly, but it guarantees the > > quality. > > Again, I could do it myself, keeping the patches I am interested in in a > > separate private repository, but : > > 1. I think a lot of people can be potentially interested in such > > repository, so the costs can be divided between the "stakeholders" and > > qualitative commercial support can be provided. > > 2. Some patches are too complex for me to maintain by myself. > > > > Please give your suggestion for dealing with my/similar problems. > > > > Again maybe Professional type of support can include backports service? > > You do know that bug fixes are often backported if possible/feasible? > E.g. currently we have the release 2.6.0, trunk is at 2.7.1 and there is > the fixes branch 2.6.1 which is based on 2.6.0, but contains fixes (and > often features) that were merged from trunk and will be in 2.6.2 then. > The fixes branches are usually more stable than trunk (though trunk of > at least FPC is usually rather stable as well). It's probably fair to say that certainly not all bugfixes are backported or merged (especially in case that they require changes which are considered as possibly risky for the fixes branch), so the question is a valid one. My original thought was that it should be better asking questions about how the support worked on the support site. After having looked at it, I understand that it might be confusing because I found no simple way for contacting the site owners for such question on that site... There is a link to the company CNOC running the site, but their WWW pages are in Dutch. Nevertheless, the Contact page on that site contains an e-mail address. I'd ask the question there (although I believe that Joost or someone else would probably read and eventually answer it here too ;-) ). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] header translation question: I need an int sized boolean
Hi, I have this from the GLIB heads: typedef intgint; typedef gint gboolean; Now I need a few packed records with such gboolean types in them. On my i386 I am now just using type GBoolean = LongBool; Just to get something¹ up and running before the day was over. Unfortunately I cannot yet test this on 64 bit and I'm not a C programmer also. I assume on 64 bit architectures the int will be 64 bit, is this correct? I haven't found anything in the ctypes unit, should I use ifdefs to define my GBoolean or is there a more elegant one-liner to easily get such an integer sized bool? Bernd ___ ¹ I am trying to find out whether I can make a libpurple (Pidgin) plugin in FPC without needing these headers and gcc at all and without jumping through too many hoops. Now I have it loading, registering and unloading without a crash already :-) its not as complicated as I initially assumed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
