Hi!
Our ALTER PACKAGE always destroys the package body, i.e., routines not
listed in the new package, BLR of listed routines, and the package body
source.
This request as is is not appropriate for me, but I tend to agree it's
bad to lose the package body source.
But if we maintain it and
On 05/08/2014 08:20, Alex Peshkoff wrote:
As the result we get language-neutral compiler-independent ABI, with an
ability to generate a kind of headers for any language, with a machine
generated code to catch exceptions into status vector and raise them
from it (if language supports
On 06/08/2014 06:48, Alex Peshkoff wrote:
On 08/05/14 16:11, Adriano dos Santos Fernandes wrote:
On 05/08/2014 08:20, Alex Peshkoff wrote:
As the result we get language-neutral compiler-independent ABI, with an
ability to generate a kind of headers for any language, with a machine
generated
On 06/08/2014 09:04, Dimitry Sibiryakov wrote:
06.08.2014 13:55, Alex Peshkoff wrote:
As a side effect we have to have LocalStatus class in public header,
suppose it's not too big problem.
Unfortunately it is because LocalStatus requires whole FB memory manager
to be compiled.
On 06/08/2014 09:15, Dimitry Sibiryakov wrote:
06.08.2014 14:06, Alex Peshkoff wrote:
I would suggest for IStatus following methods:
int check() - returns 0 if status is empty, 1 if has warnings and 2 if has
errors
char* getText() - return fully interpreted text
ICode*
On 06/08/2014 08:48, Alex Peshkoff wrote:
, but I see a more big problem.
The implementation rely on method shadowing.
So if I have
Impl : Interface
{
void method1()
{
method2();
}
method2()
{
}
}
and
ImplSpecialization : Impl// Not
Alex and All,
Based on Alex code, I did some changes (attached) to support:
- Avoid runtime crash if a method is missed in an implementation
- Avoid need to manually initialize the vTable
- Avoid preprocessor tricks
- Inheritance from implementations
The cost? Very low IMO.
You need to use an
On 07/08/2014 10:24, Alex Peshkoff wrote:
I can agree with your arguments provided you demonstrate a real world
sample where we need to inherit the implementation of interface. The
problem is that surprisingly named methods will be present always, but
need in implementation inheritance is
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
- Automatic version check (done only when necessary)
- Marks (TODO) for C/C++ exception integration
With this versioning scheme, IVersioned will die, but I maintained it
for the demo.
As we don't rely on C++
On 08/08/2014 08:52, Jim Starkey wrote:
So, if I understand your original goals, again as an outsider, I would have
to say that your current interface proposal does not meet them. Each step in
the progression may have seen logical, but the end result is not.
I'm resisting to reply to you
On 08/08/2014 07:45, Alex Peshkoff wrote:
On 08/07/14 20:44, Adriano dos Santos Fernandes wrote:
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
- Automatic version check (done only when necessary)
From code I see that it takes place on every invocation
On 08/08/2014 14:19, Dimitry Sibiryakov wrote:
08.08.2014 18:47, Adriano dos Santos Fernandes wrote:
It works provided that who called the method that returned the new
object was compiled together (or with the same API version) of who is
calling the object method. In most of cases I'd imagine
On 08/08/2014 16:13, Dimitry Sibiryakov wrote:
In contrast, last Alex/me solution does not add memory and performance
problems (each call is a single virtual call) with a check (indirect
access) for upgrade when a function returns a new object.
Individual function table in every object
here.
Adriano
On 08/08/2014 16:45, Dimitry Sibiryakov wrote:
08.08.2014 21:32, Adriano dos Santos Fernandes wrote:
Where you see individual tables and every-time initialization (you said
this before)?
Do you know about static?
No. I am a Delphi programmer, you know, I never seen
On 08-08-2014 17:30, Dimitry Sibiryakov wrote:
08.08.2014 21:59, Adriano dos Santos Fernandes wrote:
This is happening just because someone found the current implementation
to not work in FreePascal.
Actually, this is happening just because someone though about C++ only...
Firebird
Someone told abstract Delphi classes was compatible with the C++ vtable,
but FPC wasn't.
I did some tests and detected that FPC class with or without virtual
methods has a pointer in its start.
From this pointer, however, the vtable is not compatible with C++.
But we can autogenerate classes
On 10-08-2014 07:15, Dimitry Sibiryakov wrote:
10.08.2014 12:04, Dmitry Yemanov wrote:
However, apparently FB devs don't think it's important to keep it in
sync with the C++ interface - even if third parties could submit patches
for that.
So in effect, new FB (features) will not be
On 10-08-2014 12:45, Dimitry Sibiryakov wrote:
10.08.2014 17:41, Adriano dos Santos Fernandes wrote:
And none of this are passed from your library to Firebird, i.e.,
plugins, external routines.
When will you start to separate application API and plugin API?..
I do not see any sane
On 10-08-2014 05:30, Dimitry Sibiryakov wrote:
10.08.2014 10:20, Dimitry Sibiryakov wrote:
they are QueryInterface, AddRef, releaseRef.
Oops, I was too quick. Here are details:
http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12
On 10-08-2014 13:20, Dimitry Sibiryakov wrote:
10.08.2014 18:07, Adriano dos Santos Fernandes wrote:
What I'm actually saying is that inserting a dummy entry in instances
and vtable, we make free for use our objects in the languages who uses
such layout with variations.
You can insert
On 10-08-2014 15:29, Jim Starkey wrote:
It has been pointed out that the client and plugin APIs are used by different
types of developers for different purposes. You didn't respond, so it's hard
to know whether you disagreed, didn't understand the point, or just didn't
care.
There is no
On 11/08/2014 05:43, Alex Peshkoff wrote:
Technical issues can, in fact, be discussed with more depth than +1. In
fact, everything in engineering is a tradeoff, and tradeoffs can be
reasonably balanced and discussed. But dismissing something that you don't
agree with as abstract bullshit
On 11/08/2014 06:04, Kjell Rilbe wrote:
Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär:
10.08.2014 13:55, Reinier Olislagers wrote:
However, apparently FB devs don't think it's important to keep it in
sync with the C++ interface - even if third parties could submit patches
for that.
So in
On 11/08/2014 06:25, Molnár Attila wrote:
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
He's totally wrong on this!
Adriano
On 11/08/2014 09:45, Alex Peshkoff wrote:
On 08/08/14 20:47, Adriano dos Santos Fernandes wrote:
At least I have time to answer tech question. What a luck!
Sure.
Automatic vtable upgrade is ok for me, provided we have a trust-able and
reliable way to add them.
Attached a demo
On 11/08/2014 11:18, Jim Starkey wrote:
Since plugins pretty much need to be compiled with the same compiler as the
engine,
Hum??
and since both COM objects and their clients will be compiled from the
machine generated interface defintion headers, there is no danger of
incompatibilities
On 11/08/2014 11:49, Adriano dos Santos Fernandes wrote:
COM is full of problems:
Also, the our-IDL compiler may generate COM (complex) wrapper code for
our interfaces (simple).
Doesn't this kill the argument to use something that does not really fit
well as an internal API?
Then if Delphi
Another requirement not yet mentioned for C++ users, are exceptions.
While we can easily just convert IStatus to Exception, if Exception is a
FB class, not even derived from std::exception, it may be completely
inappropriate for users applications.
You know, each C++ project has its own
On 11/08/2014 14:51, Dimitry Sibiryakov wrote:
11.08.2014 19:29, Adriano dos Santos Fernandes wrote:
Another requirement not yet mentioned for C++ users, are exceptions.
Worth reading before jumping in:
http://tdm-gcc.tdragon.net/quirks
https://gcc.gnu.org/wiki/WindowsGCCImprovements
On 11/08/2014 15:00, Dimitry Sibiryakov wrote:
11.08.2014 19:55, Adriano dos Santos Fernandes wrote:
What's your point?
No exception is allowed to cross alien boundaries. Only modules built with
the same
compiler can throw and catch exceptions. Such modules has no problems you
On 11/08/2014 15:29, Tom Coleman wrote:
I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
There is never any case where I would want to see std:exception.
Could it be time to start thinking about burying this idea that is looking
more and more like a sacred cow?
On 11/08/2014 16:03, Dmitry Yemanov wrote:
We either forget about exceptions completely, or throw some partially
abstract class (thus forcing users to implement the exception before
being able to compile), or maybe go for the policies you described.
That said, I'd rather resolve the other
On 11/08/2014 16:19, Dimitry Sibiryakov wrote:
11.08.2014 21:13, Adriano dos Santos Fernandes wrote:
An integrated approach (who throws from IStatus, catchs and set IStatus)
is very welcome.
I would suggest a very simple approach: push IStatus out of engine, just
throw
exceptions
On 11/08/2014 16:37, Dimitry Sibiryakov wrote:
11.08.2014 21:28, Adriano dos Santos Fernandes wrote:
No. Providers and plugins should work when compiled by different
compilers and being in different libraries!
That's why border guards must stay between engine and plugins. As well
On 11/08/2014 16:57, Tom Coleman wrote:
On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
You may be more interested in why something failed than just that it failed.
An error mechanism should play nicely with the status vector to expose as
much -- or as little as the user needs. Sometimes
On 12/08/2014 14:59, Dimitry Sibiryakov wrote:
12.08.2014 19:54, Adriano dos Santos Fernandes wrote:
Later I'll improve it for C and FPC and put in my github.
Don't forget about Java and C#.
I'll not forget, if I want to do.
Adriano
On 12/08/2014 16:17, Mark Rotteveel wrote:
Am I correct to understand, that in the C API isc_dsql_prepare_m will
allow me to specify the database information items to request together
with the statement prepare, allowing me to circumvent the allocation and
handling of XSQLDA, and instead
On 12/08/2014 17:01, Mark Rotteveel wrote:
On 12-8-2014 21:24, Adriano dos Santos Fernandes wrote:
On 12/08/2014 16:17, Mark Rotteveel wrote:
Am I correct to understand, that in the C API isc_dsql_prepare_m will
allow me to specify the database information items to request together
On 13/08/2014 05:23, Mark Rotteveel wrote:
On Tue, 12 Aug 2014 23:48:57 +0200, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
12.08.2014 22:06, Adriano dos Santos Fernandes wrote:
Non-_m (who uses SQLDA) methods are wrappers for the _m methods.
Not anymore. *_m methods are limited to 64k
On 13/08/2014 07:04, Alex Peshkoff wrote:
On 08/12/14 21:54, Adriano dos Santos Fernandes wrote:
On 12/08/2014 14:37, Mark Rotteveel wrote:
On 12-8-2014 18:48, Tom Coleman wrote:
One bias of mine that I will confess to is that I hate C++. Every
time I am forced to use it it turns out
On 13/08/2014 09:15, Alex Peshkoff wrote:
Already done. Implementation of objects uses virtual functions and
dispatchers dispatches directly to them, without additional cost, via
obj-Name::method().
Can you send it to me?
I'll do as soon as I have the generator working a bit better.
Adriano
On 13/08/2014 13:25, Dimitry Sibiryakov wrote:
13.08.2014 13:24, Alex Peshkoff wrote:
What do you think about adding different styles of C++ code generation?
First of all I think about support of smart pointers.
Can your IDL generate current interface with pure abstract classes as
well?..
On 13/08/2014 16:22, Tom Coleman wrote:
Understanding maybe, but I'm not sure you can say the same for Agreement.
And excuse me, but you may not have to support either interface in the future
if the current users die off waiting for a FB3 release.
AFAIK, Firebird 3 is at Alpha 2, which
On 13/08/2014 16:39, Jim Starkey wrote:
You are now quite close to COM. The primary difference is that COM is based
on immutable interfaces and you have a single squishy interface with explicit
interface version. After a few iterations, developers with have to track
what versions had
On 13-08-2014 18:03, Tom Coleman wrote:
AFAIK, Firebird 3 is at Alpha 2, which snapshots almost always available.
This discussion was actually started internally.
You all think alpha versions and snapshots are there for what?
It's not there for we developers, certainly.
Download
On 14/08/2014 08:28, Dimitry Sibiryakov wrote:
14.08.2014 11:34, Alex Peshkoff wrote:
HP C/aC++ Version A.06.26
Alpha version?..
PS: The problem with FPC which started whole this topic seems to be a
compiler's bug which destroy value returning by external function.
Testcase is attached.
On 14/08/2014 11:04, Tony Whyman wrote:
master := IMaster(GetMaster());
The program now does complete without an error, but returns 15 as the
version. My reading of the Firebird code is that the correct result is
4. So still something not right - probably the way the instance variable
is
On 15/08/2014 13:39, Dimitry Sibiryakov wrote:
Wouldn't be endless checking annoying?..
It looks like in the past days, that's one of the things we were
discussing, no?
Adriano
--
Firebird-Devel mailing list,
On 15/08/2014 13:45, Dimitry Sibiryakov wrote:
15.08.2014 18:43, Adriano dos Santos Fernandes wrote:
It looks like in the past days, that's one of the things we were
discussing, no?
Yes, and you insisted on autoupgrade. That's why the example must be fixed.
It can be automatically fixed
On 15/08/2014 13:49, Dimitry Sibiryakov wrote:
15.08.2014 18:47, Adriano dos Santos Fernandes wrote:
It can be automatically fixed if/when the new C++ code is placed.
Will you generate call of master-upgradeInterface() in every method that
return an
interface?
Only if its version (field
On 15/08/2014 14:05, Dimitry Sibiryakov wrote:
15.08.2014 18:58, Adriano dos Santos Fernandes wrote:
On 15/08/2014 13:49, Dimitry Sibiryakov wrote:
15.08.2014 18:47, Adriano dos Santos Fernandes wrote:
It can be automatically fixed if/when the new C++ code is placed.
Will you generate
Hi!
I put in my github account the first version of cloop - Cross Language
Object Oriented Programming.
- https://github.com/asfernandes/cloop
This first version is limited to void and int datatypes, supports C, C++
and Free Pascal, and the makefile works only in POSIX.
Some files in
On 31-08-2014 12:06, Geoff Worboys wrote:
I'd like to argue that developers have already had years to
find a better solution than deleting the source, but really the
only better solution is UDR, and developers need significant
time to migrate. So if you want projects to stay current, you
On 01/09/2014 11:14, Jim Starkey wrote:
No, that's not even close to true. If the only fields encypted were the
procedure and trigger source blobs, nothing would be inaccessible without the
key except those blobs.
Obviously you disagree. Please explain your logic.
Source text is (may
On 01/09/2014 12:31, Dimitry Sibiryakov wrote:
01.09.2014 17:10, Dimitry Sibiryakov wrote:
These vendors are too lazy to convert their PSQL routines into UDRs.
BTW, Adriano had no problem with IDL - C++/FPC translation. I'm sure he
can make PSQL
- C++/FPC translator as well to offer
On 02/09/2014 02:42, Dmitry Yemanov wrote:
Agreed wholeheartedly. The point was that it restores exactly what was
possible prior to v3 without compromising the system tables protection
and that it's easy (if not easiest) to implement. I didn't pretent it
looking elegant.
Not only the
On 02/09/2014 11:35, Dimitry Sibiryakov wrote:
Hi, All.
When was decided that one-line blocks must not be enclosed with
parentheses? It is a
rather dangerous style...
It's not, it was not and it will never be a dangerous style.
Everything is dangerous if you write code without
On 02/09/2014 12:05, Dimitry Sibiryakov wrote:
02.09.2014 17:00, James Starkey wrote:
Mandatory indentation makes it clear.
No. With tabstop == 4, it is placed exactly under if's condition,
pretending to be
condition's continuation:
if (some condition
some other
On 02/09/2014 07:09, Jiří Činčura wrote:
Hi,
If I do similar to '[a-z\_-]' escape '\' I got a error about invalid
pattern. The - is causing problems. Surprisingly doing '[a-z-\_]' is fine
and also '[a-z-]' is fine. Testing the first regex on various parsers it
worked. Why it doesn't work
On 24/09/2014 12:33, Tom Coleman wrote:
Apologies for sounding like a broken record.
Apologies not accepted from me!
You still not said in how manner (money, tests, *useful* comments) you
are contributing to this release.
Adriano
0x40 = 64, you're basically sayg c = 64, why do you think it should not
be converted to '64' ?
Looks like you mean x'40', that's a different thing.
Adriano
On 26/09/2014 12:54, Martijn Tonies (Upscene Productions) wrote:
Hi all,
I’ve got this following problem and example:
SET TERM ^^ ;
On 02/10/2014 17:26, Thomas Steinmaurer wrote:
Hello,
I'm using the build mentioned in the subject, 32-bit, on Windows 7 64-bit.
I have the following sequence of created domains in isql:
SQL create domain d_mydomain bigint;
SQL commit;
SQL create domain d_mydomain_1 bigint;
SQL commit;
On 03/10/2014 11:50, Adriano dos Santos Fernandes wrote:
Is it required to have the others object before to make this happen?
I tested with the objects you created and they're created correctly.
Also, the select query was run in ISQL or other tool?
I'm asking because some fbstuff tests
On 03/10/2014 12:37, Dmitry Yemanov wrote:
03.10.2014 19:19, Adriano dos Santos Fernandes wrote:
I'm asking because some fbstuff tests started failing. Some time ago,
message buffers were cleared when the field was null, but now they seems
to not be cleared when connected over tcp. It seems
On 08/10/2014 07:34, Martijn Tonies (Upscene Productions) wrote:
Hi all,
I have a package with two routines in it, one of these routines is
called by a trigger.
In RDB$DEPEDENCIES, I can see that a package that uses a table, has a
record
with RDB$DEPENDENT_TYPE of 19 (“package body”) on a
On 09/10/2014 10:34, Martijn Tonies (Upscene Productions) wrote:
You could use FIELD_NAME, for backwards compatibility, but also add a
child object type column, for the package extension to distinguish between
functions/procedures/future items.
Use a field with a name for another thing is also
On 10/10/2014 12:55, Dimitry Sibiryakov wrote:
Hello, All.
I wonder why in new CLOOP interfaces versions are declared as simple
constants instead
of something like VERSION = inherited::VERSION + 3?..
The architecture of this class-scheme disallow that base interfaces are
extended.
Hi!
Please look at test staticMessage2 at
https://github.com/asfernandes/fbstuff/blob/master/src/test/v3api/StaticMessageTest.cpp
The second openCursor tries to pass NULL to a not-NULL parameter.
With embedded, the test works.
With remote, openCursor returns a ResultSet and the exception
On 14/10/2014 12:34, Alex Peshkoff wrote:
On 10/14/14 19:26, Dimitry Sibiryakov wrote:
Hello, All.
What class can be used to get IConfig interface for a config file with a
given name and
path?
PluginManager::getConfig(Status status, const string filename)
I think it should be in
On 15/10/2014 11:07, Dimitry Sibiryakov wrote:
15.10.2014 14:41, Dimitry Sibiryakov wrote:
interface.h doesn't need to include ibase.h. Actually, this include is
causing troubles
for compiling some third-party applications.
Interface.h uses legacy structs, so it should include ibase.h.
On 15/10/2014 11:31, Dimitry Sibiryakov wrote:
15.10.2014 16:26, Adriano dos Santos Fernandes wrote:
Interface.h uses legacy structs, so it should include ibase.h.
types_pub.h is enough. It does not need old API function prototypes.
types_pub.h does not exist in an installation, it's merged
Hi!
To not check class version in each method call, cloop-based interfaces
implement class-upgrade at return and argument passing.
If everything is simple, it (the mechanics) works. But not everything is
simple.
We have structs (Dtc::start - with DtcStart) with interfaces and
pointers to
On 23/10/2014 13:42, Alex Peshkoff wrote:
On 10/23/14 18:56, Adriano dos Santos Fernandes wrote:
Hi!
To not check class version in each method call, cloop-based interfaces
implement class-upgrade at return and argument passing.
If everything is simple, it (the mechanics) works
On 28/10/2014 06:34, Dmitry Yemanov wrote:
All that said, I see no need for a configuration option. Validation
should be always the default behavior. Any RDBMS is first of all about
consistency and only then about performance.
If user knows what he's doing, then the database is not
On 07/11/2014 14:03, Dimitry Sibiryakov wrote:
Hello, All.
I've changed parse.y with attached diff, but even after clean full
rebuild isql shows me this error:
SQL set transaction no replication;
Commit current transaction (y/n)?n
Rolling back work.
Statement failed, SQLSTATE = 42000
On 11/11/2014 13:04, Dimitry Sibiryakov wrote:
After the last commit where has IAttachment disappeared to? Interface.h
refuses to
compile without it you know...
I Attachment does not disappeared and tree builds fine for me in Linux.
What are you talking about?
Adriano
On 11/11/2014 13:17, Dimitry Sibiryakov wrote:
11.11.2014 16:12, Adriano dos Santos Fernandes wrote:
I Attachment does not disappeared and tree builds fine for me in Linux.
Where is it declared then? In IdlFbInterfaces.h there is no mention of it.
Interface.h: typedef name::Attachment
On 11/11/2014 13:52, Dimitry Sibiryakov wrote:
11.11.2014 16:26, Adriano dos Santos Fernandes wrote:
If you're test tree with changes, I cannot say anything about.
But I hope that you can say something about what should be in #else branch
of the #ifdef.
I'm trying to figure out. Internals
On 11/11/2014 14:15, Dimitry Sibiryakov wrote:
11.11.2014 17:13, Adriano dos Santos Fernandes wrote:
I'm trying to figure out. Internals hacks (I typedefs, structs,
non-cloop classes) are not good for external usage yet.
Do you think about undoing your commit or adding an another layer
On 12/11/2014 07:52, Alex Peshkoff wrote:
On 11/11/14 19:23, Adriano dos Santos Fernandes wrote:
On 11/11/2014 14:15, Dimitry Sibiryakov wrote:
11.11.2014 17:13, Adriano dos Santos Fernandes wrote:
I'm trying to figure out. Internals hacks (I typedefs, structs,
non-cloop classes) are not good
On 12/11/2014 08:35, Alex Peshkoff wrote:
On 11/12/14 12:56, Adriano dos Santos Fernandes wrote:
On 12/11/2014 07:52, Alex Peshkoff wrote:
On 11/11/14 19:23, Adriano dos Santos Fernandes wrote:
On 11/11/2014 14:15, Dimitry Sibiryakov wrote:
11.11.2014 17:13, Adriano dos Santos Fernandes wrote
On 12/11/2014 09:18, Alex Peshkoff wrote:
On 11/12/14 13:41, Adriano dos Santos Fernandes wrote:
Alex, let's review things then!
In one of the files I just moved firebird.h, it was already being included!
What file, from where to where did you move it? I can't grep firebird.h
in all 4
In firebird.conf it says:
# IPv4 and IPv6. Default is false on POSIX systems, true on Windows.
# On Windows, false value can only be used since Windows Vista.
Why it's different in POSIX and Windows? And why the default in Windows
is something not accepted after Vista?
But I then see in the
Hi!
Currently the API is problematic in any non usage scenario different
than one used internally in FB code.
We have the I classes witch are typedefs for a default policy, a
policy that is just not suitable for C++, as it ignore exceptions and
avoids every piece of the policy idea.
Even if the
On 17/11/2014 19:05, Dimitry Sibiryakov wrote:
17.11.2014 21:50, Mark Rotteveel wrote:
moving from Visual Studio 2010 to 2013 (or the upcoming
2015) might be something to consider for the near future.
On the other hand moving to GCC can make porting easier and reduce number
of cases when
On 18/11/2014 09:56, Dimitry Sibiryakov wrote:
18.11.2014 12:40, Adriano dos Santos Fernandes wrote:
When you have an IAttachment in DtcStart, or IStatus in any other (UDR)
class, you're doing it wrong. IAttachment is bound to a policy.
So, all you need to make it right is to unbind
It seems I'm able to transform a policy class template into a namespace
with a policy applied, without C++11 features, which can then be used
and accessed without prefix.
That's with cloop test.
Firebird code is more complex. I'll try the same approach on it.
Adriano
On 18/11/2014 09:00, Mark Rotteveel wrote:
While it makes sense to have a single official VS projects files based
on a fully free VS, since Microsoft do not learned how to support the
same files in multiple versions, it does not have any sense to adopt a
single compiler for all builds.
On 18/11/2014 14:14, Vlad Khorsun wrote:
If you compare msvc10 and msvc12 folders you'll found almost no difference.
Must say that while VS 2010 really converted older project files into its own
format, there was no such process in VS 2013 - it just loads solution and
works.
I tried in
On 28/11/2014 09:39, Vlad Khorsun wrote:
Hi all.
Recently wire compression was implemented by Alex. It uses well known zlib
library. On Linux zlib could be installed as a standalone package and there
is no problems with its presence nor for Firebird users, nor for those who
going to
On 11/12/2014 13:06, Dmitry Yemanov wrote:
11.12.2014 17:42, Alex Peshkoff wrote:
Have you ever seen in gstat -h? :)
BTW, is it really about database creation?
IIRC, ICU version is stored in collation specific attributes. If one
creates one ICU collation, then upgrade ICU and create
On 11/12/2014 13:21, Dmitry Yemanov wrote:
11.12.2014 18:06, Adriano dos Santos Fernandes wrote:
Support for multiple ICU versions (and its maybe different data tables)
exists, user just need to install them!
If I would be a support person dealing with customers databases, I'd
rather get
On 11/12/2014 13:42, Dmitry Yemanov wrote:
11.12.2014 18:32, Adriano dos Santos Fernandes wrote:
Copy back and forth and rebuilding indexes every time?
A database created with incompatible (at least different) ICU version
simply cannot be accessed on the other host. This was my experience
On 17/12/2014 08:03, Egor Pugin wrote:
In Visual Studio:
1. Select boot_* (boot step), epp_* (boot and master epp - cpp
steps), databases (security.fdb, messages.fdb, help.fdb generation),
messages (firebird.msg generation), other projects you need to turn
off (examples, etc). Right click -
On 18/12/2014 11:16, Alex Peshkoff wrote:
On 11/18/14 14:40, Adriano dos Santos Fernandes wrote:
.
As an API writer of a project that doesn't follow standards (talking
specially about std exceptions), you need to create an API which is
usable by different ways, that can be mixed (each
On 18/12/2014 11:32, Dimitry Sibiryakov wrote:
18.12.2014 14:28, Adriano dos Santos Fernandes wrote:
So like selecting the types with using (or explicitly), user would
select the functions too.
Funny. What will be returned from the function found by dlsym()?
Each different IMaster has
On 18-12-2014 18:51, Alexpux wrote:
18 дек. 2014 г., в 15:49, Alex Peshkoff peshk...@mail.ru
mailto:peshk...@mail.ru написал(а):
On 12/18/14 15:31, Adriano dos Santos Fernandes wrote:
On 18/12/2014 10:10, Alexey Pavlov wrote:
From 54e4756f1bd8dce672b10e24bac8419ec8faace7 Mon Sep 17 00:00
Please check if it's not due to inclusion of stdint.h in
IdlFbInterfaces.h... It probably can be removed.
Adriano
On 22/12/2014 12:02, Dimitry Sibiryakov wrote:
c:\users\sd\my documents\firebird\extern\icu\include\unicode\umachine.h(200):
error C2146:
syntax error : missing ';' before
On 29/12/2014 07:16, Dimitry Sibiryakov wrote:
28.12.2014 4:28, James Starkey wrote:
I agree. That's how you understand it. But you are wrong.
No matter if I'm right or wrong. Just tell me the number.
No matter what number you use, Firebird will continue, improve and use
that number.
So,
On 29/12/2014 08:33, Martijn Tonies (Upscene Productions) wrote:
-Original Message-
From: Alex Peshkoff
On 12/29/14 12:07, Martijn Tonies (Upscene Productions) wrote:
IMO,
case sensitivity is always a bug. ;)
That you should say to posix standard developers :)
Plugin will just
301 - 400 of 1691 matches
Mail list logo
