It is enough to change this to cover fixes, 3.2.3, and a future 3.2.4:
{$IF FPC_FULLVERSION >= 30203} // change here to 3.2.x fixes
{$DEFINE WITH_FTSINGLE}
{$DEFINE WITH_FTSHORTINT}
{$IFEND}
Regards,
Thaddy
On 2025-04-01 14:50, Michael Roland via fpc-devel wrote:
Ok, thanks for explaining
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-dev
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.fre
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 (21474
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 fr
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 correc
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 st
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.
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" i
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 ca
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
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 'elselabe
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
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 mo
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 implementa
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
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 current
e 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 ma
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.
27;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.
Whic
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'
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 com
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
/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
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
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
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
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 overr
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
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:
.
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 -
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:
CROSS
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
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
ectly
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
_
---
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
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 t
d/
* 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 h
s 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
e 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
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
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 entra
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
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 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 ne
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 t
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 de
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
_
t 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 figure
On 2-7-2013 0:47, Michel Catudal wrote:
I find smaller devices like the AVR32 and PIC32 more appropriate for embedded
system. ARM devices with Linux are more for use with video. The Pi is a bit
slow on graphics so I came to the same conclusion as many that it is more
usefull using ssh. I can r
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
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-dev
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 g
{$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 OBJFP
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, th
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 maillis
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
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 mailli
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 21:30, Thaddy wrote:
UNICODE} blocks. 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
Meaning/implies: when you are the compiler guardian/owner you can simply
enforce string to
On 6-2-2012 22:14, Sergei Gorelkin wrote:
under 10KBytes
Any decent code under 10k is interesting
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/
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, aga
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/l
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. Windo
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
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 oth
On 6-2-2012 21:04, Craig Peterson wrote:
In C on Windows the UNICODE symbol controls whether undecorated
functions should use the A or W versions, and what the TCHAR symbol
translates to.
This exactly the case and I do noy suggest this to be dropped. (This is
not only C but also FP-C btw)
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
http://lists.freepascal.org/mailman/listinfo/fpc
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 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
On 27-1-2012 17:25, Marco van de Voort wrote:
In our previous episode, Kornel Kisielewicz said:
{$apptype console}
Type
TLIST=class
end;
type
Ta= TLIST;
TB= TLIST;
This may very well be a (semantics) bug in Delphi.
Did you put this to Embarcadero?
IMO a type Ta<..> should
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
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-
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
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 smalle
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 im
BTW I am aware I can solve this at the sourcecode level with defines - I
just did that -, but would prefer one of my suggestions.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
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.freepa
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
Did anybody mention gettickcount is documented as microtiming?
And should not be expanded?
On 3-11-2011 9:57, Marco van de Voort wrote:
In our previous episode, zeljko said:
So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
linux, bsd and others, and in that case we can have
Gentlemen, gentlemen,
Stop this.
Every proper software clock == UTC, not local time.
The local time should always be on read time, on the fly.
Thaddy
On 2-11-2011 11:48, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
Anyway: a function that reports the local time is
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 trav
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 allo
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? You mean you are seeking the solution upstream? Seems
the design of those units is lacking.
_
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 exp
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 ac
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 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 bi
On 12-8-2011 13:16, Michael Schnell wrote:
On 08/11/2011 04:09 PM, Jeppe Græsdal Johansen wrote:
Android also has some support for a pixbuf object in native mode,
which I guess could be used for the same
Having the processor write into the pixel array would be horribly
slow. I am right now pla
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, so
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 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
1 - 100 of 216 matches
Mail list logo
