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 -
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
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
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
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
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
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
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 -
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
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"
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.
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
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
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
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
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
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 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
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?
> 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
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
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
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
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.
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
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
/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
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
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
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
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
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
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
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
___
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
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:
.
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
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
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
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
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
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
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
/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
.
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
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
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
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
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
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
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
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
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
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
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
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
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
{$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
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,
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
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
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
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
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,
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
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
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
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
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
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.
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
1 - 100 of 199 matches
Mail list logo
