Re: [Lazarus] FPC 2.6.2 + Thread.Queue?
On Wed, Apr 24, 2013 at 01:03:38PM +0200, Michael Van Canneyt wrote: Of course it can. You make the task far too complex. Start by NOT looking at the LCL code. You need simply to start with TCustomEventLoopApplication = Class(TCustomApplication) // Whatever end; Which abstracts the event loop. Then you implement a TConsoleEventLoopApplication = class(TCustomEventLoopApplication) // Whatever end; which implements the event loop for console apps using whatever mechanism you see fit. You could e.g. make use of libevent which provides a ready-to-go event loop. This will demonstrate that your concept works. After that, the remaining task is to make sure that TApplication from the LCL can be built on top of TCustomEventLoopApplication. I'm sure this will not take too long. All this is perfectly doable for 1 person. The base win32 pattern can be seen in (the old) ICS v5 (overbyte.be), unit conio. IIRC it uses (under Delphi) forms.allocatehwnd which is annoying since it is a non visual component in a visual unit. It did contain some primitives for D1 though, which I used in the FPC port. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Sun, Apr 21, 2013 at 11:11:18PM +0100, Graeme Geldenhuys wrote: This specially affects shortdescriptions, since they need the module to resolve, and is often called with .getmodule as argument. I know the HTML backend has very different code to the Linear output writers (Latex, IPF, RTF etc). I don't have problems with resolving links, cross-linking or hierarchy generation in IPF output. I also don't understand why I constantly find such coarse errors everytime I dive into fpdoc. As said, I don't understand how Michael managed to generate the 2.6.2 output (which generally looks fine) The html output is much richer though than the Latex output (and afaik also the IPF one the last time I checked). The above shortdescrs are the texts after links in the see also section btw, and also used in other places. My issue was that fpdoc crashed while I tried to build the LCL docs (all output formats). I believe you found the cause - the build_lcl_docs.lpr which also iterated over fpmake.pp units. Was this fixed in the Lazarus repository? No. I still had problems later, and worked around it in the backend, by checking every use of xxx.interfacesection with assigned() first. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Mon, Apr 22, 2013 at 10:17:50AM +0200, Michael Van Canneyt wrote: I also don't understand why I constantly find such coarse errors everytime I dive into fpdoc. As said, I don't understand how Michael managed to generate the 2.6.2 output (which generally looks fine) I just do make alldist ? I never do tweaking ? But with what fpdoc ? Did you generate 2.6.2 docs with trunk fpdoc ? For me it was totally broken, and many, if not all, of those issues should also have touched html output. (read this branch of the thread back to see what I fixed, and that is only last weekend's session) The html output is much richer though than the Latex output (and afaik also the IPF one the last time I checked). This is normal. Printed and Online docs should not look the same. I may need to do some efforts to improve PDF output, though. It's normal for Latex. It's one of the things I didn't like about IPF output the last time I checked though. It was a bit as the html attempt of Mr Walter posted ( http://codebot.org/bare/default.html ), constantly having to switch between right window and left window to browse. That is counterintuitive. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Mon, Apr 22, 2013 at 11:31:53AM +0100, Graeme Geldenhuys wrote: Curious, when last did you look at DocView and say rtl.inf? I just uploaded new binaries of both onto SourceForge. It has been a while, which is why I added last time I checked, probably in the 2.6.0 run up. I don't follow the docview stuff closely, since frankly, I don't see the point of it. It was just that Mr. Walter's page reminded me of a certain behaviour that I associated with my last .INF tests, namely that you can't browse e.g. an unit or a class without constantly changing lemmas in the treeview/index pane. IOW I like that a lemma is browsable internally, without going to other windows. It should be to test that assumption for current .INFs yourself. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Mon, Apr 22, 2013 at 11:42:08AM +0200, Michael Van Canneyt wrote: I just do make alldist ? I never do tweaking ? But with what fpdoc ? Did you generate 2.6.2 docs with trunk fpdoc ? Yes, I always do. I'm pretty much flabbergasted. Here it didn't even run through without exception (in the FCL docs), and when those were fixed, the input was less that 75% of the 2.6.0 iteration. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] GetAllFilesMask / AllFilesMask
On Mon, Apr 22, 2013 at 08:37:36PM +0300, Juha Manninen wrote: On 4/22/13, Mattias Gaertner nc-gaert...@netcologne.de wrote: See here: http://lazarus-ccr.sourceforge.net/docs/rtl/system/allfilesmask.html It says: ... On windows and dos based systems, this will be '*.*', while for unix systems, this will be '*'. Afaik both * and *.* work on Windows and Dos-with-lfn. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sun, Apr 21, 2013 at 09:23:30AM +, Mark Morgan Lloyd wrote: Unless your internet goes down... like what happened to me on Thursday. And I live in a first world country (finally) - but not even such countries are immune to internet outages. First world? I thought you were in England? ** Location has nothing to do with it. For work, I visit a lot of factories, and while some might have some wireless in office area, the workfloor has none. And even if they have, if one only visits occasionally, getting credentials is usually too bureacratic. Mobile internet reception is also flakely (usually have to go outside to get some signal due to steel in the structure, if you are permitted to take a phone into the factory begin with. Since the advent of camera phones, wanting that marks you as an industrial spy it seems). Don't get me wrong, for serious cases we always manage to get connected, but it requires effort and time. (permissions, going outside etc) It is not something you do to look up what %xxx to use in a format() argument string that you might not use everyday. Moreover in general as a small western country, the Netherlands is considered as quite decently connected, specially wrt mobile coverage. Leaving aside the performance issues, I think that the one area in which online docs are pretty much indispensable is that in principle they allow user annotation. However I think a big question is the extent to useful contributions could be folded back into the original XML (or whatever) without an inordinate load on the maintainers. Since both CHM and INF viewers are under our control, it is not a real problem to begin with. Anyway, can we _please_ all agree that we need both online and offline docs. I think the proponents of online docs better work on improving the online experience, rather than declare it perfect ex ante. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sun, Apr 21, 2013 at 07:41:08AM +0200, Reinier Olislagers wrote: So please, please, no something proprietary. Note: fpdoc can also generate plain html files from the fpdoc sources if told to do so, so you can generate not only CHM,PDF,INF but also HTML and I believe TeX. Of course, that is a main use (for the FPC and Lazarus online docs, and in the past, before CHM, also for the textmode IDE). The CHM support is basically the html support that overrides the html class how references are rendered, and keeps some extra administration to generate the additional structures. The main reason to do CHM was that the loose HTML was a burden to support on end-user computers. Probably if you extract the CHM it is nearly 1:1 with the online docs except that cross-package links are different (ms-its://package.chm/ vs ../packagename/) and the extra XMLs for the CHM functionality. (some CHM minor functionality is binary, and thus not extractable) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Sun, Apr 21, 2013 at 09:28:41AM +0100, Graeme Geldenhuys wrote: On 2013-04-20 23:47, Marco van de Voort wrote: P.s. I used script build_lcl_chm.sh, not buildchm.sh So what did you change? fpdoc and the *.lpr in Lazarus repository (docs/html/ directory)? As noted in a message a few days ago, I couldn't build any LCL docs. I wanted to supply and INF version of LCL, but couldn't. I mostly checked the html backend for regressions since the last major build (just before the 2.6.0 release, fpdoc sources december 2011). Quite a lot was merged in after that. I did a similar session last summer too (for 2.6.2RC1), but that lead to acceptable docs, not perfect docs. I don't understand how Michael was able to generate the 2.6.2 online docs fully linked, unless he also used something known good fpdoc (from dec 2011 or so). Anyway, what I did in detail. - First, don't start with the LCL, but with the FCL. 1) it is much smaller (and thus quicker) and easier to debug 2) it still has external dependencies (to rtl) only when it compiles under gdb with all the debugoptions below enabled, AND sizeof(fcl)= sizeof(last good fcl, dec2011) continue with lcl - Compile FPC trunk and install it. - Compile only the fpdoc parts (fcl-passrc and fpdoc) with as much runtime debug options as you can find ( I used -Sa -gttt -CROriot -dHEAPTRC_EXTRA -gw2l -viwn -Sg -Cppentiumm -dinheritancewarnings under freebsd/32) - get the fpdoc commandline from running the script (the above build_lcl_chm.sh or fixdocs.sh in FPCs case). In LCL's case we also reuse the output of this script (generated as docs/html/lcl/inputfile.txt ) - set up a ~/.gdbinit as follows: file path to binary fpdoc set language pascal set args fpdoc arguments b fpc_raiseexception - In LCL's case, copy the fpcdoc content files (.xct) to docs/html infs too if the inf backend needs them present. - Change to the correct directory (fpcdocs/ or docs/html/lcl (or lazautils) - run gdb and go directly to (r)un. - if exceptions pop up, do a backtrace(bt) and fix them. Not all exceptions are catastrophic (i.e. abort program), seems fpdoc writers like to open files without checking first and handling the exception if needed. I fixed some of those, and also in gettext. If you find non catastrophic exceptions, root them out, it will make debugging easier in the future. The main reason to do it this way is that the runtime checks (specially -gttt and -CR) are more likely to cause it to happen nearer to where the problem is, as opposed to where the corruption causes an exception of its own. It is very, very powerful, and whoever implemented this (Jonas for -gttt I believe) did extremely good work. I would wish I had it in Delphi. It also makes unittesting much more worthwhile, since it also uncovers errors that generally make no problems. In my case the problems were twofold: - In fcl-pastree, classes have been separated into baseclasses and descendents. However the backend code still checks like aclass.classtype= TSomeClass, but TSomeClass now also has descendents. So it should be aclass.classtype.inheritsfrom(TSomeClass). Check all TPasModule and TPasClasstype occurances not in declarations or casts. - In some places the original class is now one of the baseclass descendents, but the whole family (baseclass+descendents) is still casted to the original class. In most cases this is no problem, but in some it access fields on in the descendent. The classtree code in particular suffered from this. (probably because it is the newest) beside this there were common programming errors (like variables that are used unintialized in some codepaths) -gttt again There was also the already mentioned (on fpc-devel) weird non-error: procedure xxx(out sss :someclass); begin // sss not assigned. end; var t : someclass; t:=someclass.create xx(t); // xx is now randomized due to -gttt while without it, it still points to t. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sun, Apr 21, 2013 at 01:43:21PM +0200, Reinier Olislagers wrote: Anyway, can we _please_ all agree that we need both online and offline docs. I think the proponents of online docs better work on improving the online experience, rather than declare it perfect ex ante. Only if we also agree that the Lazarus default offline docs format is chm (not inf) That's not for me to agree on, but I can say that my patience won't last forever. The same with the fact that the IDE docs are still only in wiki, and there is no progression there either. IMHO the IDE docs should be taken offline (or readonly), and quickly reformed to some master format, and managed in SVN, versioned, like the rest of the docs. I think that needs to happen anyway, even if online is kept leading, just to get proper versioning. and we also work on the improvement of offline docs; e.g. bugs 23410 No context-sensitive help for control on form 22880 LCL.CHM: Application.Terminate shows empty page 22765 Lhelp: clicking on hyperlink doesn't do anything despite hand cursor icon 22763 Lhelp: Search can't find GetPart while it is in Index 22754 Context-senstive help for 'result' gives 'No help found for this topic' 22754 is difficult. result is not a keyword, but a pseudo variable, and its existence depends on context. So you can't simply add it to the keywords (ref.kwd), and it is not declared in each function either. I've no lhelp experience. I mainly did the CHM docs for the textmode IDE (since the html-only help was an hassle), and provide the LCL one as a courtesy. Btw, I see I used lazarus 1.1 as a source for these docs. Should there be a 1.0.x version too? What is the branch? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sun, Apr 21, 2013 at 02:04:12PM +0200, Reinier Olislagers wrote: IMHO the IDE docs should be taken offline (or readonly), and quickly reformed to some master format, and managed in SVN, versioned, like the rest of the docs. Good idea; as long as they can be as easily edited as on the wiki... That's not possible in a reasonable timeframe. I think that needs to happen anyway, even if online is kept leading, just to get proper versioning. If you take versioning as matching a certain Laz version with a certain help document, I do agree, but that would need to be done for FPC as well, IIUC. FPC does so since forever, since it only uses the wiki as it should be: public writable dumping ground for the more esotheric and/or short-lived topics. Every release comes with full offline docs in dist/version/docs/ True, it isn't versioned (branched) in SVN (and I like to see that change, for about a decade now), but that is a relative minor issue. As for the version control interpretation of versioning (the one I think you mean): no comments except a reference to our earlier discussion on this point... I mean both. 22754 is difficult. result is not a keyword, but a pseudo variable, and its existence depends on context. So you can't simply add it to the keywords (ref.kwd), and it is not declared in each function either. What happens if you do add it to ref.kwd with the caution that it works only with objfpc Delphi modes? Any result identifier will point to this. Also when it is not an implicit returnvalue, but e.g. a fieldname. Ok, it will give false positives in procedures and TP code, but that may be better than not giving any help. It will also give false positives in other modes. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot (BUILD ERRORS)
I've concatenated all warnings and errors in a log: http://www.stack.nl/~marcov/docbuilderrors.txt Some remarks: - Some of it might be due 2.6.x - trunk issues though. (bytesof?) - There seems to be a problem with enumtypes. Many errors are enum values - Importing operators seems to go wrong, and generates a slew of errors for all that import the RTL contents file (FCL/lazutils/lcl) - links are casesensitive afaik. I'll be trying to fix some of them (most notably in rtl). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UPDATED: Re: documentation snapshot
On Sun, Apr 21, 2013 at 01:45:19PM +0200, Marco van de Voort wrote: In my case the problems were twofold: - In fcl-pastree, classes have been separated into baseclasses and descendents. However the backend code still checks like aclass.classtype= TSomeClass, but TSomeClass now also has descendents. So it should be aclass.classtype.inheritsfrom(TSomeClass). Check all TPasModule and TPasClasstype occurances not in declarations or casts. - In some places the original class is now one of the baseclass descendents, but the whole family (baseclass+descendents) is still casted to the original class. In most cases this is no problem, but in some it access fields on in the descendent. The classtree code in particular suffered from this. (probably because it is the newest) I found another problem. Seems that in the past TPasElement.GetModule walked the parent dependencies and delivered the module for any paselement. Not anymore. This specially affects shortdescriptions, since they need the module to resolve, and is often called with .getmodule as argument. So the (other) backends might need to be fixed for that too. I'll update the snapshot as soon as it finishes building. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Building LCL docs
On Sat, Apr 20, 2013 at 01:16:34AM +0200, Mattias Gaertner wrote: I'm still debugging, but I get the feeling this is because someone passes some fpmake as an unit (to document) while it is a pascal main program. Of course fpdoc could check better, but probably all it can do is throw an error. That would be much better than a crash. For now, I only added a check there, since I don't where to thoroughly fix this. (it should probably happen much earlier, probably at the program kw) So probably the scripts that auto create lists of units should filter out fpmake. yes Did that too, build_lcl_docs.lpr I still have some exceptions at the end of the compile sometimes. Luckily I have been able to find a root cause of them (unitialized variables, -gttt and -CR have been very helpful, as usual). Most problems seem to be in TClassTreeBuilder.AddToClassTree. Also the CHMs are not as nicely hyperlinked as the 2.6.0 builds were, somehow the .xct content isn't resolved always in again the classtree stuff. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus helpfiles
On Wed, Jul 11, 2012 at 09:53:59AM +0100, Lukasz Sokol wrote: ( very old message, ran into it by accident while searching for something else) If the point of CHM is that they use less disk space than unpacked HTML, (yeah, I see the point : lcl.chm 11.577MB, fcl.chm 1.968MB, vs unpacked HTML files that use 187MB) then I'd include this information somewhere on the wiki... There are multiple ways in which chms are superior to the raw material: - Primarily they are compressed, and can be used as such (html decompression on plain dos can take hours) - Indexing, TOC and search is better. - cross package hyperlinking is file position independent. IOW FPC and LCL helpfiles don't have to be in the same directory to link to eachother (plain html simply does ../packagename for all unresolved links) - The code to use the helpfile is filesystem independent. In the past quite often subtle filesystem related bugs (like wrong directory separator) came to light only after release(*) (*) specially on Dos. Dos-under-Windows is more lenient than standalone dos. Note that the html inside the CHM is 99% the same, but not entirely. Using one base html for both is not really practical atm. All references between packages would break. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] documentation snapshot
I've made some progress with getting fpdoc up to speed, and here is an initial snapshot: http://www.stack.nl/~marcov/doc-chm_with_lcl.zip Known issues: - The class trees are not complete/corrupted where they span packages borders (so often ends with an unclickable TComponent with (?) next to it) - Most fpdoc generated files are smaller (in the magnitude of 5-10%) If you notice anything different compared to the previous set, please don't hesitate to reply. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sat, Apr 20, 2013 at 01:22:38PM -0400, Anthony Walter wrote: Were you going to tackle the dotted unit name Certainly not. and Delphi style generic declaration problems in the bug tracker? That is more interesting, and closer to my heart, but a bit beyond me atm, I'm afraid. I'm just doing regular debugging stints with fpdoc just to get the docs through, that is it. Usually in sync with FPC releases. I've been testing documentation generation tools and editing together a nice style with a tree view feature (I'm working on adding an index feature). Here is an example if you want some inspiration: http://codebot.org/bare/default.html I don't like the treeview (as it is currently). It seems to have a really deep hierarchy, and clicking a link in the right window, doesn't synchronize the left, so you are constantly folding and unfolding the treeview The toplevel class lemma is nearly defunct. It doesn't really provide links to the class (need treeview for that), and doesn't contain much other info. I also don't like showing methods etc in a table. I like the current situation more (more compact _AND_ more information) If I recall correctly, docview also suffered from this. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sat, Apr 20, 2013 at 02:58:27PM -0400, Anthony Walter wrote: The benefit of online docs ... Anyone can access them without installing a thing (assuming people have a web browser, which everyone does). This allows people to peruse/browse before they try, which is what most people do, read the web and google search stuff. Since online docs are online, they become easily queryable via everyone default search tool (google, or bing or whatever). All true. But that is a reason to _ALSO_ have online docs. The primary use of SDK information is to access them using context information from within the IDE. In the matching version of course. It's scary to admit it, but in sofar I agree with Graeme. Online docs can be updated/corrected/added to without sending needing to download updates/patches. While true, it is rarely exercised. Docs mostly follow the software release cycle. and that is not just for FPC/Lazarus. Of course, when you get to be the size of an Apple or Microsoft, you can have a continuous team updating it, but that is an exception, rather than the rule. Maybe you can make online help leading, but then it has to be a lot better than what you posted (for reasons Graeme already said, the interface is too poor). But whatever route is chosen, I think a development tool (which might be used for a long, long time) should come with documentation. Since the disappearance of online help (or a mere move or change of hosting) would make older versions of the tool unusable, otherwise. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] documentation snapshot
On Sat, Apr 20, 2013 at 09:39:49PM +0200, Sven Barth wrote: On 20.04.2013 21:21, Lubos Pintes wrote: ... And something that is totally inaccessible. So please, please, no something proprietary. Use widely used formats like HTML, or PDF if you absolutely must. Considering that IBM is not developing/improving the IPF/INF format anymore, the fact that Graeme has developed a fully Pascal open source viewer and that fpdoc contains an open source reader looks like enough reason to support it. Also PDF is propritary as well (maybe even more than IPF/INF). That reminds me, what is the current status of the INF compiler ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] UPDATED: Re: documentation snapshot
On Sat, Apr 20, 2013 at 05:27:29PM +0200, Marco van de Voort wrote: I've made some progress with getting fpdoc up to speed, and here is an initial snapshot: http://www.stack.nl/~marcov/doc-chm_with_lcl.zip The snapshot above was updated. Most interpackage hyperlinks work again, and the inheritance subpages (the [properties (by name)] links on each class page) are now filled again. There might be still errors left, but if there are, they are magnitudes less frequent than the ones now fixed. If you notice a regression, please don't hesitate to contact me. The old link doc-chm.zip was originally actually meant for fpc only help, (the textmode IDE) and in time I plan to use it for that again. Please update all links to doc-chm.zip to doc-chm_with_lcl.zip for that purpose. P.s. I used script build_lcl_chm.sh, not buildchm.sh -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Wed, Apr 17, 2013 at 08:56:12PM -0400, Anthony Walter wrote: Pascal would have to make an inventory of all files in the searchpath, not just in a certain (classpath or GAC) location. There are only 2 differences between what we currently have with dotted unit names acting as namespaces and C# namespaces. 1) You can't have more than one namespace in a file 2) You can't span a namespace across multiple files 3) it is a special form of namespace that can't contain anything else than units. To contain something else, it must be an unit namespace. Regarding the code insight you asked me about, those two differences aren't relevant to the programmer user experience My remark was somewhat compiler specific, but it bleeds through in the IDE too, since in a Lazarus/FPC project, not all used source must be named in the project. Stronger, the project doesn't even exist on a build level. I'm no Lazarus expert, but I assume that bleeds through in the IDE. IOW one can't assume that the project compilation unit list is complete. No, you don't need a GAC to achieve this. All you need is a list of unit paths, and the IDE can scan those folders for unit names. Something Lazarus already does. I was wrong however to assume that Lazarus doesn't already constantly monitor filepaths already. I don't know what it does there. I mixed up the compiler and IDE/codetools POV. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Building LCL docs
On Fri, Apr 12, 2013 at 04:45:15PM +0200, Mattias Gaertner wrote: I've tried using fpdoc from FPC 2.6.2, 2.6.3 and 2.7.1. I each case fpdoc crashes. I've tried generating HTML, CHM and IPF documentation - no luck with any of them. I'm using Lazarus (trunk) from r40661 (28 March 2013). Confirmed. fpdoc crashes under Linux 64bit too. I'm still debugging, but I get the feeling this is because someone passes some fpmake as an unit (to document) while it is a pascal main program. Of course fpdoc could check better, but probably all it can do is throw an error. So probably the scripts that auto create lists of units should filter out fpmake. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fedora 18: problems with package conflicts
On Wed, Apr 17, 2013 at 05:58:57PM +0200, zeljko wrote: On 04/17/2013 05:53 PM, Bart wrote: /lib/libEGL.so.1: undefined reference to `wl_display_dispatch_queue_pending' Why do we use libwayland-egl and not libEGL in the first place? Maybe some 3rd party package which is installed into IDE uses that. Lazarus does not use any wayland lib afaik. Does it use OpenGL? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Tue, Apr 16, 2013 at 09:39:46AM -0400, Anthony Walter wrote: Regarding you question about code insight, here are two arbitrary nice features of how code insight can be used with dotted namespaces I captured from Visual Studio (other IDEs and other languages do similar things): When adding using (uses in pascal) referecing a unit/assemble/namespace IDEs can show you a list of namespaces to choose from at each dot, and then they filter that list further as you type after the dot: True. But the C# namespace concept is totally different from the Pascal one, as I wrote in the previous message. Pascal would have to make an inventory of all files in the searchpath, not just in a certain (classpath or GAC) location. IOW, the resemblence of dots in filenames and C#/Java namespaces is only superficial. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IUnknown and reference counting
On Thu, Mar 21, 2013 at 11:36:14AM +0100, Hans-Peter Diettrich wrote: As already mentioned, Delphi interfaces are the workaround for the missing multiple inheritance in OPL, as known from many languages (Java...). Everything else IMO is language/implementation specific. I think they are primarily meant for/as external proxy objects. The MI angle is only secondary (or even less important. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Sat, Apr 13, 2013 at 07:05:51PM -0400, Anthony Walter wrote: Because in theory you should get code insight when you type Identified(dot). Which theory? As far as theory goes, I'd say that Code insight usually looks through the scope stack for matches. The scope stack is created by the uses statement, so codeinsight wouldn't work there. From a style perspective I also tend to avoid underscores in my own identifiers. I reserve underscores for methods you normally shouldn't call (_AddRef), or for imported C code (MAX_PATH, type_). Maybe. Also, I am sure you know dotted unit namespaces are an addition to Free Pascal. They are familiar to C#/Java people, and probably look better (style-wise) to them. I would be very careful with that, since that also raises other expectations the limited dotted concept cannot furfill. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor fails on namespace dotted unit names?
On Mon, Apr 15, 2013 at 12:07:19PM +0100, Graeme Geldenhuys wrote: Someone recently explained Delphi's namespace usage to me, and gave me a valid example of this. tiOPF has unit names with the same name, but used by different GUI toolkits. eg: tiMediators.pas is used by VCL, LCL and fpGUI. Each toolkit support has there own tiMediator.pas unit. You need to change unit search paths, so the compiler knows which unit to use. Anyway, recently somebody added FireMonkey support for the tiOPF mediators (Model-GUI-Mediator design pattern), but found an issue with threading. The tiOPF has a tiThread.pas unit, but FireMonkey's threading works differently. So instead of littering the tiThread.pas code with IFDEF's, the developor simply duplicated the units (yeah, not too great), but then added the FMX namespace to that unit. eg: Trouble is that it has the same problem as the define/ifdef. If you compile in parts and forget to pass the -d (or -NS) to one stage, you get funky errors. True, one ifdef less in source (since unitname automatically adjusts), but for that it is an very specialized feature, and there probably will be consequences for unit searching also. (similar to the filename case stuff on *nix) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fixes 2.6.2 cod breaks 2.6.0 code?
On Thu, Mar 14, 2013 at 09:49:55AM +0100, Mattias Gaertner wrote: [...] What fixes branch are you talking about? FPC 2.6 fixes or Lazarus 1.0 fixes? In the next release we should mention that it uses a newer compiler, which includes many bug fixes, but contains a few incompatibilities too and include a link to the fpc 2.6.2 changes. It's already this way in 2.6.0: http://wiki.lazarus.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties Yes, but 2.6.2 contains a few incompatibilities as well and Frank is right that a 1.0.8 release is meant as a bug fix release, so it should not contain incompatibilities. That's a sliding slope. Strictly speaking, a new version of the compiler that predefines just one extra symbol (e.g. due to a new architectural issue) would then not be acceptable since an user could already use the symbol in its own code. Things are not black and white. If there are incompatibilities, they are mostly there for a reason. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] gtk 3 header
On Wed, Mar 27, 2013 at 06:54:42PM -0400, Andrew Haines wrote: Thats because the files were generated with the introspection files from those two versions. It's pretty easy to generate any version needed for the bindings using the gir2pas program in the Lazarus CCR Thanks, that is the bit of info that satisfies my curiosity :_) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TTreeView question
On Thu, Mar 28, 2013 at 03:21:41PM +0100, Mattias Gaertner wrote: Its logic is platform independent. It uses the LCL theme drawing functions and colors. Some native widgets have some nice features, but have often problems with more than a few thousands items. Do they still in windows versions that will be supported longer than an year from now, or is that old story? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] gtk 3 header
Was browsing the GTK site a bit, and saw that for recent GTK3 versions there seem to be Pascal headers? http://www.gtk.org/language-bindings.php -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] gtk 3 header
On Wed, Mar 27, 2013 at 09:53:05AM +, Mark Morgan Lloyd wrote: Was browsing the GTK site a bit, and saw that for recent GTK3 versions there seem to be Pascal headers? http://www.gtk.org/language-bindings.php With the link pointing at http://wiki.lazarus.freepascal.org/GTK2_Interface The link of pascal, yes. But I'm intrigued why GTK3.4+3.6 are ticked for Pascal and 3.0 and 3.2 not :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IUnknown and reference counting
On Thu, Mar 21, 2013 at 08:26:21AM +, Graeme Geldenhuys wrote: Correct. And as Martin said, the name CORBA is a bit misleading. FPC has no CORBA or ORB implementation, so no distributed communications can be done out of the box. (Well, there is DCOM of course) The interfaces in that mode [CORBA style], I guess, is just _similar_ to real CORBA apps. The easiest way to explain it is that CORBA style interfaces are just like COM style interfaces, but without reference counting, and no IUnknown methods. Corba ORB interfaces ARE reference counted. (using incref and decref methods iirc). The difference was that in Corba it was custom to handle this manually, since keeping references long than necessary meant that the Corba server had to keep the object instance in memory. But I agree that the name was horribly, horribly chosen. Basically what happened is that there was whining about how windows dependent the IUnknown scheme was, when it was implemented, somebody mentioned Corba as non-Windows possibility. The usual anti Delphi/Windows chorus in the maillist caught on, and suddenly all non-IUnknown interfaces were Corba :-) The reference counting is purely done for COM purposes, not for direct memory safety collection. Note that all other ref counted types in Delphi can't cause cycles. Interfaces can. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] XML Support in Lazarus
On Mon, Mar 11, 2013 at 03:35:36PM +0800, Xiangrong Fang wrote: I am reading this: http://wiki.freepascal.org/XML_Tutorial It seems quite old (2005?)I wonder if the status quo is still same, especially that the FCL units still does not support UTF8 encoding? They are UTF16, but can (and generally will) write utf8 afaik. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Ide add-ons licensing issue
On Sat, Feb 23, 2013 at 05:45:20PM +0100, Sven Barth wrote: The problem of the original poster are IDE design time packages, not extra programs. Thus it's about linking and there I agree with Martin (though I'm no lawyer either...). Me too. GPL is a linking distribution license. Products from GPL programs are not automatically GPLed. So designtime lazarus packages are only subject to GPL when distributed in linked form. (against the GPL part, Lazarus). See also http://wiki.lazarus.freepascal.org/licensing#MPL_issues_relating_to_Lazarus MPL is here used as GPL incompatible license, but of course that could be read as commercial too. Note that the language is a bit weasely becuase at the time I was not very sure about this. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ZeosDBO
On Tue, Feb 19, 2013 at 09:53:20PM +, Graeme Geldenhuys wrote: until my project actually compiled. I'm using Zeos checked out from the SubVersion repository on SourceForge, and my copy is at r1848. No idea what version it is at. You do know the branch you checked out? :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Unpack of PHP
On Mon, Feb 04, 2013 at 03:29:54PM -0200, silvioprog wrote:
Oops... And this is the full code:
program project1;
{$mode objfpc}{$H+}
uses
Classes,
SysUtils;
function ReadInt(AStream: TStream): Word;
begin
Result := 0;
AStream.Read(Result, SizeOf(Word));
Result := BEtoN(Result);
end;
var
VFile: TFileStream;
begin
VFile := TFileStream.Create('data.ascii', fmOpenRead or fmShareDenyWrite);
try
VFile.Seek(2, 0);
WriteLn(ReadInt(VFile));
VFile.Seek(6, 0);
WriteLn(ReadInt(VFile));
finally
VFile.Free;
end;
end.
That's so boring! In FPC 2.7.1 this should work:
uses
Classes,
SysUtils,
StreamEx;
var
VFile: TFileStream;
begin
VFile := TFileStream.Create('data.ascii', fmOpenRead or
fmShareDenyWrite);
try
VFile.Seek(2, 0);
WriteLn(VFile.ReadWordBE);
VFile.Seek(6, 0);
WriteLn(VFile.ReadWordBE);
finally
VFile.Free;
end;
end.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling IDE issues using FreeBSD 9.1 FPC 2.6.0
On Sun, Feb 03, 2013 at 11:40:16PM +0100, Mattias Gaertner wrote: Maybe the gmake clean does not work under FreeBSD? Are there any custom rules regarding this file, or SED use? Makefile operation under FreeBSD is older than fpcmake generated makefiles. [clean] # clear all .ppu/.o/.rst files in all source and output directories files=$(wildcard $(COMPILER_UNITTARGETDIR)/*$(OEXT)) \ $(wildcard $(COMPILER_UNITTARGETDIR)/*$(PPUEXT)) \ $(wildcard $(COMPILER_UNITTARGETDIR)/*$(RSTEXT)) \ $(wildcard $(COMPILER_UNITTARGETDIR)/*.lfm) \ $(wildcard $(COMPILER_UNITTARGETDIR)/*.res) \ $(wildcard $(COMPILER_UNITTARGETDIR)/*.compiled) \ $(wildcard ./units/*$(OEXT)) $(wildcard ./units/*$(PPUEXT)) $(wildcard ./units/*$(RSTEXT)) \ $(wildcard widgetset/*$(OEXT)) $(wildcard widgetset/*$(PPUEXT)) $(wildcard widgetset/*$(RSTEXT))\ $(wildcard *$(OEXT)) $(wildcard *$(PPUEXT)) $(wildcard *$(RSTEXT)) Afaik such constructs should simply work. It will be passed to rm, and gmake is the same as make on linux, just might be a slightly older version. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling IDE issues using FreeBSD 9.1 FPC 2.6.0
On Fri, Feb 01, 2013 at 02:39:00AM +0100, Mattias Gaertner wrote: 'bigide' option, or one of the packages that 'bigide' pulls in has a compile problem under FreeBSD. Please create a bug report with the complete output of the make clean bigide output. And the dates of both fileutil.ppu's. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Compiling IDE issues using FreeBSD 9.1 FPC 2.6.0
On Sun, Feb 03, 2013 at 11:22:10PM +0100, Mattias Gaertner wrote: $ find . -name fileutil.* -print ./components/lazutils/fileutil.inc ./components/lazutils/lib/x86_64-freebsd/fileutil.ppu ./components/lazutils/lib/x86_64-freebsd/fileutil.o This is ok. ./components/lazutils/fileutil.pas ./docs/xml/lazutils/fileutil.xml ./lcl/units/x86_64-freebsd/fileutil.ppu ./lcl/units/x86_64-freebsd/fileutil.o Where is this fileutil.ppu coming from? Maybe the gmake clean does not work under FreeBSD? Are there any custom rules regarding this file, or SED use? Makefile operation under FreeBSD is older than fpcmake generated makefiles. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Typo in TFPCustomFont?
On Mon, Jan 14, 2013 at 12:00:43PM +0100, Michael Van Canneyt wrote: correct? StrikeThrough or StrikeTrough? It is a typo. And if it is really a typo, can I fix it even breaking compatibility? Fix it. ... and merge it back to 2.6.2 ? :-) IMHO: yes. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Typo in TFPCustomFont?
On Wed, Jan 16, 2013 at 02:35:07PM +, Martin wrote: ... and merge it back to 2.6.2 ? :-) IMHO: yes. Maybe make the old one deprecated in fixes, while adding the new. Done to fixes. (which will be branched for 2.6.2) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Converting pence into pounds and then to string
On Wed, Dec 12, 2012 at 11:23:46AM +, Richard Mace wrote:
Got a simple question that has stumped me, which tends to happen if I don't
do development for a couple of months.
How's the best way of converting an integer number 208 (that is pence)
into a string value that is in pounds (2.08)
Logically, to format currency one uses the standard library function
formatcurr:
http://www.freepascal.org/docs-html/rtl/sysutils/formatcurr.html
uses sysutils;
var v : currency;
begin
v:=208 /100;
writeln(formatcurr('#.##',v));
end.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] tachart breaks trunk compilation
tachartaxis.pas(337,46) Error: identifier idents no member GetAlignment Lazarus trunk, fpc trunk. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] tachart breaks trunk compilation
On Sun, Oct 07, 2012 at 12:43:34PM +0200, zeljko wrote: tachartaxis.pas(337,46) Error: identifier idents no member GetAlignment Lazarus trunk, fpc trunk. I've successfully compiled laz trunk (r38980) with fpc-2.6.1. (including tachart?) I've looked deeper into it, and it seems Alexander is fond of strict protected and private, but calls getalignment in a not inherited fashion. (on another class) Afaik that was where FPC was more lax than Delphi and Jonas corrected that yesterday. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fpc version 2.6.1 source code
On Thu, Oct 04, 2012 at 03:10:23PM +0200, Bernd wrote: The debs in the official Debian repository are built by someone else (someone from Debian) using a different method and I believe thats also the reason why the Debian debs are needlessly split into a myriad of separate packages while the ones resulting from the Lazarus build scripts are just fpc, fpc-source and lazarus. Afaik that is a result of the policy of many package systems to add all possible dependencies to a package. Debian is just stricter enforcing that. (which is strange, since of all systems, Debian has a suggests system) FPC, with all its header packages would thus have a tremendous amount of dependencies. FreeBSD has the same problem. I never liked that either :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] tachart breaks trunk compilation
On Mon, Oct 08, 2012 at 12:11:38AM +1100, Alexander Klenin wrote: I've looked deeper into it, and it seems Alexander is fond of strict protected and private, but calls getalignment in a not inherited fashion. (on another class) Fixed in r38981 Thanks. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Cute little toy program
On Sat, Sep 15, 2012 at 08:13:58PM +0100, Graeme Geldenhuys wrote: We should add that program to the the collection of odd apps. I have written one (code is still somewhere on my system) that calculates the Stardate (as defined in the Star Trek series). For the life of me, I don't know why I needed it, but it is written. :-) I can donate calculating Easter and all movable holidays in FPC 0.99.8 style assembler :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Process ID
On Fri, Sep 14, 2012 at 08:06:38PM +, Mark Morgan Lloyd wrote: In Linux, everything is (accessible as if it were) a file (or a directory). This is a _good_thing_. Yeah. Everybody doing his own parsing of system textfiles is *such* a good principle to build durable applications on *g* I think it was you who made the point earlier that doing this the Linux way takes multiple syscalls to enumerate the content of directories in the /proc or /sys tree. That's obviously valid criticism, but at the same time I'm not sure there's a better way to handle a complex structure with version- and system-specific elements (example: /proc/cpuinfo is grossly architecture-specific, even for basic things like counting the number of CPUs). You miss the point. The /proc structure for the most doesn't even address that since it often packs more than one value into one file. In such it is worse than its direct competitor on Windows, the registry. but this would be difficult on account of /proc and /sys being an unstructured mix of stuff defined by the architecture and stuff changing every nSec. That was exactly the point of my reply to a msg that tried to glorify /proc. I'm no registry fan, but at least it tries to keep things separate. Indeed. I wonder whether POSIX has anything instructive to say about this sort of thing? No. Afaik only the per process part of /proc is standarized, and even then in an optional part. Posix is rarely a solution into anything *nix. It is merely the rock bottom most common denomitor. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Process ID
On Fri, Sep 14, 2012 at 11:55:52AM +0200, Michael Schnell wrote: Yet another approach of ransacking the whole disk. /proc is not on a disk. It's a virtual file system that generates it's content only on request. In Linux, everything is (accessible as if it were) a file (or a directory). This is a _good_thing_. Yeah. Everybody doing his own parsing of system textfiles is *such* a good principle to build durable applications on *g* -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Process ID
On Thu, Sep 13, 2012 at 09:08:19AM +, Mark Morgan Lloyd wrote: So be fair, I don't think I have ever come across a Linux distro that doesn't include the ps binary as standard. And I have used Linux since 1996. Even *BSD and *Solaris include the ps binary as standard too. Yes, but the ps parameters vary. I'm using this stuff in my FPC build script on Linux and Solaris. Can anybody say what the xBSD situation is? What's in /proc/nnn ? In BSD /proc/a pid contains [marcov@dragon ~]$ ls /proc/44539 cmdline ctl etype filemap rlimit status [marcov@dragon ~]$ but afaik BSDs can turn /proc off, and this is commonly done so on servers. /proc is only a SysV compatibility feature there, most BSD-own tools work via other interfaces (like sysctl(3)) Turning it off is getting rarer though (probably linux converging). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Process ID
On Thu, Sep 13, 2012 at 03:33:25PM +, Mark Morgan Lloyd wrote: Yet another approach of ransacking the whole disk. This time just to get a process ID. Is that state of the art software developement? There is no other way doing it on Linux? [Sigh] /proc is a special filesystem which the kernel uses to expose information about each process. Apart from the fact that it is mounted into the standard filesystem namespace, it has absolutely nothing to do with a physical disc. Still it is at least one syscall to enumerate the dir and then 2-3 syscalls (open/read/close) to get a value. Not counting fileexists() which is probably another syscall. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parsing command line options
On Mon, Sep 10, 2012 at 05:39:20PM +0200, michael.vancann...@wisa.be wrote: The main problem is the Windows API, which has only 1 string in which to pass all command-line options. IMHO this is not a Windows problem. There are two problems as I see them, one being that APIs only accept one cleanly normalized form (be it as an array of arguments, or with exact quoting rules), and that the common notation must be rewritten to those rules. This always needs some filtering and cleaning. The second problem is that the common everything on one line notation is OS specific, and even within an OS is fragmented between shell and API rules. (windows too, shellexecute createprocess, though the differences are smaller) This significantly increases the need for rewriting (one could argue that notation like --xxx=yy xx is an unixism) that is not strictly necessary. As already said in similar discussions on the FPC maillist: nearly _every_ FPC version had changes in quoting and new bugs/featurerequests. In 2.0.x/2.2.x times, some of those even have been a problem for lazarus. Most of these changes also have not been minor, and quite often newly introduced bugs have been fixed just barely in time, between the RC and release. Already in 1.9.2, executeprocess() was added that fixed this issue for the more procedural interface. All the older versions have slowly been deprecated and removed (a still ongoing process) So in short, the tprocess maintainers (mostly Michael and me) have said enough is enough. The primary, supported way to hand parameters to tprocess is to deliver them separated, and cleansed of unnecessary quoting. This mostly fixes the second problem. The first problem is more minor. (and can often be fixed by simply stripping quoting before passing it. We hope this will allow for a more stable interface, and I heartily recommend it for any non-trivial use. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parsing command line options
On Mon, Sep 10, 2012 at 05:19:35PM +0200, J.A. de Vries wrote: on *nix). The 3rd step is to add each parameter using TProcess.Parameters.Add. It is kind of a middle ground though I definitely support your suggestion if doable. Parsing a command line is a can of worms! Might I make a suggestion? Why try and invent the wheel ourselves? There's a very good library named getopts that has been used by masses of programmers for years now. Maybe we could learn from that and re-implement the choices made in there? Besides the already named problems, that library and its principles are unix-centric. Though that matters less than in the past. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Passing a section of an array to a function.
On Mon, Sep 10, 2012 at 02:29:14PM +0200, Sven Barth wrote: The delphi compatible way is slice, but ti was only documented after the last release: http://bugs.freepascal.org/view.php?id=22681 I did know about Slice, but not about the possiblity to use ranges directly (and now I know what the corresponding code in the parser is for :P ) Afaik it was one of those FPC must find its own way, and not slavishly follow Delphi features. Usually orphans at birth. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parsing command line options
On Sat, Sep 08, 2012 at 10:34:37PM +0300, patspiper wrote: Depends. Split arguments for TProcess use (like in the above bugreport): afaik none. Simply keep all arguments separate and pass them to the parameters propery. Keeping arguments separate may not be possible: Not *easily* possible. Not impossible. http://permalink.gmane.org/gmane.comp.ide.lazarus.general/64781 That's why the old option is still available deprecated for a while. But no new functionality will be added. IOW it will remain compatible to how it was when it was deprecated (2.6.0 compatible). If you can't change it out of compatibility, this will be no problem, since the current interface should be exactly compatible to 2.6.0 and before. However, splitting the command line with the separator being an unquoted space should be good enough. No it wouldn't, since -xx=bla needs to be dequoted on windows (and I assume OS/2) too. Your message is a very good example why the whole splitting and escaping approach was abandonned. Every issue was considered to be just add this, since then it works for me now, but after multiple years of such changes, there are still corner cases left. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Passing a section of an array to a function.
On Mon, Sep 10, 2012 at 10:47:33AM +0200, Sven Barth wrote: func(buf[32 .. Last index of the array]); reference: http://www.freepascal.org/docs-html/ref/refsu59.html And it's still true: even I as a compiler developer can learn something new as I didn't know yet that this was possible. The delphi compatible way is slice, but ti was only documented after the last release: http://bugs.freepascal.org/view.php?id=22681 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Parsing command line options
On Sat, Sep 08, 2012 at 06:38:40PM +0300, patspiper wrote: This is related to http://bugs.freepascal.org/view.php?id=22751 - What FPC/Lazarus functions are available to parse a command line (where parameters begin with a dash)? Depends. Split arguments for TProcess use (like in the above bugreport): afaik none. Simply keep all arguments separate and pass them to the parameters propery. In case of the callee, see the unit getopts. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] lazarus archive [increasingly OT]
On Thu, Sep 06, 2012 at 02:47:40PM +0100, Martin wrote: ??? ? ? ??? ? ? ?? Very interesting message. Please fix mail client :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Mon, Aug 27, 2012 at 03:15:43PM +0200, Michael Schnell wrote: On 08/24/2012 10:36 PM, Marco van de Voort wrote: I read that as that there will be ref counted objects, not that all objects will be ref counted per se. -- Ok, but if there are reef-counted objects what is the point in not using them ? Because they might not only have advantages? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Tue, Aug 28, 2012 at 12:08:05PM +0200, Felipe Monteiro de Carvalho wrote: Does anyone know if: 1 It will be possible to choose if a class or object is to be ref-counted? How? 2 If all existing objects will suddenly be ref-counted? No. The above is all I have seen. I think it is an interresting addition, if it is something that one can choose on a per-class basis and should be off by default in existing classes. GC has absolutely nothing to do with mobile, so I have no idea why they mixed both. I doubt that is possible. The non GCed classes would not have the events to handle the non ref counted classes. References from non ref counted classes to ref counted classes etc would not work. Something like that is only possible with completely separated hierarchies (like Firemonkey). I'd much prefer multiple inheritance if they are feeling like adding more language features. I much prefer they simply fix bugs and increase optimization. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Sun, Aug 26, 2012 at 10:53:53PM +0200, Felipe Monteiro de Carvalho wrote: On Sun, Aug 26, 2012 at 9:23 PM, Marco van de Voort mar...@stack.nl wrote: Then you will also see that your Office counterexample is irrelevant, since app store rules don't apply to Office. (but they do to nearly everybody else). I am not aware of any app store rule that says that people need to use native controls and cannot use controls which merely immitate native ones. I think that I would have heard if Qt apps were prohibited in the Mac app store for example, remember that Qt is not native. So please show the rule which prohibits custom drawn apps (seriously, it would be something interresting to know if it exists). If there is no such rule, then your entire point makes no sense, since it presuposes such a rule. The point is that the VCL styles are a different binary type (win32) than allowed in the store (WinRT) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Sat, Aug 25, 2012 at 02:38:23AM +0100, Graeme Geldenhuys wrote: On 24/08/12 21:38, Marco van de Voort wrote: And the TUFKAM(*) option is a skin, not native, and thus not marketstorable. I don't think the skinning is a big deal at all. Especially if you consider that Microsoft itself created a metro skin for their flagship product - Microsoft Office. Yes the new MS Office is NOT a real metro app, but has the metro look. Yes, I know your allegiances lie with owner drawn :-) But try to see beyond the obvious, the bit is that from what I saw they mumble over appstores and metro, but never admitting that they don't go together. (same as that they mumble about mobile without shipping either an own or FPC's arm compiler) Then you will also see that your Office counterexample is irrelevant, since app store rules don't apply to Office. (but they do to nearly everybody else). And then I'm even ignoring that the scale of something like Office is beyond what nearly everybody can manage, including investments in making owner drawn UIs very close. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE invocation of lhelp, probable endianness issue
On Wed, Aug 22, 2012 at 02:35:47PM +0200, Sven Barth wrote: Running lhelp from a shell using gdb gives me Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 25970)] 0x0038c844 in _$CHMREADER$_Ll594 () at src/chmreader.pas:1144 1144ind:=LEToN(plongint(head)^); I'm not familiar with the chmreader code. Please create a bug report. At least it's a pointer dereference... so there must indeed be some misalignment going on... I think a lot of internal records are read that way. Arbitrary pointers are pointed to records in buffers (decompressed datastructures), and then iterated like this. So there might be hundreds of such cases. Afaik alignment is hardly tested, and endianess only quick. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Wed, Aug 22, 2012 at 11:44:14AM +0200, Michael Schnell wrote: On 08/21/2012 01:01 PM, Howard Page-Clark wrote: http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/ Besides, technically, I read that Objects will become reference counting and thus .Free gets obsolete (like in Prism). I read that as that there will be ref counted objects, not that all objects will be ref counted per se. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Wed, Aug 22, 2012 at 06:09:00PM +0100, Graeme Geldenhuys wrote: On 21 August 2012 12:01, Howard Page-Clark h...@talktalk.net wrote: If you have not seen it, users of Delphi XE2 may be interested to read And the big news is that the soon to be launched XE3 will not ship with FireMonkey or FPC or any iOS development tools for that matter. Wow, I can see quite a few ISV's (eg TMS) being pretty pissed of now, spending lots of money building 3rd party components for FireMonkey - all for nothing! And the TUFKAM(*) option is a skin, not native, and thus not marketstorable. Don't you just hate it when companies like Embarcadero use our hard earned cash for their experiments. Seems they missed their new compiler deadline twice in a row. (*) The UI Formerly Known As Metro. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Delphi post-XE3 roadmap
On Thu, Aug 23, 2012 at 11:50:08AM +0200, Anders E. Andersen wrote: This they will be added at a later date is exactly the point. They release a product as the successor to XE2 and leave those people in the rain that already built upon the mobile components provided by XE2. Well I haven't used XE2 myself, but the impression I get, both from Embarcadero and from others, was that the mobile solution was not really too userfriendly. That was because for XE2 their own toolchain (compiler, linker, debugger) was also not ready, and they had to use FPC, and since FPC relies on Apple's linker etc, and probably gdbing, they invented the workaround tour. If it can be so easily omited, you wonder why they did that for XE2. Same goes for Firemonkey. Even FM enthusiast say that it is not really finished. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Translating the Component Palette tabs
On Sun, Aug 05, 2012 at 10:33:14AM +0200, Sven Barth wrote: It is not an oversight, it is more that a lot of such captions won't be translated anyway, e.g. SynEdit, LazControls, fpWeb, SQLdb. I think that it is better to keep palette not translated at all, than to have a (hard to read and navigate) mix of languages. For the sake of completeness (not that I'm suggesting this as a solution): Delphi translates all tabs of components that belong to the IDE (e.g. Standard, Dialogs, Additional etc.), but not those of 3rd Party components (e.g. I can see Indy Misc in my component palette). I don't know whether you can somehow trigger a translation of your own tab from your design time package... My guess would be: those components don't provide translation dlls, probably because of work and to avoid complicating building too much. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 06:18:24PM +0200, Sven Barth wrote: The main difference though is that they concern different targets, and do not share a Tier 1 target like win9x Nevertheless we have (official) testers for those two targets. They take care for them and even add new features (remember Tomas adding support for TProcess to OS/2 some months ago?). That's currently more love than Win9x gets... Also FreeDOS (on which FPC can run) is an actively developed/distributed platform like is ECOMStation. This is again unlike Win9x. So in my opinion DOS and OS/2 should not be put into the same bin as Win9x. The category was defined as being mostly active during release engineering. Dos and OS/2 (but also e.g. Debian) are together responsible for 80% of the post branching and pos RC1 activity. That is disproportionately much. Win9x has fewer such issues in number, probably because it piggy backs on a major target, but often its issues slip past RC1, causing a Tier 1 target to be rebuild without RC validation (for IMHO next to nothing). At least OS/2 and Dos only risk their own releases. This is the major reason for the splitting proposal. ( Though again, IMHO we should simply stop support win9x in main builds. Interested people can maintain 3rd party builds for a while for the unhappy few. Technical possibilities (slapping external unicode libraries under it etc etc) enough, but IMHO that will all be talk and tinkering, but will never reach a realistic level of releasable quality. If people show they can maintain a 3rd party port to win9x for a whole major cycle, we can always revert and split at that point. But IMHO first show is viable, then infrastructural changes. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] System.Enum.GetNames
On Fri, Aug 03, 2012 at 05:01:27PM -0300, silvioprog wrote: How to I get a list of the names of a specified enumeration type? Eg: http://www.delphibasics.co.uk/Method.asp?NameSpace=SystemClass=EnumType=ClassMethod=GetNames I'm trying to create a function *similar* to implode function of PHP, but to work with enums. Maybe you are looking for something like http://www.stack.nl/~marcov/phpser.zip ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New doc CHM snapshot (RC1 testing)
On Fri, Aug 03, 2012 at 10:40:17PM +0100, Hans-Peter Diettrich wrote: The CHM files are all double spaced in LHelp. This applies to class declarations, unit lists etc. The online (HTML) versions are not double spaced. About a year ago I could fix that by using your CSS file. But I never could figure out what really makes that difference, and found random behaviour regardless of what I tried. Note that FPC's fpdoc chms don't have it, what I think happened: - last time I built with FPC's fpdoc.css - afterwards, when committing I cleaned up paths in the generation script - so now I used Lazarus' fpdoc.css A diff between the two is at http://www.stack.nl/~marcov/fpdoccss.diff -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] (no subject)
On Sat, Aug 04, 2012 at 12:29:02PM +0100, Hans-Peter Diettrich wrote: Why is this relevant to a project which is predominantly European? If Sourceforge can't distribute it because of the laws under which they operate then we should look for an alternative. The restriction is an *international* agreement, not limited to SourceForge or the USA. What restriction? The categorization of SF.NET contains crypto is US only, we had to send a mail to the relevant US ministry even. Nothing International about it. Russia blocked nearly all sanctions and continues to deliver military equipment. We should accept the weird political reasoning, and distribute encryption units only as add-ons. No. Either drop sf.net as hosting or add a minor mirror on free soil, but not complicate everyday work because of it. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Please remove Arabic language from the release version
On Fri, Aug 03, 2012 at 07:57:53PM -0300, silvioprog wrote: I am Pascal programmer for a 20 years, my wife also teacher, teaching students Delphi 7 in English language. Here in Brazil all programmers (yes, ALL) use Delphi in english. Here in the NL, english is fairly common, and nearly all students and professional programmers will use English. In general they often will even have UK Windows and Office versions. (you can enable Dutch spellcheck in it) But many older programmers will use dutch. Not all users will be hardcore IT people, quite some are teachers and I know even realtors doing mortgage calculations on it. And pupils of the teachers. If you are in hardcore IT circles, you won't see such users, but they probably are there. That being said, on the original subject, can't we simply change the default for such languages? IOW that people with arabic locale get English as default, but leave the Arabic option in for people that want to work on it, now or in the future? That fixes the annoyance for the current users, without closing the doors on the alternative. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Adding Lazarus 1.0 RC 1 to version options in mantis
On Sat, Aug 04, 2012 at 10:42:16AM -0300, William Oliveira Ferreira wrote: Could someone add Lazarus 1.0 RC1 in Lazarus Version list on Mantis? I reported a bug some minutes ago and i didn??t see the version on list... Sorry about any english mistakes... Done, I hope the laz devels don't mind. If so, please delete it again. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Please remove Arabic language from the release version
On Sat, Aug 04, 2012 at 06:47:00PM +0200, J?rgen Hestermann wrote: If everybody in the world would start with an english version If you believe that I assume you learned Esperanto ? :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] (no subject)
On Sat, Aug 04, 2012 at 09:24:54PM +0100, Hans-Peter Diettrich wrote: The restriction is an *international* agreement, not limited to SourceForge or the USA. What restriction? See the Wassenaar Arrangement wassenaar.org, Cat. 5.D.2 (encryption software), and the participating states. That is mostly paper, see the FAQ: --- How are regulations on export controls implemented in the WA? Export controls are implemented by each individual WA Participating State. Although the scope of export controls in Participating States is determined by WA lists, practical implementation varies from country to country in accordance with national procedures. --- Afaik the only state that enforces such measures on old encryption, for which code has been been widely available for 20 years, is the USA. Btw, while I'm uncomfortable with the SF.NET situation, I don't like rash matters like switching providers. At least sf.net has been long time stable. It could be a good reason to have at least one separate mirror somewhere to defang the biggest problems, not need to change everything. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] win32 api level testproject for mdi
Hello, Cleaning my harddisk I found a MDI demo (on win32 api level) that I translated in December. I haven't gotten around trying to integrate in Lazarus yet (seeing that the main windowproc very big), but maybe sb wants to have a look: http://www.stack.nl/~marcov/mdidemo.zip Marco -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus and Free Pascal downloads plummeting on SourceForge
On Thu, Aug 02, 2012 at 06:38:47PM -0500, Curt Carpenter wrote: Could it also have had something to do with the release of DelphiXE? XE2 you mean? No, the codebases of the iOS port snapshot are not distributed by us (via sf.net or otherwise). They just took a snapshot, manage that internally and distribute themselves. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 08:28:41AM +0200, Bart wrote: 2.4.2 didn't work on win9x afaik. Only a handful noticed, afaik all of You mean Win9x I guess. All fpc's up and til 2.6.0 still run fine on at least WinMe (don't know about Win98, can't test that). Ah ok. So I could have taken win95 as win9x in general in some msgs. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 09:43:55AM +0100, Graeme Geldenhuys wrote: Ehmm.. I'm trying to contain myself, but WHY does Lazarus 1 and 1+ even support Win9x/ME anymore? Because not everybody feels the need to fix what isn't broken. That is a very strange argument when asking for a NEW version of a development toolchain :_) Why must we always pay the Microsoft-tax simply because Microsoft thinks there latest crapware is better that the previous one - and we all know that isn't always true (Vista anyone?). But that doesn't apply to the win9x set. IMHO the only good reason to run win9x is having significantly less than 512MB memory. win2000 could run decently with 192MB, but is already deprecated (and was always expensive). XP could run with 256MB, but barely, and the requirements due to updates have increased over time. 384MB might be doable, but I haven't tried in ages. And to answer your earlier question, our clients put together has over 2000+ PC's still running Win98. Would you like to tell them they must all instantly upgrade (and pay a fortune) when those systems still run perfectly for there purpose? No. I would sell them an old version. And ask them what their plans are before making assumption. For all that you know they plan to dump them in the bin next month. It has already been pointed out that we are already not exactly the last group or company that cut win9x support, so it can barely come as an surprise. Asking Microsoft, they will obviously tell you NOBODY is still using Win95 or Win98 - but in reality it is quite different. I haven't seen one in years that was not attached/embedded in machinery. (and even that is getting rare) Hardware speced for/delivered with win9x is nineish years old. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 10:26:13AM +0100, Graeme Geldenhuys wrote: So with that I would guess you consider Win 3.1 unsupported for ages too. Yet Microsoft only announced that back in 2008. Now consider when Win 3.1 came out! http://blogs.msdn.com/b/jcoyne/archive/2008/07/09/it-s-the-end-for-3-11.aspx That is sale, not support. We are not removing old releases from FTP yet :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] New doc CHM snapshot (RC1 testing)
Hello, as it happens, yesterday I was working on getting fpdoc from trunk to generate proper CHMs again when RC1 happened. It seems the major fpdoc restructures have been finished (78 patches since 2.6.0, mostly by Michael), and the docs now generate again. As soon as these changes can be considered validated by this release they can be merged to fixes26. So for testing purposes I generated a snapshot based on fixes26 FPC source, and due to the special occasion also the Lazarus RC1 tag. This is also the first release to contain the lazutils.chm Please test an report irregularities in this thread. http://www.stack.nl/~marcov/doc-chm_rc1.zip Marco -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 10:51:51AM +0100, Graeme Geldenhuys wrote: 2.2 a separate win9x branch supported by whomever wants to work on it I actually like Marco van de Voort's idea of creating two target platforms for Windows. That is the most sane comment on this subject so far. It will be very similar to the LCL-GTK1 vs LCL-GTK2 implementation. It also forces the target to carry its own weight, and doesn't force people uninterested to pay attention. But that is something for trunk branch, not for fixes like 2.6 But that works to ways, IOW it also means you can build in a complete unicode emulation without the 99.9% NT majority suffering from it (read: getting endless binary size discussions) (win9x support might be something that will get harder when more unicode centric releases as fpc/trunk.7.1 come out, though the unicode changes are glacial at the moment) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 11:54:21AM +0200, Bart wrote: I sympathize with Graeme and his users. OTOH maintaining Win9x/WinMe support is gonna be a huge task, and who's gonna volunteer for that? The fact that we have this discussion during release time says enough. Breakage only noticed during release time means nobody has been testing with trunk in a long, long time. Signs of a dead platform. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 01:04:13PM +0200, Reinier Olislagers wrote: (win9x support might be something that will get harder when more unicode centric releases as fpc/trunk.7.1 come out, though the unicode changes are glacial at the moment) That does sound like a good plan for FPC trunk. What do we do with Lazarus though? At least the 1.0 code base would presumably need Win9x support. Note that I don't think it is a /good/ plan. It is IMHO simply the only sustainable compromise if win9x must be long term supported in all new releases. (and it is a different question alltogether if we should, IMHO not. If I had my way it would have ended with 2.6.0 already) The only other (and IMHO better) solution is simply branch a FPC and Lazarus that still support it, and minimally maintain that ad infinitum. That means maintaining two installs for people that target win9x, but at least it puts the burden where the pain is. Not on unsuspected devels that haven't touched win9x in ten years or longer. http://wiki.lazarus.freepascal.org/Lazarus_Development_Process#Lazarus_branches_.2F_version_numbers_around_1.0 AFAIU, current trunk is 1.1. We could e.g. branch it off and have a separate Win9x architecture branch based on the (to be created) Win9x branch off FPC trunk in time for 1.2? I don't know the tradeoffs for Lazarus. Widgetset is another dimension to the target platform, so it is an independent choice from what FPC does. Specially with crucial unicode decisions in limbo it is hard to predict a sane course. That's one other reason I don't like committing to support it. The future of FPC/Lazarus must be defined by other things than win95 support considerations. On the other hand, the current situation with nobody doing anything with win9x except whining when the release doesn't work (afterwards) is not going to continue. At least not with FPC. I'm not waiting or repacking on win9x issues popping up during release process anymore. If it is going to be a viable target, people must work and test with it also between releases and with trunk. Same goes for Dos and OS/2 btw. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New doc CHM snapshot (RC1 testing)
On Fri, Aug 03, 2012 at 12:33:50PM +0100, Graeme Geldenhuys wrote: The CHM files are all double spaced in LHelp. This applies to class declarations, unit lists etc. The online (HTML) versions are not double spaced. See attached screenshot. More lhelp problem, though the generated html doesn't deserve a beauty price with p's in tables. Could also be css (wrong css file) related, but I'm not that deep into html. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
In our previous episode, Graeme Geldenhuys said: That is sale, not support. We are not removing old releases from FTP yet :-) But for someone to still want to buy Win3.1 in 2008, there must clearly be some obscure need for it - in this day and age. Weird, I know. :-) I happen to know that. Major OEMs _had_ to deliver machines with a windows version, per agreement with microsoft. Major firms and higher(?) education however have site licenses, also per machine, with significant lower cost per machine then a normal OEM license. So they did order machines from the major OEMs (Dell, HP) with the cheapest licensing option available (Win3.11, OEM price Eur 9 or so), and put their own Windows XP image on it. In the basement of one of our uni buildings there were several containers, each about 1m^3 in size full of 3.1x and 9x licenses, CD without case +certificate shrinkwrapped together (I'm talking about the 2000-2005 timeframe here) So there probably was no need for those versions. It was merely part of a licensing construct/loophole. I'm not working at a company with sitelicensing anymore so I don't know what the current ways are. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New doc CHM snapshot (RC1 testing)
On Fri, Aug 03, 2012 at 03:26:14PM +0100, Graeme Geldenhuys wrote: Please test an report irregularities in this thread. On the first screen after opening the ref.chm file... Michael van Canneyt 's name is garbled. After all his hard work creating those FPC docs, I think we owe it to him to at least get his name right. ;-) That's one way of looking at it. The other is that it were his patches that caused it :-) Seriously, I think we are dealing with a 2.7.1 specific unicode issue, so the first thing to investigate if 2.6.1 also has this problem when the patches are merged. As for the css- double height issue, I'll extract the css file from the old chm and compare. (one can simply extract files using chmls extract lcl.chm actnlist/taction.html and chmls list lcl.chm lists files in the archive ) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 04:35:46PM +0200, Sven Barth wrote: I'm not waiting or repacking on win9x issues popping up during release process anymore. If it is going to be a viable target, people must work and test with it also between releases and with trunk. Same goes for Dos and OS/2 btw. Somehow I have the feeling that we (FPC) have more testers for DOS and OS/2 than for 9x ;) They are mostly the same: Pierre and Tomas. They all share the same trouble of very little activity between releases. The main difference though is that they concern different targets, and do not share a Tier 1 target like win9x -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 04:23:30PM +0200, Sven Barth wrote: But for someone to still want to buy Win3.1 in 2008, there must clearly be some obscure need for it - in this day and age. Weird, I know. :-) In my university's system for Microsoft software I can still download DOS 6.22 and Win 3.11 ;) Maybe their licenses for those are perpetual. But that doesn't mean I want to support them forever :) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Fri, Aug 03, 2012 at 04:38:14PM +0200, Sven Barth wrote: win2000 could run decently with 192MB, but is already deprecated (and was always expensive). XP could run with 256MB, but barely, and the requirements due to updates have increased over time. 384MB might be doable, but I haven't tried in ages. If I'd not run Linux on such a machine I'd prefer to use ReactOS (even if it would crash every now and then) before going near a 9x. :) Depends on if your source of machinery is homogenous (e.g. from some enterprise range), or mis match. I don't know much _practical_ about reactos, but I can imagine driver issues on all sides. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Translations / Localizations for controls at design time
On Wed, Aug 01, 2012 at 08:39:19AM +0200, Reinier Olislagers wrote: http://sourceforge.net/projects/dxgettext/ Some advantages: open source; Automatic extract of name of components from form; Manually include text to translate (addition to the above) using .po files Automatic add translation in .exe (with right-click); Automatic choose of language depending on Local Settings; Manual setting of language (if someone don't want previous option); Very easy to use (even I can use it ;) ) Their website says: Supports for Kylix 3, Delphi 5, 6, 7, 2005, 2006, 2007, 2009, FreePascal, Lazarus and C++ Builder. so perhaps that already has been done? I use this at work for Delphi (2009..XE), and how it works depends strongly on Delphi versions. Unicode versions don't need changes to auto translate resource strings, older versions do. But since FPC's resource system is different anyway, it is hard to predict how that would work out. Basically to internationalize an app in D2009 I had to do the following things: - do something at program startup to select the correct language (like lazarus my apps allow to change language, but require restarts) - extract all strings using dxgettext tools to form .po files. - I (visually) inherit most of my forms from a base form that has a method that initializes the gettext translation routines on form creation - resourcestrings work out the box. - except when used in structured constants. So _() calls must be inserted for those cases - Changed all places where I runtime change text to use resourcestrings and format() variable parts into them The descriptions seem to indicate it uses Windows explorer integration which I personnally hate, but... it's open source ;) I like the editor (GORM) too (at least over poedit). ... and it is available in source. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Thu, Aug 02, 2012 at 08:23:34PM +0200, Bart wrote: Current installer for 1.0RC1 indeed does not run on WinMe. Well, maybe I should have written: I tested the installer for 1.0RC1 on WinMe and it does not run on WinMe. As far as win9x, I've already decided that any win9x problems are no reason to halt for a repack or fix of a release anymore. I'd rather drop it all together, but currently the real problem is always the retrospect Anyhow, as long as the fpc installer runs on win9x I'm happy. And when we drop the win9x platform, I have a valid excuse to update hardware (although it really is a sport maintaining it). IMHO, if win9x support should be continued, the win32 target should be splitted into a separate win9x and win32u target. This has been said several times, but people keep fixing win9x. IMHO it should either fork to its own target or simply stop. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inno Setup no longer supports Windows 95, Windows 98, Windows Me
On Thu, Aug 02, 2012 at 10:31:47PM +0200, Reinier Olislagers wrote: response/aside It would look like: a. an idiotic decision if there is a large number of Win9x users 2.4.2 didn't work on win9x afaik. Only a handful noticed, afaik all of which were SVN users that could patch/compile their own -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus and Free Pascal downloads plummeting on SourceForge
On Mon, Jul 30, 2012 at 10:19:02PM +0200, Florian Kl?mpfl wrote: Free Pascal on SourceForge, but for some reason the download rates of both suddenly seem to be in free-fall! See the attached graphs. Actually I find more the increase and randomness in 2012/2012 strange. I see no reason why suddenly in 2010 fpc gets a popularity boost. Afaik sf merged to a new statistic system, and the old was overloaded and sometimes didn't register for periods of several weeks. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Building help files: the nitty-gritty
On Mon, Jul 23, 2012 at 10:16:04AM +, Mark Morgan Lloyd wrote: Marco van de Voort wrote: Well, the pdf manuals are on average 100-150 pages, but sometimes 300 pages, 40-60% of which is custom per project. Then on top of that, blueprints and BOMs of all mechanical parts. Do you ever have a situation where you need to index into a PDF, and if so how do you cope? No. We don't do help. Stronger even, I haven't really in past jobs either, since those were server apps. So all my helpfile stuff is hobby, but that goes back a long time. I was already dabbling with helpfile systems in my topspeed days (before FPC) I'm looking at something where it would be beneficial to have a collection of electronics info, and I'd want immediate access to a given section. Allowing for the dominance of PDF in that industry, the best I can think of so far is to burst each PDF into pages, and then convert each page back to PDF. Since I don't HAVE TO deploy anything, I only work on long term solutions. IMHO this is not one :-) For the same reason, I don't like the constant Kylix help recommendations either. Fine for isolated cases, but shouldn't be promoted as general thing to do IMHO -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Bug tracker file formats: 7z prohibited?
On Sat, Jul 21, 2012 at 09:39:56PM +0300, Juha Manninen wrote: For me personally this is not an issue because I use Ark (comes with KDE) and it opens pretty much any compression format you can imagine. Also, 7z archiver can be installed to Windows. Sure, but I don't like maintaining a set of compressors for each of the computers I occasionally fix bugs on. Just use zip. If the 7z bit matters, than your case is too big :-) Creating artificial limitations for file formats is not a good idea. Getting example projects (and patches) is a valuable thing and it should be encouraged by being flexible. Another similar issue is the patch format. At least earlier the Git patch format was rejected by developers, although Git is especially good for maintaining local branches for people without commit rights. The only patches I refused were refused because they didn't apply with normal gnu patch and diff. Not because they came from git. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Building help files: the nitty-gritty
On Wed, Jul 18, 2012 at 07:26:29PM +0100, Graeme Geldenhuys wrote: (Only one helpfile per app?) No, you can concatenate multiple help files, specify a help directory (instead of a file), specify an environment variable etc... DocView is very flexible with this. I don't ship Lazarus applications. :-/ Time to speak to your boss then. It's mostly my call. There is nothing much to gain there. At work I use Delphi, but I don't ship help with those either. (though I have in previous jobs). We ship latex generated manuals in PDF format for You guys have it way to easy! :) All our apps must ship with help files, and we have a separate installation PDF. Our end-users are not the most computer literate, but they know everything about Maths and Science. Well, the pdf manuals are on average 100-150 pages, but sometimes 300 pages, 40-60% of which is custom per project. Then on top of that, blueprints and BOMs of all mechanical parts. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Building help files: the nitty-gritty
On Tue, Jul 17, 2012 at 08:15:29AM +, Mark Morgan Lloyd wrote: I'm writing this from the position of an outsider, so am happy to be corrected by Marco, Andrew et al. However if I there are areas that I haven't been able to get my head round after several days scouring the Wiki and Google, it's going to be far worse for a tyro. If somebody thinks I've got things wrong, I suggest that exploring /why/ I've got it wrong and what can be improved is in order. This has all been rehashed umpteen times. The bottom line: It's a work in progress, people seem to start competing projects instead of chipping in. Recent progress is slow or has stalled. The current situation- and this is with Lazarus trunk, not stable- appears to be that HTML keyword-based application help works well provided that you're prepared to tolerate browser startup time. Decompress a zip with the html help on an ARM with SD or something else slow. Then the browser startup isn't the worst bit anymore. (I've seen the FPC installer do over 30 minutes of decompression on dos, and that was when the docs were far smaller. The rest of FPC installed in 2 minutes) However, even worse than the startup delay is the fact that in the general case neither the IDE nor general apps can tell an existing browser to change the page it's displaying: I believe there's a backdoor for this sort of thing in IE on Windows but on unix you can end up with multiple browser instances that don't go away when the program's shut down. It's not really IE. It is simply true browser instrumentation vs cheap and easy fire and forget browser launching. I very much look forward to the CHM reader being made available for apps rather than just for the IDE, I'm starting to code what could be my magnum opus and I'd like the opportunity to exercise it. I don't know if Andrew is still actively working on lview. I never worked on the visual part. That's because I originally came to work on CHM from the textmode IDE side, not Lazarus. The end user is entitled to have all files of a particular type (chm in the current case) look and handled the same, but I'm not sure it should be the developer's choice which program is opened for a given file type, unless he is prepared to take full responsibility for things going wrong in other apps. This is too vague and generic. look and handled the same from where? From the explorer, I agree, that is the users choice. But the help is lauched from the app, not the explorer, and thus the app developer's responsibility. We all would like it otherwise, but on *nix it has been that way for a while, and it doesn't look like it is going to change soon. As a general point, current desktops (including KDE and Gnome) have a standardised set of programs for opening files by extension (xdg-open etc.), and to be quite honest I think it's not to the credit of anybody who tries to open a browser or viewer without reference to these. xdg-open is opening a document (and even then only the gnome-KDE lowest common denomitor only. I'm pretty sure KDE apps don't call their help or instrument eachother via xdg-open) I'm instrumenting an application, for which there is no standarized set. KDE and Gnome afaik both have separate instrumentation (ORB like) systems, which often change on major releases. The canonical tool appears to still be the Microsoft Help Workshop (or some similar name), and almost everything else appears to be based on this in some way Be careful. That Workshop consists out of two tools, both equally horrid. One is a simple editor for help projects, and one is the compiler. You can do without an editor (just generating a hhp project from some other source), and chmcmd is rougly equivalent with to the compiler. Most CHM authoring tools call the MS compiler in the end. With some crafting you can simply use commercial authoring tools and then export it to a hhp project (or rescue that from %TEMP% while compiling). Or just create html, and use the DOM tool chmcmd is rough, but I have gotten reports of people using it ON WINDOWS to workaround bugs with the MS tool (which seems to have problems with big files) :_) Being able to enable the multi-core compression which is in CHM, but not stable would be another really big boon. Anyway, the chmcmd compiler should work for most basic projects. A simple editor that allows you to add html to a project, scan it for labels and/or outlines should be easy, as long as you control where the html is coming from. : chmcmd is pretty much unique, to the extent that I've seen a Debian bug report asking why it's not packaged separately because of it's general usefulness. Well I expanded chmcmd a bit in the last few releases to become a .hhp compiler (before it was only rudimentary access to the chm writer class, I basically added the same, but to/from the .hhp ini like format, implemented recursive scanning for additional files). But the real
Re: [Lazarus] Building help files: the nitty-gritty
On Fri, Jul 13, 2012 at 02:38:53PM +0200, Mattias Gaertner wrote:
lhelp will open them manually, but keyword help in the IDE (e.g. F1 on
begin or {$i) doesn't. I get IDE popups like 'Help keyword
FPCKeyword_begin not found.
lazarus-trunk$ find . -iname '*chm'
./components/wiki/chm
./docs/chm
./docs/chm/toc.chm
./docs/chm/user.chm
./docs/chm/fpdoc.chm
./docs/chm/prog.chm
./docs/chm/fcl.chm
./docs/chm/rtl.chm
./docs/chm/ref.chm
./docs/html/lcl/lcl.chm
Add the ref.kwd file too.
ref.kwd shouldn't be needed anymore since 2.4.2, since then the ref.kwd has
been processed into the ref.chm index.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
