>One of our developers discovered that Firebird 2.5 fails to compile
MSVC2013, made some steps in the direction of fixing it (like we did
internally for GCC 6), and was told that for Firebird 2.5, it was more work
than he envisioned: http://tracker.firebirdsql.org/browse/CORE-5120
You can look to
15.03.2016 18:37, Lionel Elie Mamane wrote:
>
> Short version: will Firebird (2.5? 3? latest?) in general be kept
> compatible with the latest major compilers (within a reasonable time
> of their release) for each platform for the foreseeable future?
Yes. Just don't expect it to happen
On Tue, Mar 15, 2016 at 04:37:06PM +0100, Lionel Elie Mamane wrote:
>
> Then, we read the thread "Compiler for official Firebird 4 release on
> Windows" on this ML. Which says that not only Firebird 3, bit Firebird
> 4 binaries on http://firebirdsql.org/ will be compiled with
> MSVC2013. Some
Could somebody explain why Firebird is in the filename translation
business at all? Other than the need for the inet remote interface to
follow symbolic links, historically this has not been necessary. It
clearly isn't needed to open the file.
If the purpose is to server as the root of the
On 03/15/2016 08:27 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Among examples in "interfaces" folder I don't see any that could show how
> to work with
> services using new API. Is it possible at all?
>
Yes, certainly.
Plan to add it (also use of FB_MESSAGE macro to describe
Hello, All.
Among examples in "interfaces" folder I don't see any that could show how to
work with
services using new API. Is it possible at all?
--
WBR, SD.
--
Transform Data into Opportunity.
Accelerate
On 15/03/2016 13:30, Dimitry Sibiryakov wrote:
> 15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
>> Also should test old client (which cannot use utf8_filename dpb)
>> connecting to new (with your change, and already one without it)
>> checking it work as originally.
>Old client that
Casting text to integer fails if text is within range but more than nine digits
---
Key: CORE-5151
URL: http://tracker.firebirdsql.org/browse/CORE-5151
Project: Firebird Core
Hi,
Short version: will Firebird (2.5? 3? latest?) in general be kept
compatible with the latest major compilers (within a reasonable time
of their release) for each platform for the foreseeable future?
Long version:
As you may already know, LibreOffice embeds Firebird 2.5. This is
currently as
15.03.2016 14:50, Michal Kubecek wrote:
> As most linux distributions have been using UTF-8 for everything for
> quite some time, file names ended up being in UTF-8 as well. But it's
> just kind of an "unwritten law", not a standard.
Ok, I'll add calls to Utf8ToSystem into unix.cpp before
On Tue, Mar 15, 2016 at 01:49:20PM +0100, Dimitry Sibiryakov wrote:
> >Does POSIX requires any changes for this issue ?
>
>AFAIK - no, fopen() handles utf-8 in file names out of box.
I would rather say posix filesystems are encoding agnostic. In general,
the file name is just a sequence
15.03.2016 14:00, Alex Peshkoff wrote:
> Please provide proof reference for it.
http://stackoverflow.com/questions/4676327/how-to-open-a-file-with-wchar-t-containing-non-ascii-string-in-linux
--
WBR, SD.
--
On 03/15/2016 03:49 PM, Dimitry Sibiryakov wrote:
> 15.03.2016 13:36, Vlad Khorsun wrote:
>> But why you not included it into namespace os_utils ???
> To keep old code working. Otherwise I would have to change every piece of
> code where
> the class is used.
It's OS specific and therefore
On 03/15/2016 03:36 PM, Vlad Khorsun wrote:
>> Question: should I commit them at once or separately?
> I see two questions in statement above.
I've discussed some points with author privately in russian and I do not
agree with this commit. It's half done and breaks a lot of places even
15.03.2016 13:47, Adriano dos Santos Fernandes wrote:
> No regressions in any commit is top priority.
Sure. I'll do extended testing in areas you mentioned.
> It surely work.
>
> Without isc_dbp_utf8_filename ever work as intended. You sure should
> test this with different servers and
15.03.2016 13:36, Vlad Khorsun wrote:
> But why you not included it into namespace os_utils ???
To keep old code working. Otherwise I would have to change every piece of
code where
the class is used.
Besides, I doubt that this all-purpose class belongs to that namespace.
> Also, i prefer
On 15/03/2016 09:41, Dimitry Sibiryakov wrote:
> 15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
>> You should at least test every code path related to the functions you
>> changed the input/output code page, like code paths related to files
>> names in databases (external files, shadows,
15.03.2016 13:24, Adriano dos Santos Fernandes wrote:
> You should at least test every code path related to the functions you
> changed the input/output code page, like code paths related to files
> names in databases (external files, shadows, whatever).
I was explicitly asked by admins not to
On 03/15/2016 03:34 PM, Jiří Činčura wrote:
> Nobody from core team?
>
Jiri, I have no idea how to help you. fbsvcmgr works just fine.
If you can provide reproducible test case which I can run on linux (may
be client on wine) I will take a look what happens.
15.03.2016 14:05, Dimitry Sibiryakov wrote:
>In attachment you can find patch for CORE-3172 and another one that adds
> minimal support for unicode database names into engine.
You moved class WideCharBuffer into os_utils, as suggested, it is ok.
But why you not included it into namespace
Nobody from core team?
--
Mgr. Jiří Činčura
Independent IT Specialist
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn
On 15/03/2016 09:18, Dimitry Sibiryakov wrote:
> 15.03.2016 13:13, Alex Peshkoff wrote:
>> first of all I
>> want to know how was it tested - what environments and what tasks.
>Testcase was attached. Only operations relevant to CORE-3172 were tested:
> creation of
> database and attach.
On 03/15/2016 03:18 PM, Dimitry Sibiryakov wrote:
> 15.03.2016 13:13, Alex Peshkoff wrote:
>>first of all I
>> want to know how was it tested - what environments and what tasks.
> Testcase was attached. Only operations relevant to CORE-3172 were tested:
> creation of
> database and
15.03.2016 13:13, Alex Peshkoff wrote:
> first of all I
> want to know how was it tested - what environments and what tasks.
Testcase was attached. Only operations relevant to CORE-3172 were tested:
creation of
database and attach. The rest is untouched by patch and will require separate
On 03/15/2016 03:05 PM, Dimitry Sibiryakov wrote:
> 14.03.2016 9:49, Dimitry Sibiryakov wrote:
>>Agreement?
>
> Silence is an agreement, huh?..
>
> In attachment you can find patch for CORE-3172 and another one that
> adds minimal support for unicode database names into engine. Together
On 03/15/2016 12:40 PM, Dimitry Sibiryakov wrote:
> 15.03.2016 10:33, Alex Peshkoff wrote:
>> Where do we have races in_current_ codebase?
> Dunno, you told about them.
>
I've said that _if_ you remove filenames comparison from
initAttachment() in jrd.cpp or make it case-insensitive on
14.03.2016 9:49, Dimitry Sibiryakov wrote:
Agreement?
Silence is an agreement, huh?..
In attachment you can find patch for CORE-3172 and another one that adds minimal
support for unicode database names into engine. Together they make attached testcase work.
These patches target
[
http://tracker.firebirdsql.org/browse/CORE-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimitry Sibiryakov reopened CORE-3172:
--
Planning Status: Considered for inclusion
This ticket is not a duplicate because is
On 15/03/16 02:24, Jim Starkey wrote:
> The combination of cmake and git submodules would let the Firebird
> project to be decomposed in clean, separate, architecturally independent
> projects, a win-win all around.
The key statement there is the 'combination of'. Although the facilities
15.03.2016 10:33, Alex Peshkoff wrote:
> Where do we have races in_current_ codebase?
Dunno, you told about them.
--
WBR, SD.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications
On 03/14/2016 08:56 PM, Dimitry Sibiryakov wrote:
> 14.03.2016 18:39, Alex Peshkoff wrote:
>> Do you suggest to lock db list mutex from yvalve? And from network
>> server? :)
> This is a separate discussion about thread races on database file
> creation and open, if
> you haven't noticed.
31 matches
Mail list logo
