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 va
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 - fp
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 b
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
> > MyStrin
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 a
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 fa
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 ca
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 ar
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 t
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 clea
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 def
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
http://lists.freepascal.org/cgi-bin/mailman/list
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
http://lists.freepascal.org/cgi-bin/mailman/
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 an
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
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 c
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 in
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 wer
On Fri, Oct 12, 2018 at 2:31 PM Jonas Maebe wrote:
> The documentation is wrong.
>
> Boolean8 is defined as an alias for Boolean in the RTL, so it won't
> help.
If the intent of BooleanN is to help interfacing C-libraries.
Would it make sense to change BooleanN from being an alias to more
consis
On Fri, Oct 12, 2018 at 1:07 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
>
> Boolean8 is an alias to Boolean. But if you need to work with 1 and 0, but
> have 4 Byte width then you could try Boolean32.
>
Indeed. It's scheduled for 3.2.0 release as alias for Boolean.
Howev
On Fri, Oct 12, 2018 at 1:07 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Dmitry Boyarintsev schrieb am Fr., 12. Okt.
> 2018, 17:26:
>
>> Maybe "Boolean8" type should help instead?
>> David, could you please test with Boolean8 inste
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
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
(rathe
On Fri, Oct 12, 2018 at 1:51 AM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> Dmitry Boyarintsev schrieb am Fr., 12. Okt.
> 2018, 02:07:
>
>> On Thu, Oct 11, 2018 at 4:16 PM Jonas Maebe wrote:
>>
>>> However, the Objective-C BOOL type
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 versio
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 s
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 a
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 ideal
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 = cl
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 t
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 bec
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 C
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 i
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 also
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
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 funct
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 PUR
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/
> 1
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 userSpaceScaleFactor (which was in t
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 cocoa_extra.pas
In that
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 has no
> support (it would
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
_
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
> wrote:
>
>>
>> Compilable source code + used command line parameters.
>>
>
> A stand-alone test doesn't reproduce
On Tue, Jun 7, 2016 at 12:00 PM, Jonas Maebe
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 command line parameters.
>
A stand
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 li
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 = procedure
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 (at
least not to be forgotten)
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
functions syntax for forward
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
http://lists.freepascal.org/cgi-bin/mailman/listinfo/
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 block-based APIs of NSFileHandl
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 extendedGamePadChange(gamepad: GCExt
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*
* threa
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.
>
> Sounds like GameMaker (htt
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 contains the "self" pointer of the
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
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 (gamepa
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
>>> discussion. Does it mean the original issue is a
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
http://lists.freepascal.org/
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.
...and there should be a sol
Hello,
Is it possible to pass a macro through command line (fpc 2.6.4)?
here's an example.
The following code compiles and works as expected:
{$macro on}
{$define A:=5}
begin
writeln(A);
end.
But, the program
begin
writeln(A);
end.
fails to compile with the following command line:
fpc -Sm -d
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:
https://www.youtube.com/watch?v=BJIqHIYSDrk
thanks,
Dmitry
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 into the code, th
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 ;)
That's exactly the thin
On Mon, Oct 12, 2015 at 3:11 PM, 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 needed to broken from.
>>
>
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 come up with whacko sto
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. (
https://docs.python.or
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", assuming it works in turbo pa
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 F
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
> common ground ;)
>
I wonder if
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 t
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 expression should
> be bl
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
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;
>
> Thereby expr1 returns Boolean and e
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. Java Loading Shared Lib (JNI)
On Fri, Jul 17, 2015 at 2:03 PM, Maciej Izak 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 these.
>
I'
On Fri, Jul 17, 2015 at 1:53 PM, Maciej Izak 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
compiler speed, ge
On Fri, Jul 17, 2015 at 11:44 AM, Paul van Helden
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 C.
>
> So wi
On Tue, May 12, 2015 at 12:43 PM, Marco van de Voort
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 FPC?
thanks,
D
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 abo
On Mon, Feb 23, 2015 at 6:02 PM, Jonas Maebe
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!
___
fpc-devel mailli
On Wed, Nov 12, 2014 at 7:03 AM, Juha Manninen
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 in the parser?
Afte
On Sun, Nov 9, 2014 at 4:27 AM, Juha Manninen
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
> about FPC options be
On Fri, Nov 7, 2014 at 11:05 PM, Adriaan van Os
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
Not sure, if I'll
On Sat, Nov 8, 2014 at 2:15 PM, Juha Manninen
wrote:
> On Fri, Nov 7, 2014 at 1:13 AM, Tomas Hajny 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 is a good idea if only somebody impl
On Fri, Nov 7, 2014 at 12:55 PM, Adriaan van Os wrote:
> (to my astonishment Xcode even installs nasm).
>
> Just in case, you find this interesting:
http://forum.nasm.us/index.php?PHPSESSID=sl1i7lf3upjgenov75agnkui56&topic=1972.msg8738#new
___
fpc-deve
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 funct
On Wed, Oct 29, 2014 at 10:33 AM, wrote:
> I believe that whoever came up with new strings overcomplicated it
> Consider Java and C# : they do not store encoding in string variables
>
And NSFoundation (the foundation for Cocoa and iOS) strings do.
But adding encoding was not about "what other l
On Tue, Sep 23, 2014 at 10:47 PM, Boian Mitov 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 advantages.
>
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 -
On Tue, Sep 23, 2014 at 1:51 PM, silvioprog wrote:
> On Tue, Sep 23, 2014 at 1:53 PM, Boian Mitov 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 the process) ~2 years ago, the
On Sat, Sep 20, 2014 at 3:43 PM, Boian Mitov 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 Pascal Magaz
On Tue, Jul 22, 2014 at 12:17 PM, 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
> necessary: one t
On Tue, Jul 22, 2014 at 6:46 AM, 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?
>>>
On Sun, Jul 20, 2014 at 6:28 PM, Jonas Maebe
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 one context o
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 V
Hello,
I was curious about the proposed syntax option, why "in block" rather than
just "block"? There's no "block" reserved word in FPC yet (unlike mentioned
earlier Oxygen).
In general "reference to" seems like a poor choice made by Embarcadero (and
FPC has to follow).
* using "in block" seems m
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 to
On Fri, Jul 4, 2014 at 5:07 PM, Sergio Flores 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 exactly this,
> I
On Tue, May 27, 2014 at 6:47 PM, Sergei Gorelkin wrote:
>
> 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?
___
I thought it would be good for consistency with other translation files:
errorpl.msg / errorpli.msg
errorhe.msg / errorheu.msg
...and sanity.
Could transcoder update the comment as well?
thanks,
Dmitry
On Tue, May 27, 2014 at 2:24 PM, Sergei Gorelkin wrote:
> 27.05.2014 22:07, Dmi
1 - 100 of 221 matches
Mail list logo