Some sync from 3.4 into 3.2

[vszakats]

Hi,

Throughout the last, almost 4.5 years since I've created the

3.4 fork, the forked codebase diverged quite much from the

3.2. This was the result of about 5000 extra commits that went

into 3.4 only. This meant that merging code back-and-forth

could more often require manual conflict resolution and it

was difficult to oversee the "real" difference between the two

codebases.

So, in the recent week I've made about 25 commits to the 3.2

codebase, that aim to sync up certain changes from 3.4 back

into 3.2, such as file, directory and variable renames, source

files splits/merges, formatting/indenting/whitespace or other

coding style-related changes, some minor source code fixes

and cleanups, silencing a certain class of C compiler warnings,

syncing most core docs, and last but not least comment and

text cleanups, fixing among others a few thousand typos.

The total .diff size of these 25 commits is 7.2MB, and it's been

created manually for the most part.

The two codebases still have 10MB of .diff remaining, not

counting the 3rd party code hosted in the Harbour repo.

(Total size of both repos is 62 MB, of which 17-18 MB is vendored

3rd party code, leaving Harbour's own sources at 44-45 MB)

This difference consists of bugfixes, some new functions/CPs,

completely overhauled or extended components, like hbnf, hbcurl,

hbssl, hbtest, hbmk2/hbrun, hbdoc, new contribs like hbampq,

hbcrypto, hbmac, hbyaml, an extensive cleanup of all test code

in tests/* and /contrib/*/tests/*, build and distro automation,

portability/build fixes/extensions, better UTF-8/Unicode support,

VF IO support and applying general best-practices along the whole

codebase, gtwvw refactor together with gtwvg and hbwin, several

other contribs cleaned up/fixed, and general all-around

maintenance, including vendored 3rd party sources in the tree.

-Viktor

[Gerald Drouillard]

Thank you Viktor.

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards
--------------------------------------
Gerald Drouillard
Cell: 734.502.4356

[Teo Fonrouge]

Hello Viktor,

AFAICS, your 3.4 fork is a superset of current official git repo harbour-core,

so it seems a natural path to upgrade current official harbour-core with your

fork and release it as harbour-core 3.4 .

And a important question (at least for me) is: why don't you get back to

use harbour-core as your main development harbour repo ?

Currently harbour-core as 115 issues closed and 10 open, and your fork

has 251 issues closed and zero open, so it seems that the actual heart beat

of Harbour is in your hands ...

best regards,

Teo

[Ash]

A class act, Viktor. 

Thank you.

Ash

[vszakats]

Hi Teo,

On Wednesday, September 13, 2017 at 10:47:56 PM UTC+2, Teo Fonrouge wrote:

Hello Viktor,

AFAICS, your 3.4 fork is a superset of current official git repo harbour-core,

It is indeed. All 3.2 commits were merged into 3.4, except a couple

minor exceptions.

so it seems a natural path to upgrade current official harbour-core with your

fork and release it as harbour-core 3.4 .

And a important question (at least for me) is: why don't you get back to

use harbour-core as your main development harbour repo ?

Currently harbour-core as 115 issues closed and 10 open, and your fork

has 251 issues closed and zero open, so it seems that the actual heart beat

of Harbour is in your hands ...

To be fair there is a handful of long-standing issues in 'Closed' status

under the "help wanted" label, though this is true both for both 3.2 and 3.4.

(in 3.4 this is documented in `.github/CONTRIBUTING.md`)

These are all potential issues, and they are waiting for someone to

implement/fix them:

   https://github.com/vszakats/harbour-core/issues?q=label%3A%22help+wanted%22

   https://github.com/harbour/core/issues?q=label%3A%22help+wanted%22

Back to your question, doing this in 3.2 would vastly inflate the

required work involved (due to discussions/support, more users

and 3rd parties, and the wider range of "officially" supported

targets, contribs and expectations, etc.)

To put this bluntly: I can't afford to fix BCC, WinCE or certain

legacy contrib related issues, MS-DOS compatibility, or do extra

support/releases/etc over what I do now. In fact I'm looking for

ways to _ease_ maintenance. Deprecation is key here. In 3.2

I wouldn't dare to delete the (unused, but maintenance heavy)

jpeg/tiff sources. In 3.4 I can do that without fear of a revolt.

3.2 became the unchanging platform that also supports everything

that was decided ~20 years ago. 3.4 is there for those who are

willing to move a bit faster and can also handle the "as-is" nature

of this option.

If mainline Harbour may once refocus its priorities to what it can

actually support with its existing limited capacity, merging 3.4 may

become a viable option.

-Viktor

[Teo Fonrouge]

Viktor,

I see your point and completely agree.

3.2 became the unchanging platform that also supports everything

that was decided ~20 years ago. 3.4 is there for those who are

willing to move a bit faster and can also handle the "as-is" nature

of this option.

If mainline Harbour may once refocus its priorities to what it can

actually support with its existing limited capacity, merging 3.4 may

become a viable option.

Let me ask you a question: what would be the point of "refresh" 3.2

when it fulfills the original purpose for what it was originally created ?

Then I see 3.2 perfect as it is now, and it should be kept that way.

do you in 3.4, plan to add some features that could attract new users ?

features like; an apache module as database engine, web server scripting ...

I know that some of such features (have been/are) developed for brave

Harboureans, so why not aim to create (for example) a harbour-sdk,

harbour-rte, ... to, lets say, send up to the Ubuntu's ( or Homebrew ) 

main stream package repos ?

I still feel that Harbour is a perfect language for business apps, strong,

and simple at the same time, his core source code is a world class one.

multiplatform, ...

-Viktor

Well, thank you Viktor and all others great developers/maintainers.

best regards,

Teo

[Massimo Belgrano]

Thank you Viktor for your effort
merging 3.4 for me is ok becuase i I not use BCC, WinCE ,  MS-DOS
I hope in a binary distributionfor windows  who include qtcontrib easy to install

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[vszakats]

Hi Teo,

Let me ask you a question: what would be the point of "refresh" 3.2

when it fulfills the original purpose for what it was originally created ?

The world keeps evolving: usage, environments, tooling change. Ideally

software needs to follow that to stay usable/relevant?/maintainable, even

if it's main purpose remains about the same. Software has also known

issues and bugs discovered by time.

Then I see 3.2 perfect as it is now, and it should be kept that way.

Speaking of the core, 3.2 and 3.4 is largely the same, except some

things like VF IO and better unicode/keyboard support in 3.4 .prg-level

code, some extra CP updates, better versioning and minor features

and fixes here and there. It'd say they are both equally "perfect" here.

Vendored 3rd party code (sqlite3 and similar) in 3.2 is very outdated.

F.e. 3.4 supports PCRE2 in core.

Supplementary code, like build, utils (hbmk2) and tests, 3.2 is also

very outdated.

Regarding contribs, 3.2 is largely very outdated, too, except some

hotspots that were kept maintained. 3.4 has a quite large number

of fixes and additions here, and certain contribs are only maintained

there. It's possible some of these are not important, or not used at

all by anybody, in which case they'd need to be identified and deleted

from both project I think.

What I'm saying is: Software is not standing still because it's perfect,

but because it's just not being updated.

The 3.2 advantage here is that it's a steady target.

do you in 3.4, plan to add some features that could attract new users ?

I don't want to actively attract new users. If I stumbled on something that

seemed useful for Harbour or myself, and there was no alternative around,

or those needed work, it happened that I added it as a contrib. But, no

active plans to develop new modules for the sake of it.

features like; an apache module as database engine, web server scripting ...

I know that some of such features (have been/are) developed for brave

Harboureans, so why not aim to create (for example) a harbour-sdk,

harbour-rte, ... to, lets say, send up to the Ubuntu's ( or Homebrew ) 

main stream package repos ?

I believe that just those things should be added to the Harbour repo that

1) can't be developed easily (or at all) as external code

2) is kept maintained there.

That's the healthy/sustainable way. Likely all what you list can be developed

completely independently from Harbour itself. If some core hooks or new

features are required, it's best be submitted as a Pull Request to core.

Harbour is already on Homebrew and 3.4 offers its own Harbour formula,

but package managers only host non-fork versions and stable releases,

so it is problematic for both 3.2 and 3.4 at the moment. Another problem

is that Harbour repo comes with a long list of contribs with their multitude

of dependencies. Nobody wants a package that pulls in mysql and pgsql

and a dozen other packages unconditionally. So for package manager

purposes, Harbour badly needs to be split to core + separate package for

each contrib.

I still feel that Harbour is a perfect language for business apps, strong,

and simple at the same time, his core source code is a world class one.

multiplatform, ...

Yes, it has indeed a very good and compact core and it's perfect for its

purpose.

Well, thank you Viktor and all others great developers/maintainers.

Thank you!

-Viktor

[Andi Jahja]

Hi Viktor,

 

What you did was good indeed, thanks.

What I hate is the file renaming; I built Harbour with my own script, and these file renaming brought me lots of work to modify my script.

 

Please, in future,  if I may beg, avoid unneeded renaming.

 

Thanks again.

 

Andi

[Andi Jahja]

Sorry, one more thing, I think it is an unwritten convention that committer should post an email notification upon commiting.

It is not a bad thing, IMO. I noticed that for that so many changes, no ChangeLog notification was addressed to this list.

 

Andi

 

 

[vszakats]

Hi Andi,

That's exactly the "attitude" that keeps me from doing substantial

work in 3.2.

Anyhow I believe that anybody working with software needs

to endorse the fact that things change, usually for good reasons.

I'm also committing a lot to follow various changes in the different

components that surround Harbour or private code/scripts. Sorry

to say it, but it's business is usual, hate it or not.

Having said that, in these cases there is most of the time a warning,

but for sure rename markers in the ChangeLog.txt, so it's easy

to spot.

One thing you may do is to avoid relying on specific location of

supplementary files, f.e. by using the build scripts that come with

Harbour itself - these get updated out of the box.

-Viktor

[Klas Engwall]

Hi Andi,

The commit messages are automatically sent to:
https://groups.google.com/forum/#!forum/harbour-commits

Regards,
Klas

[vszakats]

On Thursday, September 14, 2017 at 3:28:23 PM UTC+2, Andi Jahja wrote:

Sorry, one more thing, I think it is an unwritten convention that committer should post an email notification upon commiting.

It is not a bad thing, IMO. I noticed that for that so many changes, no ChangeLog notification was addressed to this list.

Sorry, I don't do this. It's manual, awkward and dated. With Git and

GitHub (or any similar service), there is plenty of ways to get notified

about new commits, which you can configure to your precise taste

and workflow.

We have the harbour-commits list that's gets the commits automatically,

in GitHub you can 'watch' the repository, you may use a mobile or desktop

app to push a notification on each commit, or you may just open the commit

page of the Harbour repo, or use its RSS feed in your preferred client or

combine it with IFTTT or similar. I do this for several projects.

-Viktor

[Maurício Faria]

Viktor, thanks a lot for all the effort.
Your work on Harbour in all this past years are fantastic !

May I suggest here, in the users list, to freeze 3.2, declare it "stable
version" and move on all the effort to 3.4 as the development work ?
So 3.2 should receive only bug fixes and 3.4 becomes the path to the future.

Everyone, please drop an opinion about this...

Regards,

Maurício Faria

[Domenico D'Oria]

good suggestion

Domenico

[Massimo Belgrano]

yes good

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ToninhoFWi]

Hi,

Don't forget: Harbour 3.4 is not BCC compatible.

Newer versions like BCC 7.2 32bits for example, doesn't work.


Regards.

.

[Mel Smith]

On Saturday, September 16, 2017 at 4:59:37 AM UTC-6, ToninhoFWi wrote:

Hi,

Don't forget: Harbour 3.4 is not BCC compatible.

Newer versions like BCC 7.2 32bits for example, doesn't work.

Hi:

   Regularly (i.e., daily), I check/update and build Harbour under MinGW 7.1, VC 2017, and BCC 7.3 .

   After each of these separate builds, I compile and run ...\harbour\tests\speedtst.prg.

   For Viktor's latest 'sync', each compiler was built correctly, and speedtst ran successfully under each one.

   btw, VC2017 was marginally faster that MinGW, and BCC was significantly slower than either.

-Mel

[vszakats]

To be precise: In 3.4, BCC support is _deprecated_, but no

BCC-related logic has been actively removed (as of now).

Reasons for the deprecation:

- There exists much better, faster, widely-used, open, portable

alternatives.

- Testing/using BCC is cumbersome and costly, because _no_

modern 3rd party components (curl, OpenSSL, QT, almost any

GUI, etc), services (f.e. CI like AppVeyor), or infrastructure

supports is, including systems and platforms I personally use.

- BCC 7.x, 10.x also costs actual money. Unless you pirate

it, which for me is not an option. (registering for a demo is

also not viable.)

- This makes testing/maintenance the job of actual BCC users.

- Turns out I received zero BCC-related patches in the last

4-5 years, which is consistent with my experience in the

previous 5+ years in 3.x, where BCC users were very keen

on reporting problems and expecting everything to just work,

but volunteering to keep BCC support up was non-existent.

- Recent BCC versions broke toolchain compatibility in various

ways and 32 and 64-bit versions work differently and are quite

badly documented on the vendor's website.

- BCC is a niche. As per Google, StackOverflow, GitHub,

nobody uses it. There is no information about it, and nobody on

the internet is interested in BCC-related bug reports. You can try

it for yourself. If I Google for a BCC-related issue, most of time

I find my own bug report or some posts from Harbour's own

mailing lists.

- All the above has been known since at least the 3.0.0 release

and before. That's at least 6 years ago.

Anyway, all this means that BCC support in 3.4 is subject to

natural _feature rot_, which means it's not actively hurt, but as

development goes by, and nothing being tested with BCC, its

support may suffer collateral damage or regressions. I don't

know if this is the case, or the what extent, somebody should

try it. (I do know about one BCC bug that hit 3.4)

The difference in this regard compared to 3.2, is that 3.2 receives

almost zero maintenance (besides Przemek's contributions

to certain core components), so its BCC supports works the

same as it did 5 years ago, just because nothing has really been

touched that might have broke it.

Which takes us the the next problem: F.e. 64-bit BCC support,

which isn't supported at all with 3.2 (but few years ago I added some

untested bits for it to 3.4), or BCC 10.x support, which will require

a deeper overhaul of the build system. Anyhow, like 5.5, probably

7.x will also work for the next 20 years, so maybe it's not a large

problem in practice for users.

I'd be really interested to find out where the fixation to BCC comes

from inside the (x)Harbour community. I understand this was the

single free compiler in 1999, but this was almost 20 years ago, which

in IT-times counts as at least 50-100 normal years. It's also known

that BCC is very forgiving for sloppy C code, while MSVC and other

C compilers aren't. I also understand that xHarbour, FiveWin, MINIGUI

(maybe) are to this day promoting this compiler for exact reasons

only they may know.

So why is a large portion Harbour community stuck with pirated

and/or outdated C compilers, like BCC 7.x/5.x?

Anyhow I'd encourage everybody to step up and experience GCC

or the slightly worse, but safer bet, MSVC, which is sort of the

Windows-standard anyway. It's just a C compiler after, not the end

of the world.

-Viktor

[Francesco Perillo]

Hi Viktor,

thank you for your great work.

Regarding your question, you asked and answered yourself...

Question:

I'd be really interested to find out where the fixation to BCC comes

from inside the (x)Harbour community.

 

Answer:

 I also understand that xHarbour, FiveWin, MINIGUI

(maybe) are to this day promoting this compiler for exact reasons

only they may know.

From what I remember, it is really quick to compile and, more important, to link. I remember I was shocked when I moved from BCC to mingw years ago.

So why is a large portion Harbour community stuck with pirated

and/or outdated C compilers, like BCC 7.x/5.x?

Because the tools a lot of Harbour programmers use are based on BCC compiler and they'd need changes in the code or in the build tools to work with mingw.

The reason very few of these programmers contribute with patches to Harbour is that they are really great business coders but not fluent in c or don't know the underlying tools their ide uses. They can build a great, best selling, nice looking ERP but can't compile harbour from source code...  It is normal: my programmers collegues develop great applications in several languages (not in Harbour) but a couple of them don't know how to install Windows on a pc or the tools they use to develop...

Francesco

[vszakats]

Hi Francesco,

Thanks for you thoughts, appreciated.

I understand most of these, but I believe even the least-interested

"business coder" is able to change a C compiler in a 5-10 timeframe,

if he wants to. Especially since all the steps have been documented

extensively throughout this time and hbmk2 got developed which hides

most toolchain related differences. I'm sure installing a C compiler

shouldn't be a problem, mingw needs to be unzipped, MSVC has its

standard installer, MSYS2 also has its installer.

Though I understand even hbmk2 is not good enough for FiveWin, so

they are pushing MS-DOS BATCH files for their customers and actively

fight using hbmk2. This obviously makes it harder to switch even for

those how would.

What remains is home-baked C code and C-based products coming

from 3rd parties.

As for home-baked C code, for most non-C coders such code may be

redundant as easy to replace with calls to hbwin or similar lib.

At least that's my impression from reading Harbour forums for a

long time. The rest I'm sure can be fixed with the help of fellow

programmers or fellow projects.

As for C products that are coded in BCC-specific way, that's pretty

unfortunate, and definitely not a technical reason, the proof is Harbour

itself which can happily compile with nearly all existing C compiler

without modification. BCC was outdated 10 years ago already, with

better option, the direction was also clear.

As for compilation/linking speed: Since I've heard this first 10

years ago (when it may have been a borderline valid reason),

computers got their performance and memory multiplied, you got

multiple cores with multi-threaded builds, incremental compilation,

linking. Simple to access with hbmk2. And if you so much fear mingw's

compilation speed, MSVC is pretty competitive here, without generating

executable with crap runtime speed. Plus after all, nobody is using

Win 95 anymore, even though it'd surely be faster than Windows 10.

What seems to be missing is intent or interest in making any effort.

I personally don't care which business is promoting which inferior

tooling, component or platform, but maybe you understand that as

a major contributor and likely the only person currently maintaining

Harbour, I have zero incentive to help businesses (or anybody)

to maintain byzantine standards with no technical merit, in my own

spare time.

Sadly though, it doesn't stop here:

Dealing with BCC/POCC/XCC is a poison not just for the remaining

maintainer(s), but for this whole, small community, by creating even

smaller segregated, insulated sub-communities and narrowing the

choices for everyone. Plus of course Harbour itself, which is held

back by outdated tools and a technically stagnating audience. This

holds back development on all fronts, makes access to 3rd party

components slow and problematic, because you must deal with these

outdated lowest common denominators.

In 3.4, I opted to attract and welcome Harbour users who are able

and willing to endorse change, upgrade their tools, etc. For me,

not dealing with BCC and all that comes with it is a definite blessing.

-Viktor

[Angel Pais]

Hi Viktor:

First I want to show my thinking about this...
Since there are very few low level programmers available to harbour,
having too many compilers compatibility creates a lot of aditional an
duplicated work.

I assume harbour's primary goal is to have a MULTIPLATFORM xbase/clipper
compatible compiler.
With this in mind I think gcc support would be enought to achieve that
goal. Am I right ?

ADDITIONALY, if we are to devote efforts in supporting more platforms to
our beloved harbour, we should be looking for more modern/new emerging
platforms support, like the web browsers ecosystem.

What is your oppinion about this:
https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
Would it be feasible ?

I'd LOVE to use harbourd instead of javacript for DOM management.
Imagine our mem:DBFs on a browser session or even as a method for data
serialization in the new "Progressive Web Apps" that google is promoting
now.

Is all of this doable ?
What developper profile is required in harbour to achieve this ?
Theres too many low level thing I can't answer.
Like a RDD running in webassembly or DOM accesibility thru harbour
scripting.

Thank you in advance for your oppinions an excuse my poor english
management.

Angel Pais

[vszakats]

Hi Angel,

On Saturday, September 16, 2017 at 8:41:50 PM UTC+2, Angel Pais wrote:

Hi Viktor:

First I want to show my thinking about this...
Since there are very few low level programmers available to harbour,
having too many compilers compatibility creates a lot of aditional an
duplicated work.

Indeed.

 

I assume harbour's primary goal is to have a MULTIPLATFORM xbase/clipper
compatible compiler.
With this in mind I think gcc support would be enought to achieve that
goal.  Am I right ?

GCC covers most basis, yes. I'd add CLANG, which will overtake

GCC if current trends continue. MSVC on Windows probably cannot be

avoided, but that pretty much covers all bases for the foreseeable future.

ADDITIONALY, if we are to devote efforts in supporting more platforms to
our beloved harbour, we should be looking for more modern/new emerging
platforms support, like the web browsers ecosystem.

What is your oppinion about this:
https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
Would it be feasible ?

I've tried that a few month ago and even added as a new target

to 3.4, named 'abstr' (as abstract). Looked pretty interesting, with

even more interesting possibilities, but with lots to do to make it

production ready.

Fun facts: harbour.js (the compiler) is 4.2MB in size, hbmk2.js

is 27MB, hbrun.js was 32MB. They all start up correctly in the

browser.

I'd LOVE to use harbourd instead of javacript for DOM management.
Imagine  our mem:DBFs on a browser session or even as a method for data
serialization in the new "Progressive Web Apps" that google is promoting
now.

Is all of this doable ?
What developper profile is required in harbour to achieve this ?
Theres too many low level thing I can't answer.
Like a RDD running in webassembly or DOM accesibility thru harbour
scripting.

WebAssembly makes it possible to run Harbour apps directly

in the browser. _In theory_ you can save rewriting your app and

run it as-is there, with the cost of added complexities. In theory,

because to reach this production level, quite a bit of extra code

and logic needs to be created to make this go smoothly. Then

the app code most definitely needs to be rethought to accommodate

for the browser as its new environment (f.e. you don't have

a filesystem there.)

I'd rather take the approach of Lorenzo: a Harbour as a

server-side backend, f.e. behind nginx or similar and a browser

layer using popular standard like JS (I really hope that with 

WebAssembly, the world will get more languages here.),

and optionally native mobile apps that can tap on that same

server.

 

Thank you in advance for your oppinions an excuse my poor english
management. 

I can understand you perfectly, no worries!

-Viktor

[José Quintas]

A recent case in http://www.pctoledo.com.br/forum/:

http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=18595

CreateObject()

hbwin - win_OleCreateObject()
xhb (xHarbour compatibility) xhb_CreateObject()
HMG Extended: CreateObject()
HMG3: CreateObject()
xHarbour: CreateObject() or xhb_CreateObject(), not sure

Why these too many CreateObject()?
Why Harbour have a xHarbour compatibility if libraries are not compatible with xHarbour?

Some xHarbour users create another "CreateObject()" to be sure the correct CreateObject() is inside EXE.

On Harbour:   oSoap := win_OleCreateObject( "MSXML2.ServerXMLHTTP" )

On xHarbour: Depends, may be oSoap := CreateObject( "MSXML2.ServerHMLHTTP.6.0" )

This is not a Harbour problem, but affects Harbour when samples of these libraries mix several CreateObject versions.
And when a xHarbour users try use Harbour .... if use same sample will get error, because in xHarbour do not works in same way, or is using a not compatibile CreateObject().
And may be this is the reason to libraries do not use HBMK2 - no standard on functions, but not about Harbour.

What I think:
If update xHarbour to works as Harbour... why not use Harbour that is ready.
If update Harbour 3.2 to works as Harbour 3.4... why not use Harbour 3.4 that is ready.
Library on Harbour to work as xHarbour... not sure how xHarbour works using some libraries...
xBase is powerfull, but seems that each year, it is divided into more small groups, less powerfull than before.

We need all developers, from Harbour and xHarbour and from libraries.
At momment each one create problems to another, and to users, where serveral do not understand and only copy samples, that sometimes works and sometimes not.
Not sure on how is the better way to solve this question, because there are several people envolved, several working projects, several libraries.

José M. C. Quintas

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

[Angel Pais]

Thank yopu for your time.
See below...

El 16/09/2017 a las 04:42 p.m., vszakats escribió:

What is your oppinion about this:
https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm
Would it be feasible ?

I've tried that a few month ago and even added as a new target

to 3.4, named 'abstr' (as abstract). Looked pretty interesting, with

even more interesting possibilities, but with lots to do to make it

production ready.

Fun facts: harbour.js (the compiler) is 4.2MB in size, hbmk2.js

is 27MB, hbrun.js was 32MB. They all start up correctly in the

browser.

Very interesting to know !

WebAssembly makes it possible to run Harbour apps directly

in the browser. _In theory_ you can save rewriting your app and

run it as-is there, with the cost of added complexities. In theory,

because to reach this production level, quite a bit of extra code

and logic needs to be created to make this go smoothly. Then

the app code most definitely needs to be rethought to accommodate

for the browser as its new environment (f.e. you don't have

a filesystem there.)

Excelent !

I'd rather take the approach of Lorenzo: a Harbour as a

server-side backend, f.e. behind nginx or similar and a browser

layer using popular standard like JS (I really hope that with 

WebAssembly, the world will get more languages here.),

and optionally native mobile apps that can tap on that same

server.

 

That's what i have now:
Servers in: react, apache/cgi, apache+/php, harbour's httpd and xbase++/xb2net (soap web server).
Clients.  Http+css+js, native harbour/json, native xbase++/xb2net.

So now I have to handle 5 different syntaxes: 2 dialects of xbase, html, css, javascript and php.
I very dislike javascript lousy/confusing behaviour and debugging is a nightmare.
It would very nice in the future to substitute javascript with harbour scripts in my web apps.

Thank you again !
Angel Pais

PD: I also use other packages like FWEB for web apps, and LIVECODE for crosplatform dev ( I don't like it very much).
PD2: This is the Babel Tower of programming and I'm a simple accountant.

[vszakats]

Hi Angel,

On Saturday, September 16, 2017 at 11:56:42 PM UTC+2, Angel Pais wrote:

server-side backend, f.e. behind nginx or similar and a browser

layer using popular standard like JS (I really hope that with 

WebAssembly, the world will get more languages here.),

and optionally native mobile apps that can tap on that same

server. 

That's what i have now:
Servers in: react, apache/cgi, apache+/php, harbour's httpd and xbase++/xb2net (soap web server).
Clients.  Http+css+js, native harbour/json, native xbase++/xb2net.

So now I have to handle 5 different syntaxes: 2 dialects of xbase, html, css, javascript and php.
I very dislike javascript lousy/confusing behaviour and debugging is a nightmare.
It would very nice in the future to substitute javascript with harbour scripts in my web apps.

I think using multiple language is inherently inevitable and not

a bad thing. It's not just the language syntax but their library/API

environments. F.e. if Harbour could compile directly to WebAssembly,

it'd be real nice, but it'd still feel different because you wouldn't

have a SUBSTR() function. As soon as you have that, or even

RDDs, that's a hefty package. Nevertheless, a "better JS" would

be nice.

What's important though is to have smooth ways for these

components to communicate with each other. What remains is

to maintain sanity as a developer / devops.

Thank you again !

You're welcome!

 

Angel Pais

PD: I also use other packages like FWEB for web apps, and LIVECODE for crosplatform dev ( I don't like it very much).
PD2: This is the Babel Tower of programming and I'm a simple accountant.

It is :)

I still haven't made a full jump to webapps, but getting prepared

for the Babel!

-Viktor

[vszakats]

Hi José,

On Sat, Sep 16, 2017 at 10:45 PM, José Quintas wrote:

A recent case in http://www.pctoledo.com.br/forum/:

http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=18595

CreateObject()

hbwin - win_OleCreateObject()
xhb (xHarbour compatibility) xhb_CreateObject()

(It should be CreateObject() in xhb lib, but I understand it's confusing)

 

HMG Extended: CreateObject()
HMG3: CreateObject()
xHarbour: CreateObject() or xhb_CreateObject(), not sure

Why these too many CreateObject()?
Why Harbour have a xHarbour compatibility if libraries are not compatible with xHarbour?

Because the whole Harbour "ecosystem" is a huge mess.

Reasons are many.

In Harbour we have a good quality implementation (written

by Mindaugas and Przemek), that was rewritten from scratch

(before that we had _two_ parallel, inferior implementations

inside the codebase), moved to its proper component, bugs

fixed and maintained/updated ever since (recently in last

months by Przemek), and ideally everybody should use that

one and only that one, from 3.2 or 3.4. (if in doubt, go with 3.2)

Harbour also has its 'xhb' library, which was created (it was

my - bad - idea many years ago) with the intent to offer xHarbour

APIs in an xHarbour compatible way, so xHarbour apps can be

recompiled with Harbour, just by adding this library, and make

apps work with both compilers. I've never used this library and

besides Przemek, nobody else ever contributed to it. Of course

the effect isn't 100% and there may even be bugs, I don't know

what exactly is the case for this particular function, though I

believe the OLE compatibility stuff should be solid, it's the work

of Przemek and it's a wrapper to the native implementation. There

are also some things we cannot or don't want to emulate fully

and some other things came broken from xHarbour sources

directly, some of these have been fixed, some not.

The point is: It's a compatibility layer, extra complication,

I don't recommend it for production.

See also: https://github.com/vszakats/harbour-core/blob/master/contrib/xhb/WARNING.txt

Use native Harbour functions (including hbwin) instead. If

there is suspected problem with that one, report it with example

code.

Why HMG, HMG3, even FiveWin has its own OLE interface

implementation and API, I don't know, but I'm sure everybody

has a story.

OLE interface is complicated, it's enough to have a single

one of it, I definitely agree.

On Harbour:   oSoap := win_OleCreateObject( "MSXML2.ServerXMLHTTP" )

On xHarbour: Depends, may be oSoap := CreateObject( "MSXML2.ServerHMLHTTP.6.0" )

Stick with the Harbour one.

 

This is not a Harbour problem, but affects Harbour when samples of these libraries mix several CreateObject versions.
And when a xHarbour users try use Harbour .... if use same sample will get error, because in xHarbour do not works in same way, or is using a not compatibile CreateObject().
And may be this is the reason to libraries do not use HBMK2 - no standard on functions, but not about Harbour.

Well, hbmk2 is just a build tool, there is no fixed set of functions.

At the end, app developers are responsible what they use and

what they link.

Probably unrelated but with BCC/FiveWin/xHarbour communities

it's normal practice to link the _same function from multiple places_

and suppress the linker warnings (it's suppressed automatically

by the provided build tools/batches!). This makes it even worse,

because nobody even knows which copy was linked to the final

exe. This has been discussed a million times and there is just no

reason at all for this practice - none. Yet, it prevails, maybe because

even though it's incorrect, it's easy and works in some/most cases.

What I think:
If update xHarbour to works as Harbour... why not use Harbour that is ready.
If update Harbour 3.2 to works as Harbour 3.4... why not use Harbour 3.4 that is ready.
Library on Harbour to work as xHarbour... not sure how xHarbour works using some libraries...
xBase is powerfull, but seems that each year, it is divided into more small groups, less powerfull than before.

Yep, pretty sad :(

We need all developers, from Harbour and xHarbour and from libraries.
At momment each one create problems to another, and to users, where serveral do not understand and only copy samples, that sometimes works and sometimes not.
Not sure on how is the better way to solve this question, because there are several people envolved, several working projects, several libraries.

Back then when I still had some hopes, I believed that there

should be a single compiler package (Harbour core), its list

of default contribs, and every 3rd party package, including

HMG, HMG3, MiniGUI, FiveWin, whatever, would be

freeware/payware libraries installed in addition and linked/used

freely.

It's also how every other popular language works on the planet.

(hbmk2 made its .hbp/.hbc/project standardization effort with

that mind, but the idea never got across to the communities or

most 3rd party lib developers.)

But, nowadays several library producers (FiveWin, MiniGUI, maybe

even HMG) will provide you with their own build of the Harbour

compiler/core, including various patches/build options, and similarly

named, but incompatible libraries and functions. xHarbour is basically

the same, but with a dated and incompatible compiler/core.

So in effect you must use the compiler that your library provider

provides, choose the C compiler he has chosen for you.

It's backwards.

What to do? I don't know. For my own use, I try to use Harbour

core/contribs only and some limited number of components I can

build from source code. It's not a solution for many people, and also

for me it's very costly and limiting.

-Viktor

[do...@people.net.au]

Firstly thanks to Viktor for all his great work.

I just downloaded 3.4 and compiled my existing code base and only had to add one library reference (-lhbpcre2)

The xBase language is fantastic in that it is natural and extensible and has naturally been able to be extended to encompass object orientation.

So why isn't it more widely used?

It offers so many options but isn't an out of the box solution.  A new user essentially has to decide:

What version of (x)Harbour
What compiler
What GUI library
What database

There is some very useful documentation but faced with the above most potential new users never really get started.  That pretty much leaves us with those of us who were converted in the dBase/Clipper days.

As I see it we are facing an almost impossible decision.  Supporting multiple platforms and multiple compilers on the various platforms is simply making the maintenance / language enhancement task too big.  Which makes cutting down the number of compilers supported the logical answer.

However if, for example, BCC support was dropped that might fracture an already small community even further with its own inherent problems.

It would be nice if we could somehow reach agreement on a strategic direction and get the maintainers of the various libraries to agree on a restricted range of compilers to take effect from some future date - maybe April 2018.  I don't see that as such a big task.  I have just moved my GUI library from GTK2+ to GTK3+ which involved, I would have thought, significantly more changes than moving to a different C compiler.  (I use Linux as my platform so gcc is pretty much the obvious compiler choice.)

I think that it would also be good to clearly split the core language and its various optional enhancements but have them available from the one source.

Currently I am working in a rather demanding job but do hope to at least semi retire in the not too distant future.  I would like to contribute towards the future of Harbour if and when that happens.  But we need to secure that future.

Regards
Doug

[Bacco]

Hi All

My 2 cents: if Harbour devs decide to drop things like BCC, the ones that still use it will need to move forward anyway, be it other ecosystem or simply other compiler, probably the latter when applicable.

I believe in most cases those with complex build systems and environments are tied too much to the past, and some just because they don't want to get out of their comfort zone - sometimes an illusory one, as moving on will make peope finally realize that most of the archaic solutions aren't needed anymore, as even hbmk2 alone can handle complex scenarios with ease.

I can imagine that the best scenario would be an official (big one) announcement that support for BCC and other outdated things will be dropped completely (removed from the source also) in some **future** date, so users can realize that they need to move on unconditionally, but with enough time to rethink their systems.

Seriously, I think it's unfair Harbour development be slowed down because people don't want to do their homework.

NOTE: I really know that there may be exceptions, but in this case the interested parties should came and post their scenarios in a more detailed way to make their point. Supporting extreme outdated technologies should require very consistent reasons.

That said, I'm ready... you can start throwing stones now :)

Regards

Bacco

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.

[ToninhoFWi]

I agree.

I'm moved from BCC to MSVC 2015 some months ago and

I don't have anyting to complain, *BUT* believe me, there are A LOT

of Harbour users that still using BCC, take a look please:

https://medium.com/harbour-magazine/harbour-magazine-survey-results-resultados-de-la-encuesta-de-harbour-magazine-4faa69605e30

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

[Mario H. Sabado]

A LOT of Harbour "users" using BCC...  means greater possibility of potential volunteers to maintain BCC support?

[vszakats]

Hi Bacco,

On Monday, September 18, 2017 at 11:13:29 AM UTC+2, Bacco wrote:

Hi All

My 2 cents: if Harbour devs decide to drop things like BCC, the ones that still use it will need to move forward anyway, be it other ecosystem or simply other compiler, probably the latter when applicable.

I believe in most cases those with complex build systems and environments are tied too much to the past, and some just because they don't want to get out of their comfort zone - sometimes an illusory one, as moving on will make peope finally realize that most of the archaic solutions aren't needed anymore, as even hbmk2 alone can handle complex scenarios with ease.

I can imagine that the best scenario would be an official (big one) announcement that support for BCC and other outdated things will be dropped completely (removed from the source also) in some **future** date, so users can realize that they need to move on unconditionally, but with enough time to rethink their systems.

Not sure how big such announcement should be, but I've announced

around the release of 3.0 that it will be the last one where BCC binaries

will be shipped and later (6 years ago in 2011) the BCC nightly binaries

were terminated as well.

I believe anybody who was just a tiny bit paying attention to this space

(where development is going on), must know that BCC was very much

unwelcome and discouraged by Harbour devs for a long time. The topic

has been discussed here quite a lot. Those who wanted to, could hear

the message around the 2.0 release, that's in 2009, 3.0 was in 2011.

In 3.4, BCC, POCC and XCC (all versions) were deprecated in

December, 2016, by this commit:

   https://github.com/vszakats/harbour-core/commit/e3e9b26fba4576a10cdf6de8106f52b44a75d68f

In practice it means that I no longer accept Issues and

Pull Requests (patches) for these platforms, and they are not

considered when adding new components or updating existing

ones. It also means that special cases maintained for these

platforms will be gradually toned down and I'll also ignore

BCC-specific forum messages, reports and in-source TODOs.

What I can promise is that till 2017-12-31, support for these

platforms won't be actively removed.

It'd be nice to coordinate that with 3.2, though I'm not sure who

should be responsible to speak on its behalf.

Seriously, I think it's unfair Harbour development be slowed down because people don't want to do their homework.

NOTE: I really know that there may be exceptions, but in this case the interested parties should came and post their scenarios in a more detailed way to make their point. Supporting extreme outdated technologies should require very consistent reasons.

Not only extremely outdated technologies, but toolchains that are not

accessible for open source development, due to they licensing and/or

price and/or limited platform support and/or their incompatibility. It is

not a coincidence these compilers are not used/supported anywhere

in the open source scene.

Even if these aspects would be right, any new compiler would have to

offer a substantial advantage over existing, good and widespread ones

to justify pouring development resources into them. (CLANG/LLVM

jumped this by making it a plug-in replacement for existing toolchains

and making it fully free/open.)

-Viktor

[Maurício Faria]

As expected, no unanimity...
 
But a few thoughts:
 
 - BCC is used by a large number of users, but probably the most part of them are able to port to MinGw. I used to use BCC myself and ported to MinGw without major issues, only some work.
 - 3.2 will not be eliminated, it will be exactly as it is, only declared stable. If BCC is really needed, just stay with 3.2...
 - 3.4 will still be open source and BCC support can be maintained by anyone interested and capable of it.
 - This is a community and divergences are always part of communities. When a major one comes, the best way to solve them with a minimum impact is to vote.
 
So, lets vote.
 
My personal vote:
 
Declare 3.2 stable, freeze and maintain bugfixes ?     Yes.
 
 
[[]] Maurício Faria
 

[Bacco]

Hi, Mauricio

The only problem I see with voting is that it considers only the absolute number of participants, and not it's relevance/involvment with the project (and this is why democracy fails miserably in some places, like where I live - no "weight" on votes). This kind of decision should be made by the developers, based on their technical experience and their knowledge about the community, and the project goals itself. Of course we that benefit from it can make our point of view known to add the value to the discussion and help the devs make their decisions, but we can't (and shouldn't IMHO) simply decide anything here by mere majority.

Everyone that want something diverse from that decision is free to fork the codebase and do it as he/she wishes.

Additional consideration: the list participants are a tiny fraction of the user base, and even if every vote was given the correct weight, it would be unfair because it wouldn't reflect necessarily what the whole community wants.

Unless, of course, you mean that we are voting only to do some extra feedback to the devs, but I really prefer we simply bring our point of view here as we are doing already, to avoid wrong expectations.

Regards,

Bacco

--

[Francesco Perillo]

Mario wrote:

A LOT of Harbour "users" using BCC...  means greater possibility of potential volunteers to maintain BCC support?

Mauricio wrote:
 - BCC is used by a large number of users, but probably the most part of them are able to port to MinGw. I used to use BCC myself and ported to MinGw without major issues, only some work

Yes, there are a lot of BCC users out there but I think that a lot of them use whatever their tool/ide/framework provider tells them to use. Once I read they can't even upgrade Habour version by themselves.

As I said, a lot of them are great "business" programmers but they *currently* don't have the skills to maintain BCC port. And probably they don't want to invest their time...

[Massimo Belgrano]

Possible a sample for better understand?

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francesco Perillo]

From their web sites:

HMG extended: Borland C++ compiler (or MinGW, or Visual C, or Open Watcom, or Pelles C compilers)

Minigui: mingw32 or 64 bits

Fivewin: Borland C 5.82 FiveWin can also be used with Microsoft Visual C compiler (including the free Express edition), and also with the GNU MinGW (gcc) compiler.

So it seems compiler support is not really a problem for the libraries, but it is just a decision of the "business" developers.

[vszakats]

Hi Francesco,

So far so good, though if I understand it correctly, this is what

these respective sources support in theory. IOW they can be

built from source code using these tools.

It'd be interesting to see which C compiler is used in pre-built

distribution packages, and whether using any of the modern

alternatives have any downsides? (f.e. certain features partially

implemented, missing or unstable)

I'd also add xHarbour to this mix, where at least mingw 32-bit

and MSVC are both supported (AFAIK), though I think non-free

lib binaries are BCC-only (but those are built-against xHarbour

anyway). Maybe XCC is also involved in some ways.

-Viktor

[Patrick Mast]

Hey Viktor,

So why is a large portion Harbour community stuck with pirated

and/or outdated C compilers, like BCC 7.x/5.x?

Anyhow I'd encourage everybody to step up and experience GCC

or the slightly worse, but safer bet, MSVC, which is sort of the

Windows-standard anyway. It's just a C compiler after, not the end

of the world. 

I agree 😁

The Community edition of Microsoft's Visual Studio is free:

https://www.visualstudio.com/downloads/

Patrick

[Patrick Mast]

Hey Viktor,

I'd also add xHarbour to this mix, where at least mingw 32-bit

and MSVC are both supported (AFAIK), though I think non-free

lib binaries are BCC-only (but those are built-against xHarbour

anyway). Maybe XCC is also involved in some ways.  

FYI; xHarbour Builder, the commercial distribution of xHarbour, is build using XCC (PellesC) and MSVC.

Patrick