Re: [fpc-devel] C library header - var vs pointer for function arguments

Consider backwards compatibility in fixes On Wednesday, August 3, 2022, gabor via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I'd like to provide some fixes for packages that are headers for c > libraries. When and should I use the "var" argument for function arguments > that return a

Re: [fpc-devel] register calling convention for Apple M1 ?

On Wed, Feb 16, 2022 at 3:17 PM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Anything similar on M1? > should it be ARM64 calling convention? https://en.wikipedia.org/wiki/Calling_convention#ARM_(A64) ___ fpc-devel maillist -

Re: [fpc-devel] TStrings and BOM

On Wed, Jan 1, 2020 at 6:51 PM Ondrej Pokorny wrote: > If you want to simplify a call, use a class helper: > > TStringsHelper = class helper for TStrings > ... > procedure TStringsHelper.SaveToFileWithBOM(aFileName: string); > begin >WriteBOM := True; >SaveToFile(aFileName); > end; > a

Re: [fpc-devel] TStrings and BOM

On Wed, Jan 1, 2020 at 7:07 PM Ondrej Pokorny wrote: > > The WriteBOM property has a valid purpose - it is set in LoadFrom* > > according to the BOM presence in the loaded file. I.e. if you do: > > > > MyStrings.LoadFromFile('abc'); // WriteBOM and Encoding properties are > > set here > >

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, Jun 10, 2019 at 12:57 AM Ben Grasset wrote: > So, you're going to keep pretending like you're actually concerned about > maintaining the integrity of some (completely fictional) "traditional" > Pascal (that FPC never has been and was presumably never intended to be), > and implying that

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 10:52 PM Ben Grasset wrote: > On Sun, Jun 9, 2019 at 10:28 PM Dmitry Boyarintsev < > skalogryz.li...@gmail.com> wrote: > >> So if you're fan of having ^Integer as a parameter type, then you pretty >> much self-declaring to be a fan of

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 10:14 PM Ben Grasset wrote: > I mean, like *many, many, many *things, yes it is technically possible > for that to be valid Pascal syntax. As far as *should*, well, I'm not > personally a fan of that sort of too-many-parentheses typecasting, but I > wouldn't specifically

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 8:48 PM Ben Grasset wrote: > Of course not. That would be rather nonsensical, *for very obvious > reasons*, that I've already gone out of my way to address in this comment > chain. It is however utterly ridiculous to directly correlate that with > `^Type` syntax, as they

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 9:05 PM Ryan Joseph wrote: > What if static array and record types were the exception? Avoiding making any exceptions in a design is typically a good thing. > Personally I’ve had to write dummy types more than once in order to get > around this design problem. If I had

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 8:48 PM Ben Grasset wrote: > On Sun, Jun 9, 2019 at 8:11 PM Dmitry Boyarintsev < > skalogryz.li...@gmail.com> wrote: > >> Do you really want to change it? If yes, what's the **technical** >> benefit? >> > > Yes? Obviously? I clearly d

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Sun, Jun 9, 2019 at 6:29 PM Ben Grasset wrote: > Again, literally nobody in this entire message chain has stated any actual > reason why exactly they think it would be specifically *bad* to have > `^Type` in method parameters. > Is it because parameter types are doesn't really match a type

Re: [fpc-devel] changes in objc headers (boolean type parameter)

On Tue, Nov 27, 2018 at 1:53 AM Michael Van Canneyt wrote: > > That will normally be 3.2. > Great! anything released after 3.0.4. thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] changes in objc headers (boolean type parameter)

Hello, At what version is it planned to release headers changes https://bugs.freepascal.org/view.php?id=34609 (for boolean parameter) ? thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Saturday, October 13, 2018, Jonas Maebe wrote: > > A single test program compiled at a single optimization level does not > demonstrate how a particular compiler generates code in all possible > situations. In addition, the ABI specification trumps a particular > compiler's implementation in

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Sat, Oct 13, 2018 at 9:55 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > ObjC language doesn't have its own boolean type. > No. I'm convienced now: http://wiki.freepascal.org/ObjC_Bool It appears the the compiler is always clearing the entire register to pass t

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Sat, Oct 13, 2018 at 3:08 AM Michael Van Canneyt wrote: > > Because introducing a type in a language and naming it after some library > is > not done. objcbool at least refers to another language. > ObjC language doesn't have its own boolean type. It's either C "_Bool" for ARM, or "a signed

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Fri, Oct 12, 2018 at 6:48 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Not quite: the Boolean16, Boolean32 and Boolean64 types were introduced > because the libraries provided by GTK required a 4-Byte boolean type that > worked like Object Pascal's Boolean. > That's

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Fri, Oct 12, 2018 at 3:51 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > All the Pascal Boolean types are not "Integer types". You can't assign > any of them to a Integer or whatever without typecasting. They *all* > behave like Boolean, because that was the way they

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Fri, Oct 12, 2018 at 11:09 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > so, far the only reliable approach to fix the issue (for the current > compiler version) is something like that: > Maybe "Boolean8" type should help instead? David, could you

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Fri, Oct 12, 2018 at 10:38 AM David Jenkins wrote: > The movsbl %dl, %edx is good. Unfortunately the value of %edx is > 0x not 0x0001. This is the same result I saw when I changed it > to LongBool. > I presume this is due to the definition of YES macro in objc, which is 1

Re: [fpc-devel] OSX: Setting up parameters to objc_msgSend()

On Thu, Oct 11, 2018 at 4:16 PM Jonas Maebe wrote: > However, the Objective-C BOOL type does not map to _Bool on x86-64, but > to signed char. And values of that type indeed do need to (sign) > extended. > Should use of ByteBool resolve the problems for ObjC mapped headers for the current

Re: [fpc-devel] SizeOf( const typcasted as shortstring)

On Mon, Aug 13, 2018 at 5:24 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It's odd that such expression compiles w/o any warnings or notes. (i.e. >> "ignoring typecasting for constant value expressions") >> > > Support for typecasts in untyped constants is by design and

Re: [fpc-devel] SizeOf( const typcasted as shortstring)

On Sun, Aug 12, 2018 at 5:40 PM Bart wrote: > const > x = ShortString('abc'); > begin > writeln(SizeOf(x)); > end. > > Delphi (7) prints 256, fpc prints 3. > > Is that a bug or an implementation detail? > Implementation detail. And it seems to be wrong on Delphi size, because for reason it

Re: [fpc-devel] Pure function development discussion

On Sat, Aug 11, 2018 at 8:50 PM J. Gareth Moreton wrote: > How and when is the constant defined? Should such constructs be disallowed > and constants only allowed to be declared in other units that use the unit > that contains the pure functions in its interface section? What would be > the

Re: [fpc-devel] Compile time functions

These are known as “class” methods (rather than “static”) in object pascal. Thanks, Dmitry On Saturday, July 28, 2018, J. Gareth Moreton wrote: > Aah, right. > > I'm probably being rather dumb here from not having used them before, but > do you mean things like this? > > type > TNewClass =

Re: [fpc-devel] Issue #32913

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 On Saturday, July 14, 2018, J. Gareth Moreton wrote: > I've had a look at issue #32913 for a > while now, but after looking

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 8:15 PM, J. Gareth Moreton wrote: > Yes, if any parameters are variables, then the function is not evaluated. > My intention is that the purity of a function is only determined when it > comes to evaluating it in an expression, but because of how complex > functions can

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 9:47 PM, Thorsten Engler wrote: > > > If the loop is being unrolled, what looks like a non-const expression > becomes a const expression. So if SomeFunc is marked as pure, the compiler > might be able to omit the call completely. > > There were some time testing done with

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 7:18 PM, Thorsten Engler wrote: > Maybe you don’t understand what “determine the purity of a function” means? > > > > It means that every time any function is called, the compiler has to try > to execute the function at compile time (by working through the nodes like > an

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 6:47 PM, Thorsten Engler wrote: > You are thinking about something like: > > > > const > > x = FunctionCall(42); > > > > In which case, yes, the compiler could possibly see that as in implicit > “check if that function is pure”. > > > > But “constant expressions” can

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler wrote: > 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

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 1:01 PM, Florian Klämpfl wrote: > > > No. Because pure is part of the function header and tells users "you can > use this function with constant arguments in constant expressions and this > won't change without notification". If the compiler determines by itself if > a

Re: [fpc-devel] Pure function Wiki page

On Sun, Jul 8, 2018 at 11:20 AM, J. Gareth Moreton < gar...@moreton-family.com> wrote: > As far as I know, keywords are often used (e.g. "constexpr" in C++). My > reasons are explained in the Wiki topic, but it boils down to compiler > performance. > How about adding a new modeswitch instead

[fpc-devel] String constants to ObjC types

Hello, It's somewhat common task to convert a constant string to a selector. On Thu, Apr 19, 2018 at 8:43 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > > respondToSelector instance method > https://developer.apple.com/documentation/objectivec/ > 141895

Re: [fpc-devel] Request for applying patch #33124

On Thu, Apr 19, 2018 at 2:59 PM, Ondrej Pokorny wrote: > > Good. I added the missing header definition to LCL in r57240. Could you > please review the revision and eventually fix it, if needed? > r57677 reviewed and fixed. Also added support for the deprecated

Re: [fpc-devel] Request for applying patch #33124

On Thu, Mar 22, 2018 at 11:14 AM, Ondrej Pokorny wrote: > Can somebody apply the patch at > > https://bugs.freepascal.org/view.php?id=33124 > > it's nothing serious, only a missing Cocoa header definition. > It's better, if you declare those methods as an objccategory in

Re: [fpc-devel] function evaluation by a debugger

Hello, On Fri, Mar 27, 2009 at 3:03 PM, Jonas Maebe wrote: > a) even if gdb would not complain, you would probably get a crash because > as mentioned before, on i386 FPC by default uses the completely > non-standard "Borland fastcall" calling convention, for which gdb

Re: [fpc-devel] "Default" discussion for SmartPointers etc

On Thu, Jul 28, 2016 at 10:37 AM, Michael Van Canneyt < mich...@freepascal.org> wrote: > [+] Default field (even if it is only syntactic sugar) > can-o'worms: Wasn't there a discussion to have multiple default fields depending on the type? thanks, Dmitry

Re: [fpc-devel] Aarch64-darwin, float-point parameter

On Tue, Jun 7, 2016 at 11:31 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > On Tue, Jun 7, 2016 at 12:00 PM, Jonas Maebe <jonas.ma...@elis.ugent.be> > wrote: > >> >> Compilable source code + used command line parameters. >> > > A

Re: [fpc-devel] Aarch64-darwin, float-point parameter

On Tue, Jun 7, 2016 at 12:00 PM, Jonas Maebe <jonas.ma...@elis.ugent.be> wrote: > On 07/06/16 14:36, Dmitry Boyarintsev wrote: > >> Any suggestion what should I pay attention to and/or provide information >> about? >> > > Compilable source code + used comma

[fpc-devel] Aarch64-darwin, float-point parameter

Hello, I'm observing a weird behavior in a generated code (fpc-trunk, last night revision). A routine looks like this: procedure some_paint(... ; x, y, w, h: Single; ...) var f1, f2 : Single; // local variable .. // all operands are Single type f1 := 1 / Data.t1 / Data.v1;// <-- the

Re: [fpc-devel] c-blocks (darwin aarch64)

Hello Jonas, Regarding the fix on 30022. I'd think the behavior is Delphi compatible, where it would also complain passing a function (block) with address operator. It's just a bit surprising, since it's inconsistent with regular procedure type variables. {$mode delphi} type TMyProc =

Re: [fpc-devel] c-blocks (darwin aarch64)

On Sat, Apr 16, 2016 at 8:18 PM, Sven Barth wrote: > Yes, because aside from the cdecl Delphi uses the same syntax for > anonymous function references, so we (aka Jonas) copied that for blocks. > Change request is made. http://bugs.freepascal.org/view.php?id=30023

Re: [fpc-devel] c-blocks (darwin aarch64)

On Sat, Apr 16, 2016 at 8:18 PM, Sven Barth wrote: > Yes, because aside from the cdecl Delphi uses the same syntax for > anonymous function references, so we (aka Jonas) copied that for blocks. > Oh yes, that rings a bell, I remember an email about reusing anonymous

Re: [fpc-devel] c-blocks (darwin aarch64)

Aside question: Is syntax for blocks settled? at least for "reference to" part? I'm eager to create Code Tools feature request. thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] c-blocks (darwin aarch64)

On Sat, Apr 16, 2016 at 5:42 PM, Jonas Maebe wrote: > > Yes, a test program that can be used to reproduce the bug (preferably > command line) > > even better! it's pure OSX (x86_64)! not need for iOS http://bugs.freepascal.org/view.php?id=30022 The sample is using

Re: [fpc-devel] c-blocks (darwin aarch64)

On Sat, Apr 16, 2016 at 3:05 PM, Jonas Maebe wrote: > Using r33526, the app crashes with compiler native blocks at the same >> spot (on calling set block handler) >> > > Can you share code that crashes? uses .. GameController // from iOS headers procedure

Re: [fpc-devel] c-blocks (darwin aarch64)

On Fri, Apr 15, 2016 at 9:09 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > > I'm going to update to the latest FPC revision now. > Using r33526, the app crashes with compiler native blocks at the same spot (on calling set block handler) *(lldb) bt* * thread #1:

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

On Fri, Apr 15, 2016 at 3:01 AM, Maciej Izak wrote: > > I'm too lazy to do things in that way. I need object inspector with > properties/events tabs + WYSIWYG. ;) > > That is also the reason of introducing smart pointers branch. I'd like to > omit any Free/FreeMems. > >

Re: [fpc-devel] c-blocks (darwin aarch64)

On Fri, Apr 15, 2016 at 5:13 AM, Jonas Maebe wrote: > > The tests in the testsuite work at least, both for ARM and AArch64. Could it be run-time environment dependent then... > Even if that were the case, it wouldn't crash at that place in > objc_msgSend. r0

Re: [fpc-devel] c-blocks (darwin aarch64)

On Thu, Apr 14, 2016 at 11:10 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > > Does anyone know if cblocks are working for darwin-aarch64? > Actually, It's (obviously) not aarch64, but arm7. Xcode requires to build a fat binary, but still runs 32-bit version on i

[fpc-devel] c-blocks (darwin aarch64)

Hello, Does anyone know if cblocks are working for darwin-aarch64? I'm trying to use GCController objects. The notification is based of blocks. The code looks like this: GCExtendedGamepad.inc {$modeswitch cblocks} type GCExtendedGamepadValueChangedHandler = reference to procedure

[fpc-devel] Dotted namespace

On Wed, Jan 27, 2016 at 8:46 AM, Maciej Izak wrote: > 2016-01-27 14:44 GMT+01:00 Michael Van Canneyt : > >> On Wed, 27 Jan 2016, Juha Manninen wrote: >> >> Hey guys ... >>> >>> Now this Generics.Collections is completely hijacked by a namespace >>>

Re: [fpc-devel] macro through command line

On Mon, Jan 18, 2016 at 11:41 AM, Jonas Maebe wrote: > Yes, or in an include file included in the unit interface. > Alright. Thank you. I'll reconsider the approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FPC 3.0.0 on OSX 10.6.8 32bit Compile problem

On Mon, Jan 18, 2016 at 3:43 AM, wrote: > After setting the -Aaa-darwin flag It progresses further, but now stops > here > I presume you set -Aaa-darwin in the project custom options? You might need to set -Aaa-darwin in the option for the each package used as well.

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Tue, Oct 13, 2015 at 5:25 PM, Michael Van Canneyt wrote: > However, I seem to be one of the very few thinking this given the > enthousiasm with which people are discussing this. > Even Niklaus Wirth regrets about bloating languages:

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 2:07 AM, Sven Barth wrote: > It's from Extended ISO Pascal and I don't know for how long it exists in > FPC already, but it does so definitely for some time. > Thanks! I've never thought to go and read the FP documentation on "case statement",

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 1:35 PM, Ralf Quint wrote: > > Either the while loop is executed or it isn't, depending in the > expression. I don't see an actual use case for any else/otherwise extension > to it... > You probably want to reread python while-else implementation. (

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 1:54 PM, Ralf Quint wrote: > Sorry, we are programming here in Pascal, not Python. I could give a > rodent's posterior about what Python implements. > > People need to properly design their software, not just hacking away. Then > they do not need to

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 3:11 PM, <wkitt...@windstream.net> wrote: > On 10/12/2015 02:02 PM, Dmitry Boyarintsev wrote: > >> >> The next step would probably be controlled "break", where a user would be >> able >> to specify how many nested loops neede

Re: [fpc-devel] new features and facilities

On Mon, Oct 12, 2015 at 4:01 PM, Marco van de Voort wrote: > (ifthen clashes name with the delphi functions of the same name in a much > used unit as math, the name should be different but the intrinsic principle > IMHO is best) > But they're inline functions. Thus when inline-d

Re: [fpc-devel] Fwd: While - Otherwise Statement

On Mon, Oct 12, 2015 at 3:47 PM, wrote: > by checking the value that caused the break ;) deity knows i've done it > many times before back in the TP/BP 6&7 days... i did it exactly as > described, too... we had to do it that way as there is/was no other way to > do it ;)

Re: [fpc-devel] Fwd: While - Otherwise Statement

a bit off-topic, But has case-otherwise been in FPC from the start? I believe it came from GNU pascal ( http://www.gnu-pascal.de/gpc/otherwise.html) and never existed in Delphi world ( http://docwiki.embarcadero.com/RADStudio/XE3/en/Declarations_and_Statements#Case_Statements) ?! I can see that

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 5:04 PM, Sven Barth wrote: > Yes a compiler intrinsic could handle that. In the end all three syntaxes > are the same code representation anyway: namely an if-node. > The IfThen() intrinsic would be fine with me as well. Let's call this our >

Re: [fpc-devel] new features and facilities

The only Pascal way is left := IfThen(expr1, expr2, expr3) Similar to addr(), sizeof(), length(), write() and recently added Default() in intrinsic. I guess functions declared in Math unit are not covering all the needs (since type of expr2, expr3) may vary. That's why a bit of compiler support

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 2:30 PM, Michael Van Canneyt wrote: I'm not sure this kind of semantics is possible with a compiler intrinsic... > But if it is: In that case the IfThen or IIF() or somesuch has my absolute > top preference, followed by ternary. (and the If .. then

Re: [fpc-devel] new features and facilities

On Fri, Oct 9, 2015 at 2:45 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Looking at the assembler code, a=0 is evaluated first. > If it's true, the code is passed to the next line after assert, w/o > evaluating 'error '+intToStr(b). > And that's the

Re: [fpc-devel] new features and facilities

On Thu, Oct 8, 2015 at 12:54 PM, Sven Barth wrote: > I had the idea to implement inline-if as well. I think the syntax I > selected is derived from Oxygene, but it looks very Pascal and shouldn't > break anything: > > left := if expr1 then expr2 else expr3; > >

Re: [fpc-devel] re : FPC app crash with "has text relocations" / android 6.0

On Wed, Sep 9, 2015 at 3:40 PM, Maciej Izak wrote: > still unreadable ... :( > > needs to be replaced with the space, obviously 2015-09-09 18:35 GMT+02:00 크레딕스 최원식 : Oh Sorry More Testing - Test Env. FPC 3.1.1 (svn 31577) Case 1.

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

On Fri, Jul 17, 2015 at 11:44 AM, Paul van Helden p...@planetgis.co.za wrote: The Oxygene dialect is absolutely beautiful in my opinion. Lots of things in there that I've been wanting for decades and many stupid things dropped completely. Silly example: var declarations when you need them like

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

On Fri, Jul 17, 2015 at 1:53 PM, Maciej Izak hnb.c...@gmail.com wrote: Proposed mode is not proposed as default pascal mode. You are safe :P. You will be able to using classic pascal forever. So what is the problem? Is it better to spend compiler-development time to such staff as improving

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

On Fri, Jul 17, 2015 at 2:03 PM, Maciej Izak hnb.c...@gmail.com wrote: 2015-07-17 17:44 GMT+02:00 Paul van Helden The world is looking for a new language. That is why we recently got Google's Go and Apple's Swift. I believe a modern and clean dialect of Object Pascal has a leg-up on both of

Re: [fpc-devel] Xe3 Parallel for

On Tue, May 12, 2015 at 12:43 PM, Marco van de Voort mar...@stack.nl wrote: IMHO no discussion is necessary besides the bugreport where you added the patch :-) Except for Prism (which is a descendant of pascal syntax) are there any other thread oriented syntax that could be accommodated by

Re: [fpc-devel] AArch64 port committed to svn trunk

I've been able to get a project compile for x86-64-iphonesim. I just gave a few hints on the wiki: http://wiki.freepascal.org/iPhone/iPod_development#iOS_8.0 I've been looking through existing tutorials (i.e. Simon Choi's compiling iOS 7 or earlier Ingemar's iOS 5). Each tutorial is mentioning

Re: [fpc-devel] AArch64 port committed to svn trunk

On Mon, Feb 23, 2015 at 6:02 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: I've just committed the AArch64 (aka ARM64) port to trunk. It currently only supports iOS, but adding Linux support should not be difficult. Great news! Thank you, Jonas!

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

On Wed, Nov 12, 2014 at 7:03 AM, Juha Manninen juha.mannine...@gmail.com wrote: The fact still is that fpc -h + a parser in Lazarus requires the least amount of maintenance in the long run. The help output already listed the vast majority of all options. Is there an exclusion for -P option

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

On Sun, Nov 9, 2014 at 4:27 AM, Juha Manninen juha.mannine...@gmail.com wrote: Sorry, my bad. We had a long discussion about this subject, Mattias thought the info about FPC options should be maintained in FPC project. I agreed because it is quite logical and makes sense. Why should help info

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

On Sat, Nov 8, 2014 at 2:15 PM, Juha Manninen juha.mannine...@gmail.com wrote: On Fri, Nov 7, 2014 at 1:13 AM, Tomas Hajny xhaj...@hajny.biz wrote: If you mean that FPC itself should use a JSON file for generating the help, that doesn't sound like a good idea to me (see below). I think it

Re: [fpc-devel] Masm

On Fri, Nov 7, 2014 at 11:05 PM, Adriaan van Os adri...@microbizz.nl wrote: I saw that and wondered if nasm can be used with FPC on Mac OS X. What is the status of -Amacho, by the way ? Stalled. The same place is was 4-5 years ago. i386 only (the only hardware I had then) and no PIC support

Re: [fpc-devel] Masm

On Fri, Nov 7, 2014 at 12:55 PM, Adriaan van Os f...@microbizz.nl wrote: (to my astonishment Xcode even installs nasm). Just in case, you find this interesting: http://forum.nasm.us/index.php?PHPSESSID=sl1i7lf3upjgenov75agnkui56topic=1972.msg8738#new

Re: [fpc-devel] Proof of Concept ARC implementation

On Wed, Oct 29, 2014 at 10:38 AM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: ... about Delphi compatibility. That's the number two (and some times number one) reason, why FPC has to deal with the new features as ref-counting, anonymous functions, strings ...etc

Re: [fpc-devel] Suggestion: reference counted objects

On Tue, Sep 23, 2014 at 10:47 PM, Boian Mitov mi...@mitov.com wrote: Hmm... I have serious doubt the anonymous methods (actually referenced objects as previously discussed) will be discouraged. If anything they are more and more used across the majority of the languages, as they have huge

Re: [fpc-devel] Suggestion: reference counted objects

On Tue, Sep 23, 2014 at 1:51 PM, silvioprog silviop...@gmail.com wrote: On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov mi...@mitov.com wrote: It used to be compatible, however since we rewrote it to use anonymous methods, and attributes (And reduced the code to 1/4 of the original size in

Re: [fpc-devel] Suggestion: reference counted objects

That's exactly what I wanted to confirm - no name - for an anonymous function. I'm sure eventually the development society, will discourage the use of anonymous functions (just like unnamed constants are considered to be a bad pattern). Thus the only thing that would remain welcomed are closures

Re: [fpc-devel] Suggestion: reference counted objects

On Sat, Sep 20, 2014 at 3:43 PM, Boian Mitov mi...@mitov.com wrote: PS. Forgot the mention the anonymous methods – a real revolution when you do multithreading or parallel processing. Anything else looks like joke next to them... You can see some of my examples from interview in the Blaise

Re: [fpc-devel] Method for write string into TStreamt

On Tue, Jul 22, 2014 at 6:46 AM, tha...@thaddy.com tha...@thaddy.com wrote: A case for ternary computing is not really a bad idea ;) On 21-7-2014 21:42, Hans-Peter Diettrich wrote: Dmitry Boyarintsev schrieb: How about introducing a default parameter? The parameter keeps the method

Re: [fpc-devel] Method for write string into TStreamt

On Tue, Jul 22, 2014 at 12:17 PM, tha...@thaddy.com tha...@thaddy.com wrote: What I was a little bit more than hinting at in my previous answers is that it is impossible for an abstract read stream to know that there's a string to read. There is at least one higher level of implementation

Re: [fpc-devel] Method for write string into TStreamt

How about introducing a default parameter? The parameter keeps the method backward compatible, allowing write a string without the prefix. public procedure TStream.WriteAnsiString( const S: string; withLength: Boolean = true; ); thanks, Dmitry On Mon, Jul 21, 2014 at 5:34 AM, Marco van de

Re: [fpc-devel] Syntax choice (was: Blocks support)

On Sun, Jul 20, 2014 at 6:28 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: I proposed to use is block because of the analogy with the already existing is nested. Neither block nor nested was/is/would be a reserved word afterwards, just like many other words that have a special meaning in

Re: [fpc-devel] New targets for FPC - Windows Phone 8 and Flash

Sergio, Not sure if it helps you.There's a project of converting pascal to JavaScript. The thread about it came up just recently: http://lists.freepascal.org/pipermail/fpc-devel/2014-April/033689.html I'm sure you'd find it helpful for Pascal to ActionScript conversion. Besides, you might want

Re: [fpc-devel] New targets for FPC - Windows Phone 8 and Flash

On Fri, Jul 4, 2014 at 5:07 PM, Sergio Flores rel...@gmail.com wrote: Also, would anyone have interest in support Flash as a FPC target? It is possible to compile C++ to .swf, so having the same capacity for FPC would be great! There is a open source project called FlashPascal that does

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

22:07, Dmitry Boyarintsev пишет: Hello, The message file contains the comment (introduced in r13815) # Russian (utf-8) Language File for Free Pascal The file is in fact CP 866. This (non) issue is small enough to skip the bug tracker. I'm not sure that it's worth changing

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

On Tue, May 27, 2014 at 6:47 PM, Sergei Gorelkin sergei_gorel...@mail.ruwrote: Stock one (the iconv program) does not change contents of the file. Anyway, errorr.msg updated in r27819. Should sed -i 's/# Russian (utf-8)/# Russian (cp 866)/g' errorr.msg help, after iconv call?

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

:58 PM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: http://en.wikipedia.org/wiki/FLAGS_register It's a trap (single-step) flag. to stop after each instruction. (IIRC with some exceptions). I'd think it should be AMD64 compatible. thanks, Dmitry On Mon, Mar 31, 2014 at 6:17 PM

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

On Tue, Apr 1, 2014 at 1:47 PM, Martin Frb laza...@mfriebe.de wrote: Anyway, If it exists for 64 bits, should/can it be added to rtl\win\wininc\defines.inc same as it is for 32 bit? Imho, no. At least not in rtl defines. 1) it's not part of originating Windows headers (if these are used as

Re: [fpc-devel] What is / Where originates : FLAG_TRACE_BIT = $100; { our own invention } IN rtl\win\wininc\defines.inc

http://en.wikipedia.org/wiki/FLAGS_register It's a trap (single-step) flag. to stop after each instruction. (IIRC with some exceptions). I'd think it should be AMD64 compatible. thanks, Dmitry On Mon, Mar 31, 2014 at 6:17 PM, Martin Frb laza...@mfriebe.de wrote:

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 10:25 AM, Martin Frb laza...@mfriebe.de wrote: It does not state if or if not it is an operator. And also give no indication on its precedence, or if it is applied before or after operators. This is not so much about he -a^ (which is a (very) constructed case), but

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Mon, Feb 3, 2014 at 11:02 AM, Martin Frb laza...@mfriebe.de wrote: Parsed yes, but if it comes to evaluation, then you get {$T-} (@a)^ cant dereference an untyped pointer or similar @a^ always works. All I was asking is if the documentation should state it more clearly that ^ is (As part

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

On Sun, Feb 2, 2014 at 8:42 PM, Martin Frb laza...@mfriebe.de wrote: This does not include: ^ deref . accessing a member of a class/record (not unary) Are these two even considered as operators in pascal? Shouldn't [] (array-element access) be added in this case? thanks, Dmitry

Re: [fpc-devel] CPPClass

On Sat, Jan 18, 2014 at 12:19 AM, Den cyr...@gmail.com wrote: I'd really like to use it as I would rather write a Pascal CPPClass and interface with a Library rather than making my own bridge library and interfacing with that. Shouldn't there be 2 kind of CPPClass variants? One for GNU

  1   2   3   >