Introduce POSIX data types #177

stweil · 2015-12-23T19:44:42Z

POSIX provides portable data types for signed and unsigned integer values
of different size.

This patch maps those POSIX data types to the Tesseract specific types.
In a next step, the Tesseract data types can be eliminated by replacing
them with the POSIX data types.

Use also standard definitions for the printf format specifiers.
MS Visual Studio does not support that standard (at least not in older
versions), so local definitions are needed there.

~~NULL is standard, so a local definition should not be needed.~~

Signed-off-by: Stefan Weil sw@weilnetz.de

stweil · 2015-12-25T11:17:38Z

Updated patch: removed part for format specifiers, don't remove NULL definition (both issues should be done in separate patches).

LinusU · 2016-01-22T10:40:34Z

Maybe it would be even better to go thru the code and use, for example, int8_t instead of inT8...

stweil · 2016-01-22T10:50:25Z

@LinusU, yes, that would be the next step as soon as this pull request was accepted.

LinusU · 2016-01-22T12:11:39Z

👍

stweil · 2016-02-18T06:44:10Z

Ping? Are there any more thoughts on my proposal?

zdenop · 2016-02-18T07:39:49Z

...waiting for review @theraysmith

stweil · 2016-03-16T11:29:28Z

@theraysmith, ping. Do you support the idea of replacing Tesseract data types by POSIX data types (so I can prepare a follow-up pull request)?

Many other free software projects with similar compiler / host conditions have shown that using POSIX data types works. Especially for library interfaces, but also for the rest of the code, it would be good to get rid of project specific data types which don't provide any additional value compared with the standard.

stweil · 2016-04-30T16:18:15Z

Ping? I suggest to apply this patch now, wait one more month and then replace all Tesseract integer types by the POSIX types.

stweil · 2016-05-15T17:18:18Z

@theraysmith, @zdenop, do you have any comments to my last proposal? Can we proceed like that?

stweil · 2016-07-08T13:27:04Z

Ping?

stweil · 2016-08-05T19:47:41Z

I still think it would be a good idea to replace all proprietary data types by the POSIX ones. Is it really necessary to wait for @theraysmith (who is obviously very busy)? Lots of other free (and also commercial) software projects work pretty good with the POSIX data types, using similar environments as Tesseract (Linux and other Unixes, Windows with Cygwin / MinGW-w64 / MS and other compilers).

So can we do the first step and apply this PR which is waiting for more than 7 months now?

stweil · 2016-09-08T18:58:34Z

Another month passed. I'd still like to see Tesseract switching to POSIX data types.

Shreeshrii · 2016-09-11T09:25:13Z

@zdenop said re: next release in #165 (comment)

I hear something like end of September 2016, but you never know ;-) It will big update (probably we will drop support of compilers nor support c++11)...

Will dropping support for compilers effect Tesseract switching to POSIX data types?

stweil · 2016-10-24T16:22:51Z

Will dropping support for compilers effect Tesseract switching to POSIX data types?

I don't think that POSIX data types are affected by the compiler decision. They exist for many years now, so any supported old or new compiler will work with POSIX data types.

POSIX provides portable data types for signed and unsigned integer values of different size. This patch maps those POSIX data types to the Tesseract specific types. In a next step, the Tesseract data types can be eliminated by replacing them with the POSIX data types. Signed-off-by: Stefan Weil <sw@weilnetz.de>

stweil · 2016-11-22T07:11:34Z

@theraysmith, may I kindly ask you to give your consent?

theraysmith · 2016-11-22T16:29:20Z

Now we're synced, yes I think that would be a positive change, but it may be something to keep for 4.00 forward, so as to maintain maximum support for old compilers in the last 3.xx version.
(I already put a few experimental uses of nullptr in 4.00 to see if anyone squeals.)
Not being a git expert yet, I assume I can just hit the pull button and 3.xx can still be unaffected right?

zdenop · 2016-11-22T19:57:03Z

Yes, just hit button "Merge pull request" if you wan to include it to currect (4.00) code

LinusU · 2016-11-24T14:05:22Z

Woohoo! 🎉

Now if we could only replace all occurences of inT8 with int8_t, uinT8 with uint8_t and so forth 🙌

stweil · 2016-11-24T18:18:01Z

Yes, replacing those Tesseract data types by the POSIX data types will be the next step.

@zdenop, that means changes for nearly all source files which will give conflicts with pending pull requests. Should I nevertheless send one large PR which does the replacement, or would it be better to do it in smaller steps (starting for example with all files in lstm)? Are there more major changes pending after the integration of LSTM?

zdenop · 2016-11-24T18:26:35Z

@theraysmith : Is there plan to commit new code that would interfere with this changes?
@stweil : I would wait for the moment ;-) so there is change to fix building of 4.0 (outside of linux). E.g. 1-2 weeks after lstm data files are available.

stweil · 2016-11-24T18:38:05Z

I already put a few experimental uses of nullptr in 4.00 to see if anyone squeals.

@theraysmith, training/stringrenderer.cpp already uses nullptr for more than two years now. AFAIK nobody complained, so that seems to work. Replacing NULL by nullptr would be good, but also touches many files, so this could be done in the same action as the switch to POSIX data types.

Do you care for comments after modified code? Replacing data types or NULL is easy, but the replacements are a little bit longer, and moving the comments to the right column means much hand work without code formatter.

theraysmith · 2016-11-26T02:36:57Z

Training is a different kettle of fish to the recognition engine, as the latter is currently (3.0x) *much* more portable than the training tools. I want to see if anyone squeals when they start porting the 4.00 recognition engine to other platforms, although there are likely to be howls of protests over the other missing ingredients first, like big-endian support and SIMD extensions. Although now I mention that, anyone who has a machine old enough to squeal over C++11 probably doesn't have the horsepower to run 4.00 at a reasonable speed.

…

On Thu, Nov 24, 2016 at 10:38 AM, Stefan Weil ***@***.***> wrote: I already put a few experimental uses of nullptr in 4.00 to see if anyone squeals. @theraysmith <https://github.com/theraysmith>, training/stringrenderer.cpp already uses nullptr for more than two years now. AFAIK nobody complained, so that seems to work. Replacing NULL by nullptr would be good, but also touches many files, so this could be done in the same action as the switch to POSIX data types. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#177 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL056QF3tQJra8WTACr_cvaeVjUG0yP6ks5rBdmWgaJpZM4G6wao> .

-- Ray.

theraysmith · 2016-12-01T06:08:05Z

FYI: This change breaks several tests in the Google repository because the Google int64 is long long and the posix int64_t is just long, and the compiler says they are not compatible.
Of course they shouldn't have used the wrong type to begin with.
I'm hoping that they can be fixed easily enough and it doesn't open a whole can of worms, but I thought you would be interested that it is not as easy as you thought.

stweil · 2016-12-01T06:31:55Z

Yes, the change to POSIX requires some work (not only in your tests), but it will help in the long run – for example as soon as there is a 128 bit architecture with long being int128_t. And it helps a lot as soon as you want to use Tesseract code in other software.

egorpugin · 2016-12-01T07:22:28Z

There's also int_least64_t. http://en.cppreference.com/w/cpp/types/integer

This fixes a warning from the Intel compiler: src/textord/cjkpitch.cpp(79): warning tesseract-ocr#177: function "<unnamed>::SimpleStats::maximum" was declared but never referenced Signed-off-by: Stefan Weil <sw@weilnetz.de>

This fixes warnings from the Intel compiler: src/textord/cjkpitch.cpp(319): warning tesseract-ocr#177: function "<unnamed>::FPRow::good_gaps" was declared but never referenced src/textord/cjkpitch.cpp(383): warning tesseract-ocr#177: function "<unnamed>::FPRow::is_bad" was declared but never referenced src/textord/cjkpitch.cpp(387): warning tesseract-ocr#177: function "<unnamed>::FPRow::is_unknown" was declared but never referenced Signed-off-by: Stefan Weil <sw@weilnetz.de>

This fixes a warning from the Intel compiler: src/textord/cjkpitch.cpp(79): warning tesseract-ocr#177: function "<unnamed>::SimpleStats::maximum" was declared but never referenced Signed-off-by: Stefan Weil <sw@weilnetz.de>

This fixes warnings from the Intel compiler: src/textord/cjkpitch.cpp(319): warning tesseract-ocr#177: function "<unnamed>::FPRow::good_gaps" was declared but never referenced src/textord/cjkpitch.cpp(383): warning tesseract-ocr#177: function "<unnamed>::FPRow::is_bad" was declared but never referenced src/textord/cjkpitch.cpp(387): warning tesseract-ocr#177: function "<unnamed>::FPRow::is_unknown" was declared but never referenced Signed-off-by: Stefan Weil <sw@weilnetz.de>

stweil force-pushed the posix branch from b1c66fc to 8797b86 Compare December 25, 2015 11:15

stweil changed the title ~~Introduce POSIX data types and definitions~~ Introduce POSIX data types Jan 22, 2016

amitdo assigned theraysmith Jun 13, 2016

stweil force-pushed the posix branch from 8797b86 to 49c5a57 Compare October 26, 2016 07:04

zdenop merged commit 64159c7 into tesseract-ocr:master Nov 24, 2016

stweil deleted the posix branch November 24, 2016 16:53

stweil mentioned this pull request Nov 26, 2016

opencl: Use nullptr and POSIX data types #503

Merged

stweil mentioned this pull request May 2, 2017

Replace Tesseract data types by POSIX data types #865

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce POSIX data types #177

Introduce POSIX data types #177

stweil commented Dec 23, 2015 •

edited

Loading

stweil commented Dec 25, 2015

LinusU commented Jan 22, 2016

stweil commented Jan 22, 2016

LinusU commented Jan 22, 2016

stweil commented Feb 18, 2016

zdenop commented Feb 18, 2016

stweil commented Mar 16, 2016

stweil commented Apr 30, 2016

stweil commented May 15, 2016

stweil commented Jul 8, 2016

stweil commented Aug 5, 2016

stweil commented Sep 8, 2016

Shreeshrii commented Sep 11, 2016

stweil commented Oct 24, 2016

stweil commented Nov 22, 2016

theraysmith commented Nov 22, 2016

zdenop commented Nov 22, 2016

LinusU commented Nov 24, 2016

stweil commented Nov 24, 2016

zdenop commented Nov 24, 2016

stweil commented Nov 24, 2016 •

edited

Loading

theraysmith commented Nov 26, 2016 via email

theraysmith commented Dec 1, 2016

stweil commented Dec 1, 2016

egorpugin commented Dec 1, 2016

Introduce POSIX data types #177

Introduce POSIX data types #177

Conversation

stweil commented Dec 23, 2015 • edited Loading

stweil commented Dec 25, 2015

LinusU commented Jan 22, 2016

stweil commented Jan 22, 2016

LinusU commented Jan 22, 2016

stweil commented Feb 18, 2016

zdenop commented Feb 18, 2016

stweil commented Mar 16, 2016

stweil commented Apr 30, 2016

stweil commented May 15, 2016

stweil commented Jul 8, 2016

stweil commented Aug 5, 2016

stweil commented Sep 8, 2016

Shreeshrii commented Sep 11, 2016

stweil commented Oct 24, 2016

stweil commented Nov 22, 2016

theraysmith commented Nov 22, 2016

zdenop commented Nov 22, 2016

LinusU commented Nov 24, 2016

stweil commented Nov 24, 2016

zdenop commented Nov 24, 2016

stweil commented Nov 24, 2016 • edited Loading

theraysmith commented Nov 26, 2016 via email

theraysmith commented Dec 1, 2016

stweil commented Dec 1, 2016

egorpugin commented Dec 1, 2016

stweil commented Dec 23, 2015 •

edited

Loading

stweil commented Nov 24, 2016 •

edited

Loading