On 04/09/11 19:44, Adriano dos Santos Fernandes wrote:
> On 09-04-2011 08:58, Vlad Khorsun wrote:
>>> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
Revision: 52693
http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev
Author: alexpeshkoff
On 04/10/11 15:47, Dmitry Yemanov wrote:
> All,
>
> While being on the subject, may I kindly ask everyone to *stop* naming
> the methods (especially public ones) as nouns and use verbs instead.
> Method names like version(), owner() etc drive me crazy. It gets
> especially "funny" when the form
Den 2011-04-11 09:19 skrev Alex Peshkoff såhär:
> I'm far not sure everything is so fine with that structure/class. Look here:
> unsigned
> blrLength;
>
> const unsigned char* blr;
> Pointer (8-bytes object) is placed after integer (4-bytes object). C
> language has a requirement to align
On 04/11/11 11:35, Kjell Rilbe wrote:
> Den 2011-04-11 09:19 skrev Alex Peshkoff såhär:
>> I'm far not sure everything is so fine with that structure/class. Look here:
>> unsigned
>> blrLength;
>>
>> const unsigned char* blr;
>> Pointer (8-bytes object) is placed after integer (4-bytes o
>> Btw, i see no problem curently. Alex made change but it is not means it
>> can't be undone if
>> necessary.
>>
> Ah, that's it. Every change I do, specially from you come this discurse
> of where the thing was discussed.
>
> But for others, no. It's just a commit that can be undone.
11.04.2011 11:19, Alex Peshkoff wrote:
> passing pointers to structures into interfaces is definitely wrong solution
We deal with pointers to XSQLDA in the public API for twenty years
without problems. I fail to see why interfaces are so much different in
this regard.
Dmitry
11.04.2011 10:44, Alex Peshkoff wrote:
> That's possible, I think. But not too good.
> The main disadvantage that this layout may probably differ for different
> hardware.
> And what - with every new port rewrite/review a piece of documentation?
I think that "#pragma pack(X)" in the header may
Den 2011-04-11 10:44 skrev Alex Peshkoff såhär:
> On 04/11/11 11:35, Kjell Rilbe wrote:
>> 2. If I'm not mistaken most languages support a "packed" directive that
>> tells the compiler to not align/pad the struct. Delphi does. But I doubt
>> it's possible to do the other way around: tell a compil
On 04/11/11 12:49, Dmitry Yemanov wrote:
> 11.04.2011 11:19, Alex Peshkoff wrote:
>
>> passing pointers to structures into interfaces is definitely wrong solution
> We deal with pointers to XSQLDA in the public API for twenty years
> without problems. I fail to see why interfaces are so much diff
On 04/11/11 13:32, Kjell Rilbe wrote:
> Den 2011-04-11 10:44 skrev Alex Peshkoff såhär:
>> On 04/11/11 11:35, Kjell Rilbe wrote:
>>> 2. If I'm not mistaken most languages support a "packed" directive that
>>> tells the compiler to not align/pad the struct. Delphi does. But I doubt
>>> it's possi
> PS Alex will explain you why "struct" or "class with data members" is
> bad for *portable* code.
Taking into an account Dmirty's sample with XSQLDA I must say that may
be not everything SO bad in this area. At least somehow it did work all
this time. What is problematic - how to add something t
11.04.2011 12:28, Alex Peshkoff wrote:
> Taking into an account Dmirty's sample with XSQLDA I must say that may
> be not everything SO bad in this area. At least somehow it did work all
> this time. What is problematic - how to add something to such structures?
Make it internal. The main problem
On 04/11/11 14:33, Dimitry Sibiryakov wrote:
> 11.04.2011 12:28, Alex Peshkoff wrote:
>> Taking into an account Dmirty's sample with XSQLDA I must say that may
>> be not everything SO bad in this area. At least somehow it did work all
>> this time. What is problematic - how to add something to suc
11.04.2011 12:49, Alex Peshkoff wrote:
> Dimitry, how is it related with internals of isc_db_handle?
> May be you mean some other structure?
No, this is exactly the structure I had on my mind along with isc_tr_handle,
isc_stmt_handle, etc. They all were pointers to structures before became
ar
On 04/11/11 15:21, Dimitry Sibiryakov wrote:
> You are talking about using structures (actually, pointers to them) in
> new API, right? Passing pointers to structure to interfaces doesn't mean that
> user has do
> work with these structures' members directly, AFAIU.
Certainly, one can safely p
11.04.2011 14:00, Alex Peshkoff wrote:
> On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>> You are talking about using structures (actually, pointers to them) in
>> new API, right? Passing pointers to structure to interfaces doesn't mean
>> that user has do
>> work with these structures' members d
Does Firebird use the page cache settings in the database (backup file)
during restore?
While trying to restore a large database on my developer pc, that has far
less resources than the production server the database normally runs on,
Firebird very quickly consumed all my physical memory,
> 11.04.2011 14:00, Alex Peshkoff wrote:
>> On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>>> You are talking about using structures (actually, pointers to them) in
>>> new API, right? Passing pointers to structure to interfaces doesn't mean
>>> that user has do
>>> work with these structures' me
> Does Firebird use the page cache settings in the database (backup file)
> during restore?
Yes. You can override it using appropriate gbak switch.
Regards,
Vlad
--
Xperia(TM) PLAY
It's a major breakthrough. An a
11.04.2011 14:31, Vlad Khorsun wrote:
>> 11.04.2011 14:00, Alex Peshkoff wrote:
>>>On 04/11/11 15:21, Dimitry Sibiryakov wrote:
>>> Certainly, one can safely pass any pointer to interface if it is only
>>> passed, no access to it's internals is attempted.
>>> The problem is that with mentioned
> But reading the discussions during last couple of weeks I see no reason why
> this API
> declaration would ever be ported into another language.
It is your fault then ;)
> It just don't have enough advantages over old ISC API.
With this new API many simple programs (like yours, f
11.04.2011 14:59, Vlad Khorsun wrote:
>> It just don't have enough advantages over old ISC API.
>
> With this new API many simple programs (like yours, for example) will be
> easy to write and require
> NO additional access layers.
Not quite so. "Easy to write" (for me) means "use well do
On 04/11/11 16:31, Vlad Khorsun wrote:
> We talk there about API *declarations*. API *declarations* ideally
> shouldn't have code else
> it will be hard to port it into another language. As for struct\interface
> choice :
>
> - struct should be as simple as possible to avoid problems with di
On 04/11/11 17:20, Dimitry Sibiryakov wrote:
> 11.04.2011 14:59, Vlad Khorsun wrote:
>>> It just don't have enough advantages over old ISC API.
>> With this new API many simple programs (like yours, for example) will
>> be easy to write and require
>> NO additional access layers.
>Not qu
> Yes. You can override it using appropriate gbak switch.
>
> Regards,
> Vlad
>
Thank you, that worked. I mistakenly took the -BU parameter as overriding
the default settings in firebird.config, not the specified settings in the
header page.
--
Mvh
Trond Dammen
-
> 11.04.2011 14:59, Vlad Khorsun wrote:
>>> It just don't have enough advantages over old ISC API.
>>
>> With this new API many simple programs (like yours, for example) will
>> be easy to write and require
>> NO additional access layers.
>
> Not quite so. "Easy to write" (for me) means "u
11.04.2011 15:38, Alex Peshkoff wrote:
> New features are much easier to implement using interfaces. For example,
> when we try to add namespaces to old XSQLDA (i.e. need to extend that
> structure), we have a lot of backward compatibility problems.
Nope. Enough to ignore data for which given v
On 04/11/11 17:57, Dimitry Sibiryakov wrote:
> 11.04.2011 15:38, Alex Peshkoff wrote:
>> New features are much easier to implement using interfaces. For example,
>> when we try to add namespaces to old XSQLDA (i.e. need to extend that
>> structure), we have a lot of backward compatibility problems
11.04.2011 15:44, Vlad Khorsun wrote:
>>Not quite so. "Easy to write" (for me) means "use well documented API
>> which has enough
>> examples of usage". Nothig from this is applied to the new API.
>
> Do you have completed API somewhere ? Where do you read that API is
> already completed
11.04.2011 16:04, Alex Peshkoff wrote:
> Dimitry, can you be more specific here? Telling true, inability to
> extend XSQLDA in backward compatible way was always obvious for everyone
> here.
I can't believe that nobody saw IB implementation. XSQLDA has field
"version" exactly
for that purpose
> 11.04.2011 15:44, Vlad Khorsun wrote:
>>>Not quite so. "Easy to write" (for me) means "use well documented API
>>> which has enough
>>> examples of usage". Nothig from this is applied to the new API.
>>
>> Do you have completed API somewhere ? Where do you read that API is
>> already c
11.04.2011 17:44, Vlad Khorsun wrote:
>> They can be implemented in an old API as well.
>
> So far i know no plans to extend XSQLDA.
I mentioned that a few times here and I still support extending XSQLDA
(to the extent it's still maintainable).
Dmitry
-
11.04.2011 18:04, Alex Peshkoff wrote:
> Telling true, inability to extend XSQLDA in backward compatible
> way was always obvious for everyone here.
Only partially true. It's designed to be backward compatible and I don't
see why it cannot work. The only major problem there is the fixed size
of
>>> They can be implemented in an old API as well.
>>
>> So far i know no plans to extend XSQLDA.
>
> I mentioned that a few times here and I still support extending XSQLDA
> (to the extent it's still maintainable).
Then i leave to you a "pleasure" to answer on DS questions. It is enough
fo
11.04.2011 18:18, Dimitry Sibiryakov wrote:
> Look at _already implemented_ API extension - fb_ping() and point me to it's
> description in doc/ folder, please. None.
FWIW, it's not a part of the public API. This symbol is not exported.
Dmitry
--
11.04.2011 16:52, Vlad Khorsun wrote:
> Did you noted descriptions of much more important new API's, such as
> fb_shutdown ?
What is it important for? Or, may be, you mean fb_cancel_operation(), not
fb_shutdown()?..
> Where are your ticket at the tracker, btw ?
Solve CORE-3382
11.04.2011 14:23, Alex Peshkoff wrote:
> Dmitry, just please recall - how many times we said: sorry, this feature
> requires XSQLDA modification, this is serious API change, we will not do
> it this time.
Because we never wanted to change the public API in a big way (causing
serious adjustments
11.04.2011 17:12, Dmitry Yemanov wrote:
> 11.04.2011 18:18, Dimitry Sibiryakov wrote:
>
>> Look at _already implemented_ API extension - fb_ping() and point me to it's
>> description in doc/ folder, please. None.
>
> FWIW, it's not a part of the public API. This symbol is not exported.
What doe
11.04.2011 19:11, Vlad Khorsun wrote:
They can be implemented in an old API as well.
>>>
>>> So far i know no plans to extend XSQLDA.
>>
>> I mentioned that a few times here and I still support extending XSQLDA
>> (to the extent it's still maintainable).
>
> Then i leave to you a "pleasure" t
11.04.2011 19:24, Dimitry Sibiryakov wrote:
> What does it do in ibase.h then?
It contains entrypoints public from the subsystem POV, but it's "hidden"
using the linkage (made server only). So it's not supported outside the
server, it's not delivered over the wire and thus it's not exported.
I
On 11-04-2011 04:19, Alex Peshkoff wrote:
> On 04/09/11 19:44, Adriano dos Santos Fernandes wrote:
>> On 09-04-2011 08:58, Vlad Khorsun wrote:
On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote:
> Revision: 52693
> http://firebird.svn.sourceforge.net/firebird/?rev
On 11-04-2011 07:28, Alex Peshkoff wrote:
>
>> PS Alex will explain you why "struct" or "class with data members" is
>> bad for *portable* code.
>
> Taking into an account Dmirty's sample with XSQLDA I must say that may
> be not everything SO bad in this area. At least somehow it did work all
> t
On 11-04-2011 12:09, Dmitry Yemanov wrote:
> 11.04.2011 18:04, Alex Peshkoff wrote:
>
>> Telling true, inability to extend XSQLDA in backward compatible
>> way was always obvious for everyone here.
>
> Only partially true. It's designed to be backward compatible and I don't
> see why it cannot w
On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 07:28, Alex Peshkoff wrote:
>>> PS Alex will explain you why "struct" or "class with data members" is
>>> bad for *portable* code.
>> Taking into an account Dmirty's sample with XSQLDA I must say that may
>> be not everything S
On 11-04-2011 13:15, Alex Peshkoff wrote:
> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
>> On 11-04-2011 07:28, Alex Peshkoff wrote:
PS Alex will explain you why "struct" or "class with data members" is
bad for *portable* code.
>>> Taking into an account Dmirty's sample with X
On 04/11/11 19:20, Dmitry Yemanov wrote:
>> I can agree that reasonably designed structure can be made safe when
>> used in API. I can even suppose that it can be used from all actively
>> used programming languages. But when you need to add something to it -
>> you have problems.
> I'd say it's a
On 04/11/11 20:19, Adriano dos Santos Fernandes wrote:
> On 11-04-2011 13:15, Alex Peshkoff wrote:
>> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
>>> On 11-04-2011 07:28, Alex Peshkoff wrote:
> PS Alex will explain you why "struct" or "class with data members" is
> bad for *por
11.04.2011 20:04, Adriano dos Santos Fernandes wrote:
> Extending XSQLDA/XSQLVAR is like going backto SQLDA/SQLVAR. Plain ugly.
Luckily, it's not absolutely required in many cases. As you know, the
whole SQLDA stuff is a [supposedly] user-friendly wrapper for the
sql_info() call. We may easily
On 11-04-2011 13:25, Alex Peshkoff wrote:
> On 04/11/11 20:19, Adriano dos Santos Fernandes wrote:
>> On 11-04-2011 13:15, Alex Peshkoff wrote:
>>> On 04/11/11 19:53, Adriano dos Santos Fernandes wrote:
On 11-04-2011 07:28, Alex Peshkoff wrote:
>> PS Alex will explain you why "struct" or
Read and write null mask into external tables
-
Key: CORE-3438
URL: http://tracker.firebirdsql.org/browse/CORE-3438
Project: Firebird Core
Issue Type: Improvement
Reporter: Dimitry Sibi
Don't include trainling non-null fields into null mask
--
Key: CORE-3437
URL: http://tracker.firebirdsql.org/browse/CORE-3437
Project: Firebird Core
Issue Type: Improvement
Compon
All,
Usage of namespaces in our code is very ugly, as we divide things in
main-level namespaces.
In headers, we have lot of "Firebird::". They're specially ugly in this
type of usage:
Firebird::Pair > >
With make almost "obligatory" to create extra typedefs.
I suggest we fix namespace usages in
> -Original Message-
> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
> Sent: Lunes, 11 de Abril de 2011 18:10
>
> Usage of namespaces in our code is very ugly, as we divide things in
> main-level namespaces.
>
> In headers, we have lot of "Firebird::". They're specially
On 11-04-2011 20:23, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
>> Sent: Lunes, 11 de Abril de 2011 18:10
>>
>> Usage of namespaces in our code is very ugly, as we divide things in
>> main-level namespaces.
>>
>> In
>Yes, it can. It stores first 4 (on linux 6) arguments in registers, the
>rest are stored on stack using cdecl conventions.
I must say, there is a difference in treatment of the stack between Windows
and Linux systems. Windows not only passes the first 4 parameters in
registers but ALWAYS allocate
55 matches
Mail list logo
