> The compiler already supports keeping records in registers under the same
> conditions, but only up to a certain size (two native registers) and only
> using the
> same layout as they would have in memory (so no explicit splitting out fields
> into separate registers).
Using record fields as
>. For us inline variables is one of the most horrid if not *the* most horrid
>thing Embarcadero could have done to Object Pascal.
Can you tell us why ?
(In C I often declare variables just before using them and I indeed would even
like to do “for (int i = 0; i<10; i++) {a[i] = a[i+1];} ☺
> If Oxygene was open source and (CPU) native,
Oxygen *is* CPU native (optionally). But not open source, and of course there
are a lot more drawbacks regarding fpc/Lazarus.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
> codepage aware AnsiString was one of the disruptive changes that couldn't
> really be avoided.
IMHO, it could have been avoided (largely), but that would have come at the
cost of less perfect compatibility with Delphi XE (which even more severely
broke compatibility to previous Delphi
> . Syntax for parallel math (SIMD)
In Oxygen, you have parallel loops and future variables. This can be used for
defining parallelism in the syntax.
I understand that currently RemObjects implemented this as a simple translation
of the appropriate .Net framework API, and that it’s only
> Martin was a loner kind of guy, he did the most of the MSEGUI etc projects
> alone too.
A real Genius, but always happy to take part in very interesting discussions.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
> I'm interested in starting (or joining) a discussion on the next (*non*
> backwards compatible) version of FPC.
Did you take a look at Oxygen (RemObjects Elements) ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 25.02.2018 18:21, Giuliano Colla wrote:
Well, just for sake of argument, it appears to me a rather drastic
approach.
While you can do really cute stuff with Macros in C, using the (or doing
a) debugger for code that uses macros is a horrible PITA.
Nonetheless it would be nice if there
On 21.12.2017 08:51, Michael Van Canneyt wrote:
I know. But I believe such people are completely on the wrong track.
This is, because seemingly for you (and many others), the User
Communication is a most important part of the project and needs to be
crafted in the best possible way regarding
On 21.12.2017 08:52, Michael Van Canneyt wrote:
because I consider it a misguided approach,
Could you elaborate why you think so ?
What I have in mind is:
- Do a common project for both "business" and the "GUI near" code.
- The IDE provides some means to define which parts of the codes are
On 20.12.2017 11:36, Michael Van Canneyt wrote:
(Nothing stops really the server-side-native binary (e.g. written in
Pascal)
from sending a pas2js transpiled program to the browser as a part of
a 'html page'/script,
You could do so.
But I don't think you should.
How else should the Java
On 20.12.2017 11:36, Michael Van Canneyt wrote:
You program both separately, this is natural.
Obviously !
But this is not necessarily the end of what might be provided by (e.g.)
Lazarus.
-Michael
___
fpc-devel maillist -
On 19.12.2017 10:40, Lukasz Sokol wrote:
If I Understand This Correctly, pas2js treated program would run in a
browser, client side only ? And does not care what the server is,
because it does not run on server ?
That is of course correct and it is why I offered the sentence in brackets.
Great !
Thanks a lot to all who enabled this fantastic enhancement to the fpc
system !
I have been dreaming of being able to "simply run" Lazarus projects (and
legacy Delphi-) ) in a server and have the GUI displayed in a browser.
This seems to get in reach right now :) :) :) . (OK,
On 10.12.2017 20:01, J. Gareth Moreton wrote:
Starting at the 4th command, it looks back
to find a match in the 1st command,
What about loops (such as using arrays of n elements as obvious Vectors).
Supposedly, here some higher level optimization would be necessary.
-Michael
On 06.05.2017 09:39, Sven Barth via fpc-devel wrote:
That might be the one from Michael Schnell.
Very unlikely, as this text does not mention anything about how a source
file byte sequence is converted in a String constant / literal.
-Michael
On 06.05.2017 09:39, Sven Barth via fpc-devel wrote:
That might be the one from Michael Schnell. Probably it should be
marked with a big, fat warning that it's merely a user's suggestion
and nothing official.
I hope it is absolutely clear in the text that this is only a suggestion
Performance-wise, moreover for some tasks (such as Matrix
multiplication) with modern multi-core machines parallel calculation
could increase performance greatly. This can be done e.g. by using a
thread pool. (I once did a thread pool implementation based on TThread,
but I suppose there are
On 15.12.2016 08:35, Jonas Maebe wrote:
Thanks a lot for the detailed explanation !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I remember that some time ago an LLVM version of fpc was under discussion.
I'd like to know the state.
Background: I might be interested in doing a project that runs in the
browser. It seems that the upcoming technology for this is WebAssembly.
I found that an LLVM backend for WebAssembly
Just a note:
Such functions often are needed for semaphores etc.
In that case they need to take multi-thread and multi-Processor issues
into account.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 13.08.2016 18:57, Michael Ring wrote:
As you can see I have added the used registers list for this procedure
so my expectation was that only the register declared does get added
to the list of used registers.
Just an additional comment:
There are MIPS CPUs (e.g. PIC32 series) that
Great !
I am using a kind of home-brew pseudo closure (a function that ends with
"free;") in a project I am preparing.I'd be happy to use the formally
correct stuff.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 12/06/2015 03:03 AM, Denis Kozlov wrote:
The only way to make TSimpleIPCServer.PeekMessage respect
DoReadMessage=False parameter is to store locally all sent data
streams
TThread does contain a queue for "TThread.Synchronize" and
"TThread.Queue". It is decently managed for the main
Is this syntax candy for automatically creating multiple functions
(completely dedicated code for each type (combination) it is called
with) (in fact optimizing for CPU usage), or is a single code sequence
generated that takes different branches at certain locations (in fact
optimizing for
On 11/14/2015 11:20 AM, Sven Barth wrote:
You are aware that the discussion is about FPC's embedded target, thus
no device drivers available, because there's no OS running that could
host them?
I in fact did not know that with the RTL the term "embedded Target" is
defined in that way, but it
On 11/12/2015 09:48 PM, Simon Ameis wrote:
Hello Georg,
yes, RTL may be the wrong term, so let us call it PEL (Pascal Embedded
Library)
In fact much of this needs to be done by (or at least better is done by)
Device drivers, and hence not in the reach of fpc.
-Michael
(Not hitchhiking the other thread...)
On 13/10/15 19:59, Mohsen wrote:
Pascal sets can only contain values/enumerations whose ordinal value
is <= 255.
As currently new language features are discussed I would vote to drop
(or relax to some K ) this limitation. This would not break any
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:
IPC = Inter PROCESS Communication.
I know that you know this, but Ondrej is talking about cthreads in one
of his message, so I tried to politely set a trigger.
-Michael
___
fpc-devel maillist -
On 09/14/2015 03:56 PM, Ondrej Pokorny wrote:
3.) MISSING: Multiple clients (from different processes) talk to one
server.
4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a
server that isn't running. The server is
On 09/15/2015 02:43 PM, Michael Van Canneyt wrote:
With my paranoid mind I of course assumed you were hijacking the
thread...
Of course I was eagerly waiting on Ondrej to confirm that he was looking
for thread support :-) :-) :-)
-Michael
___
On 07/30/2015 06:58 PM, Jonas Maebe wrote:
Some results are interesting, like the lowercase(shortstring) function
becoming a rather impressive vectorised jungle:
http://pastebin.com/vpugp80e .
Really interesting
It would take a lot of expertize to do this manually.
Did you check that
On 07/24/2015 12:13 PM, Den wrote:
*Plan first, Then Code*: I believe was said? ;)
Tee or beer / cupboard or fridge :-) :-) :-)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 07/24/2015 12:13 PM, Den wrote:
Perhaps we could work on a Standard instead of just on the Compiler
itself?
the normal RFC process ...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote:
Declare before use has at least one technical advantage: it allows to
make much faster compliers. Declare before use allows to compile in
one pass, while compilers for languages like C need at least 2 passes.
???
ANSI C is a Declare
On 07/23/2015 09:21 AM, Michael Van Canneyt wrote:
If you want the features of C#, you should use C#, full stop.
True for syntax variant features.
But *some* syntax candy for common multi thread usage cases (e.g. a
parallel loop) nowadays is a necessity.
-Michael
On 07/23/2015 10:34 AM, Michael Van Canneyt wrote:
Support for a parallel loop is more than syntax candy, it is a
fundamental language change
and hence falls under 'compelling arguments'.
I suppose that happily such syntax supposedly will be a pure extension
and not interfere with the
On 07/17/2015 09:00 AM, Maciej Izak wrote:
I think is good idea to discuss new dialect.
The Code-aware String implementation could be much better than as well
in Delphi as in fpc, but this only makes sense when the TStrings type
(and it's descendents) and the interface to many libraries are
On 05/29/2015 08:37 AM, Jonas Maebe wrote:
The compiler adds an explicit comparison to ensure that in case of an
integer division by zero, a run time error is raised anyway. The same
is done on PowerPC, which doesn't trigger an exception for integer
division by zero either.
As jumps in
On 05/29/2015 10:22 AM, Edmund Grimley Evans wrote:
There may be cases in which you don't need to know about the exception
immediately.
In fact - especially with high-performance applications - there are
cases where the algorithm you are doing guarantees that the divisor is
not zero, so
On 05/14/2015 12:28 AM, Marco van de Voort wrote:
No, since the that coder decides what he wants to offer up for
inclusion, not the community.
For obvious reasons, a single person is less able to see the
consequences of a design decision than multiple analysts can.
So that principle often
On 05/13/2015 11:16 AM, Sven Barth wrote:
You do know that there exist other synchronisation primitives beside
the event queue? And since the TParallel.For itself is a blocking call
I highly suspect that they *don't* use the event queue, but TEvent and
similar instead.
If using other
On 05/12/2015 06:43 PM, Marco van de Voort wrote:
Will the fpc library provide the appropriate classes for doing
TParallel.For as described ?
That will depend on when you submit that patch :-)
This of course triggers my standard answer to such wording:
It does make sense to first decide
On 05/12/2015 05:49 PM, Sven Barth wrote:
Their own .Net compiler has shown that one can't simply map the
Delphi language to the CLR 1:1 and expect something seamless. We see
that with FPC's JVM support as well. So using a variant of the
language that embeds itself into the framework is a
On 05/12/2015 05:39 PM, Sven Barth wrote:
Why should that interfere in any kind?! Behind the scenes it's
propably using TThread anyway...
Because Foreground code (here the calls made by the visible code the
user creates to use TParallel) and the background code in the
threads that
Seemingly Xe3 provides a parallel loop feature to support fast
multi-Core applications
try
// counts the prime numbers below a given value
Tot:=0;
SW:=TStopWatch.Create;
SW.Start;
Ooops
- Delphi Xe8
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 05/12/2015 02:21 PM, Sven Barth wrote:
They don't /own/ Prism. They merely license it, so what the Oxygene
developers do and what the Delphi developers do are two different things.
IMHO it's really silly that they provide different Pascal Dialects and
Widget frameworks for different
On 05/12/2015 02:21 PM, Sven Barth wrote:
In the end I suppose that support for that TParallel class will be
based on patches welcome once anonymous functions are supported.
OK.
As this is a kind of thread support, I assume that it might interfere or
be related with with the
Hi Linux and Java experts,
My son is about to start a project that aims to research variations in
small code snippets that are automatically generated by a kind of compiler.
Of course he uses fpc to do the testing system, that also includes the
compiler.
Now he needs to start the code
On 12/14/2014 04:51 PM, Marco van de Voort wrote:
More importantly, TRUE is generally defined as !FALSE, and vice versa
IMHO, (usually, ubiquitously ) FALSE is defined as a binary zero of
appropriate bit count (hence unambiguously) , while TRUE is defined as
not FALSE and hence it's binary
On 12/05/2014 10:51 AM, Hans-Peter Diettrich wrote:
IMO the Insert procedure should change the encoding of the
string-to-insert into the CP of the target string. Else the target
string can become unusable, containing an mix of characters from
different codepages. While a RawByteString can have
On 12/03/2014 05:02 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
- It does not result in additional conversions.
It does, e.g. in searching or sorting of StringList, when it can contain
strings of different encodings. The choice of a unique encoding for
application strings (maybe
On 12/03/2014 12:52 AM, Hans-Peter Diettrich wrote:
You forget that Jonas refers to *dynamic* string encodings, unknown at
compile time.
???
In you other mail you pointed out that fpc (other than Delphi) does not
provide *dynamic* string encoding with RawByteString (and where else
would it
On 12/03/2014 12:52 AM, Hans-Peter Diettrich wrote:
In Delphi *no* string can have an dynamic encoding of CP_NONE or CP_ACP,
If you really do have Dynamic strings, obviously, the *definition*
(i.e. CP_...) of such strings is strictly static (just for compiler use)
and never cant be used as
On 11/28/2014 09:15 PM, Hans-Peter Diettrich wrote:
You suggested to use string as UTF-16 on Windows, and UTF-8 on
Linux. That's what I understand as a unique program-wide string
representation (not sourcecode-wide, instead program as *compiled*).
Then I cannot see any need or use for
On 12/02/2014 01:05 PM, Michael Schnell wrote:
But why do you say would be appreciated ? Is it not possible to use
RawByteString in a way the name suggests, by never bringing it
together with any String variable of a different encoding brand and
hence avoid any conversion - be same intentional
On 11/29/2014 07:55 AM, Jonas Maebe wrote:
Exactly the same goes for converting strings with code page CP_NONE to
a different code page: your program is broken when it tries to do that,
While accessing an array beyond its bounds is not detectable at compile
time and accessing an array beyond
On 11/28/2014 08:19 PM, Hans-Peter Diettrich wrote:
In that discussion I found several errors, which are not detected by
the compiler nor handled in the RTL. In the concrete entry the illegal
use of the *generic* CP_NONE identifier is mentioned. That's why I
felt a need to address several
On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote:
The universal paradigm would allow for extensions (e.g. UTF-32,
multiple 16 Bit Code pages, an additional fully dynamic String type,
n-byte un-encoded string types), as I described in the Wiki page.
Even if feasable, such arbitrary string
On 11/27/2014 07:29 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
E.g. there are (are least two Code pages for UTF-16 (LE, and
BE), that would be worth supporting.
You are confusing codepages and encodings :-(
That is why I put goose-feet around Code pages. I used this wording
On 11/26/2014 05:25 PM, Sven Barth wrote:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
No, you can't, because the RTL does not handle that. For AnsiString
the element size is *always* 1. It's
On 11/26/2014 05:37 PM, Jonas Maebe wrote:
invalid (in the meaning of undefined) in both FPC and Delphi.
Sorry (I am not a native speaker). But to me undefined and invalid
have completely different meanings (in this context). An Invalid use
of the language would result in an error (compiler
On 11/26/2014 09:30 PM, Hans-Peter Diettrich wrote:
So seemingly you could do MyStringType = type
AnsiString(CP_UTF16), and seemingly the size information is set
according to this.
Not in Delphi XE.
Thanks for the clarification.
I did have some hope that fpc would be (or could be
On 11/26/2014 07:13 PM, Hans-Peter Diettrich wrote:
Not all codepages have a fixed number of bytes per character.
The string preamble contains the *element size* (1 for AnsiString),
just like with every dynamic array.
Sorry for sloppy wording. Of course I did mean element size
(Character here
On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote:
How does that look when hand-written on a cheque?
Supposedly this is a non-breaking space, that does not allow to be
replaced by a line-break (nbsp; in HTML)
-Michael
___
fpc-devel maillist -
On 11/24/2014 10:45 AM, Michael Schnell wrote:
. I'll post the wiki paper on this tomorrow.
Please see a preliminary version of the text -
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support#Three_more_RAW_types
.
(Please use a new thread for any discussion
I fail to understand some of the text.
It seems to be unavoidable to use the name ANSIString even though I
always though up when seeing a thing called ANSI containing Unicode
(e. g. UTF8String = type AnsiString(CP_UTF8) ).
Seemingly here the bytes per character setting implicitly is
On 11/26/2014 11:40 AM, Mattias Gaertner wrote:
Ansistring supports only one byte per character code pages.
Even more confused. Am I wrong thinking that with code aware Strings,
for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not
right, than due later) ?
What is a
On 11/26/2014 12:09 PM, Sven Barth wrote:
In Delphi (and FPC) CP_ACP corresponds by default with the current
system codepage (e.g. CP1252 on a German Windows).
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in
On 11/26/2014 12:13 PM, Mattias Gaertner wrote:
In mode delphiunicode String=UnicodeString.
I see.
So even in Delphi XE where UnicodeString is denoted by CP_UTF16, the
value of the constant CP_UTF16 is not the same as the value of the
(constant or) variable CP_ACP, (while OTOH using the
On 11/26/2014 12:10 PM, Mattias Gaertner wrote:
the results of conversions from/to the CP_NONE code page are undefined.
... because CP_NONE is not a real code page.
So you understand result as what you would get when printing.
In the context of this wiki page I would understand result as the
After re-reading yet another question:
In section String concatenations there is no mentioning about
auto-conversion. For statically typed Strings it's rather obvious that
they will be auto-converted if appropriate. Technically - if differently
encode - they seem to be converted to Unicode
On 11/26/2014 03:05 PM, Sven Barth wrote:
OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as
String(CP1252) but different from String without brackets which in
turn is the same as String(CP_UTF16) ? Correct ?
There is no String with brackets. You can only use AnsiString
On 11/23/2014 04:31 PM, Michael Van Canneyt wrote:
What about RTL with UTF8 as default?
I am nearly done with the would-be designdocument Wiki text, you
seemed to want to see done on a suggestion for an extension of the
string type variants, that allow for e.g. (1) TStrings siblings and
On 11/23/2014 05:28 PM, Marco van de Voort wrote:
I meant in the way Mattias proposed, continueing making the default
string type utf8 on Windows.
As with Windows, the OS requires API access with UTF-16 encoded strings
this would force lots of auto-conversions, not only in the RTL but with
any
On 11/24/2014 10:26 AM, Michael Van Canneyt wrote:
How do you reconcile this with the fact that pascal should be easy,
and it should be usable for teaching ?
..
Let's not get carried away, please... keep it simple.
I do know that this is a decent argument
That is why I put my text in
On 11/24/2014 10:41 AM, Michael Schnell wrote:
Maybe a way to allow the user to define the project-wide default
encoding branding for the unqualified type String can be invented
(e.g. OS-Default if not explicitly set)
Obviously this asks for a versatile String type (not existing in Delphi
On 11/21/2014 09:53 AM, Marco van de Voort wrote:
The versatile string type is vaporware. There is no designdocument,
Do you want me to create a document ? I could easily do it.
But as it would need compiler magic to work with, I don't have any
chance to do the necessary patches. So I think
On 11/21/2014 10:44 AM, Michael Van Canneyt wrote:
But as it is, without anything for anyone to work with, your ideas are
simply dead-born childs.
Right you are and Marco is right that it is nothing but Vaporware right
now.
I did post a kind of documentation draft here to provide a base to
On 11/19/2014 06:46 PM, Marco van de Voort wrote:
Not old Delphi compatible. One can go new delphi compatible, and make
everything 2-byte as much as possible.
Of course I did mean compatibility to New Delphi Strings.
But here (seemingly) TStrings (and with this TStringList) works on a
single
On 11/19/2014 09:12 AM, Marco van de Voort wrote:
But I meant that even if you use utf8string in many places as soon as
you stuff it in a container like tstringlist, that is gone. (forced
ansi conversion, since tstringlist's interface is defined using plain
string(0))
AFAI Understand (having
Considering the multiple discussions recently here done on the New
Strings, that also introduce multiple compiler-relevant brands of a
single type, IMHO there are some restrictions to be payed attention to,
if the user is enable to use both ref-counted and not ref-counted
Objects. Otherwise we
On 10/29/2014 01:27 PM, Michael Schnell wrote:
I forgot:
...(b1) you can't assign a ref counted object to a variable of the not
ref counted type brand: this will result in a runtime error (as the ref
counted TObject type can hold not ref-counted objects by ref-count = -1)
...(b2) you can
On 10/29/2014 01:58 PM, Sven Barth wrote:
- no change in reference count when assigning a refcounted object
variable to it
- no change in reference count when assigning it to a refcounted
object variable
- no change in reference conut when assigning between weak variables
Thanks for the
On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote:
I believe you overcomplicate it
No. We are going to run into the same mess with incompatible brands of
the same types as with New Strings :-(
-Michael
___
fpc-devel maillist -
On 10/29/2014 03:33 PM, hinsta...@yandex.ru wrote:
I believe that whoever came up with new strings overcomplicated it
Consider Java and C# : they do not store encoding in string variables
Yep.
dynamically encoded Strings are a nice feature if done appropriately.
But I don't think they are
On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote:
Whatever; I disagree
refcounted descendants of non-refcounted objects should be assignable to any
variable of parent type; just like any variable is assignable to a variable of
parent type
And what about TLIst ? If TList is done for not
On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote:
I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it
be.
OK. Repeating the argument for TObjectList.
-Michael
___
fpc-devel maillist -
On 10/27/2014 10:44 PM, Boian Mitov wrote:
In general the C/C++ notion of doing as little in the language as
possible, and as much in library has worked very well for it over the
years.
Yes, pluggable languages concept has existed at least since C ;-) . I
agree, and as I said has worked well.
On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote:
Something like ShortString and AnsiString?
Only that ShortStrings can easily be avoided (AFAIK, no great
performance advantage to use them) and hence are seldom used right now.
-Michael
___
On 10/27/2014 07:59 PM, Sven Barth wrote:
- in code that does not use ARC (modeswitch arc off - the default;
or maybe better a local directive) all instance variables are
considered weak
While I do have a vision what weak means here, can you give an exact
description ?
-Michael
On 10/27/2014 11:26 AM, Jonas Maebe wrote:
I think that a cycle detector should be an independent component, just
like heaptrc is an independent add-on to detect memory problems in
regular programs.
So you suggest cyclic references should be forbidden (erroneous
programming technique).
On 10/27/2014 11:26 AM, Jonas Maebe wrote:
(e.g. suppose that inherited method inserts self into a linked list).
Or using TList with it ?
Would we need an alternate TList for ref-counted objects ?
-Michael
___
fpc-devel maillist -
On 10/27/2014 11:37 AM, hinsta...@yandex.ru wrote:
I think we should just roll out this feature to FPC trunk and let people test
it; so those who are interested in it would test it and detect potential
problems in practice rather than in thought experiments
Hmm.
The potential TList problem
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote:
Maybe; however I am asking about reference counted objects feature.
Sorry for the fuzz. (Your contribution was a direct reply to my mail
about parallel loops.)
-Michael
___
fpc-devel maillist -
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote:
I thought Svan Barth said that he considered implementing it
Regarding this, Maybe, Success in implementing should be preceded by a
decision if and how this feature does make sense regarding the possible
addition danger it offers (see the
On 10/14/2014 11:50 AM, Sven Barth wrote:
It's a proof of concept implementation to have real code to work with
instead of just theories. Also it's in a separate branch, so it
doesn't interrupt any existing code except one explicitly uses that
branch.
Sounds good.
-Michael (curious...)
On 10/11/2014 06:04 PM, Jonas Maebe wrote:
Macro's never replace text in the middle of an identifier.
Does the optional extended FPC macro processor not support a
concatenation syntax (such as ## with the C macro preprocessor) ?
In theory it could be possible to use the gnu C macro
On 10/13/2014 02:37 PM, hinsta...@yandex.ru wrote:
Any success yet?
Any chance this feature will be in FreePascal 3.0 ?
I don't suppose anybody is working on a parallel loop language feature.
-Michael
___
fpc-devel maillist -
1 - 100 of 1709 matches
Mail list logo
