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
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 -
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
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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
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
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 <jonas.ma...@elis.ugent.be>
> wrote:
>
>>
>> Compilable source code + used command line parameters.
>>
>
> A
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
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
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 =
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
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
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
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
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
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:
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.
>
>
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
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
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
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
>>>
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
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.
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:
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",
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. (
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
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
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
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 ;)
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
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
>
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 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
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
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;
>
>
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.
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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?
: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
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
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:
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
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
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
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 - 100 of 200 matches
Mail list logo