On 06 Sep 2011, at 12:52, Alexander Klenin wrote:
On Tue, Sep 6, 2011 at 20:57, Jonas Maebe
wrote:
Right after I sent my mail the server was rebooted for some reason,
and the
web server didn't respond for a while. I'm pretty sure it works
fine if you
try now (it does for
On 06 Sep 2011, at 13:24, Alexander Klenin wrote:
Hm. This may be an issue with my provider then.
However, the only site affected is freepascal.org, which is very
strange.
Will try to call the provider to investigate.
There is one known problem: the server is behind a brain dead
firewall
On 06 Sep 2011, at 15:18, Alexander Klenin wrote:
I am on Windows, so I have enabled EnablePMTUBHDetect parameter
instead,
as per http://support.microsoft.com/kb/314053
It have helped somewhat -- now instead of waiting for the full page,
half of the page is downloaded, and then the waiting s
On 06 Sep 2011, at 21:48, Joost van der Sluis wrote:
> Can someone reproduce this? And what to do now? I've even did a touch on
> the rtl/objpas/parser.inc, but that doesn't help.
If you perform a top level "make all", the RTL and packages are compiled with
-Ur so that it never gets recompiled.
On 06 Sep 2011, at 14:00, Wookey wrote:
section 5 tells you about the calling conventions, and section 6 about
the normal variants (note the bit about it applying only to
non-variadic functions - does pascal support variadic functions?)
It does, in two ways:
a) calling variadic functions imp
On 07 Sep 2011, at 16:29, Joost van der Sluis wrote:
On Tue, 2011-09-06 at 21:58 +0200, Jonas Maebe wrote:
On 06 Sep 2011, at 21:48, Joost van der Sluis wrote:
Can someone reproduce this? And what to do now? I've even did a
touch on
the rtl/objpas/parser.inc, but that doesn't
On 08 Sep 2011, at 19:53, Marcos Douglas wrote:
> You're right, but I consider the fixes_2_6 (not branches_2_6, sorry)
> safe, don't you?
No, it is not safe. The only thing that is safe is the latest release, which is
2.4.4 currently.
Jonas___
fpc-d
On 08 Sep 2011, at 20:07, Marcos Douglas wrote:
> On Thu, Sep 8, 2011 at 2:59 PM, Jonas Maebe wrote:
>>
>> No, it is not safe. The only thing that is safe is the latest release, which
>> is 2.4.4 currently.
>
> And fixes_2_4 (I'm using too) I can consider sa
On 10 Sep 2011, at 20:52, Leonardo M. Ramé wrote:
> Hi, I'm trying to compile the SVN Trunk version using FPC 2.5.1 to bootstrap.
This is wrong. It has always been wrong and will always be wrong. Bootstrapping
has always only been supported and will always only be supported when starting
with
On 11 Sep 2011, at 19:39, Martin wrote:
> Just thought to catch up.
>
> what is the status on dwarf -3 ?
Nothing has changed recently.
> The 2nd idea is about properties. Afaik in dwarf-3 they may even be encodable
> => though I have no idea what gdb would do with the info.
Neither DWARF 3 n
On 11 Sep 2011, at 23:36, Graeme Geldenhuys wrote:
> On 11/09/2011, Jonas Maebe wrote:
>>
>> Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
>> submitting a proposal to add them to the DWARF standard either. See e.g.
>
> I was under t
On 12 Sep 2011, at 08:56, Graeme Geldenhuys wrote:
On 11/09/2011 23:40, Jonas Maebe wrote:
extensions. I don't see the advantage of allocating one of those and
communicating it to other compiler writers (to avoid them using that
same extension for something else) instead of submitting i
On 12 Sep 2011, at 09:22, Graeme Geldenhuys wrote:
So maybe one should start a wiki page regarding this, putting down
some
ideas that others can review and contribute towards? Building up
towards a specification we can later submit to the DWARF guys.
That certainly sounds like a good idea.
On 12 Sep 2011, at 12:23, Martin wrote:
The big issue, is that gdb often scopes them wrong, and you loose
the watch point before you it triggers
If you use an expression in a watch point, gdb will reevaluate that
expression if a value used in the watch expression changes.
Since in genera
On 12 Sep 2011, at 15:48, Leonardo M. Ramé wrote:
I'm trying to compile from svn trunk on Win32, but I get this when I
do "make clean all":
Try manually deleting all "units" directories under fpc/packages/*. In
general, you should always perform a "make distclean" *before*
updating from
On 12 Sep 2011, at 14:07, Martin wrote:
> Anyone care to comment on those ideas?
>
> Are they worth to be made a feature request?
> And if so, which of the proposed ideas should be made into a feature request?
I really don't like hacks like that. They will have to be maintained almost
forever
On 12 Sep 2011, at 20:20, Martin wrote:
> On 12/09/2011 19:14, Martin wrote:
>> Currently properties that map to a field are already present in dwarf (again
>> why not in stabs?).
Because Stabs is legacy and I don't want to spend time on it.
>> Could not properties mapping to a function be imp
On 12 Sep 2011, at 22:05, Joost van der Sluis wrote:
> Does someone knows a trick how to make gdb call a method (function) from
> a class?
It requires a patch to gdb. I'm fairly sure I already sent it to you in the
past. It was part of an, incomplete, patch set to also add support for the
Borl
On 13 Sep 2011, at 00:31, Martin wrote:
> Maybe this will help?
>
> make.exe all OPT="-gl -gw -godwarfsets -O1 "
You should use -O-1 instead of -O1. The default for "make all" is "-O2", and
"-O2 -O1" is the same as "-O2" (it says "enable -O2 optimizations and also -O1
optimizations", but -O
On 12 Sep 2011, at 15:23, r...@rdos.net wrote:
Why would anybody want to concentrate on gdb, which is an ancient
debugger,
It's only 7 years older than FPC (GDB: 1986; FPC: 1993).
that does not have a modern GUI integrated into it,
A GUI should not be integrated in a debugger. You don't w
On 13 Sep 2011, at 12:22, Martin wrote:
On 13/09/2011 10:31, Flávio Etrusco wrote:
GDB supposedly has support for reverse execution/walking back; I
don't
even know whether it really works for C, not to mention FPC calling
conventions, but if it does it would be a killer ;-)
It's unrelated
On 13 Sep 2011, at 12:59, Michael Schnell wrote:
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA
support has been much better than its C++ support for a long time
(although C++ support is getting fairly good nowadays too
On 13 Sep 2011, at 13:46, Joost van der Sluis wrote:
I think I have that patch applied. Calling functions in itself does
work, even when they use Borland fastcall. The problem is that it does
not work for a method, this inside a class.
I've found the patch again:
http://www.hu.freepascal.org
On 13 Sep 2011, at 14:20, Graeme Geldenhuys wrote:
What you are describing is like saying "we are not supposed to change
values at runtime while debugging either".
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mo
On 13 Sep 2011, at 14:43, Graeme Geldenhuys wrote:
Wow, thanks for that tip! It's a rather important piece of
information.
Is it mentioned somewhere in the FPC docs? I searched the Programmers
Guide but couldn't find any reference to -O- or -O- syntax.
-O-1 is the same as -O- -O1 (just lik
On 13 Sep 2011, at 14:52, Graeme Geldenhuys wrote:
On 13/09/2011 14:33, Jonas Maebe wrote:
No, he's saying that it should not be easy to do this accidentally. I
can imagine that in IDEs that evaluate everything your mouse cursor
happens to hoover over, automatic evaluation of getters
On 13 Sep 2011, at 16:52, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU p
On 14 Sep 2011, at 04:15, Paul Ishenin wrote:
If I change "cdecl" to "stdcall" in g_object_dosomething then it
compiles with no error.
For me it is strange. Should developer care about internal compiler
representation of an "array of const" for different conventions?
It's more that even
On 14 Sep 2011, at 10:40, Alexander Klenin wrote:
On Wed, Sep 14, 2011 at 19:03, Jonas Maebe
wrote:
It's more that even though both are called "array of const", they are
completely different things. They also don't support the same types.
Perhaps varargs-compatible p
On 15 Sep 2011, at 13:55, Martin wrote:
http://bugs.freepascal.org/view.php?id=20225
I did run a test on w32 vista
with gdb 6.7.5 / 7.0 / 7.2.1 / 7.3.1 / 7.3.2
with fpc 2.4.4 / recent fixes 2.6 / recent trunk
stabs
dwarf
dwarf3 (only trunk + gdb 7.3.2)
The DWARF3 implementation
On 15 Sep 2011, at 17:34, Seth Grover wrote:
> This morning I tried the vanilla GDB 7.2 release, the vanilla GDB
> 7.3.1 release, and various git branches from the archer branch
> (http://sourceware.org/gdb/wiki/ProjectArcher), specifically the
> "archer-jankratochvil-vla" and "archer-tromey-pyth
On 16 Sep 2011, at 12:38, Marco van de Voort wrote:
What do you think about adding TStringsUTF8/TStringListUTF8 to
classes.pas?
I think this is a slippery slope. These kinds of hacks are slipped
in one by
one, and each one is only a small concession, but in the end it is a
disaster. I don
On 17 Sep 2011, at 15:39, Martin wrote:
> Does that mean -gh does add debug info?
As the compiler help specifies, -g enables debug information. -gh is the same
as -g -gh. You can use -g-h to enable heaptrc without debug information.
> (stabs, unless others specified)?
The default debug forma
On 17 Sep 2011, at 15:54, Martin wrote:
> On 17/09/2011 14:43, Jonas Maebe wrote:
>>
>> The default debug format depends on the target platform.
>>
> Is there documentation anywhere?
No. And the default can also change over time.
Jonas
___
On 17 Sep 2011, at 16:41, Martin wrote:
> It happens when the lazarus IDE is compiled with both -gh and -gc
-gc is a fairly flaky option and it can only be used if your entire application
only consists of FPC code.
In general, I would strongly recommend against ever using it, because you'll
On 18 Sep 2011, at 12:26, Sven Barth wrote:
> For now you can apply the following patch as a workaround. The compiler (and
> fpmake) will depend on the C-library then (which should not be the case in
> the final solution).
Not only that: even with cwstring (and under Windows) the result is wro
On 18 Sep 2011, at 13:16, Graeme Geldenhuys wrote:
> And it boggles the mind why something so broken / incomplete was
> merged into Trunk in the first place?
Yes, we suck from time to time (in this case: testsuite runs were performed,
but the sync and merge were done by a person who only had ac
On 18 Sep 2011, at 13:57, Flávio Etrusco wrote:
> One obvious way to mitigate this would be to store the last
> CodePoint->Char in the string record, so that at least the most common
> case is covered.
... and so that the common case is broken in multithreaded environments.
Directly indexing a
On 18 Sep 2011, at 14:34, Martin wrote:
> Does -gv :
> - force either stabs or dwarf
-gv by itself enables the default debug format, just like -g, -gh, -gt, -gc, ...
> - work with both, and add extend info (never mind if stabs or dwarf)
It works with both.
> - observe stabs or dwarf setting (
On 19 Sep 2011, at 09:36, Marco van de Voort wrote:
> I don't like the Java/C# way that you have to manually allocate extra
> objects (stringbuilders etc) to get(performant) access to the characters
> though.
In Java that's only the case for changing characters. Reading characters
happens via
On 19 Sep 2011, at 10:27, Flávio Etrusco wrote:
> I partly agree it's PEBKAC, but why make it easy to get wrong when you
> can avoid it? Isn't that the point of Pascal? Isn't that the point of
> AnsiStrings? Isn't that the point of strong typed languages in
> general?
Yes, but supporting unicode
On 22 Sep 2011, at 13:26, Sash0k wrote:
But in the future I plan to migrate to Debian hardfloat port: http://wiki.debian.org/ArmHardFloatPo
rt
Note that this ABI is not supported by FPC at this time.
Jonas___
fpc-devel maillist - fpc-devel@lis
On 23 Sep 2011, at 01:21, Thomas Schatzl wrote:
I found that 18251 is okay, but the newer ones are not when
compiling with -O2. It seems that one optimization that transforms
expressions of type x*x into sqr(x) for floats in 18252 (and 18257
and 18263 that seem to have been fixing issues w
On 25 Sep 2011, at 11:54, Felipe Monteiro de Carvalho wrote:
> AFAIK we don't have a special version of our pages, so I suppose that
> we should not sniff user agents.
The error message you show doesn't indicate that the server is sniffing user
agents. It only indicates that that part of the re
On 27 Sep 2011, at 22:00, Martin wrote:
> On 27/09/2011 16:58, Joost van der Sluis wrote:
>>
>> Only problem is that when GDB is in Pascal mode, it won't work. I have
>> written a patch for that
>> (http://cygwin.com/ml/gdb/2011-09/msg00072.html) or you can set GDB to
>> use C, and then call the
On 28 Sep 2011, at 03:55, Paul Ishenin wrote:
28.09.2011 4:08, Jonas Maebe wrote:
- Exceptions => I know gdb has some features to restore the
stackframe => but I have no idea, if that relies on c-style
stuff, or would work with fpc exceptions too.
It does not rely on anyt
On 03 Oct 2011, at 10:14, Florian Klämpfl wrote:
FPC doesn't do any optimization in procedures containing inline
assembler.
It does. But also assumes that all registers are used in assembler
blocks, unless the programmer specifies otherwise. If you change the
assembler block into
asm
On 03 Oct 2011, at 15:49, Paul Ishenin wrote:
As I remember there is a package "lnet" which can be somehow
installed via internet. I don't remember the details but I believe
I've seen this a half year ago or so. Why fpspreadsheet and
fpverctorial together with new utf8 package can't be fol
On 03 Oct 2011, at 16:06, Alexander Klenin wrote:
There is, again, a continuum between careful development and
stangation.
While acknowledging great work that FPC team has done on the former,
I'd venture to say that is came uncomfortably close to the latter.
I think http://wiki.freepascal.o
On 05 Oct 2011, at 01:31, Leonardo M. Ramé wrote:
Does anyone knows where can I find a bootstraping compiler for this
platform?.
There is none that is usable for current trunk, you have to cross-
compile.
Jonas___
fpc-devel maillist - fpc-dev
On 09 Oct 2011, at 22:34, Martin wrote:
> 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.
It also checks every typecast. Accessing field
On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
> 1- Most of LCL must be code page agnostic, so not use UTF8String/AnsiString
> directly (keep String)
There is no difference between ansistring and string in {$mode delphi} and
{$mode objfpc}. In a future delphiunicode mode or somet
On 10 Oct 2011, at 23:11, Martin wrote:
> On 10/10/2011 21:56, Jonas Maebe wrote:
>>> 2- It should have (dont know if currently has) a compiler switch to change
>>> the default code page to UTF8 or whatever, so all variables with type
>>> String will map to UTF8
On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote:
> On 10/10/2011 17:56, Jonas Maebe wrote:
>> On 10 Oct 2011, at 22:11, Luiz Americo Pereira Camara wrote:
>>
>>> 1- Most of LCL must be code page agnostic, so not use UTF8String/AnsiString
>>> dire
On 11 Oct 2011, at 13:29, ik wrote:
I'm having a problem compiling FPC 2.7.1 under linux 64 bit:
sysconst.pp(243,7) Error: Wrong number of parameters specified for
call to
"$fpc_ansistr_sint"
sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping
[snip]
FPC:
Free Pascal C
On 11 Oct 2011, at 04:00, Marco van de Voort wrote:
> I know that Florian and you wanted to see the default string as something of a
> dialect mode, but I never saw a way to do that practically.
How about this: a new language feature is added to the compiler that enables
defining a type alias t
On 12 Oct 2011, at 09:56, Marco van de Voort wrote:
If it was just one class it would work. But essentially it is all
OOP. (e.g.
tcomponent and tcontrol has string properties, and thus the whole of
lazarus),
Lazarus doesn't have to change anything. They are free to follow the
path you pro
On 12 Oct 2011, at 10:13, Jonas Maebe wrote:
That would indeed require some ifdefs to keep the code compilable
also by Delphi. No solution will be completely free.
Well, an alternative could be to add a global directive such as
{$modeswitch duplicate_all_string_based_code}
whereby
On 12 Oct 2011, at 14:17, Graeme Geldenhuys wrote:
eg: UTF-8 as native string type under *nix systems, and
UTF-16 under Windows. Why must some platforms get a speed penalty and
others not, when you force only one encoding on all platforms?
The reason for doing so would be to make code more ea
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identifiers.
Java does, but the JDK doesn't c
On 13 Oct 2011, at 09:28, Martin wrote:
same address when trying to insert a breakpoint
-break-insert -f testunicode.pas:182
^done,bkpt={number="11",type="breakpoint",disp="keep",enabled="y",addr="0x0edb",file="testunicode.pas",line="182",shlib="/Users/felipe/Programas/lazarus/test/lazutil
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with making -
godwarfsets the default). It requires at least the latest
On 13 Oct 2011, at 10:37, Jonas Maebe wrote:
On 13 Oct 2011, at 10:17, Felipe Monteiro de Carvalho wrote:
Then maybe the default debug info created by -g on Mac should be
dwarf2? dwarf2 works correctly in my tests.
Yes, I agree it's about time to change that (along with m
On 13 Oct 2011, at 11:37, Felipe Monteiro de Carvalho wrote:
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
It's not documented what they use internally, but since all CFString
(= NSString) "character" accessors are UTF-16 based, I think
On 13 Oct 2011, at 12:00, Martin wrote:
On 13/10/2011 09:37, Jonas Maebe wrote:
No, and such table will not be made because it's an implementation
detail. If you require a particular debug information format,
specify it. Anything else will break as soon as the default is
changed
On 13 Oct 2011, at 12:06, Marco van de Voort wrote:
In our previous episode, Martin said:
But maybe a switch could be added, where an fpc exe gives feedback,
what
it currently defaults to?
in the case of the multiple RTL situation, the target designation gets
enhanced with the encoding (or
On 13 Oct 2011, at 15:02, Paul Ishenin wrote:
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output CP_UTF8 constant.
T
On 13 Oct 2011, at 20:51, Craig Peterson wrote:
> BTW, I wanted to point out, to anyone arguing for full Delphi compatibility,
> that on OS X Delphi's DefaultSystemCodePage and AnsiString(0) are *not* the
> system encoding _or_ UTF-8. They're the Windows ANSI codepages that
> correspond to th
On 17 Oct 2011, at 23:05, Luiz Americo Pereira Camara wrote:
> Deleting locally fpvectorial dir lead to this error:
>
> make[2]: Leaving directory `D:/repositories/fpc_trunk/packages/fppkg'
> make -C fpvectorial distclean
> make: Entering an unknown directorymake: Leaving an unknown directorymak
On 17 Oct 2011, at 23:05, Luiz Americo Pereira Camara wrote:
> PPU Loading
> D:\repositories\fpc_trunk\packages\fcl-image\units\i386-win32\fpcanvas.ppu
> PPU Invalid Version 131
> Fatal: Can't find unit fpcanvas used by fpvectorial
Actually, you should delete D:\repositories\fpc_trunk\packages\
On 19 Oct 2011, at 15:45, Graeme Geldenhuys wrote:
> Not that I understand much of the assembler generated, but what I did
> notice is that Delphi XE2 64-bit uses the MOVAPD function (introduced in
> SSE2 [1]), but even if I specify -O3 -CfSSE3 with 64-bit FPC, FPC only
> uses the MOVSD (introduc
On 21 Oct 2011, at 07:54, Vincent Snijders wrote:
> Guaranteed:
> Compile http://svn.freepascal.org/svn/fpc/tags/release_2_4_2/ with fpc
> 2.4.0 to get fpc 2.4.2
> Compile http://svn.freepascal.org/svn/fpc/tags/release_2_4_4/ with fpc
> 2.4.2 to get fpc 2.4.4
> Compile http://svn.freepascal.org/s
On 22 Oct 2011, at 05:20, Andrew Haines wrote:
> I was experimenting with gtk3 a bit and a simple program was failing to
> execute properly.
>
> It's very simple:
It's very difficult. The reason is that you are not showing a complete
compilable program including all the declarations of the ext
On 22 Oct 2011, at 10:41, Ludo Brands wrote:
> What platform? Win32 builds fine with 19527 and 2.4.4.
http://lists.freepascal.org/lists/fpc-devel/2011-October/026908.html
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fr
On 23 Oct 2011, at 14:01, Paul Ishenin wrote:
> 23.10.11 19:49, 4iter пишет:
>> Hi!
>> Fatal: Compilation aborted
>> ..
>> Maybe fixit it with #ifdef ?
>
> How to define this ifdef?
>
> Maybe it could be fixed either by dynamic loading or weakexternal
On 23 Oct 2011, at 14:25, Marco van de Voort wrote:
> Seems that that function is not in the open group's specification of iconv,
> it is a GNU extension.
>
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/iconv.h.html
>
Ah, yes. Even Mac OS X apparently uses GNU libiconv. So a weak s
On 23 Oct 2011, at 15:02, Paul Ishenin wrote:
> Does weaksymbol works on all platforms where cwstrings is used (I know that
> it is not implemented on windows at least but there we don't need cwstrings
> too)?
Good question, and I'm afraid the answer is "no"... At least
http://wiki.freepascal
On 23 Oct 2011, at 15:14, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
>>> Does weaksymbol works on all platforms where cwstrings is used (I know
>>> that it is not implemented on windows at least but there we don't need
>>> cwstrings
On 24 Oct 2011, at 04:00, Paul Ishenin wrote:
I tried to handle the situation by using LoadLibrary, GetProcAddress
and also failed on osx.
The next line tries to load "iconv.dylib" while on osx the library
name is "/usr/lib/libiconv.dylib":
iconvlib:=LoadLibrary(libiconvname+'.'+SharedSu
On 27 Oct 2011, at 15:26, Alexander Shishkin wrote:
I`ve got this with 2.5.1 & 2.7.1
1) unable to clean reproduce (real code is
https://github.com/alexvins/dwscript/tree/628669df8fd349968e7498ab1da617be6c4f3977)
2) error reported in the middle of EMPTY line.
This internal error indicates th
On 27 Oct 2011, at 16:17, Ludo Brands wrote:
If it is a C++ exception, then it is a firebird client bug.
The exceptions are not supposed to leave the fbclient library...
Or fpc is catching the c++ exception and not chaining them. Similar to
win64.
It is impossible for FPC to catch a C++ exc
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 pro
On 01 Nov 2011, at 23:01, Marco van de Voort wrote:
> That is an symmetrical argument. I could argue exactly the same about
> correctness. I don't need it, so please don't force it on all users.
I suppose you meant that what is correct and what not depends on the
specification, rather than than
y on Unix. I'm not opposed at all to add some
kind of extra "return a monotonic clock value" function somewhere.
In our previous episode, Jonas Maebe said:
If you are in a case where you do want a high precision timer that is only
adjusted once to the system's timezon
Felipe Monteiro de Carvalho wrote on Wed, 02 Nov 2011:
Now() -> Like Michael proposed. Implemented with precision, but with a
switch for existing code bases to hack it into being fast.
I don't think it is appropriate to add a hack to the RTL for a case
like this. No major incompatibility wit
Marco van de Voort wrote on Wed, 02 Nov 2011:
In our previous episode, Jonas Maebe said:
Anyway: a function that reports the local time is simply
the wrong tool for the job if you need a "mostly" monotonic timer that
you can query at a high frequency. It may work (and apparently i
Martin Schreiber wrote on Wed, 02 Nov 2011:
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Just like all UTF-16 code in
the RTL is slower than what Martin Schreiber would like, and we didn't
change it to UCS-2 when he asked to do so for speed reasons.
???
I never asked
Hi,
I've put a new FPC JVM snapshot online (corresponding to svn r19598 of the
jvmbackend branch), linked from http://wiki.freepascal.org/FPC_JVM
Changes since the previous snapshot include:
* the compiler will now implicitly convert between all Pascal string types and
JLString (java.lang.Strin
On 07 Nov 2011, at 09:21, michael.vancann...@wisa.be wrote:
I have been looking at the JVM backend, and noticed that file I/O is
not
working. I'm asking what is needed to get write(ln) or read(ln)
working.
Mainly adapting rtl/inc/text.inc and rtl/inc/textrec.inc. I haven't
looked yet in
On 07 Nov 2011, at 12:21, michael.vancann...@wisa.be wrote:
TextRec uses THandle for everything, I assume it can be used to
store a pointer to an object (or whatever Java uses for files),
since in Java everything is
an object anyway ?
Yes (once THandle is added to the JVM RTL and it is de
On 07 Nov 2011, at 13:46, michael.vancann...@wisa.be wrote:
On Mon, 7 Nov 2011, Jonas Maebe wrote:
Yes (once THandle is added to the JVM RTL and it is defined to
Pointer or JLObject, at least :). It's generally a PrintStream: http://download.oracle.com/javase/1,5.0/docs/api/java
On 07 Nov 2011, at 09:21, michael.vancann...@wisa.be wrote:
I have been looking at the JVM backend, and noticed that file I/O is
not
working. I'm asking what is needed to get write(ln) or read(ln)
working.
One thing I forgot to mention: threadvars. They are already supported
and work (sh
On 15 Nov 2011, at 15:49, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 3:42 PM, Felipe Monteiro de Carvalho
> wrote:
>> So if anything was broken before rev19036 it was after 19th January or
>> it requires something special to reproduce. So far I haven't found any
>> issues with
On 15 Nov 2011, at 15:57, Felipe Monteiro de Carvalho wrote:
> On Tue, Nov 15, 2011 at 2:51 PM, wrote:
>> So it's probably a lot easier to just IFDEF with a -DANDROID or so,
>> and recompile the linux target specifically for android.
>
> I had already proposed this previously and Jonas rejecte
On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
> I dn't know if this is a good long term solution: I fear too much
> duplication with having a seperate android target. I'd prefer an
> FPC_ANDROID define, I don't think that it will pollute the rtl and
> considering that there are a lot of arm "s
On 17 Nov 2011, at 20:51, Seth Grover wrote:
Notice that in x86_64, unless you explicitly cast the longword as a
double before the division, you get some sort of rounding error or
loss of precision.
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
Jonas
___
On 18 Nov 2011, at 12:20, Graeme Geldenhuys wrote:
On 2011-11-18 13:04, Jonas Maebe wrote:
http://wiki.freepascal.org/
User_Changes_2.2.0#Floating_point_constants
The description of the "new behaviour" should change then. The part
that
says "...which doesn't cau
On 18 Nov 2011, at 14:41, Seth Grover wrote:
Fair enough. Jonas, thanks for the link and explanation. I'll just be
more aware of what I'm doing when it involves calculations like this
and do the cast when needed.
One command line parameter was added later on to facilite dealing with
such si
On 19 Nov 2011, at 11:31, Sergei Gorelkin wrote:
> Is it possible to declare a (SSE friendly) record or array type, so that
> local variables of this type get aligned to e.g. 16 bytes?
I don't think so. For this, we'd probably need a separate vector type (possibly
using a modifier for array ty
On 19 Nov 2011, at 14:04, Sergei Gorelkin wrote:
> Hm, that looks like two separate tasks: one is distinct vector type for ABIs,
> another one is alignment of arbitrary types. The issue I've stumbled into is
> the TContext record (CPU context), which contains only word and qword
> members, but
1 - 100 of 2972 matches
Mail list logo
