Re: [fpc-devel] @Gareth messages thread
On Tue, Jul 31, 2018 at 12:30 PM, wrote: > On 07/31/2018 06:10 AM, Dimitrios Chr. Ioannidis via fpc-devel wrote: >> >> Hi Gareth, >> >>could you please try again to fix the threading for your messages ? > > > > he'll have to switch readers or somehow cause the one he's using to properly > use and update the References line(s) in the headers... right now, none of > his posts have References lines in them even though the posts he's > responding to have them... > > >>It's hard to follow your very interesting conversation's without proper >> list thread support. > > > > i agree completely and asked him about this a week or so ago... > > Everything is fine here, can the people reporting an issue describe their email client and service provider? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 2:40 PM, J. Gareth Moreton wrote: > As mentioned before, the main problem with try...finally blocks is that they > incur a massive speed penalty, so they're not things you want to enter and > exit on a frequent basis. Whether that means we need to work on the compiler > so it reduces this penalty on such blocks (such as internally removing the > construct and copying the code in the 'finally' section into a local > exception handler) I'm not sure. > > I do agree though that we should manage memory with care, especially as > Pascal gives us such fine control over it (compared to, say, C++'s RAII > feature which is a little nebulous at times with its garbage collection). I > think first though we need to fix any obvious memory leaks, namely objects > and blocks of memory that we forget to free, then build up from there. At > least that will help reduce the risk of an out of memory situation during > normal operation. > > Gareth aka. Kit > Adding locally allocated structures to a global list is a pretty gnarly issue that will take some time to solve. The easier ones are simply using labels to easily manage exit conditions. It looks a lot nicer than nested if statements. The issue with such code is it is fairly boring to write, so I understand if someone didn't do it initially. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 11:42 AM, Marcos Douglas B. Santos wrote: > On Mon, Jul 30, 2018 at 12:29 PM, R0b0t1 wrote: >> On Mon, Jul 30, 2018 at 7:32 AM, Martok wrote: >>> Am 30.07.2018 um 14:24 schrieb Marcos Douglas B. Santos: >>>> Is performance more important than being correct? :| >>> In this project, the answer is always taken to be yes. >>> >> >> To hopefully offer some explanation for Mr. Santos - if I can compile >> and run the program 5 times over the course of 20 minutes, that is >> certainly better than running it and testing it once over the same >> amount of time, no? >> >> It might be hard to imagine FPC taking that much longer than it does >> currently but ~30min for a large program is the standard with other >> compilers. I very much enjoy the speed of FPC. > > All us like fast compiling... > However, IMHO, a compiler should use the same good practices that > others programs must use. > If it cannot use them because it's very slow, what is the matter about > good practices? > > "Do what I'm telling you to do, but don't do what I do" ? :) > If a program isn't long running I see programmers tend to not care about memory management, nor do I make a habit of caring about it myself. I find it hard to see anything wrong with this. As someone has mentioned this can fail on smaller computers, but how much RAM is too little? SBCs now typically come with 1-4GB of memory. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 10:24 AM, Michael Van Canneyt wrote: > > > On Mon, 30 Jul 2018, Sven Barth via fpc-devel wrote: > >> Michael Van Canneyt schrieb am Mo., 30. Juli >> 2018, >> 15:30: >> >>> Obviously provided you don't install another mechanism that does this and >>> don't raise exceptions manually, which - AFAIK - is the case in the >>> compiler... >>> >> >> The compiler does use exceptions when the compilation needs to be aborted >> e.g. when too many errors occurred or an internal error is encountered. > > > This is bad news, because it in effect means that the try/finally is > necessary > if people want to fix memleaks :( > > This will considerably slow down the compiler. > I would very much like to see the compiler usable as a dynamic library. Compartmentalizing the bulk of the code in this manner might aid readability and comprehension even if it is not immediately wise to actually use the shared object in a third party application due to memory leaks. I wouldn't mind running some static analysis on FPC in an attempt to get rid of memory leaks. It's fairly mechanical and probably a good introduction to the codebase. This page[1] is promising as it indicates valgrind should work well on FPC binaries (I didn't have much a reason to expect otherwise, but you never know). Is there any reason this hasn't been done? What could raise statements be replaced with if they must be replaced? Cheers, R0b0t1 [1]: http://wiki.lazarus.freepascal.org/Profiling ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 10:35 AM, Michael Van Canneyt wrote: > > > On Mon, 30 Jul 2018, R0b0t1 wrote: > >> On Mon, Jul 30, 2018 at 7:32 AM, Martok wrote: >>> >>> Am 30.07.2018 um 14:24 schrieb Marcos Douglas B. Santos: >>>> >>>> Is performance more important than being correct? :| >>> >>> In this project, the answer is always taken to be yes. >>> >> >> To hopefully offer some explanation for Mr. Santos - if I can compile >> and run the program 5 times over the course of 20 minutes, that is >> certainly better than running it and testing it once over the same >> amount of time, no? >> >> It might be hard to imagine FPC taking that much longer than it does >> currently but ~30min for a large program is the standard with other >> compilers. I very much enjoy the speed of FPC. > > > 30 *Minutes*, is this real ? > > Hm. I just complained to a component provider because Delphi takes 25 > seconds to compile my program with the way they set up their paths... > This is real.[1] I've experienced it myself and you can see some good discussions on https://news.ycombinator.com with a search. FPC/Lazarus has made some waves there in the last few years. FPC does have quite a bit of a lead it could shed in an attempt to be "more correct" but I would caution against this. If at every point in a software stack someone says "modern computers are just so fast, we have a little bit of wiggle room" you end up with something slower than molasses. Perfection requires effort at every single step. A good case study on this is keyboard latency in modern systems.[2] Cheers, R0b0t1 [1]: The most extreme comparison was closer to being something like a couple of minutes vs. a couple of hours, but I can't source that right now. Most people think it's a lie; granted, some of it is likely due to the excellent incremental compilation FPC has by default. [2]: https://danluu.com/keyboard-latency/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?
On Mon, Jul 30, 2018 at 7:32 AM, Martok wrote: > Am 30.07.2018 um 14:24 schrieb Marcos Douglas B. Santos: >> Is performance more important than being correct? :| > In this project, the answer is always taken to be yes. > To hopefully offer some explanation for Mr. Santos - if I can compile and run the program 5 times over the course of 20 minutes, that is certainly better than running it and testing it once over the same amount of time, no? It might be hard to imagine FPC taking that much longer than it does currently but ~30min for a large program is the standard with other compilers. I very much enjoy the speed of FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compile time functions
On Fri, Jul 20, 2018 at 7:08 PM, Sven Barth via fpc-devel wrote: > Martok schrieb am Fr., 20. Juli 2018, 23:20: >> >> >> What do you think? > > > The main problem is that not all functions that would be eligible for your > approach are also declared as inline thus their node trees would not be > stored inside the PPU and thus you could not work with them. > Additional benefit of the "pure" modifier: the compiler can check once the > method has been parsed whether it's pure or not and can thus error out in > the latter case. > How does the existing constprop optimization relate to the pure modifier? I apologize if this was already covered. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Progress of pure function research
On Mon, Jul 16, 2018 at 12:01 AM, J. Gareth Moreton wrote: > Hi everyone, > > So I thought I'd do a little progress update on the pure function research. > > So far I'm mostly researching how the node builder works, specifically how > inline > functions are handled, since that's a situation where a 'call' node is > effectively replaced, and I intend to builda similar system to handle pure > functions. > > Designing an emulator to step through the nodes is a little tricker if only in > regards to where it should slot into the project. It's a fun challenge, but > probably one of the most technical problems I've undertaken to date. > > The full design is a little awkward because I want to cover every eventuality, > which is hard to predict. Fully self-contained functions with only a single > output parameter (i.e. the result) are relatively straightforward as I don't > have > to handle any calls to other pure functions, and the 'call' node can be > replaced > with a node representing a literal of some kind once it's calculated, but it > gets > more complicated if other pure functions are called inside it, there are 'out' > parameters or there are difficult situations like infinite loops or code paths > that simply take too long to complete. There's also testing required to see > if > the functions still work with partial compilation (i.e. where some PPU files > aren't rebuilt). > > As stated in the Wiki page, my first test case is the Max function. Since it > works both as an inline and a pure function, I can easily change the > directive to > analyse the code flow in the compiler. > The discussion about the potential implementation left me a bit confused. I think part of what might need to happen is a better type system, in part to keep track of constant expressions. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue #32913
On Sat, Jul 14, 2018 at 1:54 PM, Martok wrote: > Am 14.07.2018 um 20:41 schrieb Dmitry Boyarintsev: >> Exiting from finally? Is it something new?0 >> >> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/cm_cant_leave_finally_xml.html > Still documented for Tokyo: > <http://docwiki.embarcadero.com/RADStudio/Tokyo/en/E2126_Cannot_BREAK,_CONTINUE_or_EXIT_out_of_a_FINALLY_clause_%28Delphi%29> > > Although the example is of course wrong, the way it's given would be 'E2097 > BREAK or CONTINUE outside of loop'. Just substitute "break" with "exit". > Are they not allowed in a finally clause? > Control flow statements are allowed in an EXCEPT block. Come to think of it, > didn't we have another TRY/FINALLY/EXCEPT nesting issue that might have > something to do with that? > If the above is true then this confuses me. Except should run before finally, so if you use flow control in an except block then the finally clause "shouldn't" run. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 4:43 PM, Thorsten Engler wrote: >> -Original Message- >> From: fpc-devel On Behalf Of >> R0b0t1 >> Sent: Monday, 9 July 2018 07:22 >> >> There were some other comments touching on reasons for or against a >> keyword, and I apologize for not speaking to them precisely. But, >> this is why I would like to avoid a keyword - it is redundant. > > People keep talking about keywords. As shown in the examples, pure is not a > keyword. It's a context-sensitive directive. This is already wrongly stated > in the proposal itself (so people can be excused for picking up on the use of > the term "keyword" in the proposal) and it should be fixed (in the proposal). > > And it's not redundant. You are telling the compiler: I want this function to > be pure. Please tell me if I made a mistake. > I suppose the language I should have used was "reserved word." After having been explained that the token would only have special meaning in function declarations I feel a bit better, but would the highlighter also be context sensitive? The IDE has a habit of bolding valid identifiers for I think this very reason, and it is rather annoying. The supported dialects of Object Pascal is quite cluttered. That can in part be attributed to the existence of Delphi mode... I don't want to oppose all progress and think this is a worthwhile optimization, I would just ask that partially aesthetic issues like this be considered. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 12:33 PM, Marco van de Voort wrote: > In our previous episode, Florian Kl?mpfl said: >> > >> > It doesn't explain why you chose for a modifier rather than preprocessor >> > switch. >> >> Why a preprocessor switch for something which applies to a particular >> function? > > Maybe. But this kind of stuff will be rare, and is only an hint to speed up > parsing. I think having a directive is a bit too much honor. > > Maybe it is time for an attribute system? > There were some other comments touching on reasons for or against a keyword, and I apologize for not speaking to them precisely. But, this is why I would like to avoid a keyword - it is redundant. As noted only certain statements are constant. If marked so the compiler must verify they are constant anyway. So, what makes more sense is determining the constexprness of an expression by analyzing each subexpression. If an expression is made of only constant expressions it too is constant. The information *must* already be there. It would be best to not introduce another keyword and to keep the user from worrying about it. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 9:50 AM, J. Gareth Moreton wrote: > Hi everyone, > > With some blessing from Florian on the concept, I've set up a Wiki page > discussing the design proposals for the support of pure functions, as well > as some explanation on what they actually are. > > wiki.freepascal.org/Pure_functions > > I hope it proves useful to explain what I'm doing. How do the proposals look > so far, Florian? > > Gareth aka. Kit > This is usually done without a keyword. Why add a keyword? If a keyword must be used, I'd appreciate if they weren't taken from the English language. Doing so is liable to make older code that uses variables of the reserved word's name incompilable. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multiple variable initialization
On Sat, Mar 24, 2018 at 10:53 AM, Jonas Maebe <jo...@freepascal.org> wrote: > In the end, pretty much every extra language feature makes both the compiler > and the language more complex. Therefore, I think the question for language > extensions should never be "is there a good reason not to allow this", but > "is it really necessary to allow this"? I.e., does it make things much > easier to read, less error prone to write, and/or increase productivity a > lot. I don't think the answer is "yes" for any of these questions as far as > this extension is concerned. > For the record the Oberon languages were designed with this philosophy in mind, and language changes only ever removed functionality (which did not happen often). Those languages never saw wide adoption but are very interesting specimens of engineering. I might agree with an addition similar to Python's tuple unpacking in assignment, which would allow multiple assignment but require multiple values: var A, B: Integer = 0, 1; C, D: Integer = 0, 0; However in some languages this is without good precedent or justification within the language, and seems like an unnatural bolted-on feature. Far more important I think is partial initialization of arrays and records. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix CamelCase in unit and method names
On Thu, Mar 22, 2018 at 10:18 AM, Juha Manninen <juha.mannine...@gmail.com> wrote: > On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov <dez...@gmail.com> wrote: >> Please do... It has caused enough eye (OCD) stress over the years ;) > > +1 > Yes, it has bothered also me a lot. I use code completion to get the > unit names correctly. Most of them are CamelCase but some are > lowercase. The result looks sloppy. Maybe it is OCD, don't know. It > bothers me anyway. > I agree it looks sloppy. Something else that has bothered me, but a lot less, is the conflicting naming standards. E.g. Contnrs "should" really be Containers, more like Delphi; the former is more of a C style that you find when everything is lower case and abbreviated, which is not really the style I see most Object Pascal programmers adopt. I apologize for the unwarranted opinion, but it had been bothering me for a while. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix CamelCase in unit and method names
On Thu, Mar 22, 2018 at 6:42 AM, Michael Van Canneyt <mich...@freepascal.org> wrote: > > > On Thu, 22 Mar 2018, Ondrej Pokorny wrote: > >> Hello, >> >> will a patch be applied that fixes CamelCase in unit and method names and >> other identifiers? >> >> Example: >> >> dateutils -> DateUtils >> sysutils -> SysUtils >> typinfo -> TypInfo >> contnrs -> Contnrs >> strutils -> StrUtils >> EnterCriticalsection -> EnterCriticalSection >> DoneCriticalsection -> DoneCriticalSection >> LeaveCriticalsection -> LeaveCriticalSection >> TryEnterCriticalsection -> TryEnterCriticalSection >> (Funnily enough InitCriticalSection is correct.) >> >> TPoint.x -> TPoint.X >> TPoint.y -> TPoint.Y >> >> (For unit names: of course only the unit definition name will be changed, >> not the file name). > > > At first sight I don't see any disadvantages from this, so yes, I would > apply such a patch. > > Code completion will benefit from it, I suppose. > I asked about this a while ago; please apply the patches if any are made. On Thu, Mar 22, 2018 at 7:44 AM, Tomas Hajny <xhaj...@hajny.biz> wrote: > On Thu, March 22, 2018 12:42, Michael Van Canneyt wrote: >> On Thu, 22 Mar 2018, Ondrej Pokorny wrote: > > > Hi, > >>> will a patch be applied that fixes CamelCase in unit and method names >>> and other identifiers? >>> >>> Example: >>> >>> dateutils -> DateUtils >>> sysutils -> SysUtils >>> typinfo -> TypInfo >>> contnrs -> Contnrs >>> strutils -> StrUtils > . > . >>> (For unit names: of course only the unit definition name will be >>> changed, not the file name). >> >> At first sight I don't see any disadvantages from this, so yes, I would >> apply such a patch. > > IMHO preferably not the unit names (as in 'unit XxX') - with case > sensitive file names on Unix, this change might increase time for > searching the respective file (somewhat). Obviously, all further > references of the unit (as in 'SysUtils.Execute') should be fine. > I don't understand how it would increase the search time. I believe what happens is all names are converted to lowercase for the search, as in the strings taken from the user or their files and the names taken from the disk are both converted to lower case before comparisons are made. This is why some of the unit names are entirely lower case - they were at some point stored internally as entirely lower case, and no one fixed them (because you have to do it each time you interact with certain IDE GUIs). There may have been some versions of Lazarus that would not allow you to save mixed case file names, or at least made it very hard to do so. I suspect some of the mixed case file names that are not capitalized properly are due to the lack of case sensitivity and code completion. I found some Microsoft projects which misspelled something the same way in each of 4-5 places, probably because the name was typed once and then never fully typed again. Following from the above, very interesting patches would be ones that do not automatically lower case file names in Lazarus. Cheers, R0b0t1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
