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
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:
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 ...
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
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
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
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
Sergei Gorelkin schrieb:
Thanks, applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
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
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
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:
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
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
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
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
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
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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:
Hello again,
We are seeing more and more hacks being applied to projects trying
to scramble around the missing FPC feature - no built-in Unicode
supporting.
A simple example in Lazarus Loading a UTF-8 encoded file into a TMemo.
Normally you would write code as
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 :=
Alexander Klenin schrieb:
On Mon, Nov 17, 2008 at 05:39, Florian Klaempfl [EMAIL PROTECTED] wrote:
No, just look at the actual assignment:
i:=v;
By const/reference it generates 5 instructions, by value only 4. The rest is
entry code. If you've only one access, passing by reference might have
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that does
not make difference using constant parameters or not for double types.
So is
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that
does not make
Luiz Americo Pereira Camara schrieb:
Jonas Maebe escreveu:
On 16 Nov 2008, at 14:52, Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
Maybe the documentation
(http://www.freepascal.org/docs-html/ref/refsu50.html#x126-13300011.4.4)
can be modified to clarify this since
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size is 4.
Don't forget that this makes an extra memory access.
I
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization
Michael Schnell schrieb:
I set no special options in FPC
Lazarus does.
and I don't use WideString at all.
UTF-8 fits perfectly in the standard String type.
Some conversions are correct or seem to be correct in that case.
It has been already pointed out several times that lazarus
Graeme Geldenhuys schrieb:
On Tue, Nov 11, 2008 at 6:21 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Some conversions are correct or seem to be correct in that case.
It has been already pointed out several times that lazarus abuses the
anstring type to store utf-8 and this breaks several
Sergei Gorelkin schrieb:
Hello,
The attached patch fixes two opcodes generated by i386 internal assembler.
The first one fixes the mov ax, word ptr [somevar] command which was
generated without $66 prefix (reported by freepascal.ru forum user,
don't know if it is in bugtracker).
The second
Dmitry Lizorkin schrieb:
I agree, no real life need.
Except probably for my 150 students to whom i can no longer recommend
FPC as a reference implementation.
Hopefully they won't be schocked when being hit by another real world
programming language implementing mod like it is implemented in
Michael Schnell schrieb:
If you want to have good multicore scaling you are lost with OpenMP.
As I said, that is my POV, too.
I did not start this discussion for preaching for OpenMP. In fact I know
close to nothing about it. My starting point were the rather poor
results for FPC in the
Michael Schnell schrieb:
You still didn't show any example which shows the real power of parallel
which cannot be solved by a T(Pooled)Thread.Create and
T(Pooled)Thread.WaitFor statements.
As I said several times, I don't suggest that any other implementation
(be it OpenMP or whatever)
Thaddy schrieb:
I consider parallel as syntactic sugar:
- the same effect can be achived by some thread classes
- it gives the compiler no opportunity to generate better code
- the use cases are limited, it is nothing being used hundred of times
in a typical program
- it solves none of the real
Felipe Monteiro de Carvalho schrieb:
On Tue, Nov 4, 2008 at 8:10 AM, Marco van de Voort [EMAIL PROTECTED] wrote:
Well, I gave up PIC24 since they don't contain motorcontrol,
I've always wanted to know what does a microcontroller with
motorcontrol is supposed to do different from a normal
Michael Schnell schrieb:
Moving things in the language without a notable advantage which can be
solved by a library is not a good thing.
Don't you think ease of use _is_ a notable advantage of a programming
language ?
It is. But as pointed out, parallel does not solve any of the
Michael Schnell schrieb:
Maybe it would be good to first start the OpenMP library part - a unit
providing some functions to easily use light weight threads.
I just read that as of v4.2, GNU C supports OpenMP by language
constructs (seemingly preprocessor directives). When looking at the
Michael Schnell schrieb:
I don't see how Mandelbrot requires OpenMP. One can easily launch n
threads depending on the number of the available cores.
(We are discussing this in the German Lazarus Forum right now...)
I feel that OpenMP is never _required_ to optimize a problem, but just
Daniël Mantione schrieb:
Op Mon, 3 Nov 2008, schreef Florian Klaempfl:
Michael Schnell schrieb:
IMHO any technology that enables FPC to compile a loop like (using
Oxygen syntax):
for parallel i := 0 to 10 do begin
a[i] := a[i] + b[i];
end;
in a way that it on a multicore processor
Michael Schnell schrieb:
IMHO any technology that enables FPC to compile a loop like (using
Oxygen syntax):
for parallel i := 0 to 10 do begin
a[i] := a[i] + b[i];
end;
in a way that it on a multicore processor runs as fast as the
appropriate GNU C construct:
#pragma ocm_parallel
Michael Schnell schrieb:
For a big vector operation the number of used threads should be
adapted to the memory architecture,
With the C #pragma opm_ this can be done statically by the
programmer using the schedule keyword, defining chunks (there seem
to be more sophisticated ways
401 - 500 of 1078 matches
Mail list logo