[fpc-devel] thread safe random
I think that the just committed threadsafe random is overly complex. I provided a working version some time ago that is less intrusive. https://forum.lazarus.freepascal.org/index.php/topic,35050.msg242571.html#msg242571 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible bug in fpc_round_real for softfloat?
It is a bit more complex than that: using the softfloat ABI does not necessarily mean softfloat is used. The ABI can still use hardware fp. And that is the case here, I suspect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible bug in fpc_round_real for softfloat?
Raspberry Pi, what OS, because you write armsf and the default on Raspbian (and other major distro's) is armhf. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)
On 2019-11-08 22:33, Bart via fpc-devel wrote: Hi, > 2. A rather more serious issue. Compile time errors occur with e.g. ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc (32-bit), objfpc (32+64-bit) and delphi (32+64-bit) Range check error while evaluating constants (2147483648 must be between -2147483648 and 2147483647) Same error for AnInteger.SetBit(High(TIntegerBitIndex)) in modes objfpc (32-bit), delphi (32-bit) and macpas (32-bit) I broke my brains and could not conclude anything else than a compiler bug in these cases: setting the sign bit is all I do and the bit patterns are all correct. It seems that this is also confirmed. Anyway you suggestion to do the internals only as unsigned types makes sense if in that case the sign bit is respected. Funny how such simple code - which it is - can have so much complexity. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
On Wed, 31 Jul 2019 01:26:23 +0200
Martok wrote:
Of course, if you wanted a run-time error you would need to insert a
run-time
check, and 'some people' seemed to be hell-bent on saving these 2
cycles at any
cost.
The patch to switch from option a1) to a2) would be straightforward,
fix 32079
and insert a default otherwise clause that raises a RunError in -Miso.
But the
question is again, does Freepascal actually aim to be compliant with
anything,
or just have a compatible syntax and do its own thing from there?
It seems to me that the problem of a lack of correspondence in a case
statement list should be of the same level of attention of the index
limits of an array, except there is no memory corruption risk. The
solution could be to insert a run time check in presence of the
switch {$R+}, if the latter is allowed in iso mode.
Greetings, Marco Borsari
No, that is not allowed in the context of the standards, but the
compiler solves that already earlier in the code path and if the code is
compiled with {$rangechecks on} an out of bounds will be detected. What
needs to be detected if all *used* labels are within the confines of the
used ordinal, but a selector without label should throw an error.
In the case of my patch it behaves like extended pascal mode and throws
a run-time error in that case. That is debatable in some cases, because
if the selector has no label and the compiler can resolve that at
compile time it should in my opinion and how I read ISO 10206 throw a
compile-time error. See my remarks and test code.
Maybe you can evaluate those conclusions I made.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I might add to my previous post that case(2) is open for discussion after the patch: One might argue that also in the case of ISO 10206 the compiler should throw a compile-time error in that particular case, because it is already obvious that the value has no label. Therefor I left out a correctness evaluation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
Indeed the wording between 7185 and 10206 has changed little, but important: dynamic. Therefor note I still think the patch is acceptable. I studied some more on the subject and here I will try and explain what the actual behavior needs to be when one want to interpret the ISO 7185 case very strict. In that case we need a different patch to solve the issue that is more complex: suppose ISO 7185 is interpreted very strict, then one should read it as I illustrate with three examples. The current ISO implementation has bugs anyway. If one has to keep the *compile time* error a patch needs to solve this type of code *without* an error or warning: program testisocase1(infile,outfile); // If compile time for iso 7185 errors are correct: // this code currently throws a compile-time error // and that's a bug. // It should give no error at all and no warning at all // After the patch there is still a- spurious - warning (small bug in extendedpascal!) type operator = 3..5; var x:integer; o:operator = 4; begin x:=1; case o of 3 : x := x;// all 4 : x := x;// possible 5 : x := x;// cases end; end. --- And if ISO 7185 is interpreted to throw a compile time error, this code should throw a compile time error: --- program testisocase2(infile,outfile); // If compile time for iso 7185 errors are correct: // This code should throw a compile time error with the current interpretation // and it does. // But after my after the patch it throws a run-time error // not a compile time error. type operator = 3..5; var x:integer; o:operator = 4; // here it is an invalid value begin x:=1; case o of 3 : x := x; // 4 : x := x;// this label removed! 5 : x := x; end; end. - And this code should issue just a warning: - program testisocase3(infile,outfile); // If compile time for iso 7185 errors are correct: // This code should issue a warning and not a compile time error // since the labels are in the ordinal range. // My patch handles this case correct. type operator = 3..5; var x:integer; o:operator = 3; begin x:=1; case o of 3 : x := x;// valid 5 : x := x;// labels end; end. --- Summary: if current interpretation is correct, then to the best of my knowledge: case 1 is a big bug:throws compile error on good code. Needs to be fixed anyway. case 2 handles correct throws compile error on value without label case 3 is a bug throws compile error, but should issue a warning, not an error if ISO 10206 behavior is acceptable (which I think it is!): case 1 handles correct, but issues a spurious warning case 2 issues a run-time error case 3 handles correct and issues a correct warning The above is the exact behavior as in extendedpascal. Note that here this code proves that that code is also not fully correct because of the spurious warning. On 2019-07-31 01:26, Martok wrote: If you want something a bit more clear, try ISO/IEC 10206 (Extended Pascal). They split up errors and dynamic violations, which helps make the point clearer. The patch to switch from option a1) to a2) would be straightforward, fix 32079 and insert a default otherwise clause that raises a RunError in -Miso. But the question is again, does Freepascal actually aim to be compliant with anything, or just have a compatible syntax and do its own thing from there? Best, Sebastian ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I have the faint suspicion that the case chapter in the extended pascal standard is a deliberate rephrasing of the one in iso 7185:1990. Specifically adding the wording "dynamic" with regard to the error type. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 14:04, Sven Barth via fpc-devel wrote:
thaddy schrieb am Di., 30. Juli 2019, 10:04:
On 2019-07-30 01:43, J. Gareth Moreton wrote:
As someone on the issue pointed out... on page 2, section 3.1:
3.1 Error
I have added this to the bug report. Consider that here all possible
case labels are implemented, the compiler still throws a compile
time
error.
That means the implementation is wrong anyway.
{$mode ISO}
program isobug(infile,outfile);
type
operator = (plus, minus, times);
var
x:integer;
o:operator = plus;
begin
x:=1;
case o of
plus : x := x; // all
minus : x := x; // possible
times : x := x; // cases
end;
end.
The easy way out seems to revert to the 3.0.4 implementation given
the
section mentioned.
Gareth's suggestion would be nice to have, though.
That's definitely a bug, cause the same code (with "operator" changed
to "op") compiles in mode ObjFPC without any warning or error.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Yes, it is a bug, but note the case handling in mode objfpc (all modes
except macpas, iso and extended) differs.
It should only error out if the selector value has no case label.
Extended Pascal then throws a run-time error.
The other modes, like objfpc, silently continue.
It should not error out at all at compile time.
I provided a patch that makes the iso behavior equal to the extended
pascal behavior.
This solves both the above issue and the compile time vs run time error.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
Scott Franco a.k.a. Moore says this, what makes sense, in his manual "Rules of ISO 7185": == Case statement The case statement defines an action to be executed on each of the values of an ordinal: case x of c1: statement; c2: statement; ... end; The "selector" is an expression that must result in an ordinal type. Each of the "case labels" must be type compatible with the selector. The case statement will execute one, and only one, statement that matches the current selector value. If the selector matches none of the cases, then an error results. It is NOT possible to assume that execution simply continues if none of the cases are matched. A case label MUST match the value of the selector. == So the core is that his interpretation is: selector - on use - *must* match an existing label. Ergo not the ordinal type but its value determines if it is an error or not. FPC currently has it the other way around: if the case has insufficient processing for ALL possible values for the selector it already throws a compile-time error. That's in my opinion the wrong interpretation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
The C case block differs from Pascal's case block in that it falls through if no return is specified. That means a single value can trigger multiple case labels. In Pascal it can only trigger one case label. Because of the fall-through a default: has greater purpose than in Pascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 12:26, Paul Breneman wrote: This message thread has been interesting to read. I just realized today that I dealt with similar issues in Delphi 19 years ago. This is discussed in the good Microsoft Press book *Code Complete* by Steve McConnell. Using the default else block of a case statement to show a program error message is exactly what is recommended on pages 319-320 (and the same thing for repeated if statements on page 316). I don't know if this directly applies, but it was fun to renew a few brain cells by looking at old emails. If I add an enumerated type and forget to update some of my code, I'd like to get an error message when the unchanged code is run. Regards, Paul www.ControlPascal.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel I actually hope Scott Franco reads this (a.k.a Scott Moore). He knows a lot about the standards and developed several iso compliant interpreters/p-code compilers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 12:12, Marco Borsari via fpc-devel wrote: On Tue, 30 Jul 2019 06:38:56 +0200 thaddy wrote: According to what I found there is no smoking gun: I could not find any implementation or reference from any reputable source that implements the case statement in the way that is implemented in trunk: compile time error when not all of the ordinal range for the case are processed. It simply does not exist as far as I am concerned, unless someone can convince be by a reputable source that such implementation exists elsewhere. Pascal-S of Wirth does it. Marco Borsari I just compiled pascal-s (Moore's iso version, because that's the relevant one) but did not run it yet with my patch. It fails at run-time or compile-time? It is an interpreter/p-code system, so has a greater level of freedom. Note iso7158 is based on Wirth's but Wirth's version is not iso compliant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 10:23, Michael Van Canneyt wrote: Just interpreting the standard, I think that the error should be run-time, not compile-time (although definitely keep the warning). That's just my take on it though. If it is to be changed, it should be simple enough by configuring the 'elselabel' field to point to an error-raising routine rather than 'endlabel' (which occurs if there's no else block). I tend to agree with your reading of the spec. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel I solved it by having iso use the same codepath as extended pascal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 11:18, J. Gareth Moreton wrote: Yeah, I don't find that description clear either. One shouldn't have to be a lawyer in order to decrypt such standards! Of course, FPC can follow its own standard, but it should be one that everyone agrees on. While I think we shouldn't live in the shadow of Delphi or be jammed in the realm of backwards compatibility, I'm a bit wary if there are quirks or errors that might otherwise cause people to back away from FPC rather than adapt their code to conform to it. But just from a practicality point of view, I think a run-time error is better in this instance because you may be able to justify a particular input value not being possible, and so not need to add code for it in your case block, but if such a value ends up reaching the case block anyway, then you deserve to endure a run-time error because it means you haven't covered it properly. Speaking of books and documentation, what's out there for Free Pascal in particular? Gareth aka. Kit P.S. I like to think my own design specs are a lot clearer than that ISO! Efforts to try and be exact often fail. Natural language is way to expressive for human beings to achieve exactness. Otherwise we would have a compiler for it ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
I submitted a patch so that iso mode behaves like extended pascal mode. i.e. The compile time error is gone (also in the case I showed to be a true bug) And a run-time error is issued as per extendedpascal. Solves most problems I have with the "feature" and existing code written in iso mode compiles again. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
On 2019-07-30 01:43, J. Gareth Moreton wrote:
As someone on the issue pointed out... on page 2, section 3.1:
3.1 Error
I have added this to the bug report. Consider that here all possible
case labels are implemented, the compiler still throws a compile time
error.
That means the implementation is wrong anyway.
{$mode ISO}
program isobug(infile,outfile);
type
operator = (plus, minus, times);
var
x:integer;
o:operator = plus;
begin
x:=1;
case o of
plus : x := x; // all
minus : x := x; // possible
times : x := x; // cases
end;
end.
The easy way out seems to revert to the 3.0.4 implementation given the
section mentioned.
Gareth's suggestion would be nice to have, though.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor debate with ISO standard on case blocks
Telling. I took the trouble to look up the case statement in a random selection of about 30 instruction manuals, books and magazines about Pascal from my personal library (only a few pretend to be ISO compliant or mention the standard, though. These beasts are rare) and some compilers. I can not find 1! implementation that tries to do what FPC trunk currently does. I am really passionate about this. The quote below seems to suggest that the behavior in 3.0.4 was acceptable after all. That said: the suggestion by Gareth to issue a warning at compile time and a run-time error when an ordinal is used that has no case label seems to be much closer to what the 7185:1990 standard actually describes. According to what I found there is no smoking gun: I could not find any implementation or reference from any reputable source that implements the case statement in the way that is implemented in trunk: compile time error when not all of the ordinal range for the case are processed. It simply does not exist as far as I am concerned, unless someone can convince be by a reputable source that such implementation exists elsewhere. I strongly object against the current implementation and I believe it to rely on false premises. Thaddy On 2019-07-30 01:43, J. Gareth Moreton wrote: As someone on the issue pointed out... on page 2, section 3.1: 3.1 Error A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected. NOTES 1. If it is possible to construct a program in which the violation or non-violation of this International Standard requires knowledge of the data read by the program or the implementation definition of implementation-defined features, then violation of that requirement is classified as an error. Processors may report on such violations of the requirement without such knowledge, but there always remain some cases that require execution, simulated execution, or proof procedures with the required knowledge. Requirements that can be verified without such knowledge are not classified as errors. 2. Processors should attempt the detection of as many errors as possible, and to as complete a degree as possible. Permission to omit detection is provided for implementations in which the detection would be an excessive burden. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] OpenSLL units deprecated protocols.
I have internally deprecated some SSL protocols since they no longer work because they are no longer compiled in. I also internally changed the bottom line to tls 1.2 Would it be OK to provide that as a patch? Or would you consider more things are necessary than just deprecated and default? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Optimizing unused return values of inline functions
> On 21.08.2017 13:22, Michael Van Canneyt wrote:
>>
>>
>> On Mon, 21 Aug 2017, Benito van der Zander wrote:
>>
>>> Hi,
>>>
This pattern is not inherently efficient. Why should it be ?
>>>
>>>
>>> It is not efficient, because of the pointless instruction!
>>
>> I am not speaking of the current FPC implementation. It may well be that
>> the
>> code is not most optimal.
>>
>> I am asking, why do you think *this pattern* (of always returning self)
>> should be inherently more efficient ?
>
> The pattern definitely has its uses. E.g. in the user space of our
> operating system at work we have a StdOutPrinter class that is used like
> this:
>
> === code begin ===
>
> StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
> ")->hex()->out(42)->line();
>
> === code end ===
>
> Each function returns again the instance that was returned by
> StdIO::stdOutPrinter().
>
> The whole pattern is called method chaining or fluent interface:
> - https://en.wikipedia.org/wiki/Method_chaining
> - https://en.wikipedia.org/wiki/Fluent_interface
>
> Regards,
> Sven
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
E.g. KOL is based on this (or very close). The core methods always return
self.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
Jonas, sorry for the late response: The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_. Because you seem to have implemented it or most of it. It renders a mathematical comparable distribution in the negative to the positive values. In both Turbo Pascal as in Delphi and because they use a different algorithm and made an implementation error as well, the negative values are indeed not defined. But that's because of the algorithm and because of the implementation by Borland (yes, it stems from Borland times). The Mersenne Twister we use is also valid for negative values and if you want I can send you the mathematical proof. I already made the LCG in Delphi compatible mode available on the wiki and that implementation differs in so far as that it corrects the "undefined for negative values" for that algorithm too. It is 100% compatible for the Delphi documented range, btw. I am busy evaluating important Random implementions for different languages, so an FPC library is available for data that is generated in a different language and relies on a particular PRNG. Also note that the output of the current random is strictly valid for 32 bit only. In my code I already added a 64 bit version. Regards, Thaddy On 5/20/2017 2:57 PM, Jonas Maebe wrote: On 20/05/17 14:36, Martin Schreiber wrote: Is this intended? If not, which one is correct? random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
Of course 64 and 32 bit are the sizes, not the platform! That may not be clear. On 5/24/2017 9:35 AM, Thaddy de Koning wrote: Jonas, sorry for the late response: The implementation is _*not *_undefined for negative values,_unless you say that you define it as undefined_. Because you seem to have implemented it or most of it. It renders a mathematical comparable distribution in the negative to the positive values. In both Turbo Pascal as in Delphi and because they use a different algorithm and made an implementation error as well, the negative values are indeed not defined. But that's because of the algorithm and because of the implementation by Borland (yes, it stems from Borland times). The Mersenne Twister we use is also valid for negative values and if you want I can send you the mathematical proof. I already made the LCG in Delphi compatible mode available on the wiki and that implementation differs in so far as that it corrects the "undefined for negative values" for that algorithm too. It is 100% compatible for the Delphi documented range, btw. I am busy evaluating important Random implementions for different languages, so an FPC library is available for data that is generated in a different language and relies on a particular PRNG. Also note that the output of the current random is strictly valid for 32 bit only. In my code I already added a 64 bit version. Regards, Thaddy On 5/20/2017 2:57 PM, Jonas Maebe wrote: On 20/05/17 14:36, Martin Schreiber wrote: Is this intended? If not, which one is correct? random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error seeking resources when copiling with {$R *.res}
On Fri, 4 Nov 2016 11:46:24 +0200 (EEST)
{$R *.res} in ONLY allowed for the project file.
You should never try to link in a * resource in a unit, because the *
resolves to the main project name.
Same as in Delphi.
If you need a resource in a unit, resolve the full name, like {$R
myunit1.res}
The main *.res is available over all units in a project.
"NetSpirit"
wrote:
> CONDITIONS
> Unit file contains {$R *.res} directive. File *.res exists in the same
> directory where *.pp file for unit exists.
> Compiled units resides in subdirectory, for example called
> 'units' (-FU command line switch).
>
> DESCRIPTION
> When project with such unit compiled first time - all work as
> expected. Compiled *.ppu files goes to 'units', resulting binary
> created.
>
> On the second and next compilations we encounter en error:
> "Error: Can't open file 'D:\projectpath\units\Unit1.res'".
>
> This error is a result of searching *.res in a directory where
> compiled units exists, but not in a directory where unit source file
> resided.
>
> FPC VERSION: FPC 3.0.0, precompiled binaries for win32, win64
> OS: Windows
>
> TEST PROJECT:
> Demo project for this bug in attach or download here:
> http://rgho.st/8GRBWVWcM
> (Extract all files to disk; correct path to your FPC in
> 'compile.bat'; run 'compile.bat' two times)
>
>
>
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bitset assembler
Before I answer that: did you check what assembler code the compiler generates? That may be just as efficient as handcoded assembly in this case. With the proper optimizations it will probably hard to improve on. Compile the code with -O4 and -s. That generates the assembler output in a *.s file. The compiler is rather good at bitmaniputations. > Hello to all assembler experts, > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
That may be true, but takes tricks. The compiler from me WILL build trunk, because it is a trunk. I do not have much time but as I stated before i WILL update it. It just takes a bit longer. Also, I won't do a full .deb for it, unless some helps with that. I wasn't able to do that yet and do not have experience with package building for Debian.. My starting compiler still will compile trunk with OVERRIDEVERSIONCHECK=1. This is a temporary solution until 2.8 is released and the debian guys will accept the latest stable 2.8 (which is a long way off, I understand): debian won't accept 2.71, because it is experimental. Raspbian follows Debeian. Debian is rightfully slow in accepting anything but the most stable and release versions. Debian will almost never accept anything else. Point is: to obtain best results on the Raspberry Pi, you WILL need the latest FPC. It is really a great compiler for the platform. The instructions I wrote still work as of 28898 (todays checkout) Thaddy On 10/23/2014 2:11 AM, peter green wrote: Pierre Free Pascal wrote: https://archive.raspbian.org/raspbian/pool/main/f/fpc/ The 2.6.4 release is able to successfully compile a 2.7.1 trunk compiler. :) Thanks for confirming. Several files are missing in this source release: The source package which is made up of fpc_2.6.4+dfsg-4+rpi1.dsc , fpc_2.6.4+dfsg-4+rpi1.debian.tar.xz and fpc_2.6.4+dfsg.orig.tar.gz does contain the files you mention. To extract it you use dpkg-source -x on the dsc file. This is the source used to build the deb files. The binary package fpc-source exists primerally for the benefit of lazarus users, it appears to contain more than is needed for lazarus use but not enough to actually build the compiler which does seem a bit strange. This is not raspbian specific, the packages in debian are the same way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. Maybe the guy(s) or/and girl(s) who have done the original build for the Raspberry Pi can shed a light on that one... On 10/23/2014 10:55 AM, Thaddy de Koning wrote: Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Which means you shut out the platform. Which is a teaching platform. On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, By never saying that people should build trunk with trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. On 10/23/2014 11:10 AM, Jonas Maebe wrote: On 23/10/14 11:00, Thaddy de Koning wrote: At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. The real starting compiler is a cross-compiler. You always have to start using a cross-compiler when building for a platform on which the previous release is not available. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Not for ARMV6 EABIHF On 10/23/2014 11:23 AM, Jonas Maebe wrote: On 23/10/14 11:16, Thaddy de Koning wrote: I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Bad practise is the only practise if knowledge about good practise is not available. I am fully prepared to accept you are right. In fact, in my professional settings I would not do otherwise. But this is a special case, for a huge platform, and somebody, somehow, forgot about the license Because the starting compiler for Raspbian is not available.. That's the point: In war ( I am a former tank commander when it was still relevant for an 19 year old) You improvise when resources are not available. I agree with you. Get it? But where's the stuff we can use to do it properly? My stuff works, is based on trunk, but not usable? Ofcourse not. This goes to the core of the project: either one sticks to the rules, or one deviates from it. This is a blatant case of GPL ignorance, since the starting compiler is not made available. And the compiler is GPL'd THAT'S my point. On 10/23/2014 11:16 AM, Jonas Maebe wrote: On 23/10/14 11:09, Thaddy de Koning wrote: On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: Plz advice on how to progress, By never saying that people should build trunk with trunk. Which means you shut out the platform. I'm not saying you can't provide any downloads, nor that Debian/Raspbian must remove their custom patched 2.6.4 releases. I'm only saying that you should never encourage people to build trunk with trunk for the reasons that I have explained many times before. Which is a teaching platform. So don't teach them bad practices that will get them into trouble. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
This is known. I forgot a bit about my rasp, but I will try to make a new build + build instructions within a week. The warnings can be -partially - ignored though... Tnx Paul, maybe we can coordinate this? On 10/17/2014 1:02 PM, Paul Michell wrote: On Friday 17 Oct 2014 11:35:30 Henry Vermaak wrote: fpmake.pp(46) Warning: crti.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtbegin.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtend.o not found, this will probably cause a linking failure fpmake.pp(46) Warning: crtn.o not found, this will probably cause a linking failure Where are these files on your system? I remember after multiarch happened on debian I had to add some library paths to get fpc to link. This sounds like a similar issue. They do not exist in my FP directory tree. However there are copies in the Raspian /usr/lib tree here: /usr/lib/arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/arm-linux-gnueabihf/crtn.o Thanks, Paul ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: virtual method co-variance
Isn't that exactly what is done in C++? It is prepared in library code. On 10/14/2014 12:40 PM, Marco van de Voort wrote: I recently had to dive a bit into C++ again, and reconnected with a feature I liked at first sight, the C++ covariance of virtual methods (changing the return type of a overriden method to a descendant of the original type). Googling a bit it seems that some languages(C#) also seem to allow this for parameters. (not just return types) I suddenly wondered why it was never proposed or talked about for FPC, since it seems such a nice feature. Is there something particularly wrong with it? To a certain degree it can be emulated with generics, but that it requires a generic for every type, and must be prepared in the library code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] -dREVINC
This: -dREVINC as an option to include the revision number in builds is very useful for trunk builders but it is not documented and doesn't work for Windows. Is there a reason for that? smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp without X
This is easy to fix : the encoding of your remote shell is set wrong. If you use PuTTY, go to Window|Translations|Remote Character set and set to UTF8. Then go to session and save! it. Other remote shells should have similar options. Thaddy On 16-3-2014 22:08, waldo kitty wrote: i'm not sure this is the proper area for this... if it is not, please point me to the proper list... i've a ubuntu system that i'm trying to run fp on... X does *not* start automatically... i'm working from the virtual console(s) 99% of the time... what i'm seeing and trying to solve is the frames in fp are showing up as diamond characters... after i got the help stuff loading properly, i noted that when i switched away from the editor frame, it showed the single line frame characters and the help frame was all diamonds... closing the help and returning to the editor switched the editor frame back to diamonds... i found the document in the share directory that speaks of /etc/syscontrol/console but my ubuntu system doesn't have such... i did find something online where i was able to change my console font from VGA to Terminus and a few others but none of them have helped... in the above mentioned document, it also speaks of the grab_vcsa tool... i tried linking this from my ~/development (created by fpcup) but ended up having to actually copy the binary to /usr/local/bin (in my path and where i selected to place it) and then set it to owner:group root... i also set the SUID bit as the document mentions but even this has not helped... looking at my freepascal installs on my winwhatever and OS/2 machines, i see that the frame is normally the double line frame characters and that it does switch to the single line frame characters when selecting another window in fp... TERM=linux LANG=en_US.UTF-8 1. what am i missing to solve this? 2. will fixing this in the console cause problems when i do run the X GUI and open a xterm (or other) console so as to be able to work from the command line? thanks for any assistance! :) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smarter way of generating ARMHF fpc trunk installation?
Basically it -2.6.X - doesn't accept the proper options you need. There is a workaround: Bootstrap with 2.6.2, build a trunk crosscompiler, Then bootstrap immediately again with the trunk compiler with OVERRIDEVERSIONCHECK=1. The latter will accept the proper options, which are minimally: CROSSOPT=-dFPC_ARMHF -CfVFPV2 -CpARMV6 -CaEABIHF This works but is not in ANY way supported. On 4-3-2014 7:00, peter green wrote: Reinier Olislagers wrote: fpcup, an FPC/Lazarus build/installation/update program uses the following steps on ARMHF Linux (e.g. raspbian, odroid): 1. Get FPC stable (2.6.2 currently) ARM bootstrap compiler binary This compiler cannot directly build ARMHF FPC trunk. OOI in what way does it fail? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smarter way of generating ARMHF fpc trunk installation?
Well, call me a monkey or an ape, but if you leave it out, you get an
EABI version of the compiler and EABIHF is missing. Whatever you do,
bootstrapped from 2.6.2.
On both linux and windows you only seem to obtain an EABIHF capable
cross compiler if -dFPC_ARMHF is included in both OPT and CROSSOPT and
bootstrap with trunk.
Try it.
Your explanation is both logical and theoretically correct, but QED
shows otherwise for about the last 10 months.
But I will look at my build scripts anyway. They produce the desired
results, though: EABIHF crosscompilers from windows and linux i386.
Thaddy
On 5-3-2014 17:06, Jonas Maebe wrote:
On 03 Mar 2014, at 09:24, Reinier Olislagers wrote:
make FPC=/home/odroid/development/fpcbootstrap/arm-linux-ppcarm
--directory=/home/odroid/development/fpctrunk/compiler
CROSSOPT=-dFPC_ARMHF -Cparmv7a -CaEABIHF -CfVFPv3 OPT=-dFPC_ARMHF
OS_TARGET=linux CPU_TARGET=arm OVERRIDEVERSIONCHECK=1 cycle
I just noticed that you are adding -dFPC_ARMH also to CROSSOPT. That
does not do anything and can be removed. In combination with your
remark at http://wiki.lazarus.freepascal.org/ARM_compiler_options that
e.g. adding -dFPC_ARMHF when compiling a program will not change
anything and the last post of Thaddy also talking about CROSSOPT,
there seems to a lot of confusion about what this means. It's
nevertheless very simple:
* the -dXXX command line parameter simply tells the compiler to define
symbol XXX as if there were a {$define XXX} at the top of every
compiled source file. By definition this does not (and cannot) affect
code generation. Regarding the statement on the wiki: it's like saying
that adding -vl will not change anything regarding the code
generation; it's not wrong, but it shouldn't be said either because it
suggests that under some circumstances these parameters actually could
change something (for the pedantic nitpickers: -dXXX could change
something if fpc.cfg contains an #ifdef XXX statements, but that's
not relevant here).
* the compiler contains a bunch of {$ifdef FPC_ARMHF} source blocks.
When these are enabled and you compile an ARM compiler, then the
resulting compiler will generate ARM hardfloat ABI code. Adding
-dFPC_ARMHF to OPT means that this parameter will be used while
compiling the compiler (both cross and native), and hence the compiled
ARM compilers (both cross and native) will generate ARM hardfloat ABI code
* adding a parameter to CROSSOPT means that it is only specified when
compiling code using a generated cross-compiler. So if you were to add
-dFPC_ARMHF to CROSSOPT and not to OPT, then you would first build an
ARM cross-compiler that generate softfp ABI code, and subsequently the
makefiles would build a native ARM compiler that itself uses the
softfp ABI, but which generates hardfloat ABI code. It seems extremely
unlikely that you would deliberately want your cross-compiler and
native compiler to generate different code.
* Adding -dFPC_ARMHF both to OPT and CROSSOPT means that -dFPC_ARMHF
will be passed once while building the cross-compiler and twice while
building the native compiler. Again, this is not wrong, but it
shouldn't be done because it suggests that under some circumstances
-dFPC_ARMHF should be part of CROSSOPT.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smarter way of generating ARMHF fpc trunk installation?
I have a fresh baked zipinstall (tar.gz, not a deb) for the Raspberry Pi straight from my build farm every morning if you want... But even that is not guaranteed to work every time, since it is trunk. But anyway, let me know Thaddy thaddy[whatever belongs here] thaddy[dot] com On 3-3-2014 20:33, Jonas Maebe wrote: On 03 Mar 2014, at 19:39, Paul Breneman wrote: On 03/03/2014 12:13 PM, Jonas Maebe wrote: On 03 Mar 2014, at 17:49, Paul Breneman wrote: On 03/03/2014 03:24 AM, Reinier Olislagers wrote: fpcup, an FPC/Lazarus build/installation/update program uses the following steps on ARMHF Linux (e.g. raspbian, odroid): 1. Get FPC stable (2.6.2 currently) ARM bootstrap compiler binary This compiler cannot directly build ARMHF FPC trunk. 2. Use the compiler to build a regular ARM fpc trunk compiler (the intermediate bootstrap compiler... sorry, not that good at naming :) ) make FPC=/home/odroid/development/fpcbootstrap/arm-linux-ppcarm --directory=/home/odroid/development/fpctrunk/compiler CROSSOPT=-dFPC_ARMHF -Cparmv7a -CaEABIHF -CfVFPv3 OPT=-dFPC_ARMHF OS_TARGET=linux CPU_TARGET=arm OVERRIDEVERSIONCHECK=1 cycle Could the first part(s) be packaged into a small Free Pascal distribution, like the 3 zips on this page? www.CtrlTerm.com No, because you have to redo step 2 every single time you update your sources. I'm not suggesting that the source be put into the zip. But could the other tools be put into a zip so I could download a small zip on my Raspberry Pi and easily follow a few directions to compile a new ARMHF FPC+RTL? The point is that the tools change every time a new revision is committed to svn, other than the initial 2.6.2 compiler (which is already available separately). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] KOL 64 bit version available for testing.
For anyone developing with KOL, Dmitry K did a - as yet unofficial - 64 bit Windows version that is sufficiently stable to be considered to be added to the official branch at kolmck.net. You can obtain it here: http://yadi.sk/d/Z0uMP31_67nJY If you are interested and know something about how to use KOL/MCK, plz test and let me know. Remember to compile with at least -Mdelphi -Rintel -dPUREPASCAL Unicode version doesn't require -Mdelphiunicode but rather: -dUNICODE_CTRLS This is because KOL already had unicode before FPC. Thaddy p.s.: ppcrossx64 outperforms dcc64 in size and speed, at least with KOL. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Issue 0025028 (Florian)
This is marked as won't fix. I do not fully understand that. In Delphi, an interface is given a guid internally whatsoever it is declared. In FPC, this mechanism is also in place. I refer: IWhatEverInterface = _*type *_IInterface; // which has a guid.. and type inference works correctly I am a known - but well meaning - idiot, but can you please explain why you closed this as won't fix as the issue seems to be completely fixable and reasonable. Regards, Thaddy, smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Nasty raspberry arm issue that I can't solve. But is it a bug?
The following issue ocurred, but I am not sure it's a real bug. Only: I can't see what's wrong! My automated crosscompile for arm builds and links ok, but when I build fpc trunk on RaspBian native I get: -- snip Start compiling package fpcmkcfg for target arm-linux. Compiling fpcmkcfg/fpcmkcfg.pp Linking fpcmkcfg/bin/arm-linux/fpcmkcfg The installer encountered the following error: External command /home/pi/fpc271/compiler/ppcarm -Tlinux -FEfpcmkcfg/bin/arm-linux -FUfpcmkcfg/units/arm-linux/ -Fu/home/pi/fpc271/rtl/units/arm-linux/ -Fu/home/pi/fpc271/packages/fcl-base/units/arm-linux/ -Fu/home/pi/fpc271/packages/fcl-res/units/arm-linux/ -Fu/home/pi/fpc271/packages/rtl-objpas/units/arm-linux/ -Fu/home/pi/fpc271/packages/fpmkunit/units/arm-linux/ -Fu/home/pi/fpc271/packages/hash/units/arm-linux/ -Fu/home/pi/fpc271/packages/paszlib/units/arm-linux/ -Fu/home/pi/fpc271/packages/fcl-process/units/arm-linux/ -Fu/home/pi/fpc271/packages/libtar/units/arm-linux/ -Ur -Xs -O2 -n -Fu/home/pi/fpc271/rtl/units/arm-linux -Fu/home/pi/fpc271/packages/paszlib/units/arm-linux -Fu/home/pi/fpc271/packages/fcl-process/units/arm-linux -Fu/home/pi/fpc271/packages/hash/units/arm-linux -Fu/home/pi/fpc271/packages/libtar/units/arm-linux -Fu/home/pi/fpc271/packages/fpmkunit/units/arm-linux -Fu/home/pi/fpc271/packages/fcl-json/units/arm-linux -darm -dRELEASE -viq fpcmkcfg/fpcmkcfg.pp failed with exit code 1. Console output: Target OS: Linux for ARMEL Compiling fpcmkcfg/fpcmkcfg.pp Writing Resource String Table file: fpcmkcfg.rsj Assembling fpcmkcfg Linking fpcmkcfg/bin/arm-linux/fpcmkcfg fpcmkcfg.pp(484) Error: Error while linking fpcmkcfg.pp(484) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted /usr/bin/ld: warning: fpcmkcfg/bin/arm-linux/link.res contains output sections; did you forget -T? /home/pi/fpc271/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' /home/pi/fpc271/rtl/units/arm-linux/cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/pi/fpc271/utils' make[1]: *** [utils_all] Error 2 make[1]: Leaving directory `/home/pi/fpc271' make: *** [build-stamp.arm-linux] Error 2 -snip--- Any clues, anyone? Regards, Thaddy smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOS GUI
My whole point is: add a license that you find suitable to your intend. But add a license. Pref compatible with the fpc licenses. In the case of the company: I almost forgot about it. You can be right, but not in the us of a without big pockets to enforce it. (In Europe it is much easier, in the Netherlands you just deposit your code with at the tax office - a lttle uknown -) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOS GUI
Well, I have a statement from their legal dating from 2005 amounting to: we use it as you intended (sic) and see no reason to quote that this sourcecode is yours. Furthermore, the two units that contain said sourcecode you refer to are protected under U.S. copyright law and are our intellectual property. (It blahblah's a lot more, this is the essence and not verbatum) In other words: closed source. Now you can be right and probably you are right but to be legally right in de U.S. this will cost a lot of funds that I can better use elsewhere. This type of answers is not unique to my case. I believe Henri Gourvest has a rather unique addition to some of his his open-licenced sourcecode explicitly exluding said company from using it after a similarly bad experience. On 14-1-2014 15:09, Hans-Peter Diettrich wrote: Thaddy schrieb: It happened to me once or twice ;) that a certain company with ever changing names used my sourcecode and licensed it under their own closed terms because i included the term: use as you like. Better: free for private use. If the owner wants that not to happen,, choose any of these licenses mentioned. This is really important. Without huge legal fees I can't get my intellectual property back Sorry, that's nonsense. You still have all rights on your own software, no need to get anything back. Even in outdated Copyright terms a use as you like should not mean take ownership. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOS GUI
And that license amounts to: (* * Delphi Chromium Embedded * * Usage allowed under the restrictions of the Lesser GNU General Public License * or alternatively the restrictions of the Mozilla Public License 1.1 * * Software distributed under the License is distributed on an AS IS basis, * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for * the specific language governing rights and limitations under the License. * * Unit owner : Henri Gourvest hgourv...@gmail.com * Web site : http://www.progdigy.com * Repository : http://code.google.ctom/p/delphichromiumembedded/ * Group : http://groups.google.com/group/delphichromiumembedded * * Embarcadero Technologies, Inc is not permitted to use or redistribute * this source code without explicit permission. * *) Which I think is rather to the point. On 14-1-2014 15:09, Hans-Peter Diettrich wrote: Thaddy schrieb: It happened to me once or twice ;) that a certain company with ever changing names used my sourcecode and licensed it under their own closed terms because i included the term: use as you like. Better: free for private use. If the owner wants that not to happen,, choose any of these licenses mentioned. This is really important. Without huge legal fees I can't get my intellectual property back Sorry, that's nonsense. You still have all rights on your own software, no need to get anything back. Even in outdated Copyright terms a use as you like should not mean take ownership. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOS GUI
This is good advice. It happened to me once or twice ;) that a certain company with ever changing names used my sourcecode and licensed it under their own closed terms because i included the term: use as you like. If the owner wants that not to happen,, choose any of these licenses mentioned. This is really important. Without huge legal fees I can't get my intellectual property back I am sadly, and not only with this company, not alone in this. Protect it from misuse. Thaddy On 14-1-2014 11:27, Kostas Michalopoulos wrote: Well, all open source projects need a license, otherwise they're not very useful legally speaking, so he'll need to pick one. If he doesn't care what people do with his code he can use a permissive license like MIT or zlib. More information and a list of licenses can be found at http://opensource.org/licenses On Mon, Jan 13, 2014 at 9:23 PM, Anton Kavalenka anto...@tut.by wrote: On 13.01.2014 15:30, Kostas Michalopoulos wrote: Is it/will be open source? Under what license? Author said so. He gives it away for community for free. He even did not require to mention his name. Do you need a written permission from him? regards, Anton btw it looked like http://www.unichrom.com/history/sv95.gif On Fri, Jan 10, 2014 at 3:51 PM, Anton Kavalenka anto...@tut.by wrote: On 07.01.2014 12:19, Michael Schnell wrote: What is the difference between this and the TUI that comes up when you start tp. (Same obviously already is part of the fpc source code distribution.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Sorry for delay. Yes, It is TV-based. Non-gui units can be used either from TV or FV. But GUI implementation is true graphic, not pseudographic dialog frames etc. Unit names of GUI part somewhat like TPW - kernel, user, windows but they have nothing common except names. GUI written from scratch in TV classes hierarchy. generally it was looked like UniChrom DOS Btw where to upload sources - to listserver as mail attachment? regards, Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new rtl- packages
Hoi, Marco, native win32 ben je vergeten. matrix... Groetjes, Thaddy On 6-1-2014 13:10, Marco van de Voort wrote: To whom it may concern, fyi The RTL was getting quite big, and is compiled 4-5 times per make all, so with a major branch splitting off in the next half year and the end of the 2.6.x branch, it was considered time to move some of them to packages. As some of you might have noticed, the first such rearrangements have been made, three new packages have been created, containing the units listed below. rtl-extra : objects matrix ucomplex rtl-objpas : convutil(s) dateutil(s) stdconvs variants varutils rtl-console: crt video keyboard mouse Another package (rtl-unicode?) with encoding table units will follow in the coming weeks, and more units will be moved to rtl-extra. This work is done in pieces because with 30+ rtl/xxx/Makefile.fpc to edit, it is a bit sensitive. If you get an error compiling the RTL or a package due to a missing unit on trunk, don't hesitate to report it here. Thank you. Marco ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multithreading under DOS
Even that is TSR based, not a real multi-tasker. Under DOS a process can be swapped out and re-activated by a hardware interupt, either f.e. a timer or the keyboard. So, at most, co-operative multi-tasking in the sense that multiple processes can run at the same time. Because DOS is non-re entrant real multitasking will be very hard to achieve. It would be done by now ;) On 27-9-2013 13:28, DaWorm wrote: On Sep 27, 2013 3:27 AM, Michael Schnell mschn...@lumino.de mailto:mschn...@lumino.de wrote: In fact I remember that there even was a multitasking add-on for DOS. Same allowed for switching between multiple DOS desktops without needing a graphical UI. I don't remember the features and the requirements. Perhaps you are thinking of Desqview/386? Jeff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] request for a small but important addition to the docs
On 18-9-2013 10:08, Michael Schnell wrote: *If the event queue is empty, **CheckSynchronize w**aits for an event to be pushed by a TThread or for /timeout/ Milliseconds to pass. If timeout is 0, it waits forever.* In the context of a wait a wait forever given a value of naught , this is pretty much the standard. In any language, in any OS. Why document a given? smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the matter with this list ?
On 13-9-2013 16:19, Michael Schnell wrote: OK. So no technical problem, just some silent days :-) . -Michael I may suggest a currently non-unicode encodable code page was used for the mailing list since the major change? EBCDIC? smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can someone confir 2.7.2 cross arm is currently build-able
On 2-9-2013 19:51, Sven Barth wrote: Every other developer of FPC will tell you the same: The only supported version for compiling a development (2.7.1) or fixes (2.6.3) version is either the last release (2.6.2) or a development/fixes version of the same revision and nothing else. 2.7.1 definitely is a development version and it sometimes happens that things will break in a way that a older revision is no longer able to build a newer one. We do not check for compatibility with older revisions and the only way we guarantee that works is a compilation with 2.6.2. The softfloat 2.6.2 compiler should be able to compile a hard float one and as far as I've understood the softfloat discussion it should also work on hardfloat systems. Otherwise you could compile a hardfloat compiler on a Debian system (using a 2.6.2 as starting compiler), move that to your odroid U2 and build the compiler (of the same revision!) with that (the compiler does not use libc or any other library so you can freely move it between Linux systems). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Your answer is to the point and right. It is of ultimate importance, though, that the compiler options for armXX have changed considerably since 2.6.2/3. For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap with OVERRIDEVERSIONCHECK=1 I think that is a perfectly viable option. Maybe it is just a case of pointing out exactly that. There are still no public makefiles that support those options, afaik. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can someone confir 2.7.2 cross arm is currently build-able
On 3-9-2013 12:06, Jonas Maebe wrote: On 03 Sep 2013, at 11:56, Thaddy wrote: For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap with OVERRIDEVERSIONCHECK=1 I think that is a perfectly viable option. It is not, as evidenced by the fact that about 99% of this thread until now has been about trying to determine whether there is in fact something wrong with the current 2.7.1, or whether the problems are simply caused by not using the latest release to bootstrap. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel At least the current RaspBian releases (wheezy and Jessie) still bootstrap from 2.6.2, if that helps. The point I was referring to is about the generated code. There were some fixes related to bx. So I assumed wrong compiler settings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can someone confir 2.7.2 cross arm is currently build-able
On 3-9-2013 12:24, Marco van de Voort wrote: In our previous episode, Thaddy said: Your answer is to the point and right. It is of ultimate importance, though, that the compiler options for armXX have changed considerably since 2.6.2/3. For my Friday toys (Pi's) I use 2.7.1 with the new ARM options and bootstrap with OVERRIDEVERSIONCHECK=1 I think that is a perfectly viable option. If that 2.7.1 was just bootstrapped using the same SVN starting with 2.6.2/3. That's the only reason why OVERRIDE.. exists. 1. bootstrap native 2.7.1 from 2.6.2, then 2. use that to bootstrap something cross-arch that 2.6.x doesn't support. But do both stages _every_ time (svn update) Anything that builds 2.7.1 with an older 2.7.1 is not supported. If you're unlucky a single revision can cause problems. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I know Sometimes I learned something, Marco. Hence my comment. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
Basically, this whole discussion is a bit pointless. On 29-6-2013 19:28, Paul Breneman wrote: On 06/29/2013 08:58 AM, Michel Catudal wrote: Le 2013-06-21 03:32, Michael Schnell a écrit : I don't understand why RPI (still) gets so much interest. The point is that the RPi is a *coherent educational concept *as a whole - software, hardware, planning, resources - that has to some extend been taken over by hardcore hacker loudmouths who always seem to be disappointed. And it took over 4 years to realize the concept, not just the hardware, that was easy, and a choice made based on price and availability in 2009. Get the big picture and get the success of the concept (over 2.000.000 sold as per today) and you see why the BB, Odroids and the likes are by a long way not as successfull in the market. I for one would be glad to see those hardcore complainers gone from the raspberry pi community. They are missing the point, any point. basically clueless on what to do with it. Well: there are no professionally written educational resources for BB and Odroid for example. All documentation is geared to professionals or hackers. Instead of using their capabilities to enhance eand contribute the RPi's eco, all they can do is moan about something better. It isn't! there's no plan behind it, there's hardly a concept, you're basically on your own and the GPU alternatives often underperform compared to the RPi. By all means, go ahead. But don't forget FPC is a viable compiler and Lazarus is a viable IDE for the Raspberry Pi. And the history of Pascal has a strong educational background. And on the RPi it has about 2.000.000 times more potential to find Pascal converts then the measely sales figures from the alternatives ;) Thaddy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 2-7-2013 13:52, Jonas Maebe wrote: Hi, Can this discussion about the pros and cons of various ARM-based boards please be moved to fpc-devel? This discussion is completely unrelated to developing FPC itself. Thanks, Jonas FPC mailing lists admin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Agree. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Performance of string handling in trunk
On 24-6-2013 17:13, Michael Schnell wrote: On 06/24/2013 04:44 PM, Hans-Peter Diettrich wrote: Not in Delphi. For binary data TBytes has been added. Which (AFAIK) is not reference counting can't do + and thus much less versatile. It is also highly controversial since XE4: For example a good breakdown in http://blog.synopse.info/post/2013/05/11/Delphi-XE4-NextGen-compiler-is-disapointing This is by no means the only complaint about the latest string whatever it is supposed to be. ;) Thaddy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?
On 24-6-2013 17:15, Michael Schnell wrote: Karlheinz said on the Phone that the boots in some 10 seconds to the command line when using the original Angstrom Distribution and at least 20 seconds when using Debian. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Yes, at 700 Raspbian boots in 20-22 seconds. With the maximum allowed - without loosing warranty - settings the latest Raspbian boots in about 12-14 seconds. The discrepancy in these maths comes from the fact that the GPU is also overclocked to 500 (from 250) and the Raspberry Pi bootstraps from GPU, not CPU. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus issues on ARM Linux
On 8-4-2013 14:49, peter green wrote: Michel Catudal wrote: I am also having some issues with Lazarus, I am not sure if it is the right forum to talk about it. I had a previous version working fine on Rasphberry Pi. For some reason I can't get it to work on Mele A2000G. I have compiled it on gentoo on the Mele, using distcc and locally, same results. I didn't get any error during compile so I was expecting it to work. fpc seems to work, I haven't written any code with it yet, I was expecting to use lazarus to do that. My system on Mele A2000G is gentoo with mate desktop. I have everything compiled with hard float as I did on the Raphsberry Pi. Upstream 2.6.x does not support the hard float ABI so unless you have a patched version (such as the one shipped in debian) it won't correctly link against C libraries on a system that uses hard float ABIS. Also even when the hard float ABI support is present in the compiler source code you need to either bootstrap with a starting compiler that uses the hard float ABI or explictly specify -d FPC_ARMHF during the build. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel At the moment the current lazarus doesn't compile here for trunk, not even on raspberry. A couple of days ago it did. But this is today. I will put in a bug report if I checked my build stup, can reproduce it and if so isn't fixed within two days or so. Most of the time it will. You probably definitely must use trunk to get proper results for arm. Lot's of changes/improvements. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
{$MODE SUBJECTIVE} is more appropriate in this discussion.
But i am by -first - education a political scientist.
On 6-3-2013 15:44, Michael Schnell wrote:
On 03/06/2013 02:37 PM, Sven Barth wrote:
What exactly do you mean?
we already have:
{$MODE FPC}
{$MODE OBTP}
{$MODE DELPHI}
{$MODE OBJFPC}
{$MODE OBJMAC}
if {$MODE OBJMAC} not already is for objective Pascal there could be
something like
{$MODE OBJECTIVE}
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
On 6-2-2013 12:13, Henry Vermaak wrote: What I'm trying to say with this (admittedly contrived) example is that when you are forced to read the docs to find out which functions you can use for converting numbers to strings, you'll probably discover functions like Format. At least in my case, the most useful tricks I learn come from reading the documentation for something, then exploring a bit. I apologise if I come across as overly cynical and I do appreciate Sven's work in the compiler! Henry First of all, a huge tnx to Sven. And Henri: do you also oppose macro support? With that you can make Freepascal code look like anything. And RT(X)M has never harmed anyone.. cynism intended ;) . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] embedded again
On 11-1-2013 11:54, Jy V wrote: So the options are either to do cross compiling (with Lazarus) or to install FPC on the target and compile the code there. What is the more viable way ? IMHO use virtual machines: Most of my customers run vmware sphere on their servers. I only have to version and copy the virtual machines. Mind you: My compilers are still configured for remote and crosscompile but this setup is more or less static: the vm's can simply be replaced with a newer one on live or moved to hardware. (And ofcourse - in my case for webdevelopment incl. ARM - cycle through a set of ip's before one becomes production) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] embedded again
On 11-1-2013 12:07, Michael Schnell wrote: I don't see how I could install Lazarus on the QNAP, as there is no GUI / Widget system at all. I was told that on the Raspberry Pi, QT can be run, but that it is dead slow. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel On the 256 model 2: yes, on the 512 model 2: No, acceptable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE support degraded?
AFAIK! and tested today, and only for kolce and fpc 2.5.1 wince works. Anything newer doesn't. (No wince above 6.5) I have no clue if it is the compiler or the libraries yet. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 7-2-2012 12:20, Marco van de Voort wrote: In our previous episode, Hans-Peter Diettrich said: That depends on decisions still to be made. If we also support 1-byte RTL, it will still be on the level of winNT. But I do think that a win9x vs winnt split is unavoidable in time. Specially since otherwise one gets in the current situation that win9x is occasionally fixed for a release, but in reality constantly broken in between. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I do not think that you will break anything if you make W api or A api default based on platform. This can be switched in the winapi units. That will take little effort, as I explained: we did it already for KOL. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 17:54, Felipe Monteiro de Carvalho wrote: The related bug tracker item is: http://mantis.freepascal.org/view.php?id=21114 IMO This should not be done that way (at all): MS does it by respecting the PE flag for unicode and expects strings accordingly: If the PE says it's unicode, a default string should be unicode, (so apiW) if the header says ansi the default should be apiA. Just my three cents. But that still requires changes, I agree with that part. This might be an issue for xplatform, although I believe nixes have the same behaviour. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote: The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed No, this is not true, not at all, to the contrary, that's what the PE flag is for: If you want to compile for any windows version, choose ansi mode and the OS respects and expects that. If you want a unicode default (i.e. win2000 and higher) choose unicode mode. The library should be totally opaque when the programmer decides what he wants. What you are doing is making changes in the generated code that shoukld be resolved at compile time. This can be resolved at link time, but I expect it should be resolved at compile time. That's why I agree with you that changes are necessary. (Although the PE flag is a linker instruction) What we are required to do is respect the OS we compile for. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote: The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1 makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2 Breaks the interface because the string type changed No, this is not true, not at all, to the contrary, that's what the PE flag is for: If you want to compile for any windows version, choose ansi mode and the OS respects and expects that. If you want a unicode default (i.e. win2000 and higher) choose unicode mode. The library should be totally opaque when the programmer decides what he wants. What you are doing is making changes in the generated code that shoukld be resolved at compile time. This can be resolved at link time, but I expect it should be resolved at compile time. That's why I agree with you that changes are necessary. (Although the PE flag is a linker instruction) What we are required to do is respect the OS we compile for. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 20:21, Sven Barth wrote: Out of interest: Which flag are you talking about? Because I'm not aware of any such flag. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel It is known which versions are unicode. I am merely refering to the OS version flags. These are the ones which determine if the windows version is unicode or ansi. There's no point in running an ansi compiled exe on a unicode platform. Once a programmer decides his/hers minimum requirements, the compiler should obey. The OS does (up to a certain point) These decisions should be made by the compiler based on platform choice, not in rtl code. That should be optional (as of 2010/XE this is also D compatible) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 21:07, Sven Barth wrote: The check you are talking about in C++ is a compile time define that just switches the defines for e.g. CreateProcess to CreateProcessW or CreateProcessA (depending on whether UNICODE is defined or not when including the Windows headers). There is no other magic in Windows that changes the imports at runtime. Nope, but a compiler should choose the_optimum_ for the platform. Otherwise you can hand-code it. The A/W versions of the windows API have been in Delphi at least since D3, but I can check D2 in a minute. Of course it's a compile time switch! Point made by me in the first place. BTW you can even fool delphi and fpc to behave irratically (do what I want) by doing things like -uFPC -Mdelphi -dVER200 in fpc or defining -dVER200 when you have a D7 (VER150) . Sometimes handy to know the compilers (be it C or FP-C) at least understand the programmers meaning. (Just in case you wonder why I would fool the compiler to be over his age: parsing some badly behaving sourcecode) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 21:04, Craig Peterson wrote:
Delphi does the same thing, except the change was built into the
language, rather than done using a conditional symbol, and the A or W
decision was hard-coded rather than wrapping them in {$IFDEF UNICODE}
blocks.
I am not sure about this, (I do not know if the latest production
version has this) but I think you can (could) undefine unicode.
I propose FPC follows a similar strategy.
We already did it for Kol, which has a (almost) totally opaque
KOLstring/char type depending on switching on UNICODE_CTRLS or ANSI.
(And we had that switch some time before FPC)
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 21:35, Sergei Gorelkin wrote: 06.02.2012 20:39, Felipe Monteiro de Carvalho пишет: So, this is basically a first step of locking Windows RTL to use utf-8 by default and reducing chances it ever will call 'W' API without conversions? That is another point that worries me too. Windows NT + are not native UTF8 but UTF16. That's why my suggestion to make the default string type fully opaque per platform requirements. That can be done on the compiler level with little effort in rtl/fcl. (For KOL it took weeks, not months) smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
Of course, KOL is a framework, not a compiler. I merely want to state it can be done in a proper way. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 21:41, Sven Barth wrote: But in FPC you'll need to recompile the Windows RTL if you want to have UNICODE defined (thus having e.g. CreateProcess default to CreateProcessW instead of CreateProcessA). In C you just include the header with the define either defined or not. Nope, again no: this has to do with the RTL/FCL Any KOL program (try it) compiles in either unicode (-dUNICODE_CTRLS --Mdelphi -uFPC -dVER150) or ansi (skip the unicode_ctrls) and just plain works as expected. Not only with a Delphi compiler, also with fpc 2.6.0 and higher. This has nothing to do with the compiler itself. That behaves already like it should. smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
On 6-2-2012 22:14, Sergei Gorelkin wrote: under 10KBytes Any decent code under 10k is interesting smile smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] potential bug, generics vs helpers
On 27-1-2012 17:25, Marco van de Voort wrote:
In our previous episode, Kornel Kisielewicz said:
{$apptype console}
Type
TLISTT=class
end;
type
Ta= TLISTPOINTER;
TB= TLISTPOINTER;
This may very well be a (semantics) bug in Delphi.
Did you put this to Embarcadero?
IMO a type Ta.. should never be assignable to a type Tb.. and
reverse when using generics. (unless with operator overloading or
similar defined)
I think this may be an unintentional feature in Delphi.
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] NowUTC in the RTL
On 9-12-2011 14:02, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: I know nothing about OS/2-eCS, but the same arguments as for Go32V2 apply as far as I am concerned. If all these platforms can guarantee returning correct UTC time, I do not see why we would not introduce it. Afaik the original point was that some people were interested in some kind of timestamp that does not jump around (except possibly when overflowing). I don't think anyone particularly needed the time in UTC. Therefore, something like FPGetTickCount seems much more appropriate than NowUTC, and it also solves the problem that some targets may not support returning the time in UTC. Agree fully. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Except that it rules out writing standardscompliant internet applications? If the network stack isn't in userland, there is no point in putting NowUTC or whatever in userland. Bout where are the network stacks in these legacy OS's? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RE $MODE Delphi
On 29-11-2011 21:53, Jonas Maebe wrote: It actually perfectly describes what you want to do, be it only regarding things that can be checked by only relying on the compiler. I'm not sure whether the limited applicability of such a feature (mainly usable if you don't use, like you, the standard RTL of either FPC or Delphi) makes it worth it to add a ton of small checks sprinkled all over the compiler though. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel An audit of what and how it can be done confirms this. It can be done, but not by me and I can live with my conditional defines. Pity it's so hard to make it work both ways. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPCustomCanvas Expanded Clipping
A region is not a rect. A rect is a special case of a region. The question was about the rect. There are region manipulators Xplatform, I think. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] $MODE DELPHI quirks
I ran into my own problem when writing a program in freepascal that also should compile in Delphi (don't ask) Logically you would expect $mode delphi to enforce delphi compatibility at the sourcecode level. But this is not the case if f.e. C style operators are used or specified, or macro's. I accidentally used the former in my code. Shouldn't it be better if compatibility is enforced both ways? I am sure this would have been discussed before. Shouldn't the compiler at least generate a hint or possibly a warning, when non-delphi compatible syntax is used in delphi mode? Or with a bit more logic, shouldn't those options be excluded by $mode delphi and -Mdelphi? Or if this is inconvenient something like $mode strictdelphi? Thaddy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RE $MODE Delphi
On 29-11-2011 15:46, Jonas Maebe wrote: Possibly, but it would also require RTL changes (the FPC system unit contains many types, constants, variables and functions that do not exist in Delphi -- and for programmers the difference between the language and the system unit is often not very clear) and possibly also blocking certain packages (which can't be compiled with Delphi). It would be a lot of work even if you would limit it to only the compiler (the use of which would be questionable), and additionally only few people are interested in such functionality. For backwards compatibility reasons, such changes would have to go into a separate mode switch. Patches for that could be accepted, but again, without also changing the RTL and packages I'm not sure how much it would help you in reaching your goal. Jonas PS: please do not reply to existing messages when starting a new topic, it messes up threading both in mail clients and in web archives. I was merely indicating syntactical elements, not the use of specific units, variables and constants, not even the RTL as such. So, much like $mode objfpc extends the syntax let $mode delphi restrict the syntax. There is a case to make that f.e. the C style operators and the macro facilities belong to $mode objfpc anyway. Or am I wrong here? Or is there value in it? In that case I will have a look if I can create a patch for a $mode strictdelphi (or whatever name is convenient). It should merely exclude extended syntactical elements not available in Delphi compared to the current Delphi compatibility support. Sorry about the location of my last post regarding this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RE $MODE Delphi
On 29-11-2011 16:54, Felipe Monteiro de Carvalho wrote: mode delphi is used in a huge amount of code, so any break in backwards compatibility here would be extremely unwelcome. It surely would break a lot of code that I wrote. But yes, $mode strictdelphi looks like a good idea if you want to implement it. Provided it is limited to the compiler itself - which is what I want -, I think I may be able create a patch. If there is more demand for it. Then there are the three options on how to implement: Should it generate a hint, a warning or a syntax error in case of a violation? I suggest a 'warning: % is not supported by Delphi'. That way code generation continues, which seems correct, because the generated binary will still work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RE $MODE Delphi
On 29-11-2011 18:49, Tomas Hajny wrote: Which Delphi version would be the supposedly supported one? If this is not explicitly defined, compilation might still fail when people using lower Delphi versions try to compile the code. Do you really want to track the feature set (especially for smaller parts like that certain feature exists in Delphi but FPC extends the scope of the feature to a wider set of cases)? I'd say that there is already enough bug reports about FPC not eating Delphi code. Does anyone really want to start fixing FPC also for bug reports about Delphi not eating code compilable with FPC? If someone wants to support compilation of his code with a specific Delphi version, can he do it without really compiling it with Delphi (and also testing the result!) before publishing the code anyway? Tomas There's a documented delphi version: almost complete D7 support *by the compiler* and by now d2006 now almost feature complete. If you read me correct, I won't try to do any rtl related stuff. It is sufficient to protect against obvious compiler incompatibility, macro's, C type operators. Nothing else. Most of them are compiler switches, not library features. Throwing a warning in these cases has real value for me. (I am running my own rtl and libraries anyway: KOL+ system unit replacements for fpc and delphi 3-2010). So, no, I agree, this should not and probably can not pursue any or all incompatibilities. It can pursue however, to try to make life easier for people who need both single sourced FPC and delphi code. I do not plan to extend on $mode delphi which is documented as almost 100% Delphi7 compatible, I am trying to restrict Delphi mode a Little further. Only on the compiler level and only the obvious. Just like it pretends to be the case already. $STRICTDELPHI is probably a bad name. Open for debate as I wrote before. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About GetTickCount
Withdrawn. It is only partially true. Still it can not be expanded and can overflow easily. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with Now() and time changed by ntpd
On 1-11-2011 15:07, Jonas Maebe wrote: On 01 Nov 2011, at 12:30, Michael Van Canneyt wrote: The timezone itself does not change, unless you physically move the machine from, say, Belgium to Russia. This happens regularly with laptops (and at least I almost never shut down my laptop when traveling, I just let it hibernate so programs keep running). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Yes. Traveling between London and Amsterdam is enough. (Not at all uncommon, here) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] limited -gc ?
On 9-10-2011 22:34, Martin wrote: -gc, is apparently only useful in very limited scenarios, such as applications, that have no interaction with the OS at all, or can otherwise gurantee, never to access any memory that was returned by (and therefore allocated by) the OS. No, it only means allocation should be done in a dedicated memory manager that registers classes and dynarrays (or any) for GC. I already did that with my Boehm implementation (based on another one by Barry Kelly that also did do just that and I borrowed most of the idea's from) but for some reason people on this forum think this is too slow. It isn't. (RTM, P!) I have it running in many a production scenario for at least 4 years (big ones) My Boehm GC version is actively maintained, so try that one. An LCL app can not guarantee that... Yet what I am looking for is a simpler variant, that can help doing the same for class-instances, or dyn-array. See above. For classes there is -CR but it act only when calling methods (any method or only virtual methods?), I can for example not tell if accessing a property mapped to field would also trigger tests on this. Every class or dyn array should be in a block of memory allocated by the fpc heap mgr (probably even always at the start (or fixed offset) of such a block). Therefore I would guess (just guess...) that such a check could be done? Yes, easy. It would greatly help finding any access to freed data. The Boehm GC has options (the registered memory is maintained and accessible) for that during debugging, but not for production quality. That would defeat the point of a GC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf-8 package in Free Pascal
On 3-10-2011 13:45, Felipe Monteiro de Carvalho wrote: Also not a solution, because then fpvectorial and fpspreadsheet would not be able to compile in other RTL modes. What? confused You mean you are seeking the solution upstream? Seems the design of those units is lacking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 7:33, Felipe Monteiro de Carvalho wrote: This could be fixed by introducing some phone-like layouts in the LCL, like the linear layouts from Android. That's what I am currently experimenting with in opengl. I don't mean to turn it into a full widgetset, though. Another way is maybe to use html5 browser rendering for a UI. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 10:52, Dariusz Mazur wrote: My previous post crossed yours! Tnx for the good work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 11:07, Felipe Monteiro de Carvalho wrote: Just one hint: Android is a *lot* more then just drawing some graphics. For example: 1 Virtual keyboard. There are dozens and dozens, even widespread devices like Galaxy Tab come with non-standard keyboards, some of them only for China, some only for Taiwan. The manufacturers always make sure the standard widgets work fine with those keyboards, but custom drawn toolkits have a really hard time keeping up. And you can't test this with the emulator, you need 100+ devices to make sure it works everywhere. I don't know what Qt did, but I bet it doesn't work with half of the virtual keyboards out there. qt specifies Gingerbread (2.3) afaik. I may be wrong here. Besides, it is a simple XML configuration file for the keyboard mapping and if you want to use it: JNI is inconvienient but NOT difficult. There is C++ code for IME softkeybord bindings available from the android developer website. From the platform highlights 2.3: *Native input and sensor events* Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness. Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing. 2 Action completion. In standard apps you can for example click on a video and complete the action with any installed video player, and this requires access to the SDK which is only available from the Java side or from the bindings which I built See the 2.3 platform highlights above. 3 Application lifecycle, also something different from other platforms What do you mean? It isn't.( persé). If your APK is packaged and signed correctly, an Android machine that isn't supported won't see your app in the market. If that is what you mean. I think this is rather neat/cute/wonderful and saves headaches. 4 Orientation change, the app needs to respond to it. With standard widgets it automagically works. Also lower than 2.3 issue, but you have to provide for it in code or use a browser approach, that's true. I must say I am still playing and can't say I have things working in a generic way. Just that some code that works in the emulator also works on my Android machine and in a predictable manner. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 13:44, Michael Schnell wrote: On 08/11/2011 11:24 PM, Graeme Geldenhuys wrote: I will offer fpGUI support to anybody that works on LCL-fpGUI though. So if you do go that route and get stuck with fpGUI concepts, don't hesitate to send me a mail. Great. Sven: For me right now the biggest problem with fpGUI/LCL is that Application.QueuAsyncCall (and similar things) does not work. Maybe we can work together on improving fpGUI/LCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I volunteer to be an easy target. Not good enough at Android and compiler stuff yet, although my stuff works. I am more than good enough at coding and review, though. And comparing different languages on the same platform. (C, C++, Java, Pascal) At least my toolchain seems to be working ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 14:06, Michael Schnell wrote: On 08/11/2011 05:28 PM, Thaddy wrote: Not really/ somewhat / close enough Can you provide a photo ? - Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Course. Mail it when I am at home. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 14:18, Michael Schnell wrote: If you use openGL v2 there's of course just one abstraction layer extra. Yep. I did understand wrong that not using GL would imply not using the rendering hardware and directly writing to the pixel array instead. Will not only provide screenshot but actual, dismal! - what-if kind of code link, scratchpad, code this weekend. That seems more useful for the forum. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 12-8-2011 14:54, Flávio Etrusco wrote: | Look at the documentation, that is easier: http://developer.android.com/sdk/ndk/index.html as a start. Almost ALL OpenGl calls are available under Android Gingerbread. In all my postings I am talking about Gingerbread or higher. But indeed, I am just experimenting. Wait until I post a link to my code. It works. And it is simple. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 11-8-2011 13:56, Sven Barth wrote: Even if KSD or now FireMonkey supports ARM Linux this does not mean anything for Android. While Android does support native Linux applications it does not have a X server. Currently the only possibility for this is to run a X server through a VNC viewer and thus you can not reproduce the usual feel of an Android application. For that you'd need to write a Java bridge. Regards, Sven Bovine excrement, but I admit only partially, depending on version: There are X servers running on Android and there is qt running on Android. Except you need at least 2.3 or maybe a high 2.2.x, never had those. I have qt code running myself on an very cheap Android 2.3 tab from a toyshop and it works a charm. I also have Mono/.net code running on it. Currently both under C and C#. The Freepascal examples run a bit strange (maybe ARM EABIv7 for Cortex 8, still palyimng with it) You definitely only need JNI before Android 2.3. So that part is correct. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 11-8-2011 16:37, Felipe Monteiro de Carvalho wrote: toyshop and it works a charm. What is the size of an app using Qt on Android counting the Qt libraries that it downloads? Just what you expect from any GNU compiled program and just what you expect the runtime libraries to be with any qt based program. Counting the libraries is not as relevant, the Android runtime is also several bytes... Since you have access to a NDI native screenbuffer you can use opengl v 2 to render anything directly without qt if you want, so small is definitely possible. You need a 8 or 16 G card though, for now, to use the establishment or a rooted device. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 11-8-2011 17:01, Sven Barth wrote: I know about X servers running there (I have looked that up today morning, because I liked to know whether I somehow could run Wine on Android), but all I've found yet was the restriction to access the X screen through a VNC viewer. If you know more, I'd be glad to hear that. :) And yes, I wasn't aware of QT. It works. There is a VNC server for Android for free. Does the QT app look and act like a native Android app? Did you (or someone else) test whether the LCL would work there using QT? Not really/ somewhat / close enough I bought my tablet for €149 in a toystore (with amazing specs for the money) just to get FPC running on it, so I will keep you posted about my progress. As I implied: a shared library isn't the problem. Native rendering is, that's why I am exploring the Qt and Mono alternatives first. When I am satisfied that works I look into qt/fpc android. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 11-8-2011 17:28, Thaddy wrote: On 11-8-2011 17:01, Sven Barth wrote: I know about X servers running there (I have looked that up today morning, because I liked to know whether I somehow could run Wine on Android), but all I've found yet was the restriction to access the X screen through a VNC viewer. If you know more, I'd be glad to hear that. :) And yes, I wasn't aware of QT. It works. There is a VNC server for Android for free. I mean running on your Android machine and as an X-server.. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 8-8-2011 21:57, Sven Barth wrote: On 07.08.2011 19:52, Marco van de Voort wrote: That being said, there is another bubble going on in Mobile, and we have to be very careful that such things don't happen again. May I ask you to explain what you mean here? (Just curious) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I already explained that for a good reader. Google versus Oracle on specific issues about Android. In this case: before Oreacle took over Sun, Sun was actively encouraging Google to develop Android and saw it as a strengthening of the Java platform. After Oracle took over their point of view (b.en) or standpoint (usa.en) changed 180 degrees. But that is just a part of it on Mobile. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
they could even save more time, it they would use Lazarus ;-) That's the one part they - Embarcadero - are still miles ahead in productivity and reliability. Lazarus is workable - more than that - but still cannot compete with Delphi in productivity - but that of course is for Windows only. I use both, but I use an Delphi IDE for development. The second part might be their new framework. Still, it is good news and I rather like the idea of Delphi as a development environment for the FreePascal toolchain. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 7-8-2011 18:50, Jonas Maebe wrote: I hope so. The main problem I see with that is that they would become somewhat tainted by the FPC source code if they do so, which may make it harder to work on their own compiler later on. As long as they don't start blatantly copying code from FPC into their own compiler (like some people did in the past with Delphi RTL code into the FPC RTL) I don't think anyone who has contributed to the compiler would really care if they learned a bunch of stuff from our code base, but of course they have lawyers who almost certainly will care a lot. This can of course be solved in various ways (have someone who normally does not work on their compiler work on ours, hire a someone temporarily to do that work, external contractor, ...). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I would not be surpised at all if they have done so. After all, they really appreciated the clean-room stuff done on FPC's RTL. This might sound strange after legal threads, but that is how California works. They are still very capable of destroying parts of the FreePascal community, especially Lazarus, in at least the USA and based on their strong patent portfolio if they would take up legal action. This is something that should not be forgotten: see the Sun-Oracle- Sue you Google about Android. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
I can see the messages in the changelogs of Delphi: Reason: FPC compatibility There is a risk of an endless loop here, or a deadlock of some sort 8-) Good news: the new Firemonkey framework is already 100% compatible with Freepascal by design. On 6-8-2011 12:16, Jonas Maebe wrote: Hi, See http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/#comment-743 and http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/#comment-749 (Michael Swindell works for Embarcadero): Re FPC, we will be coming out with a Delphi ARM compiler at some point, but we're appreciative that FPC is available today for ARM/iOS and we were able to leverage to get FireMonkey to iOS. So it's just a stopgap solution for them until they have time to build their own ARM compiler, but the fact that they will ship FPC definitely serves as a testament to its quality :) Very cool! Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
