Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Michael Van Canneyt schrieb am Do., 12. Dez. 2019, 15:34: > > It was already mentioned, that the [] can be dropped if the array has > > *exactly one* element. > > Not sure what you mean here, but even if there is only 1 argument, today > the [] cannot be dropped: > > home:~> cat tf.pp > program t

Re: [fpc-devel] Object/Pointer Swap Intrinsic

Am 12.12.2019 um 00:34 schrieb J. Gareth Moreton: That's true.  Given I specialise in optimisation, I've started to venture towards the node level to see where improvements can be made. One question I do have in that regard... are platform-specific nodes allowed? What I mean is, for example, a

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 11.12.2019 um 23:40 schrieb Ryan Joseph via fpc-devel: On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt wrote: It does gain something: it tells you it is NOT a varargs, but an array of const, which is a different beast altogether. But it's a syntax equivalent for "a variable amount of arg

Re: [fpc-devel] Refactoring TVMTBuilder

Am 05.12.2019 um 13:48 schrieb bla...@blaise.ru: 1) Currently, the following snippet vmtbuilder:=TVMTBuilder.Create(...); vmtbuilder.generate_vmt; vmtbuilder.free; is present @ types_dec :objectdef generate_specialization_phase2 :objectdef jvm_maybe_create_enum_class    

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: On 08.12.2019 22:30, Sven Barth wrote: there is no official way to access such parameters 1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC developer. While it is not truly official, it is pretty close, and

Re: [fpc-devel] Object/Pointer Swap Intrinsic

Am 11.12.2019 um 07:26 schrieb J. Gareth Moreton: Hi everyone, I was wondering... is there an intrinsic in Free Pascal that swaps the pointers stored in two object or pointer variables? That is... something like "procedure SwapAddresses(var Obj1: TObject; var Obj2: TObject);" so after it is c

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Ryan Joseph via fpc-devel schrieb am Di., 10. Dez. 2019, 22:29: > > > > On Dec 10, 2019, at 11:38 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > First of Object Pascal supports "array of const" which is safer

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Ryan Joseph via fpc-devel schrieb am So., 8. Dez. 2019, 23:26: > > > > On Dec 8, 2019, at 2:30 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > And no, your patch WILL NOT allow that. We've consciously decided > AGAINST impl

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 22:46 schrieb bla...@blaise.ru: On 07.12.2019 21:39, Sven Barth wrote: I'm arguing that there is no builtin way to *access* the parameters passed in such a way. You are arguing that /now/, but it is not what you said earlier. You said, verbatim: one can not access VarArgs par

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 14:31 schrieb bla...@blaise.ru: your argument with VarArgs does not count either: one can not access VarArgs parameters inside a Delphi function (without resorting to assembly) Again, you are misinformed. I understand that you may not use DCC as much or at all, but you have

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 10:28 schrieb Jonas Maebe: If there is a consensus that this is a blocker, I am ready to do the work ASAP. provided we select the syntax. Personally, I am inclined towards these three: type M = procedure (const N: Integer) with var; type M = procedure (const N: Integer)

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 07.12.2019 um 01:00 schrieb bla...@blaise.ru: Beforehand, to provide a context, here are some excerpts from private correspondence: On 11.12.2016 22:00:37 +0300, bla...@blaise.ru wrote in 1c51a35a-bbbc-c99d-232f-0bf6529df...@blaise.ru: my progress thus far 9) Method reference directives ar

Re: [fpc-devel] Remnants of VMT regeneration

Am 01.12.2019 um 19:33 schrieb bla...@blaise.ru: TVMTBuilder.generate_vmt has _class.resetvmtentries; and TVMTBuilder.generate_vmt_def has { the VMT definition may already exist in case of generics } if assigned(try_search_current_module_type(vmtdefname)) then   exit; Thus, it

Re: [fpc-devel] Memory leak @ tobjectdef.getcopy

Am 01.12.2019 um 18:08 schrieb bla...@blaise.ru: On 01.12.2019 19:15, bla...@blaise.ru wrote: With the following two exceptions, there are no other assigned(vmtentries) checks before dereferencing. And one assertion @ TVMTBuilder.generate_vmt : if assigned(_class.childof) then   begin

Re: [fpc-devel] Autogenerated names for internal RecordDefs

Am 01.12.2019 um 11:02 schrieb bla...@blaise.ru: On 30.11.2019 20:47, Sven Barth via fpc-devel wrote: Am 30.11.2019 um 13:27 schrieb bla...@blaise.ru: { This is a resubmission of https://lists.freepascal.org/pipermail/fpc-devel/2019-August/041915.html } trecorddef.create_global_internal

Re: [fpc-devel] Memory leak @ tobjectdef.getcopy

Ryan Joseph via fpc-devel schrieb am So., 1. Dez. 2019, 19:06: > Blaise how are the closures coming? I think you have enough done you could > submit it into trunk so we can start testing. Please if you can get to this > we have people willing to help. It's been some 6 months now since I offered >

Re: [fpc-devel] Autogenerated names for internal RecordDefs

Am 30.11.2019 um 13:27 schrieb bla...@blaise.ru: { This is a resubmission of https://lists.freepascal.org/pipermail/fpc-devel/2019-August/041915.html } trecorddef.create_global_internal generates internal RecordDef names as '$InternalRec'+tostr(current_module.deflist.count) However, since

Re: [fpc-devel] Request to remove "movzwl %ax, %eax" -> "andl $0xffff, %ax" optimisations

J. Gareth Moreton schrieb am Mi., 27. Nov. 2019, 18:08: > Hi everyone, > > Specifically to Florian, Jonas and Pierre, I would like to remove the > "movz-> and" family of optimisations from the x86 peephole optimiser > because the zero-extension commands no longer have the performance > penalty th

Re: [fpc-devel] dyn packages [[was: Re: inline... and philosophy]]

Martin schrieb am Fr., 22. Nov. 2019, 19:29: > On 21/11/2019 22:56, Sven Barth via fpc-devel wrote: > > In the meantime I've managed to fix the dynamic package support that > > had experienced a bit of bit rot in the last years. Though I've > > currently only teste

Re: [fpc-devel] inline... and philosophy

Am 10.11.2019 um 16:06 schrieb Michael Van Canneyt: On Sun, 10 Nov 2019, J. Gareth Moreton wrote: This message chain has proven to be a lot more educational and insightful than I would have given it credit for.  Thanks everybody! I know a lot of the time, the size of binaries is just an ill

Re: [fpc-devel] inline... and philosophy

Am 10.11.2019 um 15:47 schrieb Marco van de Voort: (and btw, if you are serious about these scenarios, drop all optimization work immediately, and start working on packages :-) I don't know if that would help much, cause especially on Windows every application would probably provide its own set

Re: [fpc-devel] inline... and philosophy

J. Gareth Moreton schrieb am So., 10. Nov. 2019, 03:23: > Does the smart linker strip out LCL components that are not used, or must > everything that's registered in a package or unit be included? Granted, > since forms are being read from a resource file, I doubt it can really be > tied into the

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

Florian Klämpfl schrieb am Sa., 9. Nov. 2019, 20:45: > Am 09.11.19 um 20:26 schrieb Michael Van Canneyt: > > > > > > On Sat, 9 Nov 2019, Florian Klämpfl wrote: > > > >> Am 09.11.19 um 20:02 schrieb Michael Van Canneyt: > >>> > >>> > >>> On Sat, 9 Nov 2019, Florian Klämpfl wrote: > >>> > > Wha

Re: [fpc-devel] inline... and philosophy

J. Gareth Moreton schrieb am Sa., 9. Nov. 2019, 16:20: > > On 09/11/2019 15:14, Michael Van Canneyt wrote: > > > > > > On Sat, 9 Nov 2019, J. Gareth Moreton wrote: > > > >> Competitions aside, there are times where space is a premium, whether > >> it be from distributing an application on a DVD,

Re: [fpc-devel] inline... and philosophy

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 14:28: > > On 08/11/2019 13:14, Sven Barth via fpc-devel wrote: > > ... > > What's stopping that? Simple: no driving need. It's just work for > > something that has essentially no gain. > > No gain?

Re: [fpc-devel] inline... and philosophy

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 11:20: > > On 08/11/2019 09:49, Sven Barth via fpc-devel wrote: > > ... > > The compiler is compiled multiple times anyway when bootstrapping and > > the need for the scripting there is not only the WPO, but the repeated &g

Re: [fpc-devel] inline... and philosophy

J. Gareth Moreton schrieb am Fr., 8. Nov. 2019, 04:01: > Speaking of whole program optimisation, it always seems very fiddly to > set up, to the point that the FPC bootstrapper needs a script to get it > working. Not exactly user-friendly and practically demands learning a > separate skill to ge

Re: [fpc-devel] Optimizer Overhaul Take 2... Jump Optimizations

J. Gareth Moreton schrieb am Fr., 1. Nov. 2019, 12:56: > So the tests all passed on i386-win32 and x86_64-win64, so that's s a > good sign. I can't submit the patches for evaluation yet because I > haven't finished the design spec yet, and also because of a minor bug > that deals with collapsing

Re: [fpc-devel] Optimizer Overhaul Take 2... Jump Optimizations

Am 31.10.2019 um 05:57 schrieb J. Gareth Moreton: One thing I do need to do is to cross-compile to all known platforms... I can only test a handful of the i386 and x86_64 platforms, but I want to at least see if it compiles before I submit the patch for more thorough testing.  Does anyone have

Re: [fpc-devel] 034881: Request debug info for SEH (finally/except) to prevent regression when win32 switches to SEH

Martin Frb schrieb am Di., 29. Okt. 2019, 20:08: > About https://bugs.freepascal.org/view.php?id=34881 > > First of all, big thanks to Sven for the patch. > I had a look at it, I also looked through the alternatives again. > > First of all the patch would need some tweaking (but that is to be > e

Re: [fpc-devel] Question on updating FPC packages

Michael Van Canneyt schrieb am So., 27. Okt. 2019, 10:58: > Best of all would IMHO be to abolish or even totally ignore 'inline'. > It is a hint, after all. The compiler is not forced to inline, even > when the modifier is there. > That would be a bit problematic: auto inlining needs to first pa

Re: [fpc-devel] Question on updating FPC packages

> > I don't think the compiler can be made smart and safe enough to > auto-align something like the complex type to take full advantage of the > System V ABI, and vectorcall is not the default Win64 calling convention > (and the default convention is a little badly-designed if I'm allowed to > say,

Re: [fpc-devel] Question on updating FPC packages

Am 26.10.2019 um 18:51 schrieb J. Gareth Moreton: The "const" suggestion was made by a third party, and while I went out of my way to ensure the functions aren't changed in Pascal code, Florian pointed out that it could break existing assembler code. Maybe I'm being a bit stubborn or unreasonab

Re: [fpc-devel] invoke

Marco van de Voort schrieb am Di., 22. Okt. 2019, 13:13: > > https://forum.lazarus.freepascal.org/index.php/topic,47147.0/topicseen.html > > might be of interest to you despite the title :-) It is about > invoke/tvirtualinterface > But, but, but trunk already has both Invoke and TVirtualInterfac

Re: [fpc-devel] Language semantic suggesion regarding static methods

J. Gareth Moreton schrieb am Di., 22. Okt. 2019, 07:21: > Fair enough. Thanks Sven. It just seemed to be a bit of an anomaly in my > eyes. (The ambiguity shouldn't be an issue because of the semicolon > following directives) > The parser will only know whether it's a directive or part of the

Re: [fpc-devel] Language semantic suggesion regarding static methods

Am 22.10.2019 um 01:19 schrieb J. Gareth Moreton: This is a very low-level semantic issue, but I'm not particularly keen on how static methods are defined in classes. Not being "keen" on an existing, established syntax is not reason enough to change it. Please also note (to probably annoy y

Re: [fpc-devel] Policy on reserving error numbers

J. Gareth Moreton schrieb am Sa., 19. Okt. 2019, 03:52: > Hi everyone, > > So I've run into a slight annoyance while developing support for pure > functions. The compiler will need new parser messages because of > situations such as specifying the 'pure' directive when something in > said functi

Re: [fpc-devel] multi-line strings

Michael Van Canneyt schrieb am Mo., 7. Okt. 2019, 17:21: > > > On Mon, 7 Oct 2019, Ben Grasset wrote: > > > On Sat, Oct 5, 2019 at 1:37 PM Ryan Joseph wrote: > > > >> I can’t remember what Bens patch did using compiler directives but I > like > >> the Java idea of using the column of the opening

Re: [fpc-devel] Windows 32bit - FPC 3.0.4 Gets an Error - but not on Linux or Mac...

Ozz Nixon schrieb am Sa., 28. Sep. 2019, 22:53: > It's a CDECL thing... :-( > > Disabled Using_CDECL, and now the pointer passes to/from the imported > functions. (Florian/Jonas/Michael - is this an expected issue on Windows?) > It would help if you'd provide a self contained example that demons

Re: [fpc-devel] Case else allows multiple statements

Am 19.09.2019 um 21:07 schrieb Kirinn: I've stumbled on a situation where a case statement compiles when I wouldn't expect it to. I would expect the below code to produce a compile error:     program test;     var i : byte = 5;     begin     case i of     0..4: writeln('value i

Re: [fpc-devel] Return to pure functions!

Am 19.09.2019 um 20:25 schrieb J. Gareth Moreton: One thing I've fallen foul of is how to track variables in what will become the 'node parser' that the compiler will use to evaluate pure functions to calculate their return values.  Because a variable can be anything, I was planning on using th

Re: [fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

Am 02.08.2019 um 21:27 schrieb bla...@blaise.ru: On 02.08.2019 21:36, bla...@blaise.ru wrote: embed a copy of the body of insert_struct_hidden_paras into TVMTBuilder.generate_vmt, then merge those two procdef-member traversals into one (hey, performance!) Would you guys oppose such a change?

Re: [fpc-devel] Scoped VMTDefs

Am 03.08.2019 um 15:54 schrieb bla...@blaise.ru: Before the main course, I offer the attached refactorings for trecorddef.create_global_internal: 1) streamline insertions into the symtable; Applied in r42652 2) avoid shadow-copying of the parameter "n", which is now const Applied in r42653

Re: [fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

Am 02.08.2019 um 21:27 schrieb bla...@blaise.ru: On 02.08.2019 21:36, bla...@blaise.ru wrote: embed a copy of the body of insert_struct_hidden_paras into TVMTBuilder.generate_vmt, then merge those two procdef-member traversals into one (hey, performance!) Would you guys oppose such a change?

Re: [fpc-devel] Minor debate with ISO standard on case blocks

thaddy schrieb am Di., 30. Juli 2019, 10:04: > On 2019-07-30 01:43, J. Gareth Moreton wrote: > > As someone on the issue pointed out... on page 2, section 3.1: > > > > 3.1 Error > > > I have added this to the bug report. Consider that here all possible > case labels are implemented, the compiler

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 23:18 schrieb Martin Frb: On 20/07/2019 23:13, Sven Barth via fpc-devel wrote: For example I myself don't commit my .gitignore, but simply have it lying around as untracked file. Try .git/info/exclude https://git-scm.com/docs/gitignore Nice! :D Regards,

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 22:29 schrieb Ryan Joseph: On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel wrote: Why is your .gitignore so big? Mine looks like this: I’m sorry, what I wrote didn’t make any sense. I mean that after I delete .gitignore then all the .o etc.. files that it was

Re: [fpc-devel] Submitting patches using git

Am 20.07.2019 um 18:58 schrieb Ryan Joseph: 3) remove .gitignore (which now includes thousands of .o/.ppu files which need to be deleted) and any other unrelated personal files. Why is your .gitignore so big? Mine looks like this: === file begin === # ignore binary files *.o *.ppu *.exe *.pc

Re: [fpc-devel] Property attributes support

Am 20.07.2019 um 18:38 schrieb Ondrej Pokorny: The old Wiki page should propably be updated to reflect the current state of affairs... I deleted the old information (nearly everything) and put a link to the new Wiki page there. Probably for the best ;) You can also take a look at Delphi t

Re: [fpc-devel] Property attributes support

Ondrej Pokorny schrieb am Sa., 20. Juli 2019, 12:04: > Hello! > > I saw that Sven committed property attributes support in trunk. Thank > you for this! > > Is there any documentation how to use them? (Syntax, reading information > during runtime etc?) I only found very old information: > https://

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Michael Van Canneyt schrieb am Di., 16. Juli 2019, 16:31: > > > On Tue, 16 Jul 2019, Ben Grasset wrote: > > > On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> The output will then be t

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Ben Grasset schrieb am Mo., 15. Juli 2019, 23:48: > On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> That is exactly what is happening if you have a specialization in >> multiple units that don't know about

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Ben Grasset schrieb am Di., 16. Juli 2019, 00:13: > On Mon, Jul 15, 2019 at 5:50 PM Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> As far as I know, they are not. I believe that when specializing, the >> compiler checks if an identical specialization is in scope: >> if so, it uses th

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Michael Van Canneyt schrieb am Mo., 15. Juli 2019, 23:50: > > > On Mon, 15 Jul 2019, Ben Grasset wrote: > > > On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> That is exactly what

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Ben Grasset schrieb am Mo., 15. Juli 2019, 22:57: > On Sat, Jul 13, 2019 at 9:02 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Not necessarily. If you have two units that don't know about each other >> that specialize the function wi

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: On another note, I do think pass_2 (pass_generate_code) could use some refactoring.  I don't like how "flowcontrol" is a global variable.  Though it's unlikely to happen, such a state variable not being tied to a management object (e.g. current_

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton: Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions.  When studying how the compiler is built, I noticed a lot of the internal

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Ben Grasset schrieb am Sa., 13. Juli 2019, 21:52: > On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> No doubt, but this will lead to a bloated binary. I want less code (both >> source and assembler), not more. >> > > Well, it would be one instantiation p

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Am 13.07.2019 um 14:12 schrieb J. Gareth Moreton: I would like some discussion on this with the administrative team because this does require some careful design if we're going to do this properly.  Building on Florian's suggestion, I would like to propose splitting "pass_1" into "pass_syntax"

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Di., 9. Juli 2019, 15:39: > Another thing regarding array properties. If I use constref on the setter > I get an error "Illegal symbol for property access”. Is there any reason > why the setter can’t be constref? If not I’d like to change this with my > array properties pat

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton schrieb am Di., 9. Juli 2019, 08:20: > Apologies - I see now... I used them with "with" without even thinking > about it! I've made the changes as requested. Admittedly it's quite > hard for me to remove spaces from either side of operators because > that's something I learnt f

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Sven Barth schrieb am Di., 9. Juli 2019, 07:41: > Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: > > On an extra note, the assembly language produced is not yet optimal, > > so it may end up that an x86-specific implementation will be > > beneficial. TIsNode contains a virtual method named >

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension, coup

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 18:04: > > > > On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > As Pascal does not allow differentiating between result types this > indeed needs to be/stay fo

Re: [fpc-devel] [] property overloads

Ryan Joseph schrieb am Mo., 8. Juli 2019, 16:10: > I just encountered something to consider. Should a property be > overloadable if the names/args are the same but the return type is > different? I think if they are not the same access type (i.e. read/write) > then it could work (not sure about t

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Florian Klaempfl schrieb am Sa., 6. Juli 2019, 21:18: > Am 06.07.2019 um 17:38 schrieb Sven Barth via fpc-devel: > >> I tried to follow the thread, but one think I miss is: what are the > >> rules for indention? Does the lines string contain > >> spaces at the begin

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 06.07.2019 um 14:24 schrieb Ben Grasset: General question regarding the tests I'm writing: What kind of numbers should I be going for? Is something like 10 that pass and 10 that fail a good ratio? Or should it be more of them that pass? It's not about the ratio of passing and failing test

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 06.07.2019 um 16:25 schrieb Florian Klämpfl: Am 05.07.2019 um 17:29 schrieb Ryan Joseph: This may not be related but why does "l: string = lines;” work, shouldn’t that be an error or at least get clipped? I’m seeing writeln prints out the entire string as if it was an ansistring. {$mode ob

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the b

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 06.07.2019 um 00:21 schrieb Ryan Joseph: On Jul 5, 2019, at 5:45 PM, Ben Grasset wrote: Like, not working in any sense at all? That's definitely not normal. I think it’s just the push/pop isn’t working. Just to be clear should the follow code compile? For me I get an error.Try it yourse

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 22:30 schrieb Ben Grasset: On Fri, Jul 5, 2019 at 1:41 PM Ryan Joseph > wrote: This doesn’t work either. {$push} {$h+} var lines: ansistring = `   #version 150   uniform sampler2D textures[8];   in vec2 vertexTexCoord

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 22:25 schrieb Sven Barth: Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe mailto:jo...@freepascal.org>> schrieb am Do., 4. Juli 2019, 21:21: On 03/07/2019 09:26, Ondrej Pokorny wrote: > On 02.07.2019 23:34, Jonas Maebe wrote: >> Invalid data means undefined

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe mailto:jo...@freepascal.org>> schrieb am Do., 4. Juli 2019, 21:21: On 03/07/2019 09:26, Ondrej Pokorny wrote: > On 02.07.2019 23:34, Jonas Maebe wrote: >> Invalid data means undefined behaviour, always. "is" is not a special

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:36 schrieb Ben Grasset: On Fri, Jul 5, 2019 at 1:14 PM Ryan Joseph > wrote: This may present a bit of problem then because you don't appear to be able to opt-in to long strings just for constants. $h+ will always be required for multi-

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:41 schrieb Ryan Joseph: On Jul 5, 2019, at 1:36 PM, Ben Grasset wrote: {$push} {$H+} var Ansi: String; {$pop} This doesn’t work either. {$push} {$h+} var lines: ansistring = ` #version 150 uniform sampler2D textures[8]; in vec2 vertexTexCoord; in vec4 vertex

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 05.07.2019 um 19:38 schrieb Ryan Joseph: On Jul 5, 2019, at 1:34 PM, Sven Barth via fpc-devel wrote: Why should they always be required? If your multiline string is shorter than 256 characters then all is well. And otherwise you'd have the same problem with an ordinary string con

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ryan Joseph schrieb am Fr., 5. Juli 2019, 19:14: > > > > On Jul 5, 2019, at 12:10 PM, Ben Grasset wrote: > > > > Explicit "ShortString" variables are still exactly what they say they > are in all cases though, of course. > > > > This may present a bit of problem then because you don't appear to

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Pierre Muller schrieb am Fr., 5. Juli 2019, 17:51: > > > Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > > > On 05/07/2019 15:51, Pierre Muller wrote: > >> Just one point from current compiler implementation: > >> > >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180) > >> > >>

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Martok schrieb am Fr., 5. Juli 2019, 14:54: > Am 05.07.2019 um 14:24 schrieb Sven Barth via fpc-devel: > > Huh? The comment regarding dynamic packages is nonsense. The compiler > and RTL > > check that the checksums of the involved interface sections match and > thus th

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

J. Gareth Moreton schrieb am Fr., 5. Juli 2019, 14:02: > I'm glad we agree on the "is" operator. Personally I would like to > extend it so it accepts "if (I is TMyEnum) then" when I is also of type > TMyEnum, since it may be the case that you're reading I directly from a > stream, either individ

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Martok schrieb am Fr., 5. Juli 2019, 11:10: > Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: > > > With this sentence you forbid storing or communicating enumerated values > in any way: > > file, database, over network. It can be used only in a computer program > and never > > leave the cont

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Benito van der Zander schrieb am Fr., 5. Juli 2019, 11:33: > Hi, > > Am 04.07.19 um 19:51 schrieb Marco van de Voort: > > > > If $ifdef was a single char token, maybe. And for a trivial feature, not a > core one, like conditional compiling. > > > So the compiler will correctly give an error. > >

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Michael Van Canneyt schrieb am Fr., 5. Juli 2019, 10:47: > If memory serves well, FPC introduced this (before delphi) to be able to > import C enums with assigned values. > Correct. That is also why we allow both "=" and ":=" for the value assignments. Because Delphi only supports one of the two

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Jonas Maebe schrieb am Do., 4. Juli 2019, 21:21: > On 03/07/2019 09:26, Ondrej Pokorny wrote: > > On 02.07.2019 23:34, Jonas Maebe wrote: > >> Invalid data means undefined behaviour, always. "is" is not a special > >> case that is immune to this. > > > > Don't you really see the need to handle in

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Ben Grasset schrieb am Fr., 5. Juli 2019, 06:31: > Once I have a set of proper tests written, I suppose I'll submit a formal > patch to the FPC bugtracker. > As stated by I think Michael, a new modeswitch which is by default off is also required. Regards, Sven > ___

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Marco van de Voort schrieb am Do., 4. Juli 2019, 16:26: > > Op 2019-07-04 om 16:25 schreef Ben Grasset: > > On Thu, Jul 4, 2019 at 10:09 AM Marco van de Voort > > mailto:f...@pascalprogramming.org>> wrote: > > > > You clearly didn't read the message fully. It is not about > > compiler/not

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Marco van de Voort schrieb am Do., 4. Juli 2019, 12:00: > > Op 2019-07-04 om 07:34 schreef Sven Barth via fpc-devel: > > > >>> But the main question is: do we actually want a multiline string ? > >>> As far as I am concerned, that question needs to be an

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Michael Van Canneyt schrieb am Do., 4. Juli 2019, 13:54: > > > On Thu, 4 Jul 2019, Tomas Hajny wrote: > > > On 2019-07-04 12:59, Marģers . via fpc-devel wrote: > > > > . > > . > >> Why introduce ` if there already is ' ? Just use ' > >> as well for multi line strings. For people of more > >> co

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 04.07.2019 um 01:00 schrieb Marco van de Voort: Op 2019-07-03 om 20:43 schreef Michael Van Canneyt: But the main question is: do we actually want a multiline string ? As far as I am concerned, that question needs to be answered first, and for me personally the answer to that is still a re

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 04.07.2019 um 01:57 schrieb J. Gareth Moreton: While I like the idea in principle, one thing that I'm a bit worried about is how whitespace is handled, like what counts for a leading or trailing space in the string when between lines, since Pascal parsers (and those for many other language

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 04.07.2019 um 02:09 schrieb Martin Frb: On 04/07/2019 01:57, J. Gareth Moreton wrote:  Also, with the backtick suggestion, what should one do if they wish to include a control character (e.g. a linefeed) or the backtick character itself? answer := `Well, this for ``inline`` backticks an

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 04.07.2019 um 00:21 schrieb Ryan Joseph: On Jul 3, 2019, at 5:48 PM, Sven Barth via fpc-devel wrote: In case case of readability: most cases of multi line string constants are likely to be embedded scripts (shaders, SQL, whatever) and thus the $INCLUDESTRING directive mentioned in the

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 04.07.2019 um 00:08 schrieb Ben Grasset: On Wed, Jul 3, 2019 at 5:48 PM Sven Barth via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> wrote: I'm with Michael here: I see no *need* for a separate syntax for a multi line string.  I don't really think the sug

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 03.07.2019 um 20:55 schrieb Ryan Joseph: On Jul 3, 2019, at 2:43 PM, Michael Van Canneyt wrote: There is also still: https://bugs.freepascal.org/view.php?id=25536 What does this do and why has it been sitting there since 2014 if it’s useful? There are also still open questions regarding

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 03.07.2019 um 22:20 schrieb Ben Grasset: On Wed, Jul 3, 2019 at 3:27 PM gabor > wrote: I am also against this program Example; (*   This is a perfectly   normal multi-line   Pascal comment. *) const SA = `   This is a multiline   string using hypothetical

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

Ben Grasset schrieb am Mi., 3. Juli 2019, 18:00: > On Tue, Jul 2, 2019 at 7:38 PM Ondrej Pokorny wrote: > >> A good real-word example is the cast from a pointer: >> >> program Project1; >> uses Classes; >> var >>Value: TPersistent; >>P: Pointer; >> begin >>P := TObject.Create; >>

[fpc-devel] State of i8086-embedded

Hello together! For a project at work I need to run 16-bit x86 code on a bare x86 hardware (more precisely a 8086 VM). Considering that i8086-embedded had been added to FPC nearly exactly 3 years ago I though I'd give it a try and cross compiled the units for the tiny memory model. However whe

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 30.06.2019 um 00:02 schrieb Martin Frb: However this works: === code begin === function GetFoo(AIndex: Integer; BIndex: Integer = 0): Integer; property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read GetFoo; Ouch What then about   function GetFoo(AIndex: Integer = 0): Integer;   prop

Re: [fpc-devel] Is that supposed to work: property with "[var index: TFoo]" ?

Am 28.06.2019 um 10:39 schrieb Martin Frb: On 28/06/2019 07:39, Sven Barth via fpc-devel wrote: Am 27.06.2019 um 21:09 schrieb Martin:   { TFoo }   TFoo = class   private     function GetFoo(var AIndex: Integer): Integer;   public     property Foo[var AIndex: Integer]: Integer read GetFoo

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Florian Klaempfl schrieb am Sa., 29. Juni 2019, 15:52: > Am 28.06.2019 um 11:24 schrieb George Bakhtadze: > > This assumption is *not* incorrect. Only on the LLVM based Delphi > > NewGen and FPC's LLVM backend the assumption is incorrect which can > > be seen by them having added "vol

<    1   2   3   4   5   6   7   8   >