Graeme Geldenhuys schrieb:
On Thu, Nov 20, 2008 at 11:12 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Ok, two questions for the example above:
- how do you maintain backward compatibility?
- how do you load a plain old ansi file?
If the file is UTF-8 or ANSI, the above should work. UTF-8
Graeme Geldenhuys schrieb:
Hi,
Is there any list of missing features for UnicodeString in the RTL?
For example:
* I can't seem to find a UnicodeString version of TStrings or TStringList
Any more such cases?
No idea, nobody complainted so far ;) Just create one.
I would like
Graeme Geldenhuys schrieb:
On Thu, Nov 20, 2008 at 4:10 PM, Aleksa Todorovic [EMAIL PROTECTED] wrote:
Or... it could be implemented using generics, so one can choose:
TStringListUnicodeString
TStringListAnsiString
TStringListShortString
(sorry for C++ish syntax, but I hope you understand)
Graeme Geldenhuys schrieb:
Hi
How am I supposed to handle unicode characters for locale variables?
All locale variables like ThousandSeparator is type Char and there is
no overloaded UnicodeChar versions. This causes problems in Russian
locales as the example below shows.
c :=
Felipe Monteiro de Carvalho schrieb:
On Fri, Nov 21, 2008 at 7:30 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
This is easily said, please create examples and descriptions how fully
working is defined.
// Should actually convert from widestring to utf-8 when using encoding utf-8
programa
Felipe Monteiro de Carvalho schrieb:
On Fri, Nov 21, 2008 at 7:30 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
This is easily said, please create examples and descriptions how fully
working is defined.
It would be really good if there was a guide, preferably in the wiki,
to explain how
Folks, before your waste your time again with endless discussions, have
a look at Yury's work on an unicode rtl, test it and help with patches
and suggestions, it's available in svn at
http://svn.freepascal.org/svn/fpc/branches/unicodertl
___
fpc-devel
Graeme Geldenhuys schrieb:
Hi,
Has anybody written these conversions functions yet? If not, I am
about to port the ConvertUTF.c file from Unicode.org to Object Pascal.
UTF-32 to UTF-16
UTF-32 to UTF-8
UTF-16 to UTF-32
UTF-16 to UTF-8
UTF-8 to UTF-16
Graeme Geldenhuys schrieb:
On Sat, Nov 22, 2008 at 10:51 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
function UTF8Decode(const s : UTF8String): UnicodeString;
Is there some hard-coded limit on UTF8Decode? I am writing some unit
tests for these methods and on my 3rd test, it already fails
Graeme Geldenhuys schrieb:
On Sat, Nov 22, 2008 at 9:07 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
See http://bugs.freepascal.org/view.php?id=11791
OK, but that bug report is about an invalid sequence and getting out
NULL. I'm testing perfectly valid UTF-8 sequence and still getting
JoshyFun schrieb:
Hello Graeme,
Sunday, November 23, 2008, 9:21:09 AM, you wrote:
GG So UTF8Decode only supports UCS2 output! Now this is why I think
GG supporting UTF-8 in fpGUI and Lazarus LCL was a good idea. By design
GG (utf-8), you have to support the whole unicode range. With
JoshyFun schrieb:
Hello Jonas,
Sunday, November 23, 2008, 6:14:11 PM, you wrote:
//LowerCase arrays size: 2376 bytes
const UnicodeLowerCaseArraySource: array [0..593] of WORD=(
//UpperCase arrays size: 2408 bytes
const UnicodeUpperCaseArraySource: array [0..601] of WORD=(
//TitleCase
JoshyFun schrieb:
Hello Florian,
Sunday, November 23, 2008, 6:51:35 PM, you wrote:
Only general case, language tailoring is a completly different beast.
[...]
FK I think we should simply depend on the OS in this case like the cwstring
FK unit does though linux doesn't make life easy in
Tomas Hajny schrieb:
On 24 Nov 08, at 21:49, Marco van de Voort wrote:
In our previous episode, Florian Klaempfl said:
Of course if OS provides functions, use them! they should be properly
implemented and will be even faster without memory serious impact, but
I'm quite sure that not all
Jonas Maebe schrieb:
On 29 Nov 2008, at 11:11, Felipe Monteiro de Carvalho wrote:
You can tell FPC to do the SSE code for you:
-Cfx Select fpu instruction set to use, see fpc -i for
possible values
That only applies to (scalar) FPU operations at this time. It won't do
any
Dariusz Mazur schrieb:
Jonas Maebe pisze:
Of course tSSEVector should be declared in System unit.
Then any one can use SSE intentionally
Why can't you now? It's not like multiplication has any other meaning
for arrays. And declaring magic compiler types in the system unit is
something
Dariusz Mazur schrieb:
Florian Klaempfl pisze:
Dariusz Mazur schrieb:
Jonas Maebe pisze:
Of course tSSEVector should be declared in System unit.
Then any one can use SSE intentionally
Why can't you now? It's not like multiplication has any other meaning
for arrays
Felipe Monteiro de Carvalho schrieb:
Hello,
Some things weren't clear from the previous discussion, so I would
like to clarify them.
For instance, the GetTempFileName routine:
http://www.freepascal.org/docs-html/rtl/sysutils/gettempfilename.html
The routine is currently ANSI, but we
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
No, it will be RTLString which type depends on the OS.
Ok, so code would be something like this:
var
OSString: RTLString;
MyString: UTF8String;
begin
OSString
Martin Friebe schrieb:
In other words, write pascal code, just do not use some of the (imho)
most common elements of pascal syntax?
I acknowledge a language is a living thing, and needs to be adjusted to
the new things, that come up over time. I only ask, if this is the best
way?
We're open
Martin Friebe schrieb:
Marco van de Voort wrote:
In our previous episode, Martin Friebe said:
Of course they are still there, to be used in the few parts of your
code, where you specialize on whatever string type you deal with.
But otherwise, using RTLString IMHO will abandon this part
Michael Schnell schrieb:
It is planned to allow users to build ANSI version of RTL which will
be fully compatible with existing user code.
But if you choose to use unicode RTL, you must keep in mind all
unicode specific things...
This will be very helpful for the time being.
It is not
Mattias Gaertner schrieb:
On Mon, 01 Dec 2008 16:36:23 +0100
Florian Klaempfl [EMAIL PROTECTED] wrote:
[...] Martin Friebe schrieb:
I can not see how I can interpret RtlString[1]. If the result is
bigger than 128, then I must know what type it is. If it is ANSI,
it is a single byte char
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 7:01 PM, Marco van de Voort [EMAIL PROTECTED] wrote:
RTLString, IOW encoding platform dependant. Except maybe selected widgets
like
synedit. (Borland stores source in utf-8 too on windows)
A string whose encoding is unknown is
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 7:24 PM, Florian Klaempfl [EMAIL PROTECTED] wrote:
So how did people work for years with ansistring?
A ansistring used in the way proposed by FPC is extremely inconvenient
for any GUI application which will be run in different parts
Felipe Monteiro de Carvalho schrieb:
On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
[EMAIL PROTECTED] wrote:
I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
compatibility. Maybe you can give some more details, how it should work.
It was just a initial idea. I now see
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to debug STL based programs even with a in this regard
good debugger?
___
fpc-devel
Mattias Gärtner schrieb:
Zitat von Florian Klaempfl [EMAIL PROTECTED]:
Mattias Gaertner schrieb:
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing
Michael Schnell schrieb:
Don't forget that the ansistring type is actually multiple encodings and
even multi byte (even not considering UTF-8). The point is: nobody took
care of it.
IMHO a major confusion is generated by calling a string that is supposed
to hold UTF8 data ANSIString.
Michael Schnell schrieb:
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need
Unicode ?
IMHO the introduction of Unicode
Michael Schnell schrieb:
I meant more that a lot of people simply ignored in their code that
ansistrings could be also multibyte even not considering UTF-8.
Ignoring that ANSI Characters $7F are locale depending makes a program
work perfectly in a single country and mostly decently in
Mattias Gaertner schrieb:
You can optimize for one encoding or optimize for one per platform. I
know how to optimize for widestrings, for ansistring and for UTF-8
strings, but I have no experience in optimizing for multiple
encodings.
Don't forget that the ansistring type is actually
Alexander Klenin schrieb:
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try to debug STL based programs
Michael Schnell schrieb:
So, really? What is not supported?
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Or do you just want to troll around? This
Florian Klaempfl schrieb:
Alexander Klenin schrieb:
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl [EMAIL PROTECTED] wrote:
Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
Did you ever try
Michael Schnell schrieb:
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Sorry for bad language :( ! I did not mean to be aggressive. (Did you
see
Michael Schnell schrieb:
Felipe Monteiro de Carvalho wrote:
Ignore the name ansi. Take it as a string type with the system
encoding. I think it will solve the confusion.
Of course if you ignore ANSI and just use the type named String
there is no confusion as it's clear that the coding is
Michael Schnell schrieb:
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called ANSI ?
Every well educated windows programmer knows that the ansi
functions/strings whatever are not limited to the so-called ansi code
pages (which
Michael Schnell schrieb:
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If it would be
Nataraj S Narayan schrieb:
Hi
Can we write the RTL as stand alone without the backing of an OS?
Yes. However I thought you're using Ruby now?
regards
Nataraj
On 12/4/08, Jonas Maebe [EMAIL PROTECTED] wrote:
On 04 Dec 2008, at 05:41, Nataraj S Narayan wrote:
Is there a chance
Graeme Geldenhuys schrieb:
Hi,
I ported some code (a Relationship Manager design pattern) that was
written in Delphi to Free Pascal. I noticed that the original author
used 'strict private' in the class declarations - where one unit had
multiple classes.
I'am quiet sure FPC supports
Graeme Geldenhuys schrieb:
On Sat, Dec 6, 2008 at 11:02 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
I'am quiet sure FPC supports strict private in delphi mode.
Oh, I never tried that. I 99.99% of the time use ObjFPC mode - I much
prefer the more strict language rules. Why doesn't FPC
Mattias Gärtner schrieb:
I'm writing a unit to simplify parallel methods/procedures.
For example:
DoParallel(@AMethod,StartIndex,EndIndex,Data);
The AMethod is executed with several threads in parallel.
What should happen when an exception occurs?
It would be nice if the exception
Mattias Gärtner schrieb:
raised ?
It should be raised in the starter thread. The question is how to
- stop an exception in a thread (try..except)
- give it to another thread - the starter thread (giving the object is easy,
but
...)
- continue the helper thread (this will normally free
Mattias Gärtner schrieb:
Zitat von Michael Van Canneyt [EMAIL PROTECTED]:
[...]
This is the problem: At which point should this be done ?
Can you point at the statement where it should be raised in the following
code:
try
...
DoParallel(...);
...
except
end;
There is
Henry Vermaak schrieb:
2008/12/14 Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk:
Luca Olivetti wrote:
There was a thread on fpc-pascal last june, I didn't succeed, maybe things
have changed now
http://thread.gmane.org/gmane.comp.compilers.free-pascal.general/11546/
Thanks, I saw some
Paul Ishenin schrieb:
Hello, FPC developers' list.
In lazarus I need one function which does not present in fpc but exists
in delphi rtl.
I prepared a patch which adds it to fpc rtl.
Thanks, applied.
___
fpc-devel maillist -
Olivier Coursiere schrieb:
Hi,
Here is a couple of changes to improve the Haiku target.
Among other things, this patch :
- add posix thread support
- improve signal handling
- synchronize haiku's baseunix unit with the unix one (maybe it will be
possible to remove Haiku's one in a futur
Olivier Coursiere schrieb:
Hi,
Here are some more fixes for Haiku :
http://olivier.coursiere.free.fr/diff/Haiku_r12732.diff
Thanks, applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Olivier Coursiere schrieb:
Hi,
Here is an update of the baseunix unit for the BeOS target :
http://olivier.coursiere.free.fr/diff/beos_rtl_r12741.diff.
Applied, thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
SErgey Ya. KOrshunoff schrieb:
Hi!
Currently an fpc build start with building a new runtime with current
fpc compiler. There can be a failure with this. For example: no such
internal routine error if we try to build fpc 2.2.0 runtime with fpc
2.3.0. I think the right order is to start a
Sergei Gorelkin schrieb:
Hello,
Looking at the changes to rtl/win/tthread.inc made in r12761, I see that
'thread helper window' is pretty well unused, as CM_EXECPROC message is
never posted to it (grepping rtl sources for CM_EXECPROC shows that).
So maybe ThreadWndProc function and window
Sergei Gorelkin schrieb:
The attached patch fixes the crash.
Thanks, applied in r12802
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Alexander Klenin schrieb:
3) Finally, and relevantly for this list,
should something like this be included into FPC?
Imo in principle, yes, but:
- simpler than NX library in the sense of less functionally, putting
something like NX library in FPC is too much imo.
- cross platform
- FPC rtl
So next time (not this time, we're already on it now) provide small
patches if you can and try not to include old patches into new ones.
Although I do admit that that's more work, that way we can apply faster
and that way it's easier for you to make new changes...
If one has more patches,
ABorka schrieb:
Sorry guys, I knew I should have called them service packs, not patches :)
In the future I would like to do it in the right way, but I'm not
exactly sure how. Lets say I check out the latest SVN and make some
changes in a few files in /FCL-web/ .
I generate a patch file
Graeme Geldenhuys schrieb:
This is where a Git repository comes in really handy. Create a new
local feature branch or stash existing changes while working on new
changes. Then unstash / pop old changes again.
Florian, do you read freeX magazine (same people as Toolbox)?
No.
I wrote
an
Alexander Klenin schrieb:
On Sun, Mar 1, 2009 at 21:06, Florian Klaempfl flor...@freepascal.org wrote:
If one has more patches, something like using mercurial queues is a good
idea. Maybe Alexander Klenin could write a short tutorial how to use mq
to maintain patches.
There are many
Olivier Coursiere schrieb:
Hi,
While using a new working copy, i discover two things i forgot in my
previous patchs :
- pthrhaiku.inc in packages/pthreads/src/
(http://olivier.coursiere.free.fr/diff/fpc_haiku_rev12829.diff),
- compiled binaries for C sources in tests/test/cg/obj/
Graeme Geldenhuys schrieb:
That's the problem! GDB *doesn't* support all the language features
that Object Pascal offers, so some things cannot be debugged. This is
not a Lazarus issue, but a limitation of GDB with the Object Pascal
language. And I have heard the comments about trying to
Nataraj S Narayan schrieb:
Hi
There is file lpc21x4.pp under /rtl/embedded/arm. Does this mean
that i can compile fpc for the Philips LPC boards?
Yes, I did so already.
I got an LPC 2378
stk board with me. Perhaps I may need to modify the lpc21x4.pp to
suit my board.
Can anybody
dmitry boyarintsev schrieb:
Finally getting rid of GDB: This is VERY good news indeed :-)
it's been getting rid of GDB for some time already... but, imho it
should not be removed!
1) because GDB supports a lot of platforms, already. So porting a fpc
program to a new platform, will require
Martin Schreiber schrieb:
Using gdb has the *big* advantage to have a working environment on many
platforms with working remote debugging. I suspect the work for developping
an own debugger will be very big, have a look into the gdb sources and you
know what I mean...
The main problem with
Jonas Maebe schrieb:
On 11 Mar 2009, at 15:12, Jonas Maebe wrote:
It may even be quite challenging to generate debug information for
something like that with Stabs. For DWARF, it seems there is some code
that generates debug information in some cases, but only for var a:
type absolute
Mike Denisenko schrieb:
Hello everyone, I'm a student of FESU, Russia. I've started to
develop a feature - string cases (Topic: Easiest way to case
strings,
http://www.lazarus.freepascal.org/pipermail/lazarus/2009-March/023369.html),
and now some questions appear:
Existing method of
Alexander Klenin schrieb:
Where should new tests for string 'case' be added?
E.g. fpc/tests/test/tstrcaseX.pp ...
See also http://svn.freepascal.org/svn/fpc/trunk/tests/readme.txt
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Sergei Gorelkin schrieb:
Thanks, applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Bogusław Brandys schrieb:
Marco van de Voort wrote:
In our previous episode, Bogusław Brandys said:
Interesting.I have :
D:\FPC\2.3.2\bin\i386-win32fpc -i
Free Pascal Compiler version 2.3.1
Compiler Date : 2009/04/27
Compiler CPU Target: i386
and:
D:\FPC\2.3.2\bin\i386-win32grep -i
Daniël Mantione schrieb:
Op Tue, 28 Apr 2009, schreef Vincent Snijders:
Tomas Hajny schreef:
On Tue, April 28, 2009 12:13, sakesun roykiatisak wrote:
Is it possible to remove dependency on cygwin from freepascal ?
To make it clear, I actually mean remove dependency on some cygwin
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
The IDE can be compiled with and without gdb. Releases typically have
GDB,
snapshots not.
oops,sorry. That was my mistake. I always make new snapshot from SVN and
copy missing files from last release (which is used
Michael V. Denisenko schrieb:
Здравствуйте, Jonas.
Вы писали 24 апреля 2009 г., 22:30:55:
On 24 Apr 2009, at 13:24, Michael V. Denisenko wrote:
I have a question about adding error messages to msgtxt.inc.
As I've understood, there's an array of strings each 240 symbs long.
So shall I
Jonas Maebe schrieb:
On 03 May 2009, at 13:54, Marco van de Voort wrote:
(I thought btw, generics in 2.2.4 had improved to being more or less
usable?)
A number of important bugs were indeed fixed. But as far as I know,
several more are left.
I see no problem if a certain feature has
Martin Sucha schrieb:
Hi,
2009/5/5 Martin Sucha:
2009/4/29 Martin Sucha:
I've translated some C header files to be able to use pangocairo in
my application.
I'm attaching a version of the patch that I consider final.
My patch is still hanging around...
I'd be very happy if it gets
bors...@libero.it schrieb:
As in the subject, the FillPoly doesn't use the correct colour specification, for
a demonstration you can try the example poly.pas (attached) before and
after to apply the patch.
Thanks, applied.
However, I wonder if the behaviour on pattern fills is correct ...
Jonas Maebe schrieb:
situations, but not very much.
Has anyone tried it on Lazarus?
Yes, the but the results are not very impressive. The reason is due to
the way the LCL is constructed, almost every declared class can
theoretically be instantiated. On the other hand, I read that recently
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
theoretically be instantiated. On the other hand, I read that recently
the LCL was restructured a bit to improve the situation, so maybe the
results would be better now.
Also note that WPO can do little about
bors...@libero.it schrieb:
On 29 May 2009 at 0:29, Florian Klaempfl wrote:
Thanks, applied.
However, I wonder if the behaviour on pattern fills is correct ...
I have investigated a little, but I don't be sure you refer in what follows.
See the DirectPutpixel call in graph.inc line 848
bors...@libero.it schrieb:
What do you think about?
Applied, thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Alexander Klenin schrieb:
Currently, Round and Trunc functions ignore the state of $OVERFLOWCHECKS
compiler directive. The following code prints -2 -2:
{$MODE OBJFPC}{$OVERFLOWCHECKS ON}
var
a: Integer;
b: Double;
begin
b := MaxInt;
a := Round(2.0 * b);
Writeln(a);
a :=
bors...@libero.it schrieb:
On 12 Jun 2009 at 16:56, Florian Klaempfl wrote:
See the DirectPutpixel call in graph.inc line 848:
{ x1 mod 8 }
if RevBitArray[x1 and 7] and TmpFillPattern 0 then
DirectPutpixel(x1,y
Jonas Maebe schrieb:
On 19 Jun 2009, at 12:01, Maxim Egorov wrote:
Micha Nelissen пишет:
Since the return value is undefined, anything is possible:
* calculate crc32 over executable
* random value from stack
* do nothing at all
It's not true in the case of functions that return dynamic
Graeme Geldenhuys schrieb:
We are based in South Africa - I'm not sure where the
svn2.freepascal.org server is located.
Austria. If it helps you, we can also setup a git read only mirror on
one of the European server.
___
fpc-devel maillist -
Vincent Snijders schrieb:
Florian Klaempfl schreef:
Graeme Geldenhuys schrieb:
We are based in South Africa - I'm not sure where the
svn2.freepascal.org server is located.
Austria. If it helps you, we can also setup a git read only mirror on
one of the European server.
If I clone
Graeme Geldenhuys schrieb:
2009/7/11 Zaher Dirkey parm...@gmail.com:
Another nice
feature is that the local copy is much cleaner - no more duplicates of
all files so your local copy takes up less space,
If I care about this, I use a compressing file system or compress even
single folders
Nick Brown schrieb:
A very interesting port for an “OS-less” platform would be a port to the
PIC
family of microcontrollers. There may be some issues because memory is
in short
supply but notwithstanding, this would be pretty cool.
Any comments?
If it's really interesing,
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
Any comments?
If it's really interesing, somebody would have started already a port.
Afaik all architectures are done by three long time FPC devels (Jonas,
Peter, Florian, correct me if I'm wrong), except
Jonas Maebe schrieb:
On 29 Jul 2009, at 18:47, Daniël Mantione wrote:
Op Wed, 29 Jul 2009, schreef Desmond Coertzen:
This is my first question / suggestion: With byte sized variables
being the
smallest accessible variable in the PC architecture, will we see a
language
extension to
Vincent Snijders schrieb:
Vincent Snijders schreef:
Please, merge r13537, a fix for compiling for wince to the fixes_2_4
branch.
http://svn.freepascal.org/cgi-bin/viewvc.cgi?diff_format=lview=revrevision=13537
Reminder.
Done.
___
fpc-devel
Mattias Gaertner schrieb:
Has someone tested threads under windows 64bit W7_64bit ?
I can do so tonight.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Graeme Geldenhuys schrieb:
Hi,
How does the FPC developers manage the 2.3.x (up coming 2.4) branch? Is
it similar to the the Lazarus fixes branch, where fixes are applied to
trunk and then merged back into fixes branch.
Yes.
Or does it more often
have it's own development fixes which
Sergei Gorelkin schrieb:
So for me it seems a better idea to improve the existing writer rather
than making a new one. I cannot speak on behalf of the whole team,
however. Other opinions are welcome.
Well, consider you as as the xml maintainer so it's up to you :)
Nikolay Nikolov schrieb:
Thanks, applied in r13651, tested it on Ubuntu 9.04 with xterm,
gnome-terminal and konsole as well, works fine.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Just a remark: it is better to attach patches to bug reports, it
avoids that they are forgotten.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Mattias Gaertner schrieb:
On Thu, 10 Sep 2009 17:52:44 +0200
Florian Klaempfl flor...@freepascal.org wrote:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
Are there any other reasons for assigned
Martin Schreiber schrieb:
On Saturday 12 September 2009 12:14:07 Jonas Maebe wrote:
Or do you use this information only for display or code completion
purposes (so you always want the parameters in left-to-right order)?
In that case, I don't think that's possible with rtti.
:-(
Bad news
oc...@pocketmt.com schrieb:
Hello,
I'm trying embedded arm port (LPC2xxx) and I want to contribute to the
full port.
I'm adding new controllers right now. I just wanted to know, from compiler
side, what is the state of development? what need to be enhanced or
developed to have a full working
Michael V. Denisenko schrieb:
Hello everyone, is it possible to check my patch series?
Bugtracker link: http://bugs.freepascal.org/view.php?id=13700
All except the last one are applied (didn't review it yet)?
___
fpc-devel maillist -
oc...@pocketmt.com schrieb:
Ok. thanks Floran.
I was studying your files.
I'm working actually on the LPC2148. I'm porting the header file for
LPC214x (LPC2141/42/44/46/48), and I'm adding the mcus to the linker and
arm cpuinfo concerned units.
Once I got it to work to the 2148 I'll post
oc...@pocketmt.com schrieb:
Thank you Florian.
I'll publish all LPCxxx serie once I finish work on them.
Please publish work early if possible. It makes it easier to correct
wrong coding.
Just wanted to ask another question:
is there any support for interrupt procedures?
It is
601 - 700 of 1078 matches
Mail list logo
