Am Wednesday 15 August 2012 19:58:02 schrieb Marco van de Voort:
> No. The route was this:
>
> - In an earlier msg I mentioned this as dxgettext limitation (since I ran
> into it)
> - In a later msg you said you got weary of dxgettext because of "problems"
>with it.
> - I replied that it was n
I do not think a solution is required for the components.
Yes, you cannot set the location in the OI, but I do not think
this is needed in the first place, see the use case at the beginning.
We differ there. If it was easier to set the library file name we probably
wouldn't have all these
Hi,
On 16 August 2012 04:31, Marco van de Voort wrote:
>
> It's not a FPC problem, it is a linux problem that apps are not
> crossdistribution distributable.
My applications ARE all cross-dirstro capable. And they are damn good
at running on new and old distros. eg: I have compiled an fpGUI app
> And IMHO this all reeks of that. (dll name in component).
> Sounds "easy", but it doesn't really solve anything.
>
Making it easier for the programmer to specify the library he wants will put
a halt on "this discussion returning in some way or the other every 6-9
months". What is recurring in
On Thu, 16 Aug 2012, Marco van de Voort wrote:
If dynamic linking is so great, why do we constant, constantly have these
discussions and worse all these illadvised changes?
Because the problem is not in dynamic versus static.
We would have exactly the same discussions if they were staticall
Hi,
On 16 August 2012 04:39, Marco van de Voort wrote:
>
> Change in naming, (either root (gds->fbclient) or version numbers)
For God's sake!!! The gds -> fbclient was a once off deal after
Interbase was released to the open-source world and shortly thereafter
retracted that decision. The open s
In our previous episode, Ludo Brands said:
> Making it easier for the programmer to specify the library he wants will put
> a halt on "this discussion returning in some way or the other every 6-9
> months". What is recurring in these discussions also is the non- or
> badly-documented ibase60dyn.ini
On 15/08/2012 16:05, Rainer Stratmann wrote:
> Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol:
>>> If the maintainers decide to build in the suggested function above then
>>> everthing is solved. By now no one of the maintainers wants this.
>>
>> I can understand why, more or less - thi
Hi,
On 16 August 2012 08:50, Michael Van Canneyt wrote:
> The list is endless. So yes, dynamically loading is a good thing.
Indeed. I much rather prefer dynamic linking.
> So, what is the problem, and what started the whole discussion: the FPC team
> (i.e. us) simply chose a poor default for t
Ludo Brands wrote:
And IMHO this all reeks of that. (dll name in component).
Sounds "easy", but it doesn't really solve anything.
Making it easier for the programmer to specify the library he wants will put
a halt on "this discussion returning in some way or the other every 6-9
months". What
>
> We differ only in the implementation of the 'easier way':
>
> I meant that I do not see the advantage of writing something like
>
> With Inifile do
> begin
>
> IBConnection1.LibraryName:=ReadString('Connection','libraryNam
> e','fbclient.dll');
> end
>
> over
>With IniFil
Lukasz Sokol wrote:
Please explain.
I do not change the code. I am only searching some pointers.
Well, yeah, _you_ don't. What if somebody else could create a program that
extracts
private (unexported) function pointers from executables and be able to redirect
entire code paths. Oh wait. thi
Am Thursday 16 August 2012 10:16:04 schrieb Lukasz Sokol:
> On 15/08/2012 16:05, Rainer Stratmann wrote:
> > Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol:
> >>> If the maintainers decide to build in the suggested function above then
> >>> everthing is solved. By now no one of the maint
Can somebody explain Xcode-installtion?
Last version of free pascal is 2.6 and working with Xcode 3.2.6.
Meanwhile last Xcode version is 4.4.1. Version 4.1 was installed with new
folder "Developer" and folder of version 3.2.6 was redefined to
"Developer-(null)".
Since version 4.3.3 Xcode is inst
On Thu, 16 Aug 2012, Ludo Brands wrote:
Unfortunately your example illustrates nicely the difference.
InitializeInterbase is unknown in the fpc I'm using. InitialiseIBase60 does
exist but you have to add the non-trivial ibase60dyn to the uses clause to
get to it (Google has 146 hits for "Initi
On 16-8-2012 10:57, Rainer Stratmann wrote:
> Am Thursday 16 August 2012 10:16:04 schrieb Lukasz Sokol:
>> On 15/08/2012 16:05, Rainer Stratmann wrote:
>>> Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol:
> If the maintainers decide to build in the suggested function above then
>
Franz wrote on Wed, 15 Aug 2012:
Since version 4.3.3 Xcode is installed only as application in folder
applications. Some folders are apparent in content of application
but distinguishing in substance with folder developer.
Will or until when will free pascal developed for earlier version of
Am Thursday 16 August 2012 10:50:25 schrieb Mark Morgan Lloyd:
> Lukasz Sokol wrote:
> >> Please explain.
> >> I do not change the code. I am only searching some pointers.
> >
> > Well, yeah, _you_ don't. What if somebody else could create a program
> > that extracts private (unexported) function p
Am Thursday 16 August 2012 11:27:08 schrieb Rainer Stratmann:
> Customers are fully satisfied and know about my fast responce.
response
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
In our previous episode, Ludo Brands said:
>
> Unfortunately your example illustrates nicely the difference.
> InitializeInterbase is unknown in the fpc I'm using. InitialiseIBase60 does
> exist but you have to add the non-trivial ibase60dyn to the uses clause to
> get to it (Google has 146 hits f
> Remains the fact that I think that - no matter what the other
> component sets do
> - the library name should NOT be a connection component
> property, unless you
> allow each connection to use a different library. Since that
> is not possible
> with the current *dyn units, the property sho
I still dont understand why dont you hack passrc and grab all the
strings from the source ?
You can even replace them with identifiers and do all the resource
string mumbo jumbo automatically if you write a app to do this based
on passrc...
Actually, why theres no such tool included with freepasc
> > Unfortunately your example illustrates nicely the difference.
> > InitializeInterbase is unknown in the fpc I'm using.
> InitialiseIBase60
> > does exist but you have to add the non-trivial ibase60dyn
> to the uses
> > clause to get to it (Google has 146 hits for
> "InitialiseIBase60", no
Am Thursday 16 August 2012 12:23:00 schrieb Jorge Aldo G. de F. Junior:
> I still dont understand why dont you hack passrc and grab all the
> strings from the source ?
Because I have an almost finished solution. I worked already for a while on
it. Some integrated piece of code is easier to handle
Al 16/08/2012 9:50, En/na Michael Van Canneyt ha escrit:
On Thu, 16 Aug 2012, Marco van de Voort wrote:
If dynamic linking is so great, why do we constant, constantly have these
discussions and worse all these illadvised changes?
Because the problem is not in dynamic versus static.
We woul
If passrc changes, so can ABI and whatever else method you use change too...
If i was going to start a project now with multilanguage suport i
would search for a existing solution or start a new project based on
passrc.
I dont see how can searching for strings be so hard, you dont even
need a ful
On 16/08/2012 10:27, Rainer Stratmann wrote:
> Am Thursday 16 August 2012 10:50:25 schrieb Mark Morgan Lloyd:
[...]
> Please note that it works perfect.
> There can be more of those comments, making a bad mood.
> But that does not affect that this is working perfect.
> I further don't seen the need
Am Thursday 16 August 2012 13:24:01 schrieb Jorge Aldo G. de F. Junior:
> If passrc changes, so can ABI and whatever else method you use change
> too...
>
> If i was going to start a project now with multilanguage suport i
> would search for a existing solution or start a new project based on
> pas
On Thu, 16 Aug 2012, Luca Olivetti wrote:
Al 16/08/2012 9:50, En/na Michael Van Canneyt ha escrit:
On Thu, 16 Aug 2012, Marco van de Voort wrote:
If dynamic linking is so great, why do we constant, constantly have these
discussions and worse all these illadvised changes?
Because the pro
Am Thursday 16 August 2012 13:27:17 schrieb Lukasz Sokol:
> So from this POV, his process /is/ easier: he runs his program, and tells
> it to export strings to be translated, then loads 'snippets' on demand/on
> next execution.
Yes.
> To Rainer: Please accept apologies, I did not mean to offend
On Thu, 16 Aug 2012, Ludo Brands wrote:
But if people want a point-and-click interface, we can always
make a new component: TSQLDBLibraryLoader or so. With a
property for the library name of each supported DB, so we
need only 1 component.
I understand you prefer the perfect solution instea
Am Thursday 16 August 2012 13:53:18 schrieb Michael Van Canneyt:
> And let's not forget: if we choose a reasonable default library name,
> 99% of all problems fall away by themselves, and the component will
> not be needed in the first place; Just for special cases will you need it.
I did not foll
In our previous episode, Ludo Brands said:
> > > of TIBConnection, non of these difficulties would exist.
> >
> > Documentation is a different story.
>
> It is a different story but an integral part of this particular problem. Why
> else has the "solution" to be spelled out everytime the problem
In our previous episode, Luca Olivetti said:
> >> If dynamic linking is so great, why do we constant, constantly have these
> >> discussions and worse all these illadvised changes?
> >
> > Because the problem is not in dynamic versus static.
> >
> > We would have exactly the same discussions if the
In our previous episode, Rainer Stratmann said:
> > And let's not forget: if we choose a reasonable default library name,
> > 99% of all problems fall away by themselves, and the component will
> > not be needed in the first place; Just for special cases will you need it.
>
> I did not follow the
> Well, first of all, I don't think something needs to be
> changed in the first place :)
>
> So, if we must do something extra anyway, then I prefer it to be the
> correct solution, and not a shortcut.
>
And that is how also this attempt to improve sqldb grinds to a halt ...
Ludo
__
Is anybody else receiving mailformed emails from the list?
I've received several, most or all from Marco, with all with most of the
headers appearing as text since there is an extra blank line between the
X-Mailer header and the previous ones.
On Thu, 16 Aug 2012 14:29:15 +0200 (CEST)
wrote:
Am Thursday 16 August 2012 14:53:05 schrieb microc...@zoho.com:
> Is anybody else receiving mailformed emails from the list?
>
> I've received several, most or all from Marco, with all with most of the
> headers appearing as text since there is an extra blank line between the
> X-Mailer header and
In our previous episode, microc...@zoho.com said:
> Is anybody else receiving mailformed emails from the list?
>
> I've received several, most or all from Marco, with all with most of the
> headers appearing as text since there is an extra blank line between the
> X-Mailer header and the previous
On Thu, 16 Aug 2012, Ludo Brands wrote:
Well, first of all, I don't think something needs to be
changed in the first place :)
So, if we must do something extra anyway, then I prefer it to be the
correct solution, and not a shortcut.
And that is how also this attempt to improve sqldb grinds
On Thu, 16 Aug 2012, Marco van de Voort wrote:
In our previous episode, Ludo Brands said:
of TIBConnection, non of these difficulties would exist.
If drastic changes (like postponing header initialization till larger parts
of the LCL are in the air) must be made, I rather fix all issues.
microc...@zoho.com wrote:
Is anybody else receiving mailformed emails from the list?
I've received several, most or all from Marco, with all with most of the
headers appearing as text since there is an extra blank line between the
X-Mailer header and the previous ones.
On Thu, 16 Aug 2012 14
On 16/08/12 13:53, microc...@zoho.com wrote:
> Is anybody else receiving mailformed emails from the list?
The only weirdness I get is Ludo's subject header. The subject of the
first message in the thread was:
[fpc-pascal] linux: should we hard-code versioned or unversioned shared
libraries in o
> > It is a different story but an integral part of this particular
> > problem. Why else has the "solution" to be spelled out
> everytime the
> > problem pops up? You'll say people don't make the effort to
> read old
> > messages. But in this thread alone you'll find a
> "InitializeInterbase
Henry Vermaak wrote:
On 16/08/12 13:53, microc...@zoho.com wrote:
Is anybody else receiving mailformed emails from the list?
The only weirdness I get is Ludo's subject header. The subject of the
first message in the thread was:
[fpc-pascal] linux: should we hard-code versioned or unversioned
In our previous episode, Michael Van Canneyt said:
> > In our previous episode, Ludo Brands said:
> of TIBConnection, non of these difficulties would exist.
> >>>
> >
> > If drastic changes (like postponing header initialization till larger parts
> > of the LCL are in the air) must be made, I
> Why do you say that?
>
> It's not because I personally think that no extra solution is needed,
> that I am oblivious to the problems of users.
>
> We'll solve the problem, thereby improving sqldb.
> I will implement it myself next week:
>
> * Change default library names to make more sense.
On Thu, 16 Aug 2012, Ludo Brands wrote:
Why do you say that?
It's not because I personally think that no extra solution is needed,
that I am oblivious to the problems of users.
We'll solve the problem, thereby improving sqldb.
I will implement it myself next week:
* Change default library n
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org
> [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
> de Henry Vermaak
> Envoyé : jeudi 16 août 2012 15:28
> À : FPC-Pascal users discussions
> Objet : Re: [fpc-pascal] Malformed email messages
>
>
> On 16/
> > I'm glad to see I was mistaken in interpreting the way this
> discussion
> > was going. Probably seen too many other discussions and initiatives
> > that end up nowhere.
>
> Tatata. Don't sell the bearskin before the bear has been shot.
>
> You can be glad when I actually commit the soluti
On Thu, Aug 16, 2012 at 01:15:09PM +, Mark Morgan Lloyd wrote:
> microc...@zoho.com wrote:
> >Is anybody else receiving mailformed emails from the list?
> >
> >I've received several, most or all from Marco, with all with most of the
> >headers appearing as text since there is an extra blank lin
Hi Michael,
On 16 August 2012 14:11, Michael Van Canneyt wrote:
> We'll solve the problem, thereby improving sqldb. I will implement it myself
> next week:
>
> * Change default library names to make more sense.
> * Implement library loader for cases where the default library
> name is not the c
Hi,
On 16 August 2012 14:39, Marco van de Voort wrote:
>
> Then changing the simple default to libfbclient.so.2 is a problem for
> designtime, since designtime code doesn't even have the emergency
> initializeibase60 workarounds as option. Lazarus will also start to look for
> .2.
I thought this
Am 16.08.2012 15:28, schrieb Henry Vermaak:
On 16/08/12 13:53, microc...@zoho.com wrote:
Is anybody else receiving mailformed emails from the list?
The only weirdness I get is Ludo's subject header. The subject of the
first message in the thread was:
[fpc-pascal] linux: should we hard-code v
microc...@zoho.com wrote:
I note that the headers you quote include a few X- headers that I
don't see here:
X-Virus-Scanned: ClamAV using ClamSMTP
X-BeenThere: fpc-pascal@lists.freepascal.org
X-Mailman-Version: 2.1.5
X-Virus-Scanned: ClamAV using ClamSMTP
Well spotted. I don't know if zoho i
On Thu, Aug 16, 2012 at 03:20:15PM +, Mark Morgan Lloyd wrote:
> microc...@zoho.com wrote:
>
> >>I note that the headers you quote include a few X- headers that I
> >>don't see here:
> >>
> >>>X-Virus-Scanned: ClamAV using ClamSMTP
> >>>X-BeenThere: fpc-pascal@lists.freepascal.org
> >>>X-Mailm
On Thu, 16 Aug 2012, Graeme Geldenhuys wrote:
Hi Michael,
On 16 August 2012 14:11, Michael Van Canneyt wrote:
We'll solve the problem, thereby improving sqldb. I will implement it myself
next week:
* Change default library names to make more sense.
* Implement library loader for cases wher
On 16 Aug 2012, at 18:11, Michael Van Canneyt wrote:
> My plan (for linux) was:
> Search fbclient.so search fbclient.so.2 (2.x series of firebird)
> search fbclient.so.1 (1.x series of Firebird) if the library name has not
> been specified.
fbclient.so should not be searched. It could point to
On 16 August 2012 17:33, Jonas Maebe wrote:
>> My plan (for linux) was:
>> Search fbclient.so search fbclient.so.2 (2.x series of firebird)
>> search fbclient.so.1 (1.x series of Firebird) if the library name has not
>> been specified.
>
> fbclient.so should not be searched. It could point to any
Hi,
On 16 August 2012 15:49, Sven Barth wrote:
> The missing spaces where a topic some time ago already on one of the fpc or
> lazarus lists... I don't know what the outcome was though. AFAIK Graeme was
> the one who pointed it out that time.
I'm using Gmail (forced to plain/text) for years
On Thu, 16 Aug 2012, Graeme Geldenhuys wrote:
On 16 August 2012 17:33, Jonas Maebe wrote:
My plan (for linux) was:
Search fbclient.so search fbclient.so.2 (2.x series of firebird)
search fbclient.so.1 (1.x series of Firebird) if the library name has not been
specified.
fbclient.so should
In our previous episode, Jonas Maebe said:
> > My plan (for linux) was:
> > Search fbclient.so search fbclient.so.2 (2.x series of firebird)
> > search fbclient.so.1 (1.x series of Firebird) if the library name has not
> > been specified.
>
> fbclient.so should not be searched. It could point to
On 16 Aug 2012, at 20:59, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
>>> My plan (for linux) was:
>>> Search fbclient.so search fbclient.so.2 (2.x series of firebird)
>>> search fbclient.so.1 (1.x series of Firebird) if the library name has not
>>> been specified.
>>
> If someone knows the correct version numbers for the various
> postgres and mysql libs,
> that would be appreciated.
>
libpq.so.3 pg 7.3 7.4
libpq.so.4 pg 8.0 8.1
libpq.so.5 pg >= 8.2.4
libmysqlclient.so.13mysql 4.0
libmysqlclient.so.14mysql 4.1
libmysqlclient.so.15mysql 5.0
On Thu, 16 Aug 2012, Ludo Brands wrote:
If someone knows the correct version numbers for the various
postgres and mysql libs,
that would be appreciated.
libpq.so.3 pg 7.3 7.4
libpq.so.4 pg 8.0 8.1
libpq.so.5 pg >= 8.2.4
libmysqlclient.so.13mysql 4.0
libmysqlclient.so.14mysql 4
On 16 August 2012 18:41, Michael Van Canneyt wrote:
> Potential trouble ? After we have been loading it for the past 10 years ?
> Let's not get carried away...
I simply meant Firebird DB v3 has been in development for ages so
could be released around the corner. It will be a major version
change,
On 16-8-2012 23:05, Graeme Geldenhuys wrote:
> On 16 August 2012 18:41, Michael Van Canneyt
> wrote:
>> Potential trouble ? After we have been loading it for the past 10 years ?
>> Let's not get carried away...
>
> I simply meant Firebird DB v3 has been in development for ages so
> could be rele
Hi Reinier,
On 16 August 2012 22:25, Reinier Olislagers wrote:
> Presumably the sqldb would be changed for the v3 library then?
Yes, but that will only be in Trunk, and could take up to a year
before the next FPC "stable" release. I only deploy my commercial apps
with stable FPC releases. In the
On 16-8-2012 23:41, Graeme Geldenhuys wrote:
> Hi Reinier,
>
> On 16 August 2012 22:25, Reinier Olislagers
> wrote:
>> Presumably the sqldb would be changed for the v3 library then?
>
> Yes, but that will only be in Trunk, and could take up to a year
> before the next FPC "stable" release. I on
On Thursday 16 August 2012 18:11:34 Michael Van Canneyt wrote:
>
> My plan (for linux) was:
> Search fbclient.so
> search fbclient.so.2 (2.x series of firebird)
> search fbclient.so.1 (1.x series of Firebird)
> if the library name has not been specified.
>
MSEgui searches for the *.so as last optio
My plan (for linux) was:
Search fbclient.so search fbclient.so.2 (2.x series of firebird)
search fbclient.so.1 (1.x series of Firebird) if the library name has
not been specified.
So in near future we will add also fbclient.so.3 (for incomming Firebird
3) ?
BTW: packages/ibase is intended t
71 matches
Mail list logo
