On 23/06/13 20:56, Florian Klämpfl wrote:
>
> So they support now native development on MacOS X as well?
No, all development is still ONLY done under Windows. You cross compile
to OS X and iOS. You also remote debug to OS X and iOS.
I still think forcing a Windows licence for somebody that wants
On 20/06/13 22:41, Michael Ring wrote:
> Doing crosscompiles and remotedebugging will add a level of complexity
> that will not justify the better performance of lazarus when using it on
> the 'real' linux box.
It doesn't need to be!
Having tested Delphi XE4 recently with iOS and MacOSX develop
On 2013-06-02 02:44, waldo kitty wrote:
> so maybe svn "blame" will tell when it was put in and by whom?
commit 7aa20ac1cc61578db56a9de741f306f07a35460c
Author: Florian Klaempfl
Date: Sat Apr 16 14:01:44 2011 +
* Merged helper branch made by Sven Barth
-- Zusammenführen der Unters
Hi,
http://bugs.freepascal.org/view.php?id=7833
Could somebody double test my results in the above bug report (see my
comments there). As far as I can see the report isn't a bug any more.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@list
On 2013-03-25 09:18, Sven Barth wrote:
> I don't know whether it's an approbiate alternative for this purpose,
> but: http://wiki.freepascal.org/ZMSQL
Thanks for the link. tiOPF can also be used for storing data in CSV, TAB
or XML, and you use it exactly like you do for a RDBMS. But the more
impo
On 2013-03-24 13:06, Michael Van Canneyt wrote:
> I am extremely surprised to see it marked 'deprecated'.
Same here! I love using DBF for demos because I don't need any database
server or 3rd party DLL/SO files etc. It is also one of very few
database systems that can be fully compiled into a [sma
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3
lines for the actual message. Keep up the good work.
Netiquette?
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2013-03-05 13:02, Sven Barth wrote:
>>
> Two words: backwards compatibility.
To Turbo Pascal yes (ie: tp mode), but surely not ObjFPC?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
_
On 2013-03-05 17:09, waldo kitty wrote:
>
> on another system i work with, we use disk-based breadcrumb semaphore files
> for
> the different stages and parts of those stages...
Thanks for you input. It sounds similar to what I was planning. Simply
create an empty file in /tmp when each indepen
On 2013-03-05 15:24, Marcos Douglas wrote:
>
> Why follow the Delphi even knowing that is the wrong way to implement
> something?
Because like the FPC team have said a million times to me because
they follow Delphi blindly, and WILL do everything to stay "delphi
compatible".
Good thing is,
On 2013-03-05 10:31, Henry Vermaak wrote:
>
> Ah, I remember that fpmake can build with multiple threads, so perhaps
> this is a better solution than to do it with make. I'll investigate.
I've got that option enabled by default for building FPC 2.7.1 and it
does shave off a few seconds.
I'm als
Hi,
I find it extremely hard to follow conversations in this mailing list
lately. Everybody seems to disregard simple netiquette guidelines here.
For example: I can't read a message thread any more by just using my
up/down arrow keys [jumping from one reply to the next]. I have to
constantly scro
On 2013-03-05 09:12, Michael Van Canneyt wrote:
> You may think that Delphi is the best thing since sliced bread,
> but not everyone thinks so.
>
> There are several people on the list that do not like what Delphi is doing to
> the pascal language.
+1000
I think Embarcadero is butchering the Obj
On 2013-03-04 20:33, Howard Page-Clark wrote:
>
> You can simulate this in FPC as well as TP by using a local typed
> constant. e.g.
>
> function GetValue: integer;
> const value: integer = 0;
> begin
>Inc(value);
>Result:= value;
> end;
I've seen this before, and always been baffled b
On 2013-03-04 15:53, Sven Barth wrote:
> Then I'll commit my changes :)
Thanks for your efforts Sven.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2013-03-04 12:44, Sven Barth wrote:
> that really contain class helpers). Maybe we can add an additional
> "has_operators" flag and ignore all units when searching for overloads
> that don't have this flag set (the flag would propagate from the
See, so Martin posting performance results afte
Thanks for taking the time with your detailed explanation.
Regards,
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2013-03-04 13:05, Michael Van Canneyt wrote:
>
> And the first to use anonymous functions in FPC distributed code,
> I will personally make him eat his keyboard. Without pepper and salt.
Thank you!! :)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pasca
On 2013-03-04 11:17, Martin wrote:
>
> I added:
> - the name "Bar"
> - Used is at reference
> - the keyword "closure"
>
> The above code would then create the exact same closure, as your code
> does. And it does not need an anonymous method.
+1
Much better solution, an in my opinion, much e
On 2013-03-04 10:27, Michael Schnell wrote:
>
> It does make sense to allow for a kind of class that does not need to
> reside on the heap and, (residing on the stack or global space)
And that is exactly what the Object type [already] does... and was
introduced into the language in Turbo Pascal
On 2013-03-04 01:16, Marcos Douglas wrote:
>
> I know. I just used the last mail on this thread -- in that case, your
> mail. Sorry.
You should know better, and to never use any of my replies for something
like that. I have no patience or sense of humour. ;-)
> Yes, I agree... but I feel a "fi
On 2013-03-04 04:54, Boian Mitov wrote:
> In this case, not only you save declaration, you save the need to write a
> whole new class just for the task.
All my code live in classes already, so I would simply have benefited by
having a properly defined method. Then pass the method pointer to the
A
On 2013-03-04 09:24, Marco van de Voort wrote:
>
> In Delphi, synchronization primitives like queue() and synchronize() have
> been adapted to work with them, so they are actually more used than some
> other new features.
Sure, just like Delphi implemented Advanced Records, when the Object
type a
On 2013-03-04 03:59, Alexander Klenin wrote:
>
> Because computer science is advancing, and there is a limit after which
> programming language can not ignore those advancements and stay relevant.
Sure, I understand that. I just haven't seen an example that explains
why it is needed. Kind of why
On 2013-03-04 01:47, Boian Mitov wrote:
> vast improvements of the code and the readability.
They are unreadable to me.
> I recently started
> rewriting our libraries with anonymous methods and that alone allowed for
> cutting over 2 lines of code
Just my dropping method names? I doubt tha
On 2013-03-02 19:03, vrt277 wrote:
>
> I want to implement support of Delphi anonymous methods for fpc.
Just curious... why must such a feature be allowed in Object Pascal?
Referring to the recent "butchering of the Object Pascal language"
thread we had recently in fpc-pascal.
It was clearly st
On 2013-03-03 23:21, Marcos Douglas wrote:
>
> Sad. Instead of "fight", why not walking together?
I'm not joining any "fight", simply wanted to know what the 'm' stood for.
> I do not know nothing about compilers, but I know the Florian Klämpfl
> will do nothing about you're saying because do y
On 2013-03-03 19:47, Florian Klämpfl wrote:
>
> First 10 m of a marathon done.
Is that 'miles' or 'meters'? ;-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel ma
On 2013-03-02 10:28, Michael Van Canneyt wrote:
> We can say for sure that the fact you use .pas as filename extension
> will cause FPC to do twice the number of stat() calls, because .pp is
> searched first...Logical therefore that the IO is slower.
Second time I hear this this week. Can we (i
On 2013-02-12 08:48, Mark Morgan Lloyd wrote:
>
> There's a vast number of factors that you're underreporting. For
> example, the underlying VM system could detect which OS is running as a
> guest, and behave differently. Or the OS could reconfigure the CPU and
> ... snip...
That should normall
On 2013-02-11 18:24, Sven Barth wrote:
>
> AFAIK the optimizations are CPU specific, not OS specific.
That is what I expected too.
> guessing here) that the FreeBSD release was created with different
> optimizer settings than the Linux one (regarding the RTL and packages).
Both FPC 2.6.0 inst
On 2013-02-11 19:11, Sven Barth wrote:
>
> I would say the "No of tests" is the number of different test functions
> that have been invoked (all within one single test program).
Correct. The first four sets are the same persistence tests, but against
different persistence backends (CSV, TAB, var
On 2013-02-11 19:03, Mark Morgan Lloyd wrote:
>>
>> No of tests | Type of Tests | Linux | FreeBSD
>> -+-++
>> 151| CSV persistence |0:22|0:27
>> -+-++
>>
Hi,
I'm not sure how it works, but does FPC compiler optimizations for the
amd64 (x86_64) CPU's get shared across various OSes?
eg: I've read various reviews that FreeBSD benchmarks often perform
better than the same benchmarks run on Linux. It was even shown that
FreeBSD runs Linux executable fa
On 2013-02-07 17:55, Flávio Etrusco wrote:
>
> Not if you want high performance and multi-processor support.
I'll prefer _working_ code to start. Currently semaphores are broken in
FPC+FreeBSD. My implementation at least works everywhere I have tested -
without hacks or jumping through loops.
R
On 2013-02-06 19:24, Graeme Geldenhuys wrote:
> Semaphore functionality seems pretty simple though, so I am thinking of
> creating my own Object Pascal based cross-platform semaphore - no low
> level code or OS specific library API's.
Progress... It was rather simple so far. I creat
Hi Jonas,
Interesting, there is no mention of those limitations in the FPC 2.6.0
documentation. I looked in the RTL docs. It this is a concern, it is
something that should be mentioned in the docs.
Do you know more specifically what platforms or CPU's are affected, so
Michael could update the doc
On 2013-02-07 09:13, Sven Barth wrote:
> But the ifdefs will only be in one location.
I understand that, but there will be IFDEF's none the less. As I said, I
hate IFDEF's in application/library code. They have their place in FPC
source code, but I don't like them anywhere else. That's just me.
Thanks Ewald. What you described is exactly what I started, and had in
mind. Thanks for your feedback.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist - fp
On 2013-02-06 20:17, Sven Barth wrote:
>
> If you just define your own semaphore class that contains the platform
> specific types and lock and unlock methods then you only need to add an
> additional "array[0..4] of Longint" after the "sem_t" field for FreeBSD.
> Then you should be okay.
Yes tha
On 2013-02-06 20:10, Sven Barth wrote:
>
> We don't have semaphores yet in SyncObjs.
Correct. FPC's SyncObjs unit has quite a few missing features compared
to Delphi.
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform G
Hi,
OK, now that we established that semaphores are broken in FreeBSD using
FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative.
An alternative for two reasons.
- I hate IFDEF code, and the semaphore code between Linux, FreeBSD
and Windows are different.
- Semaphore sem_t
On 2013-02-04 12:22, Sven Barth wrote:
> I have an idea. But for this I'd need some confirmation: Can you please
> put in your example program the FSemaphore into a record and add also a
> ...
OK, attached is the new test project. Below is the output.
Now the FMaxPoolSize variable still has the
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is similar code used in tiOPF.
For some reason under FreeBSD, it *always* zeros the variable that holds
the Max Pool Size value passed in to sem_init()'s third parameter. This
means that
On 2013-02-03 18:29, Sven Barth wrote:
>
> Why? The variant with the TYPEDADDRESS should work for the other *nix
> targets as well...
Sorry, I replied to Marco before I tried your solution. Your solution
works. Thanks.
Regards,
- Graeme -
___
fp
On 2013-02-03 18:10, Sven Barth wrote:
>
> I personally still think there is a bug, because the compiler should (in
> my opinion) not consider "sem_init(@sem)" a valid usage of "sem_init(var
> sem: sem_t)"...
+1
> I you look at the POSIX definition at
> http://pubs.opengroup.org/onlinepubs/0
On 2013-02-03 18:08, Marco van de Voort wrote:
>
> The resulting overloading can cause problems. It can be reduced by
> deprecating the original pascallized versions, and removing them in some
> future version.
So at this current point in time, my only solution is to have code as
follows in tiOPF
On 2013-02-03 12:28, Sven Barth wrote:
>
> I personally think that the fpc-pascal list was the more approbiate, but
> nevertheless: your problem comes down to this code (in principal):
I thinking was that this problem seems to point towards a bug, or at
least inconsistency between defined types
Hi,
I initially posted this in the fpc-pascal list, but I think fpc-devel is
maybe more appropriate, because the pthreads include files might need
amendment.
I'm trying to get tiOPF to compile under FreeBSD. It works under Linux
and Windows without problems.
I got compiler errors using FPC 2.6.
On 01/30/13 02:22, Michalis Kamburelis wrote:
> Do not use a final backslash, like
>
>make install INSTALL_PREFIX=c:\fpc\2.6.1
Ah, that did the trick. Thank you for your help.
Side Note:
That also highlights how fragile the build system is, but that is
another issue.
Regards,
- Graeme -
Hi,
I'm using a Win2000, and have a released FPC 2.6.0 installed. I updated
my FPC 2.6.1 to r23533 (latest revision to date). I run by usual
build.bat script (shown below). FPC, RTL and FCL seems to compile fine,
but the 'make install ...' seems to fail. I've never had such issues
before. It seems
On 01/28/13 13:20, Michael Van Canneyt wrote:
>
> tatata, you should always understand everything :)
:-)
> Since you can do the same with simple named methods too,
> I see no need for creating the readibility horror that results of it.
Yup. I have also seen sample Delphi code where they used
On 01/25/13 17:17, Alexander Klenin wrote:
>> Using indicies is against all principles of iterators.
> I am not sure what princilpes you are talking about,
The theory. Read any Design Patterns book or technical papers.
> but accessing the key of the current element is required quite often
On th
On 01/25/13 08:07, Michael Van Canneyt wrote:
> If he wants to help, Alexander Klenin had better put his students to useful
> tasks.
>
> There are plenty to choose from.
> He said maybe he'd look after fcl-stl. The silence since was deafening.
> He said he needed a arbitrary precision math libra
On 01/25/13 08:07, Michael Van Canneyt wrote:
> Delphi 7 object pascal could be learned very easily. Nowadays with all the
> "features" added
> you go, try and explain pascal to someone. Say it is 'nice and readable'.
+1
Generics, for-in loops, anonymous methods, classes defined inside
classes e
On 01/28/13 11:49, Marco van de Voort wrote:
>
> There is a MAINTAINER field in every ports makefile? acm@
Ah got it, thanks Marco.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
On 01/28/13 11:45, Marco van de Voort wrote:
>
> The TAR installer and afaik the port should add this line to the config
> already,
I installed the stable FPC from the TAR installer, then installed the
"fixes" version from the repository. All done as a normal user, not root.
> But building fpc
Hi,
Who is the FreeBSD ports maintainer for FPC?
There are some grammar errors in the pkg-message.in (final instructions
after a make) file. I thought I would notify the ports maintainer of that.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fp
On 01/27/13 15:35, Leonardo M. Ramé wrote:
>>
>> Pass -Fl/usr/local/lib in OPT=""
>>
>
> Thanks Marco, that did the trick!.
I had a similar problem for X11 apps recently. I simply modified my
~/.fpc.cfg file and specified -Fl/usr/local/lib inside there. Solved my
problem without too much fuss, a
On 01/25/13 10:51, Michael Schnell wrote:
>
> A decent smart "indexer" class with appropriate enumerator/iterator-like
> compiler-magic syntax might help until then and is a lot nicer than the
> old-fashioned myString[i] notation anyway, on top of being compatible
> with any future string imple
On 01/25/13 10:40, Michael Schnell wrote:
> The real world in fact does not need computers.
Huh?
G.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 01/25/13 10:22, Michael Schnell wrote:
> and replacing the term myString[n] by a
> straight forward function searching for the n'th printable character
> will be very slow.
And I am yet to see a real-world example where this is needed. ALL
examples I have seen, the developer was already busy
On 01/25/13 00:11, Alexander Klenin wrote:
> Do I understand correctly that you are speaking about this article:
> http://opensoft.homeip.net/articles/iterator_pattern.pdf ?
Yes.
> As far as I understand, since iterators described in the article do
> not have the concept of a current item,
The c
On 01/24/13 23:38, Graeme Geldenhuys wrote:
>
> Do you want examples of Iterator classes?
> ...
>
> If that is what you are talking about, I can email you a copy.
I forgot it was already publicly available. See the Iterator article and
the accompanied source code.
http://open
On 01/24/13 23:26, Alexander Klenin wrote:
If you want full fledged iterators, use classes.
>>>
>>> Please provide example of your suggestion for the case in the wiki.
>>
>> I don't need to provide *anything*.
>
> Of course you do not, this is why I said "please" :)
> However, it is impossibl
On 01/24/13 19:36, Alexander Klenin wrote:
>> Enumerators are not iterators.
> Eh... actually, they are? Why do you think otherwise?
Enumerators are limited in functionality. Iterators are the full-blown
thing. Common Iterator API is something like Next, Prev, Reset, HasNext,
HasPrev etc. Enumerat
On 01/07/13 11:02, Michael Schnell wrote:
>>
> Lets see what Embarcadero comes up with
I wouldn't hold my breath. Based on recent Embarcadero history, the
first version would be absolute crap, second version might be beta
quality, 3rd version might not even exist (removed from product).
Reg
On 27/12/12 22:06, Ewald wrote:
> and an Intel i7, and works correctly. If someone would be so kind to
> test it on some other CPU's that would be great!
It gives correct result (8 cores) on my Intel i7-3770K CPU with
HyperThreading enabled in the BIOS.
Regards,
- Graeme -
--
fpGUI Toolkit
On 24/12/12 11:22, Martin wrote:
>
> half-width spaces etc..., control chars (RTL/LTR...), currently unused
> codepoints (that could become anything in future...)
As Marco said, the list will be smaller than the "allowed list".
Also the Unicode specification defines blocks or categories for cod
On 23/12/12 10:13, Michael Van Canneyt wrote:
>
> ? No, the old RTL will remain maintained. It's the same codebase, just
> recompiled.
It was impossible to deduce that from your earlier reply
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27659.html
With the new information a
On 22/12/12 16:43, Marco van de Voort wrote:
> I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
> I don't think direction on unicode (or even general) came up since the last
> unicode discussions o
On 21/12/12 17:16, Florian Klämpfl wrote:
>
> The mission goal of FPC is: develop an open source pascal compiler
> written in pascal in a community effort.
You forgot the last bit "and be Delphi compatible!"
> Maybe people should indeed first work on the compiler instead of
> developing ano
On 21/12/12 16:46, Mark Morgan Lloyd wrote:
>
> Cutting out a whole lot of crap: as somebody very much on the periphery
> of the project, I'm disappointed to see sentiments of this tenor being
> aired in public.
Mark, much of what happens with the FPC project seems to be done in
secrecy, or a p
On 22/12/12 10:34, Martin Schreiber wrote:
>>
> Please note that the message has not been posted to the list by me.
My apologies Martin. I should have taken your questions and rephrased
them in a list form. To save time, I simply obfuscated the names -
probably not the best idea. The names where n
On 21/12/12 12:26, Michael Van Canneyt wrote:
>
> We know what to do. What we lack, is time.
>
> Status currently:
Thanks for the update. Most of what you mentioned was unknown to any
person outside the FPC core team. So to us outsiders, it seems like
progress has halted.
Regards,
- Graeme
On 21/12/12 10:15, Michael Van Canneyt wrote:
>
> It would be good to keep those facts in mind before ranting.
I was simply bringing some of those questions (which I had too) to
light. Unicode has been "under development" for many years, and has come
to a halt - with no final decisions being made
On 18/12/12 13:26, Marco van de Voort wrote:
>
> They could deliver ppu's and .o's.
True, but widely untested. As a previous conversation from a few month
back ended... it should work in theory.
Also Lazarus Packages are designed to work with source only. There is no
option to install .ppu's an
On 18/12/12 12:19, Michael Schnell wrote:
>
> IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus,
> as adding a source package and recompiling does the trick just as well.
Tell that to component developers and companies like Devx, TMS etc! With
the current way things work, the
On 17/12/12 15:29, Sven Barth wrote:
> I predict that we'll reach a point in
> the near(!) future where we won't (be able to) follow Delphi's lead
> anymore.
And what a good day that will be. FPC will can innovate again. Delphi
hasn't been leading for years, and Embarcadero is milking a dead co
On 17/12/12 13:06, Hans-Peter Diettrich wrote:
>
> We should wait for and explore how the multi-target Delphi handles that.
Probably not even implemented, because Delphi IDE is Windows only - and
there are no plans to make a cross-platform IDE by Embarcadero.
Regards,
- Graeme -
--
fpGUI To
Hi,
Any FPC developer willing to comment on the status of some of these
issues (that have been years overdue)?
Original Message
Subject: Re: [MSEide-MSEgui-talk] MSEide+MSEgui 2.8.4
Date: Mon, 17 Dec 2012 08:57:15 +0100
From: John Doe 1 <>
To: mseide-msegui-t...@lists.sourc
Hello luiz,
Thursday, November 29, 2012, 9:39:36 PM, you wrote:
> In the message of the example observer:
It seems Gmail searching has failed me. Thanks for fulfilling my
curiosity.
As for my comment. It was purely a suggestion (for convenience). My
personal preference is still to
Hello luiz,
Thursday, November 29, 2012, 12:31:41 PM, you wrote:
> BTW: Graeme already pointed, that the Observer methods should be
> public. Does not makes sense to protect methods that are exposed by an
> interface.
When did I say that? [Though my memory has been failing me once or
twice.
On 2012-11-29 12:10, michael.vancann...@wisa.be wrote:
>
> The primary reason of existence for TFPList and TFPObjectList is speed and
> minimal overhead.
OK, I understand now.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net
Hi Luiz,
First off, thanks for take the trouble it creating test projects.
On 2012-11-29 02:59, luiz americo pereira camara wrote:
>
> Test1
> As is today, if you have a reference to a IFPObserver is not possible
> to use it to attach to, e.g., child objects. This occurs because AFAIK
> you can
On 2012-11-28 15:25, luiz americo pereira camara wrote:
> if an architeture works in a scenario does not mean it's good or at
> least could not be improved.
I'm not disputing that either. It just seems that Michael and I have
been using observers in production code for many years. The FPC design
i
On 2012-11-28 15:02, luiz americo pereira camara wrote:
>
> Given that better discuss / test / change such important change
> earlier than later, nothing stops to treat this release as a beta (or
> whatever name is appropriate) even if was formally released as a RC.
[Not related to the issue in
Hi,
I tested the attached program under Delphi 7 and FPC 2.6.0 and FPC 2.7.1
(dated 2012-11-15).
The test application tests two things:
1) Interface delegation via another class
2) Overriding a interface implementation using method resolution
Under Delphi 7 the test application compiles and
On 2012-11-27 16:19, Michael Van Canneyt wrote:
>
> The consequence is that you must pass around the objects themselves.
I'm curious to see Luiz's code example of what issues he has, but in the
mean time, maybe it wouldn't be such a bad idea to update (with latest
FPC changes and Observer suppor
On 2012-11-28 10:07, Graeme Geldenhuys wrote:
>
> You can add a CORBA interface to any existing class, and it doesn't need
> to descend from TInterfacedObject either. CORBA is not COM interfaces.
>
In case anybody is in doubt. Here is a small example where CORBA
interface
On 2012-11-28 09:41, Marco van de Voort wrote:
>
> You often can't reroot external components, but if they support tcomponent
> (and thus Tinterfacedobject), you can add an interface in a child class.
You can add a CORBA interface to any existing class, and it doesn't need
to descend from TInter
On 2012-11-28 08:23, Vincent Snijders wrote:
> production code already uses it, then the production code writers must
> have taken a risk for change knowing that this was a not yet released
> feature.
+1
I thought it was a known fact that if you use FPC Trunk in production
code, you stand a very
On 2012-11-27 17:17, Leonardo M. Ramé wrote:
>
> Hi, does anyone know of a link to the wiki with info about the newly
> implemented Observer pattern?.
>
No wiki page, but I did submit in the mailing list and Mantis a observer
demo with code comments to show how it works and how to use it.
h
On 2012-11-22 23:34, Giuliano Colla wrote:
> Thanks, but I managed to install. I just wanted to point out that those
> incompatibilities may frighten or discourage a new user.
I do agree with what you said - all valid points. I would also like to
point out that FPC (not sure about Lazarus) is av
On 25/10/12 00:55, luiz americo pereira camara wrote:
> - Initially i questioned the fpc obsever support, now i see as a good
> implementation
The FPC Observer and Mediator is based on works found in the tiOPF
framework - done a few years ago. And that in turn was based on a
implementation I done
On 2012-10-24 10:01, Marco van de Voort wrote:
>
> I can still unmerge the observer functionality from fixes/2.6.2. Then (1) is
> also still a possibility.
Please don't!
I've been waiting years for that in FPC, and am actively building work
based on that functionality.
G.
__
On 2012-10-24 09:59, michael.vancann...@wisa.be wrote:
>
> in the classes (!) unit, makes me shudder, though.
>
> How anyone can create such a convoluted system is beyond me.
Yup. [shaking my head in disbelief]
Delphi is going the way of the dodo.
Regards,
- Graeme -
On 2012-10-24 07:52, michael.vancann...@wisa.be wrote:
> However, given the total lack of documentation, it is hard to say.
+1
I had a look too, the Embarcadero website isn't much help.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@list
On 2012-09-27 19:16, Florian Klämpfl wrote:
>
> You care about Delphi compatibility?
:) I was waiting for that. I care about coding not having IFDEF yes - so
it stays readable. tiOPF is the only project I work on that is a shared
code base.
Graeme.
__
On 2012-09-27 17:52, Marcos Douglas wrote:
>
> I agree that is much simpler... but why nobody, in another language,
> do the same? Does not worth it? I do not know.
Well, other languages have there own quirks like case sensitive
identifiers. Thank God, Object Pascal doesn't have that.
Just imagi
1 - 100 of 1762 matches
Mail list logo
