2024-02-09 20:56 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)

[Przemysław Czerpak]

2024-02-09 20:56 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* contrib/hbcurl/core.c
* contrib/hbcurl/hbcurl.ch
+ added HB_CURLOPT_XFERINFODATA and HB_CURLOPT_XFERINFOFUNCTION
! use CURLOPT_XFERINFO* instead of depreciated CURLOPT_PROGRESS*
to implement HB_CURLOPT_PROGRESSBLOCK
! do not use depreciated CURLOPT_RANDOM_FILE and CURLOPT_EGDSOCKET,
they serve no purpose anymore
+ added macros for new protocols
+ added HB_CURLOPT_PROTOCOLS_STR and HB_CURLOPT_REDIR_PROTOCOLS_STR
! use CURLOPT_PROTOCOLS_STR and CURLOPT_REDIR_PROTOCOLS_STR instead
of depreciated CURLOPT_PROTOCOLS and CURLOPT_REDIR_PROTOCOLS
* emulate CURLOPT_PROTOCOLS and CURLOPT_REDIR_PROTOCOLS using
CURLOPT_PROTOCOLS_STR and CURLOPT_REDIR_PROTOCOLS_STR in new curl
versions
+ added support for HB_CURLOPT_MIMEPOST
! use CURLOPT_MIMEPOST to emulate depreciated in new curl versions
CURLOPT_HTTPPOST
+ added support for HB_CURLOPT_PROXY_SERVICE_NAME
! use CURLOPT_PROXY_SERVICE_NAME to emulate depreciated in new curl
versions CURLOPT_SOCKS5_GSSAPI_SERVICE
+ added HB_CURLINFO_ACTIVESOCKET
! use CURLINFO_ACTIVESOCKET instead of depreciated CURLINFO_LASTSOCKET
+ added HB_CURLINFO_SIZE_UPLOAD_T, HB_CURLINFO_SIZE_DOWNLOAD_T,
HB_CURLINFO_SPEED_DOWNLOAD_T, HB_CURLINFO_SPEED_UPLOAD_T,
HB_CURLINFO_CONTENT_LENGTH_DOWNLOAD_T and
HB_CURLINFO_CONTENT_LENGTH_UPLOAD_T
! use CURLINFO_*_T actions instead of depreciated ones which operate
double as file offset and emulate old actions using new ones in
new curl versions

* contrib/hbssl/evp.c
! Do no use EVP_cleanup() in OpenSSL 1.1.0 and newer.
It no longer has any effect.

* contrib/hbssl/hbssl.h
* set OPENSSL_API_COMPAT to 1.2.0 to pacify OpenSSL 3.0 API.
It hides OpenSSL 3.0 warnings but we should update the code to use
new suggested API.

* contrib/hbwin/olecore.c
! invoke assign methods with DISPATCH_PROPERTYPUTREF instead of
DISPATCH_PROPERTYPUT if assigned value is OLE object. If such
functionality is not implemented by the object (some OLE
implementations do not support it and returns DISP_E_MEMBERNOTFOUND)
then call it again but in previous form with DISPATCH_PROPERTYPUT

* include/hbapirdd.h
* src/rdd/dbcmd.c
! fixed error codes set by DbSetRelations() to be Cl*pper compatible

* src/rdd/dbcmd.c
+ accept symbol items in Select() and DbSelectArea() just like in
( <alias> ) -> <exp>

* include/hbcompdf.h
* include/hbexprb.c
* src/common/funcid.c
+ added compile time optimization for Select() function without parameters
+ added compile time optimization DbSelectArea( <nNum> | <sSym> )
+ added support for hb_PIsByRef( @localVarName ) -> <lPassedByRef>
When the parameter is passed by reference Harbour verifies if it's
existing local variable and change it to its index in parameter list
so effectively it works like hb_IsByRef( @localVarName ) in xHarbour

* contrib/xhb/hbcompat.ch
+ added translations for
hb_PIsByRef( @<localVar> ) <=> hb_IsByRef( @<localVar> )

best regards
Przemek

[Enrico Maria Giordano]

Il 09/02/2024 20:56, 'Przemysław Czerpak' via Harbour Developers ha scritto:

> 2024-02-09 20:56 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
> * contrib/hbcurl/core.c

hbcurl\core.c(1207): error C2440: '=': cannot convert from 'CURL *' to
'curl_mime *'
hbcurl\core.c(1207): note: Conversion from 'void*' to pointer to
non-'void' requires an explicit cast

I would fix it myself but I gave up to make unlistened pull requests to
Harbour repository, sorry.

--
Enrico Maria Giordano

http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg

[Antonio Linares]

Dear Przemek,

>  * contrib/hbwin/olecore.c

many thanks

best regards

[Antonio Linares]

Przemek,

Whats your advice on this code ? Shouldn't Harbour issue an error there ?

#include "hbclass.ch"

function Main()
   local oTest := Test()
   oTest:any( 123 )
   ? oTest:any
return nil

CLASS Test
   DATA any
ENDCLASS

thank you

[Przemyslaw Czerpak]

Hi,

The problem is Cl*pper compatibility. Clipper compiles such code

    ? oVar:name

as

    ? oVar:name()

and

    oVar:name := 123

as

    oVar:_name( 123 )

and people knows about it so they have a lot of code

which will stop to work if we implement this functionality.

The problem is also with macrocompiler. Unlike Harbour

Cl*pper does not support expressions like: &("oVar:name:=123")

in macrocompiler so programmers had to use workarounds

for it: &("oVar:_name(123)"). There was no alternative so we

should expect that code using it is not unusual.

If we divide data and code messages then we broke such code.

It means that it would have to be optional, i.e. using compiler

switch or different hbclass*.ch files though the second solution

is not clear enough for me. Now hbclass.ch is necessary only for

code which defines new classes but not for code which uses them

but to inform compiler that it should generate different PCODE

for data and code messages we need it for the second case too

so in my opinion compiler switch is better.

There are also two additional extensions which have to be

addressed:

- macro messages (see MACRO MESSAGES in xhb-diff.txt)

- access/assign methods which are in fact code messages but

should be treated them as data ones so we should generate RTE

when they are used as code (with ()). I expect that this will exploit

a lot of user code which will stop to work generating RTE it means

that probably we will have to add global HVM switch to disable

this RTE, i.e. using new _SET_* action.

Anyhow such modification would resolve yet another problem.

Using data and code messages with the same name and in the past

I was thinking about it and I even created quite simple solution in

my head. Anyhow it introduces incompatibility for exiting code so

I wanted to join it with support for real class objects and class

variables and methods. In fact neither Harbour nor xHarbour

supports real class objects. We only have some limited support

emulating class messages as object messages. It creates name

conflicts and has fatal speed overhead when class messages

are send to class object, i.e. myClass():classMsg() in Class(y) or

xBase++ is very fast because myClass() is extremely simple and

returns reference to class object created when it was called first

time and to this object reference class message is sent.

In Harbour and xHarbour each call call to myClass() creates

new object instance of the given class executing its constructors

(in Class(y) and xBase++ constructor is activated by class method

:new()) then we send to this object message which can work due

to our emulation and finally the created object is destroyed

executing all its and its ancestors destructors. 

It's very inefficient way with many bad side effects.

Unfortunately I've never found time to implement it :(

best regards,

Przemek

W dniu 11.02.2024 o 09:56, Antonio Linares pisze:

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-devel/d63967ea-228a-4873-9bb1-acfb1554a096n%40googlegroups.com.