[Harbour] test, don't read
test -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] vise the return of the functions: TimeToSec and SecToTime...
Ale,
yo no hablo portugues (nor spanish for that matter :))
Anyway, I did some tests with clipper 5.2e and I've reported what clipper
gives as result.
He probado con el compilador clipper 5.2e y les he informado de los resultados
(this is google translation).
Best regards.
Maurilio
Ale SB wrote:
> Maurilio,
>
> (desculpe, nao entendi sua resposta)
> sorry, did not understand your answer.
>
> (As Funçoes TimeToSec(cTime) e SecToTime(nSec), estao com os retornos
> errados.)
> The Functions TimeToSec (ctime) and SecToTime (NSEC), are with the returns
> wrong.
>
> TimeToSec( "24:00:00" ) //-->
> (Esta Retornando) This recurring == 0.00
>
> (Sendo que o correto deveria ser) Being that the correct should be
> TimeToSec( "24:00:00" ) //--> 86400
>
> (O mesmo acontece com a SecToTime()) The same goes for SecToTime ().
>
> Thanks, Ale
>
>
>
>
>
>
> Maurilio Longo wrote:
>> Ale,
>>
>> clipper 5.2e gives
>>
>> TimeToSec("24:00:00") -> -1
>> TimeToSec("23:59:59") -> 86399
>> TimeToSec("00:00:00") -> 0
>> SecToTime(86400) -> "00:00:00"
>>
>>
>> Best regards.
>>
>> Maurilio.
>>
>> Ale SB wrote:
>>> Please review the functions of ctTime.Prg.
>>>
>>> ? TimeToSec("24:00:00") //--> 0.00
>>> ? SecToTime(86400) //--> "00:00:00"
>>>
>>> right should not be:
>>>
>>> ? TimeToSec("24:00:00") //--> 86400
>>> ? SecToTime(86400) //--> "24:00:00"
>>>
>>> Thanks, Ale
>>>
>> --
>> __
>> | | | |__| Maurilio Longo
>> |_|_|_|| farmaconsult s.r.l.
>>
>>
>> ___
>> Harbour mailing list (attachment size limit: 40KB)
>> Harbour@harbour-project.org
>> http://lists.harbour-project.org/mailman/listinfo/harbour
>>
>>
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re[Harbour] vise the return of the functions: TimeToSec and SecToTime...
Ale,
clipper 5.2e gives
TimeToSec("24:00:00") -> -1
TimeToSec("23:59:59") -> 86399
TimeToSec("00:00:00") -> 0
SecToTime(86400) -> "00:00:00"
Best regards.
Maurilio.
Ale SB wrote:
> Please review the functions of ctTime.Prg.
>
> ? TimeToSec("24:00:00") //--> 0.00
> ? SecToTime(86400) //--> "00:00:00"
>
> right should not be:
>
> ? TimeToSec("24:00:00") //--> 86400
> ? SecToTime(86400) //--> "24:00:00"
>
> Thanks, Ale
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14511] trunk/harbour
Przemysław Czerpak wrote: > modifications. I can compile the .PRG client and server example from > xHarbour.com OLE server page. I only have to link at least one of > components (server or client) statically because both linked dynamically > with the same harbour.dll shares the same HVM so server fails inside > hb_vmInit(). I can add protection against multiple HVM initialization > anyhow using the same HVM for client and server code introduces > interactions between them which do not use OLE API, i.e. they will > use the same static variables. > In OS/2 this is a .dll definition at compile time, that is, INITINSTANCE clause inside .def file which tells the OS that the data segment has to be private for each process that attaches to that .dll. Hope this helps. Maurilio. PS. I'm sorry I haven't tested your serial routines under OS/2 yet, I simply don't have any spare time right now, but they build fine, at least. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Slow create index under threads
Przemyslaw, Przemysław Czerpak wrote: > If you have to keep existing OS then you can try to increase the memory > used by Harbour RDD driver for buffers during indexing. > In src/rdd/dbfcd/dbfcdx1.c[9191] I described how DBFCDX allocates memory. > As you can see in the comment it should not allocate more then 35Mb memory. > For modern computers such memory block seems to be quite small so you can > try to increase it, i.e. to 256MB. > In line 9167: >ulSize = ( 1L << 20 ) / ( iLen + 4 ); > change the default memory block size, i.e.: >ulSize = ( 1L << 27 ) / ( iLen + 4 ); > recompile DBFCDX (all whole Harbour) and make speed tests. What about a runtime Set() option and/or have the default using more memory? Todays pc should be able to handle 256Mb buffers without problems. Best regards. Maurilio -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour for the iPad - ok
Viktor Szakáts wrote: > Hi Maurilio, > >> what about using -gc3 to have an application which is not executed by a VM? > > What you get is a .c source regardless of > the -gc mode, but the problem is that we're > running a translator from .prg to .c. In that > sense it should not make a difference. > Yes, but this translator is run only once, during program build, from there on it is a pure machine code executable. I think the problem with Apple is that they don't want the VM running on iPhone/iPad because they cannot be sure the code does not contain malicious parts/virus/exploits and so on. > The other thing is that if you want to access > any Apple API from .prg, it's inevitable > to go through a set of wrapper functions, which > is again something Apple seems to not like, > because this way they are in the hands of wrapper > developers regarding what feature is accessible > from .prg code and how fully it is implemented. > I don't think so, you simply have some .c code which is a wrapper to something that, in the end, becomes a .c source which gets compiled/linked to a pure cpu specific assembler code. > At least that's Apple's intent. As to how they > can defend these rules "in court", I have no idea. > They don't defend it in court, they simply will not put your program on iTunes, so you cannot distribute it. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour for the iPad - ok
Viktor, what about using -gc3 to have an application which is not executed by a VM? Maurilio. Viktor Szakáts wrote: >>> You have to be a registered with Apple developer in order to access to >>> that SDK. They are getting too closed and restrictive... :-( >> I am a registered developer and the registration >> was fully free. This means I can now open XCode and >> create an iPhone app project. An iPhone emulator >> is also part of the package. > > OFF > > Okay, so an iPhone app can be created to run in > the simulator, but for a final iPhone app, it > needs to sign the app and for this a paid registration > is required. It doesn't even reaches compilation > phase. > > /OFF > > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Server Pages
Jorge Aldo G. de F. Junior wrote: > This is a kind of FCGI, not what i am looking for... > Yes > And Xitami is windows only, my server can run on any FreePascal > supported platform : > > Windows, Linux, FreeBSD, AmigaOS, BeOS, AtariOS, whatever... > Xitami was multiplatform as well and the LRWP protocol is platform neutral. > I just want to embed harbour (hbrun) on my server to be able to serve > harbour pages. > Ok, I did not clearly understand this, sorry. Maurilio. -- ______ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour Server Pages
Jorge, if you can add to your server the LRWP protocol of the old xitami web server you can have what you need and it will be very fast too. I'm right now using a cgi-bin program written in harbour which interprets .prg code to produce .html pages, after first invocation the interpreter (called hscript) connects back to the server via LRWP and registers itself for the page it was first called for. >From there on every other call to that page goes from the webserver to hscript via LRWP protocol until hscript finds it has been idle for some time and it shuts down making the entire process repeat when that page will be called again in the future. I try to better explain: - http request reaches web server - web server sees it is for a page with .prg in its name - web server calls cgi-bin/hscript url - hscript creates the page as a normal cgi-bin program - before ending hscript starts itself as an LRWP client - web server returns .html page - web server accepts hscript as handler for that page - new requests go to the hscript client via LRWP This way every instance of hscript is a separate process (if it has problems it does not create problems to the web server) and after first call, all other calls to the same page are really very fast (think about it, all .dbf are already open, for example). If you want I can send you the LRWP protocol specifications, they're public, it is a very simple protocol, should require you more or less a day to fully implement and test it. Best regards. Maurilio. Jorge Aldo G. de F. Junior wrote: > Hello harbour developers, > > I've developed a webserver (with cookies, https etc) with freepascal > and i want to help creating an harbour server pages module for it. > > If interest arise i can add chroot functionalty to the server (The > major lacking functionality). > > My idea is to allow usage of harbour in server pages, alike PHP. > > I need help from harbour developers to help me integrate harbour to my > server : http://powtils.googlecode.com/svn/dev/tools/lightwebserver/ > > if interest arise i can rewrite it to be completely harbour oriented > (IE, serving static content + harbour pages). > > I think that developing pure clipper solutions (including web > development) is an old desire of the comunity and i think i can help a > lot with this project. > > thank you in advance, J. Aldo. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: CLASSES - Instance Variable as Object - Access/Assign Elsewhere
Angel, ACCESS/ASSIGN keywords in method definition are a xbase++ compatibility issue. Maurilio. Angel Pais wrote: > AFAIR inline methods are discouraged since their access is slower than > normal ones. > > HTH > Angel > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14279] trunk/harbour
Viktor, read this sentence of mine: Maurilio Longo wrote: > Viktor, > > PS. Come from the win32 that was inside package when we were trying to build > hbrun.rc > as it comes from the win32 ico that was inside package folder at the time we were... Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14279] trunk/harbour
Viktor, here it is the OS/2 version. Maurilio. PS. Come from the win32 that was inside package when we were trying to build hbrun.rc Viktor Szakáts wrote: > Hi Vailton, > >> We have the MAC version too (inside harbour.ico.zip): >> http://www.harbour-project.org/logos.html > > Many thanks, I've missed it. Will upload it. > > Can you create an OS/2 icon, too? Probably Maurilio or David > can help you pointing to the right tool and format. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. <>___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to set XON/XOFF under hbtpathy ?
Shum, there is no XON/XOFF support under hbtpathy right now. Best regards. Maurilio. Shum wrote: > Hi All, > > As title (by using what function ?) ... > > Shum -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Happy Easter
Happy Easter from me as well to the entire Harbour crew and in particular to our Commanders! :) Il giorno 03/apr/2010, alle ore 18.14, Viktor Szakáts u> ha scritto: Same from me to everyone. [ plus this year, it's also my 'special day' ] Brgds, Viktor On Sat, Apr 3, 2010 at 2:52 PM, Fernando Athayde > wrote: Happey Easter to all Regards Fernando Athayde De: Massimo Belgrano Para: Harbour Project Main Developer List. > Enviadas: Sábado, 3 de Abril de 2010 4:03:05 Assunto: [Harbour] Happy Easter Happy Easter and Profitable and Prosperous Business around Harbour -- Massimo Belgrano Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, Viktor Szakáts wrote: > That's the other thing. We can store and OS/2 .ico in > SVN, no problem, but who will maintain it, if it changes? > Anyone, a lot of graphical programs can output OS/2 variant of .ico files. > (plus it only has a point if it can be used by gcc) > I've tested windres with OS/2 ico and windres says there's no .ico inside the file :) So, it is broken. > Well, not a huge loss anyway. The main driving force for > Windows .ico was to give a better look when installed > using .exe installer and added to Start Menu. For OS/2 > we don't have an installer, so it's not huge problem. > Yes, OS/2 has installers as well, of course, but harbour on OS/2 just requires to be put in a folder and mostly works :) so I've saved the time to setup an installer, till now, at least. BTW, installing GCC could be a lot more of work than install harbour itself. Best regards. > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor Szakáts wrote: > Many thanks for you research. Nevertheless I'd like to > propose to drop this whole feature for OS/2, as it needs > too many irregular hacks and I just don't feel confident > to add deep change for such things in GNU Make system :( > Ok, I agree. > rc.exe looks like a seriously bare/limited tool. > It can create a .res in a particular folder, give we pass the path to it, anyway, I agree it'a a limited tool. > Last thing to check is whether they fixed windres.exe > in recent (4.x?) gcc versions. > I leave this to David, but, anyway, you need the OS/2 format .ico, since the win32 is not shown at all. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, it seems the problem was in adding the win32 .ico to hbrun the cause of the problems reported yesterday. I'm not 100% sure, though, since I've done a thousands different tests. Now, with attached hbrun.rc, harbos2.ico and this command, which, as you can see, I execute from within obj\os2\gcc of hbrun I can attach OS/2 .ico and it shows inside OS/2 gui and even when I start hbrun.exe, the title-bar icon gets changed to the correct one. (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -DOS2 -p ..\..\..\hbrun.rc ..\..\..\..\..\bin\os2\gcc\hbrun.exe Operating System/2 Resource Compiler Version 4.00.011 Oct 10 2000 (C) Copyright IBM Corporation 1988-2000 (C) Copyright Microsoft Corp. 1985-2000 All rights reserved. Creating binary resource file ..\..\..\hbrun.RES RC: RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef D:\OS2\RCPP.ERR ..\..\..\hbrun.rc Writing resources to OS/2 v2.0 Linear .EXE file Writing 1 DEMAND resource object(s) Writing: 3428 bytes in 1 page(s) 1.1 (3428 bytes) Writing Extended Attributes: Default Icon Writing Extended Attributes: Checksum It creates a hbrun.res inside utils\hbrun, which should be deleted somehow and the gcc.mk should be changed to call rc with the above syntax, which I don't know how to do, since as it is now the .mk files add the .res file to the .exe, while rc can do this task, and most important, write the extended attribute of the file with a copy of the .ico, so that it shows inside the OS/2 gui. Let me know. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. <>/* * $Id: hbrun.rc 14258 2010-03-29 20:36:08Z vszakats $ */ #if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ICON 1 DISCARDABLE "../../../../../package/harbos2.ico" #else ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico" #endif ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbrun broken since a few days at least
Ok, it was my system which was "broken" I don't know how, anyway, sorry for the false report of problems. Best regards. Maurilio. Maurilio Longo wrote: > Przemyslaw, > > at 14236 it is still working... maybe a wrong harbour.dll in my path, but I've > double-checked and I did not find it and I always do a > > make clean > > before every rebuild. > > I don't know, I'll keep upgrading/rebuilding until I reach current code and > I'll let you know. > > Maurilio. > > PS. Maybe a copy of it still loaded, since a .dll gets loaded only once and > then shared between the requesting processes; maybe the system was in an > internal inconsistent state, I've also restarted it to be sure :/ > > Przemysław Czerpak wrote: >> On Tue, 30 Mar 2010, Maurilio Longo wrote: >> >> Hi, >> >>> Going back at 14230 works ok, >>> now I'm rebuilding each one commit from here on, even if reading the >>> ChangeLog >>> I don't see changes which could explain my problems. >>> I'll let everybody know what I find out. >> Check if it's not caused by shared builds. >> Maybe only binaries using harbour.dll do not work and the problem >> is caused by wrong harbour.dll version. >> >> best regards, >> Przemek >> _______ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbrun broken since a few days at least
Przemyslaw, at 14236 it is still working... maybe a wrong harbour.dll in my path, but I've double-checked and I did not find it and I always do a make clean before every rebuild. I don't know, I'll keep upgrading/rebuilding until I reach current code and I'll let you know. Maurilio. PS. Maybe a copy of it still loaded, since a .dll gets loaded only once and then shared between the requesting processes; maybe the system was in an internal inconsistent state, I've also restarted it to be sure :/ Przemysław Czerpak wrote: > On Tue, 30 Mar 2010, Maurilio Longo wrote: > > Hi, > >> Going back at 14230 works ok, >> now I'm rebuilding each one commit from here on, even if reading the >> ChangeLog >> I don't see changes which could explain my problems. >> I'll let everybody know what I find out. > > Check if it's not caused by shared builds. > Maybe only binaries using harbour.dll do not work and the problem > is caused by wrong harbour.dll version. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbrun broken since a few days at least
Going back at 14230 works ok, now I'm rebuilding each one commit from here on, even if reading the ChangeLog I don't see changes which could explain my problems. I'll let everybody know what I find out. Maurilio. Maurilio Longo wrote: > No, > > there is something more, every .exe in bin fails apart from hbmk2 ??? > > > 03-30-2010 13:22:58 SYS2070 PID 75c6 TID 0001 Slot 00b0 > E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBTEST.EXE > HBTEST->HARBOUR._hb_parvnl > 127 > > > 03-30-2010 13:26:36 SYS2070 PID 75c7 TID 0001 Slot 00b0 > E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBRUN.EXE > HBRUN->HARBOUR._hb_retclen_buffer > 127 > > > 03-30-2010 13:35:23 SYS2070 PID 75c8 TID 0001 Slot 0094 > E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBI18N.EXE > HBI18N->HARBOUR._HB_FUN_HB_ADEL > 127 > > > Maurilio. > > > Maurilio Longo wrote: >> Hi Viktor, >> >> I was looking into hbrun issue with the icon when I've found out that an >> hbrun >> I have dated 25 march does not run as well. >> >> I get this error: >> >> 03-30-2010 12:36:17 SYS2070 PID 4e34 TID 0001 Slot 00a5 >> E:\HARBOUR\BIN\HBRUN.EXE >> HBRUN->HARBOUR._hb_retclen_buffer >> 127 >> >> >> Which should mean that it does not find _hb_retclen_buffer inside >> harbour.dll, >> hbmk2 from same date runs ok. >> >> What can it be? >> >> Maurilio. >> > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbrun broken since a few days at least
No, there is something more, every .exe in bin fails apart from hbmk2 ??? 03-30-2010 13:22:58 SYS2070 PID 75c6 TID 0001 Slot 00b0 E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBTEST.EXE HBTEST->HARBOUR._hb_parvnl 127 03-30-2010 13:26:36 SYS2070 PID 75c7 TID 0001 Slot 00b0 E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBRUN.EXE HBRUN->HARBOUR._hb_retclen_buffer 127 03-30-2010 13:35:23 SYS2070 PID 75c8 TID 0001 Slot 0094 E:\REPOSITORY\HARBOUR\BIN\OS2\GCC\HBI18N.EXE HBI18N->HARBOUR._HB_FUN_HB_ADEL 127 Maurilio. Maurilio Longo wrote: > Hi Viktor, > > I was looking into hbrun issue with the icon when I've found out that an hbrun > I have dated 25 march does not run as well. > > I get this error: > > 03-30-2010 12:36:17 SYS2070 PID 4e34 TID 0001 Slot 00a5 > E:\HARBOUR\BIN\HBRUN.EXE > HBRUN->HARBOUR._hb_retclen_buffer > 127 > > > Which should mean that it does not find _hb_retclen_buffer inside harbour.dll, > hbmk2 from same date runs ok. > > What can it be? > > Maurilio. > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbrun broken since a few days at least
Hi Viktor, I was looking into hbrun issue with the icon when I've found out that an hbrun I have dated 25 march does not run as well. I get this error: 03-30-2010 12:36:17 SYS2070 PID 4e34 TID 0001 Slot 00a5 E:\HARBOUR\BIN\HBRUN.EXE HBRUN->HARBOUR._hb_retclen_buffer 127 Which should mean that it does not find _hb_retclen_buffer inside harbour.dll, hbmk2 from same date runs ok. What can it be? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14258] trunk/harbour
Viktor, there is another problem, the .ico file is a win32 one, not an OS/2 one, so I've converted it but: 1) you don't see the ico until after you mark the .exe as a PM one (presentation managers, that is GUI). 2) the .exe file, not marked as PM, does not run if built adding the generated .res one even if GCC does not complain. So, I keep reinforcing my memory that console programs on OS/2 cannot have resources added to them during build time. You can change the default icon from OS/2 interface, though. I'll keep searching. Maurilio. PS. rc.exe, by default, creates the .res file in the same dir where the .rc source resides. So, you need to specify a full output file name. Viktor Szakáts wrote: > Hi Maurilio, > >> RC := $(HB_CCPATH)$(HB_CCPREFIX)rc >> RC_OUT := -DOS2 -r >> RC_RULE = $(RC) $(RCFLAGS) $(HB_RCFLAGS) $(HB_USER_RESFLAGS) $(RC_OUT) $< >> BUT, it builds the .res file at the same dir level of hbrun.rc and, even >> moving it inside obj\os2\gcc the final .exe has not the icon, here I fear >> this >> could be caused by the fact that hbrun.exe is a console app, but I'm not sure >> about this issue. >> >> So, can you tell me how to build the correct path to hbrun.res, I mean, how >> to >> add obj\os2\gcc to the clean hbrun.rc file name? >> >> $< >> >> contains the full upward path to hbrun.rc so I have to strip all those >> ..\..\.. and add obj\$compiler\$arch or something like that. > > The most important thing to check is whether gcc's linker > can link the .res file created by rc.exe. You can verify > this outside of our make system using a small example. > > If yes, we should try to avoid -DOS2, which is a manual > hack and should be used only if all other options are out. > For this, we need to find out what is the official way to > detect OS/2 in .rc files. > > Finally we should try to find a way to specify output file > and avoid making local redefine of RC_RULE. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14258] trunk/harbour
Ok, this is it RC_RULE = $(RC) $(RCFLAGS) $(HB_RCFLAGS) $(HB_USER_RESFLAGS) $(RC_OUT) $< $@ so, .res file gets made into obj\os2\gcc subfolder. Now, lets see how to make it show when browsing a folder containing hbrun.exe Maurilio. Maurilio Longo wrote: > Viktor, > > with these rules inside os2\gcc.mk it build a .res file using rc.exe > > RC := $(HB_CCPATH)$(HB_CCPREFIX)rc > RC_OUT := -DOS2 -r > RC_RULE = $(RC) $(RCFLAGS) $(HB_RCFLAGS) $(HB_USER_RESFLAGS) $(RC_OUT) $< > > BUT, it builds the .res file at the same dir level of hbrun.rc and, even > moving it inside obj\os2\gcc the final .exe has not the icon, here I fear this > could be caused by the fact that hbrun.exe is a console app, but I'm not sure > about this issue. > > So, can you tell me how to build the correct path to hbrun.res, I mean, how to > add obj\os2\gcc to the clean hbrun.rc file name? > > $< > > contains the full upward path to hbrun.rc so I have to strip all those > ..\..\.. and add obj\$compiler\$arch or something like that. > > Maurilio. > > > vszak...@users.sourceforge.net wrote: >> Revision: 14258 >> >> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14258&view=rev >> Author: vszakats >> Date: 2010-03-29 20:36:08 + (Mon, 29 Mar 2010) >> >> Log Message: >> --- >> 2010-03-29 22:34 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) >> * utils/hbmk2/hbmk2.prg >> ! Fixed to always convert pathseps in icon filename to forward >> slashes. >> >> * utils/hbrun/hbrun.rc >> * Cleaned. Now back to original commit with purely forward >> slashes. Should see if this works with OS/2 GCC windres. >> >> Modified Paths: >> -- >> trunk/harbour/ChangeLog >> trunk/harbour/utils/hbmk2/hbmk2.prg >> trunk/harbour/utils/hbrun/hbrun.rc >> >> >> This was sent by the SourceForge.net collaborative development platform, the >> world's largest Open Source development site. >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14258] trunk/harbour
Viktor, with these rules inside os2\gcc.mk it build a .res file using rc.exe RC := $(HB_CCPATH)$(HB_CCPREFIX)rc RC_OUT := -DOS2 -r RC_RULE = $(RC) $(RCFLAGS) $(HB_RCFLAGS) $(HB_USER_RESFLAGS) $(RC_OUT) $< BUT, it builds the .res file at the same dir level of hbrun.rc and, even moving it inside obj\os2\gcc the final .exe has not the icon, here I fear this could be caused by the fact that hbrun.exe is a console app, but I'm not sure about this issue. So, can you tell me how to build the correct path to hbrun.res, I mean, how to add obj\os2\gcc to the clean hbrun.rc file name? $< contains the full upward path to hbrun.rc so I have to strip all those ..\..\.. and add obj\$compiler\$arch or something like that. Maurilio. vszak...@users.sourceforge.net wrote: > Revision: 14258 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14258&view=rev > Author: vszakats > Date: 2010-03-29 20:36:08 + (Mon, 29 Mar 2010) > > Log Message: > --- > 2010-03-29 22:34 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) > * utils/hbmk2/hbmk2.prg > ! Fixed to always convert pathseps in icon filename to forward > slashes. > > * utils/hbrun/hbrun.rc > * Cleaned. Now back to original commit with purely forward > slashes. Should see if this works with OS/2 GCC windres. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/utils/hbmk2/hbmk2.prg > trunk/harbour/utils/hbrun/hbrun.rc > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[14224] trunk/harbour
Przemyslaw,
Przemysław Czerpak wrote:
> Such results can be a little bit change by autoinlining when -O3 is used
> so it would be nice if you can also test this function:
>
>ULONG _hb_gettid2( void )
>{
> ULONG tid = 0;
> PTIB ptib = NULL;
>
> if( DosGetInfoBlocks( &ptib, NULL ) == NO_ERROR )
> tid = ptib->tib_ptib2->tib2_ultid;
>
> return tid;
>}
>
Here it is:
(E:\harbour\test)gettid
Time _hb_gettid() 693
Time _gettid() 1787
Time _hb_gettid2() 2952
> Yes it is and it's good place to store such information but it's not TLS
> area :-)
Ok, but bear in mind that on OS/2 TLS area is a very limited resource:
8<---
When a process is started, a small block of memory is set aside to be used as
a thread-local memory area. This memory is at the same virtual address for
each thread, but is backed by different physical memory. This permits each
thread to have a small block of memory that is unique, or local, to that thread.
The thread-local memory area consists of 32 DWORDs (128 bytes), each DWORD
being 4 bytes in size. Up to 8 DWORDs (32 bytes) can be requested each time
this function is called. If you want to allocate more than 8 DWORDs, you must
call this function more than once.
Allocation is by DWORD only. If you want to store a BYTE in the thread-local
memory area, you would still allocate a DWORD, then store the BYTE in it.
Best regards.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Mindaugas, as I wrote earlier I did not see any difference as well unless i just call it with -j (without number), in this case I see both of my cores doing work. I'm using the dragon media flavor of mingw. Maurilio. Mindaugas Kavaliauskas wrote: >>> You can also try to reduce the optimization level, i.e. you can use -Os >>> in MinGW flags. It should reduce the compilation time and final binaries >>> will be slower then the one created by BCC though still faster. >> >> I'm trying another approach :) Upgrading from Celeron to Core i5. It >> should help a little. :) > > > Hi, > > > in ChangeLog I found some -j option for parallel compile jobs. How > can it use it? > > I'm trying: > win-make.exe -j4 > but I see no compile speed improvement. > > > Regards, > Mindaugas > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14257] trunk/harbour
Viktor, > goto 10. So -o coff is required, but it doesn't work. > > Maybe this should be fixed in the environment?: > windres: can't get BFD_RELOC_RVA relocation type: No such file or directory > Looking for this error on google it seems a problem of windres on certain platforms. > Doesn't look like a normal output for a correct > cmdline :/ > > Anyhow I'm out of guesses. > Me too, I don't even know whether using RC.EXE is enough to be able to link the .res to the .exe. Maurilio. > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14257] trunk/harbour
Viktor, I was not at latest svn commit, here it is after latest upgrade: ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on os2 platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not supported on os2 platform ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on os2 platform ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg -i../../../../../incl ude -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF -ohbrun.o -c hbrun.c windres-o hbrun.res ../../../hbrun.rc gcc -L../../../../../lib/os2/gcc -o ..\..\..\..\..\bin\os2\gcc\hbrun.exe hbrun.o hbrun.res -lhbcplr -lhbpp -lhbcommon -lhbcplr -lhbdebug -lhbmainstd -lharbour -s emxbind: invalid binary resource file E:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/bin/ld.exe: emxbind failed make[1]: *** [hbrun.exe] Error 1 make: *** [descend] Error 2 Not working, anyway. Maurilio. Viktor Szakáts wrote: > Hi, > >> ! HB_COMPILER: gcc >> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) >> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) >> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. >> ! Component: 'gpm' not supported on os2 platform >> ! Component: 'slang' not found. Configure with HB_WITH_SLANG. >> ! Component: 'curses' not supported on os2 platform >> ! Component: 'x11' not found. Configure with HB_WITH_X11. >> ! Component: 'wattcp/watt-32' not supported on os2 platform >> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR >> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -ohbrun.o -c hbrun.c >> windres -O omf -o hbrun.res ../../../hbrun.rc >> windres: unknown format type `omf' >> windres: supported formats: rc res coff > > I don't understand this scenario. '-O omf' > is only used in gccomf mode, and you're using > gcc here. > > Could be typo on my part, but it looks alright > in config/os2/gcc.mk. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14257] trunk/harbour
Viktor, I'm not using OMF mode, I'm using .a out mode. Maybe the issue is this. Maurilio. Viktor Szakáts wrote: > Hi, > >> ! HB_COMPILER: gcc >> ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) >> ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) >> ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. >> ! Component: 'gpm' not supported on os2 platform >> ! Component: 'slang' not found. Configure with HB_WITH_SLANG. >> ! Component: 'curses' not supported on os2 platform >> ! Component: 'x11' not found. Configure with HB_WITH_X11. >> ! Component: 'wattcp/watt-32' not supported on os2 platform >> ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR >> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -ohbrun.o -c hbrun.c >> windres -O omf -o hbrun.res ../../../hbrun.rc >> windres: unknown format type `omf' >> windres: supported formats: rc res coff > > I don't understand this scenario. '-O omf' > is only used in gccomf mode, and you're using > gcc here. > > Could be typo on my part, but it looks alright > in config/os2/gcc.mk. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14257] trunk/harbour
Viktor, it doesn't work either: ! HB_COMPILER: gcc ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on os2 platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not supported on os2 platform ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on os2 platform ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF -ohbrun.o -c hbrun.c windres -O omf -o hbrun.res ../../../hbrun.rc windres: unknown format type `omf' windres: supported formats: rc res coff make[1]: *** [hbrun.res] Error 1 make: *** [descend] Error 2 Maurilio. vszak...@users.sourceforge.net wrote: > Revision: 14257 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14257&view=rev > Author: vszakats > Date: 2010-03-29 11:51:42 + (Mon, 29 Mar 2010) > > Log Message: > --- > 2010-03-29 13:50 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) > * utils/hbmk2/hbmk2.prg > * config/os2/gcc.mk > ! Fixed to not use '-O coff'. It generates strange error. > '-O omf' is still used, pls test it. > > * utils/hbrun/hbrun.rc > * Trying to make it work for OS/2 and at the same time > lessen the chaos (f.e. using forward slashes in filenames). > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/config/os2/gcc.mk > trunk/harbour/utils/hbmk2/hbmk2.prg > trunk/harbour/utils/hbrun/hbrun.rc > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
No way: ! Component: 'zlib' found in E:/REPOSITORY/HARBOUR/external/zlib (local) ! Component: 'pcre' found in E:/REPOSITORY/HARBOUR/external/pcre (local) ! Component: 'openssl' not found. Configure with HB_WITH_OPENSSL. ! Component: 'gpm' not supported on os2 platform ! Component: 'slang' not found. Configure with HB_WITH_SLANG. ! Component: 'curses' not supported on os2 platform ! Component: 'x11' not found. Configure with HB_WITH_X11. ! Component: 'wattcp/watt-32' not supported on os2 platform ! HB_INSTALL_PREFIX automatically set to: E:\REPOSITORY\HARBOUR ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg -i../../../../../incl ude -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF -ohbrun.o -c hbrun.c windres -O coff -o hbrun.res ../../../hbrun.rc windres: can't get BFD_RELOC_RVA relocation type: No such file or directory make[1]: *** [hbrun.res] Error 1 make: *** [descend] Error 2 Maurilio. Viktor Szakáts wrote: > Trying to lessen the mess, can you try this one?: > > --- > /* > * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $ > */ > > #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! defined( > __GNUC__ ) > /* os2/watcom */ > ICON DISCARDABLE "../../../../../package/harbour.ico" > #else > ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico" > #endif > --- > > Also if the icon is indeed visible as app icon. > > Brgds, > Viktor > > On 2010 Mar 29, at 11:54, Viktor Szakáts wrote: > >>> windres has a different syntax from rc, see attached file which I can >>> compile with >>> >>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 >>> ..\..\..\hbrun.rc >> Can you try two things with included .rc file: >> 1. Does it work with standard windres command-line? >>windres -O [omf|coff] -o hbrun.res hbrun.rc >> 2. Does this .rc format work with watcom? >> >> --- hbrun.rc >> #if defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) >> #if defined( __GNUC__ ) >> /* os2/gcc */ >> 1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico" >> #else >> /* os2/watom */ >> ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico" >> #endif >> #elif defined( __BORLANDC__ ) >> /* win/bcc */ >> ICON1 ICON DISCARDABLE "..\..\..\..\..\package\harbour.ico" >> #else >> /* win */ >> ICON1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico" >> #endif >> --- >> >> [ Quite nicely standardized format. not. ] >> >> Brgds, >> Viktor >> > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor. > --- > /* > * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $ > */ > > #if ( defined( OS2 ) || defined( __OS2__ ) || defined( OS_2 ) ) && ! defined( > __GNUC__ ) > /* os2/watcom */ > ICON DISCARDABLE "../../../../../package/harbour.ico" > #else > ICON1 ICON DISCARDABLE "../../../../../package/harbour.ico" > #endif > --- > without icon ID for the os2/watcom line? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, no, same error: (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -O coff -o hbrun.res ..\..\..\hbrun.rc windres: can't get BFD_RELOC_RVA relocation type: Error 0 Maurilio. Viktor Szakáts wrote: >>> Can you try two things with included .rc file: >>> 1. Does it work with standard windres command-line? >>>windres -O [omf|coff] -o hbrun.res hbrun.rc >> Without -O it works, otherwise I get an error: >> >> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -o hbrun.res >> ..\..\..\hbrun.rc >> >> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)dir >> >> The volume label in drive E is Dati. >> The Volume Serial Number is 812E:D5C2. >> Directory of E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc >> >> 29/03/10 12:00 124 . >> 29/03/10 10:10 124 .. >> 29/03/10 10:10 15.390124 a--- hbrun.c >> 29/03/10 10:10 8.211124 a--- hbrun.o >> 29/03/10 12:00 9.344124 a--- hbrun.res >>5 file(s) 32.945 bytes used >> 179.062.521 K bytes free >> >> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Oomf -o hbrun.res >> ..\..\..\hbrun.rc >> windres: unknown format type `omf' >> windres: supported formats: rc res coff >> >> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Ocoff -o hbrun.res >> ..\..\..\hbrun.rc >> windres: can't get BFD_RELOC_RVA relocation type: Error 0 > > '-O coff' should be the right option for your gcc version, > it seems supported, but yet it gives this error? Can it be that > the space is missing in your test? > > '-O omf' is for gccomf. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, Viktor Szakáts wrote: > Can you try two things with included .rc file: > 1. Does it work with standard windres command-line? > windres -O [omf|coff] -o hbrun.res hbrun.rc Without -O it works, otherwise I get an error: (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -o hbrun.res ..\..\..\hbrun.rc (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)dir The volume label in drive E is Dati. The Volume Serial Number is 812E:D5C2. Directory of E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc 29/03/10 12:00 124 . 29/03/10 10:10 124 .. 29/03/10 10:10 15.390124 a--- hbrun.c 29/03/10 10:10 8.211124 a--- hbrun.o 29/03/10 12:00 9.344124 a--- hbrun.res 5 file(s) 32.945 bytes used 179.062.521 K bytes free (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Oomf -o hbrun.res ..\..\..\hbrun.rc windres: unknown format type `omf' windres: supported formats: rc res coff (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -Ocoff -o hbrun.res ..\..\..\hbrun.rc windres: can't get BFD_RELOC_RVA relocation type: Error 0 > 2. Does this .rc format work with watcom? > I don't have it installed and working, I hope David can do this test. Maurilio. -- ______ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, see this http://www.cygwin.com/cygwin-ug-net/windres.html Maurilio. Maurilio Longo wrote: > Viktor, > > windres has a different syntax from rc, see attached file which I can compile > with > > (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 > ..\..\..\hbrun.rc > > Output goes to stdout, so you need a -o also. > > Maurilio. > > > > Viktor Szakáts wrote: >> Hi, >> >>> Using RC.EXE I can compile attached .rc file this way >>> >>> >>> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc >>> Operating System/2 Resource Compiler >>> Version 4.00.011 Oct 10 2000 >>> (C) Copyright IBM Corporation 1988-2000 >>> (C) Copyright Microsoft Corp. 1985-2000 >>> All rights reserved. >>> >>> >>> Creating binary resource file ..\..\..\hbrun.RES >>> RC: RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef >>> D:\OS2\RCPP.ERR >>> >>> ..\..\..\hbrun.rc >> One question is if it can be linked by gcc. >> >> Plus from here I can't tell what other limitation >> this system tool might have compared to windres. >> >> Other question is with watcom. It's would good to >> define what is a generally accepted OS/2 .rc format >> understood and usable with all OS/2 compilers. >> >>> I see you're calling windres, which I never knew it even exists .) >>> >>> Anyway, it fails with a parse error, I don't know why. >>> >>> Still investigating, though. >> Okay. >> >> Brgds, >> Viktor >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, windres has a different syntax from rc, see attached file which I can compile with (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)windres -r -DOS2 ..\..\..\hbrun.rc Output goes to stdout, so you need a -o also. Maurilio. Viktor Szakáts wrote: > Hi, > >> Using RC.EXE I can compile attached .rc file this way >> >> >> (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc >> Operating System/2 Resource Compiler >> Version 4.00.011 Oct 10 2000 >> (C) Copyright IBM Corporation 1988-2000 >> (C) Copyright Microsoft Corp. 1985-2000 >> All rights reserved. >> >> >> Creating binary resource file ..\..\..\hbrun.RES >> RC: RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef >> D:\OS2\RCPP.ERR >> >> ..\..\..\hbrun.rc > > One question is if it can be linked by gcc. > > Plus from here I can't tell what other limitation > this system tool might have compared to windres. > > Other question is with watcom. It's would good to > define what is a generally accepted OS/2 .rc format > understood and usable with all OS/2 compilers. > >> I see you're calling windres, which I never knew it even exists .) >> >> Anyway, it fails with a parse error, I don't know why. >> >> Still investigating, though. > > Okay. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. /* * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $ */ #if defined( OS2 ) 1 ICON DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico" #endif ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, Using RC.EXE I can compile attached .rc file this way (E:\REPOSITORY\HARBOUR\utils\hbrun\obj\os2\gcc)rc -r -DOS2 ..\..\..\hbrun.rc Operating System/2 Resource Compiler Version 4.00.011 Oct 10 2000 (C) Copyright IBM Corporation 1988-2000 (C) Copyright Microsoft Corp. 1985-2000 All rights reserved. Creating binary resource file ..\..\..\hbrun.RES RC: RCPP -E -D RC_INVOKED -D OS2 -W4 -f ..\..\..\hbrun.rc -ef D:\OS2\RCPP.ERR ..\..\..\hbrun.rc I see you're calling windres, which I never knew it even exists .) Anyway, it fails with a parse error, I don't know why. Still investigating, though. Maurilio. Viktor Szakáts wrote: > Hi, > > Pls help finding out what is the proper .rc format > to include an icon in OS/2. > > I copied current logic from hbmk2, but it's possible > nobody tried it even there, so it was wrong. > > (Worth to try with single backslashes first.) > > Brgds, > Viktor > > On 2010 Mar 29, at 10:15, Maurilio Longo wrote: > >> Hi, >> >> I get this on OS/2 + GCC >> >> >> ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -odbgbrwsr.o -c dbgbrwsr.c >> ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a & >> ..\..\..\..\..\config\os2rm -f __lib__.tmp >> gcc -shared -L../../../../../lib/os2/gcc -o >> ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket >> -s >> emximp -o ../../../../../lib/os2/gcc/harbour.a >> ../../../../../bin/os2/gcc/harbour.dll >> gcc -shared -L../../../../../../lib/os2/gcc -o >> ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def >> -lsocket -s >> emximp -o ../../../../../../lib/os2/gcc/harbourm.a >> ../../../../../../bin/os2/gcc/harbourm.dll >> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -ohbrun.o -c hbrun.c >> windres -O coff -o hbrun.res ../../../hbrun.rc >> windres: ../../../hbrun.rc:6: parse error >> make[3]: *** [hbrun.res] Error 1 >> make[2]: *** [descend] Error 2 >> make[1]: *** [hbrun] Error 2 >> make: *** [utils] Error 2 >> >> >> Maurilio. >> >> -- >> __ >> | | | |__| Maurilio Longo >> |_|_|_|| farmaconsult s.r.l. >> >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. /* * $Id: hbrun.rc 14255 2010-03-28 17:23:00Z vszakats $ */ #if defined( OS2 ) ICON 1 DISCARDABLE "..\\..\\..\\..\\..\\package\\harbour.ico" #endif ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 14255 error on build
Viktor, --8<--- Syntax: ICON icon-id [load-option] [ mem-option] [codepage] filename This form of the ICON statement defines an icon resource for an application. An icon resource, typically created by using Icon Editor, is a bit map defining the shape of the icon to be used for a given application. The ICON statement copies the icon resource from the file specified in the filename field and adds it to the application's other resources. An icon resource can be loaded when creating a window by using the WinCreateStdWindow function with the FS_ICON style. You can provide any number of ICON statements in a resource script file, but each statement must specify a unique icon-id value. icon-id Specifies the icon-resource identifier. This value must be an unsigned integer in the range of 1 through 65535, a simple expression that evaluates to a value in these ranges, or a character string. An icon-id of 1 has a special meaning; for details, see the "Comment" section. load-option Specifies when the system loads the resource from the executable file into memory. This value must be one of the following: PRELOAD System loads the resource when the application starts. LOADONCALL System loads the resource when the application calls the WinCreateStdWindow function. This is the default option. mem-option Specifies how the system manages the resource when it is in memory. This value must be one or more of the following: FIXED System keeps the resource at a fixed memory location. MOVEABLE System moves the resource as necessary to compact memory. DISCARDABLE System discards the resource if it is no longer needed. The default setting is MOVEABLE and DISCARDABLE. codepage Specifies a code page value. For a list of valid code pages see CODEPAGE Statement. filename Specifies the name of the file containing the icon resource. If the file is not in the current directory, filename must be preceded by a full path. Comments An icon with an icon-id of 1 is the default icon. The RC program writes the icon not only to the resources in your executable file, but also as the .ICON extended attribute. File Manager will display this icon next to the name of the executable file. Example This example defines an icon whose icon identifier is 11. The icon resource is copied from the file custom.ico. ICON 11 custom.ico >8- Now I'll try to remove double slashes. Maurilio. Viktor Szakáts wrote: > Hi, > > Pls help finding out what is the proper .rc format > to include an icon in OS/2. > > I copied current logic from hbmk2, but it's possible > nobody tried it even there, so it was wrong. > > (Worth to try with single backslashes first.) > > Brgds, > Viktor > > On 2010 Mar 29, at 10:15, Maurilio Longo wrote: > >> Hi, >> >> I get this on OS/2 + GCC >> >> >> ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -odbgbrwsr.o -c dbgbrwsr.c >> ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a & >> ..\..\..\..\..\config\os2rm -f __lib__.tmp >> gcc -shared -L../../../../../lib/os2/gcc -o >> ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket >> -s >> emximp -o ../../../../../lib/os2/gcc/harbour.a >> ../../../../../bin/os2/gcc/harbour.dll >> gcc -shared -L../../../../../../lib/os2/gcc -o >> ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def >> -lsocket -s >> emximp -o ../../../../../../lib/os2/gcc/harbourm.a >> ../../../../../../bin/os2/gcc/harbourm.dll >> ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF >> -ohbrun.o -c hbrun.c >> windres -O coff -o hbrun.res ../../../hbrun.rc >> windres: ../../../hbrun.rc:6: parse error >> make[3]: *** [hbrun.res] Error 1 >> make[2]: *** [descend] Error 2 >> make[1]: *** [hbrun] Error 2 >> make: *** [utils] Error 2 >> >> >> Maurilio. >> >> -- >> __ >> | | | |__| Maurilio Longo >> |_|_|_|| farmaconsult s.r.l. >> >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 14255 error on build
Hi, I get this on OS/2 + GCC ../../../../../bin/os2/gcc/harbour.exe ../../../dbgbrwsr.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF -odbgbrwsr.o -c dbgbrwsr.c ar-M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbdebug.a & ..\..\..\..\..\config\os2rm -f __lib__.tmp gcc -shared -L../../../../../lib/os2/gcc -o ../../../../../bin/os2/gcc/harbour.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s emximp -o ../../../../../lib/os2/gcc/harbour.a ../../../../../bin/os2/gcc/harbour.dll gcc -shared -L../../../../../../lib/os2/gcc -o ../../../../../../bin/os2/gcc/harbourm.dll -Wl,@__dyn__.tmp __dyn__.def -lsocket -s emximp -o ../../../../../../lib/os2/gcc/harbourm.a ../../../../../../bin/os2/gcc/harbourm.dll ../../../../../bin/os2/gcc/harbour.exe ../../../hbrun.prg -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I. -I../../../../../include -Wall -W -O3 -DHB_LEGACY_TYPES_OFF -ohbrun.o -c hbrun.c windres -O coff -o hbrun.res ../../../hbrun.rc windres: ../../../hbrun.rc:6: parse error make[3]: *** [hbrun.res] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [hbrun] Error 2 make: *** [utils] Error 2 Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[14224] trunk/harbour
Przemyslaw, Przemysław Czerpak wrote: > But before I'll make any modifications in core code I would like to see > real test results. It's possible that DosAllocThreadLocalMemory() is > already highly optimized by compiler. > > Can you check the performance of above functions in some simple loop? > See attached code, it gives these results on my PC when compiled with gcc -O3 -Wall -o gettid.exe gettid.c (E:\harbour\test)gettid Time _hb_gettid() 688 Time _gettid() 1787 The numers are in milliseconds for a 100 million times loop. > When threads ends then it's TLS area is freed so such information will be > lost in a while. Yes, but if we have an object on HVM, this object could have those numbers and they'll stay there until the object is disposed. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. <>___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[14224] trunk/harbour
Przemyslaw, if we have a thread object and/or a thread local storage area we could call _gettid() on thread start and save this value which never changes during thread life. This saves us a Dos... call every time we need the thread id. Does this make sense? Maurilio. PS. We could also have space for user/cpu times in that area so that we can write there on thread end and they would be available even after thread end when the Dos... api call cannot find the thread id anymore. Przemysław Czerpak wrote: > On Fri, 26 Mar 2010, David Arturo Macias Corona wrote: > > Hi, > >> Tested with: >> - * $Id: ChangeLog 14234 2010-03-25 23:44:10Z druzus $ >> 2010-03-26 00:44 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) >> - OpenWatcom 1.8 for OS/2 >> on a computer with Core2Duo E8400 3 Ghz >> Summary results for: >> ST >> == >> speedtst >> [ total application time: ]18.39 >> [ total real time: ]...18.38 >> >> MT >> == >> speedtst >> [ total application time: ]26.58 >> [ total real time: ]...26.70 >> >> speedtst --thread >> [ total application time: ].0.26 >> [ total real time: ]...26.48 >> >> speedtst --thread=2 --scale >> [ total application time: ].0.23 >> [ total real time: ]..105.04 >> >> speedtst.txt content included below >> >> Few hours later, same tests with older Harbour 14189: >> ST >> == >> speedtst >> [ total application time: ]18.61 >> [ total real time: ]...18.67 >> >> MT >> == >> speedtst >> [ total application time: ]26.87 >> [ total real time: ]...26.85 >> >> speedtst --thread >> [ total application time: ].0.26 >> [ total real time: ]...26.79 >> >> speedtst --thread=2 --scale >> [ total application time: ].0.16 >> [ total real time: ]..107.76 > > Thank you very much for your tests. > > Looks that new code is a little bit faster though the recursive spinlocks > introduce some small but noticeable speed overhead. Probably due to cost > of _hb_gettid(). Maybe we will find some workaround for it in the future. > Now it's important that it works. > BTW it looks that your system is not configured to use 2CPUs and everything > is executed using only one. Do you used SMP OS2 release? If not then > scalar factor will always be close to 1. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14224] trunk/harbour
BTW, on OS/2 used CPU time of a thread is not available after a thread has ended, so right now cumulative times shown are wrong. Best regards. Maurilio. Maurilio Longo wrote: > Przemyslaw, >> You can also try >>--thread= --scale >> In such version each test is executed times by one thread and then >> simultaneously once by threads. It means that it exploits the worst >> possible cases in synchronization and scalability. It should also quite >> well test spinlocks on multi CPU machines. >> > I've attached this test, with thread=2, this is on a PIV HT, so no real dual > core. > >> BTW have you tested the speed difference between _gettid() and _hb_gettid() >> in OS2 GCC builds? Or maybe GCC _gettid() makes exactly the same job as our >> _hb_gettid()? >> > No speed test done, but I think there is only one way to have this info on > OS/2, that is, going through the Dos... API. > > Best regards. > > Maurilio. > > > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14224] trunk/harbour
Przemyslaw,
> You can also try
>--thread= --scale
> In such version each test is executed times by one thread and then
> simultaneously once by threads. It means that it exploits the worst
> possible cases in synchronization and scalability. It should also quite
> well test spinlocks on multi CPU machines.
>
I've attached this test, with thread=2, this is on a PIV HT, so no real dual
core.
> BTW have you tested the speed difference between _gettid() and _hb_gettid()
> in OS2 GCC builds? Or maybe GCC _gettid() makes exactly the same job as our
> _hb_gettid()?
>
No speed test done, but I think there is only one way to have this info on
OS/2, that is, going through the Dos... API.
Best regards.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
2010.03.25 13:07:35 OS/2 4.50
Harbour 2.1.0dev (Rev. 14225) (MT)+ EMX GNU C 3.3.5 (32-bit) x86
THREADS: 2
N_LOOPS: 100
1 th. 2 th. factor
[ T001: x := L_C ] 0.53 2.15 -> 0.25
[ T002: x := L_N ] 0.39 1.80 -> 0.22
[ T003: x := L_D ] 0.37 0.60 -> 0.62
[ T004: x := S_C ] 0.50 0.61 -> 0.82
[ T005: x := S_N ] 0.37 0.57 -> 0.65
[ T006: x := S_D ] 0.36 0.57 -> 0.63
[ T007: x := M->M_C ]_ 0.55 0.65 -> 0.85
[ T008: x := M->M_N ]_ 0.43 2.26 -> 0.19
[ T009: x := M->M_D ]_ 0.42 0.61 -> 0.68
[ T010: x := M->P_C ]_ 0.49 0.63 -> 0.78
[ T011: x := M->P_N ]_ 0.41 0.64 -> 0.65
[ T012: x := M->P_D ]_ 0.42 0.64 -> 0.65
[ T013: x := F_C ] 1.20 0.98 -> 1.23
[ T014: x := F_N ] 0.95 0.77 -> 1.24
[ T015: x := F_D ] 0.60 0.66 -> 0.91
[ T016: x := o:Args ]_ 0.91 1.86 -> 0.49
[ T017: x := o[2] ]___ 0.76 0.79 -> 0.97
[ T018: round( i / 1000, 2 ) ] 1.20 1.26 -> 0.95
[ T019: str( i / 1000 ) ]_ 6.25 4.37 -> 1.43
[ T020: val( s ) ] 1.26 1.09 -> 1.16
[ T021: val( a [ i % 16 + 1 ] ) ]_ 2.22 1.97 -> 1.13
[ T022: dtos( d - i % 1 ) ]___ 2.07 1.88 -> 1.10
[ T023: eval( { || i % 16 } ) ]___ 2.45 2.94 -> 0.83
[ T024: eval( bc := { || i % 16 } ) ]_ 1.21 1.49 -> 0.82
[ T025: eval( { |x| x % 16 }, i ) ]___ 1.76 2.57 -> 0.68
[ T026: eval( bc := { |x| x % 16 }, i ) ]_ 1.26 1.52 -> 0.83
[ T027: eval( { |x| f1( x ) }, i ) ]__ 1.94 2.30 -> 0.84
[ T028: eval( bc := { |x| f1( x ) }, i ) ] 1.40 1.90 -> 0.74
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ]___ 1.41 1.78 -> 0.79
[ T030: x := &( "f1(" + str(i) + ")" ) ]__ 16.38 13.05 -> 1.25
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]__ 17.77 14.72 -> 1.21
[ T032: x := valtype( x ) + valtype( i ) ]___ 2.09 2.44 -> 0.86
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ] 6.02 4.61 -> 1.30
[ T034: x := a[ i % 16 + 1 ] == s ]___ 1.83 1.70 -> 1.07
[ T035: x := a[ i % 16 + 1 ] = s ] 1.91 1.79 -> 1.07
[ T036: x := a[ i % 16 + 1 ] >= s ]___ 1.91 1.76 -> 1.08
[ T037: x := a[ i % 16 + 1 ] <= s ]___ 1.91 1.78 -> 1.08
[ T038: x := a[ i % 16 + 1 ] < s ] 1.91 1.80 -> 1.06
[ T039: x := a[ i % 16 + 1 ] > s ] 1.90 1.78 -> 1.07
[ T040: ascan( a, i % 16 ) ]__ 1.63 1.48 -> 1.10
[ T041: ascan( a, { |x| x == i % 16 } ) ]_ 11.64 11.32 -> 1.03
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s ] 4.43 4.08 -> 1.09
[ T043: x := a ]__ 0.56 0.69 -> 0.81
[ T044: x := {} ]_ 1.07 1.02 -> 1.05
[ T045: f0() ] 0.53 0.88 -> 0.61
[ T046: f1( i ) ]_ 0.70 1.00 -> 0.71
[ T047: f2( c[1...8] ) ]__ 0.83 1.09 -> 0.76
[ T048: f2( c[1...4] ) ]__
Re: [Harbour] SF.net SVN: harbour-project:[14224] trunk/harbour
Przemyslaw,
compiled cleanly on OS/2 with gcc, I attach speedtst output as a test to
dlmalloc.
Best regards and thanks.
Maurilio.
Przemysław Czerpak wrote:
> On Thu, 25 Mar 2010, Szak�ts Viktor wrote:
>
> Hi,
>
>> msvc 2008, msvc 2008 64-bit, old msvcarm (1201), darwin clang
>> and darwin gcc build cleanly.
>
> Thank you very much.
>
> BTW do you know _MSC_VER we can use to chose between __forceinline
> and __inline?
>
> WINE uses this:
>
>#ifndef FORCEINLINE
># if defined(_MSC_VER) && (_MSC_VER >= 1200)
># define FORCEINLINE __forceinline
># elif defined(__GNUC__) && ((__GNUC__ > 3) || \
> ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 2)))
># define FORCEINLINE __attribute__((always_inline))
># else
># define FORCEINLINE inline
># endif
>#endif
>
> so I'll probably use the same condition.
> It does not use always_inline in GCC 3.1 maybe due some problems with
> this GCC version so I'll also replicate it.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
2010.03.25 11:40:48 OS/2 4.50
Harbour 2.1.0dev (Rev. 14225) (MT)+ EMX GNU C 3.3.5 (32-bit) x86
THREADS: 2
N_LOOPS: 100
[ T000: empty loop overhead ]...0.03
[ T001: x := L_C ]..0.52
[ T002: x := L_N ]..0.42
[ T003: x := L_D ]..0.42
[ T004: x := S_C ]..0.55
[ T005: x := S_N ]..0.42
[ T006: x := S_D ]..0.39
[ T007: x := M->M_C ]...0.55
[ T008: x := M->M_N ]...0.45
[ T009: x := M->M_D ]...0.45
[ T010: x := M->P_C ]...0.55
[ T011: x := M->P_N ]...0.45
[ T012: x := M->P_D ]...0.42
[ T013: x := F_C ]..0.87
[ T014: x := F_N ]..0.65
[ T015: x := F_D ]..0.55
[ T016: x := o:Args ]...0.90
[ T017: x := o[2] ].0.74
[ T018: round( i / 1000, 2 ) ]..0.90
[ T019: str( i / 1000 ) ]...3.84
[ T020: val( s ) ]..0.94
[ T021: val( a [ i % 16 + 1 ] ) ]...1.61
[ T022: dtos( d - i % 1 ) ].1.58
[ T023: eval( { || i % 16 } ) ].2.19
[ T024: eval( bc := { || i % 16 } ) ]...1.16
[ T025: eval( { |x| x % 16 }, i ) ].1.87
[ T026: eval( bc := { |x| x % 16 }, i ) ]...1.32
[ T027: eval( { |x| f1( x ) }, i ) ]2.32
[ T028: eval( bc := { |x| f1( x ) }, i ) ]..1.65
[ T029: eval( bc := &("{ |x| f1( x ) }"), i ) ].1.03
[ T030: x := &( "f1(" + str(i) + ")" ) ]...14.03
[ T031: bc := &( "{|x|f1(x)}" ), eval( bc, i ) ]...14.10
[ T032: x := valtype( x ) + valtype( i ) ].1.42
[ T033: x := strzero( i % 100, 2 ) $ a[ i % 16 + 1 ] ]..4.26
[ T034: x := a[ i % 16 + 1 ] == s ].1.32
[ T035: x := a[ i % 16 + 1 ] = s ]..1.45
[ T036: x := a[ i % 16 + 1 ] >= s ].1.55
[ T037: x := a[ i % 16 + 1 ] <= s ].1.65
[ T038: x := a[ i % 16 + 1 ] < s ]..1.61
[ T039: x := a[ i % 16 + 1 ] > s ]..1.61
[ T040: ascan( a, i % 16 ) ]1.29
[ T041: ascan( a, { |x| x == i % 16 } ) ]..11.35
[ T042: iif( i%1000==0, a:={}, ) , aadd(a,{i,1,.T.,s,s2,a2 ]3.68
[ T043: x := a ]0.52
[ T044: x := {} ]...0.90
[ T045: f0() ]..0.61
[ T046: f1( i ) ]...0.77
[ T0
Re: [Harbour] field->&("name") in a macro
Przemysław Czerpak wrote: > On Mon, 22 Mar 2010, Szak�ts Viktor wrote: > For tables which have very big number of fields the speed > improvement should be huge. Accessing fields by name is > relatively very slow operation and all RDD methods which > transfer records between workareas use such translation > table with indexes to eliminate it. > Przemyslaw, sorry if my question is a dumb one, but could the HVM+RDDs use such translation table for the normal code? I have, I think we all have, plenty of code doing alias->name := or var := alias->name in loops as well, so If this could be made faster at runtime, when the position of fields cannot change between every dbUseArea()/dbCloseArea() pair, this could be a speed boost which gives some noticeable result. Maybe this cannot be done, but maybe every alias->field could be compiled into a lookup table indexed expression and the lookup table be compiled by dbUseArea(). What do you think? Maurilio. -- ______ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Deletion from /examples
Viktor Szakáts wrote: > Hi Maurilio, > > Your work (this part of it that is) continues to > live in hbmysql, which seems to be rooted from > hbmsql, so it's by far not lost effort. > Yes, I wrote mySql just after mSql when I saw that miniSql had a lot of limitations. miniSql maybe has been discontinued, I really don't know. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Deletion from /examples
Hi Viktor, mSql was one of my first contributions, so long ago! Sniff! :,( Anyway, things have to move on... Maurilio. Viktor Szakáts wrote: > Hi All, > > I'd like to delete these subdirs from > /examples: > > - hbdoc > - hbmsql > > If there are no objections, I'll delete > them later today. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] mingw 4.5.0 benchmarks
Viktor, for real code, doing I/O on a network share, the difference could be lower, though. Maurilio. Viktor Szakáts wrote: >> Viktor Szakáts wrote: >>> I've included BCC55 for comparison. It's running at half the overall speed >>> compared to 4.5 64-bit. >> Ec... I'm still using BCC, because... it compiles f.e. \external\sqlite3 >> in 2.74 s, and MGW compiles it in 3 minutes 3.25 s, i.e. 67 times slower... > > Yes, it's good for "draft" builds. > > Though at least for live builds used by real users > IMO it's worth to take the pain of a longer build > to offer a faster working application. It's a one > time overhead on developer's side and and permanent > and noticeable gain on the users' side. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Decimal Arithmetic
Alex, (I'm resending this without attachment because the first copy, with a 120Kb attachment didn't reach the list). a couple years ago I did a quick port of Mike Cowlishaw decNumber library to xharbour. It's alpha code quality (mine, not decNumber! .)) and xharbour specific, but enough to get going with harbour as well. Maybe, if it is considered usefull we could put it into contrib. I attach it to this message, but I fear it's too big to pass. Best regards. Maurilio. Alex Strickland wrote: > Hi All > > I found this site: > > http://speleotrove.com/decimal/ > > I have often wished to get around the problems of floating point > arithmetic. This library seems to offer a route that is not too steep. > Any takers for a new type? Unfortunately "D"ecimal and "M"oney are taken. > > Regards > Alex > > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14172] trunk/harbour
Viktor, I've just rebuilt everything and now I have a bzip2.a file, is there some test program so that we can see if it works? Maurilio. vszak...@users.sourceforge.net wrote: > Revision: 14172 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14172&view=rev > Author: vszakats > Date: 2010-03-15 20:32:35 + (Mon, 15 Mar 2010) > > Log Message: > --- > 2010-03-15 21:31 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * external/bzip2/Makefile > * external/bzip2/bzip2.dif > * external/bzip2/bzip2.c > + Added patch to make it compile on dos and os2/watcom. > Thanks to Przemek. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/external/bzip2/Makefile > trunk/harbour/external/bzip2/bzip2.c > trunk/harbour/external/bzip2/bzip2.dif > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] recommended C compiler for Win
Przemyslaw, could this issue explain some of my troubles the other day? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] mingw32-make -j
Hi, it's just me or mingw32-make -j n with > 1 does not work? It seems, looking at cpu monitor, that just a core is occupied. If I issue a mingw32-make -j (without limit) it fully saturates all cores. I have a dual core, so a -j 3 or 4 should be enough, I've tested -j 6 or 8, with always just a core working. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Viktor, Viktor Szakáts wrote: > -gui doesn't set any GTs, only executable build mode. > You should use -gtgui (which will also set -gui automatically). > Not enough without the hb_gtsys() procedure. > BTW, -gtnul should also work for normal cases. > I'm not sure I've tested this, but I think I've done this test and it was not working either. > The problem in your case is that the method hbmk2 > uses (inherited from hbmk script) to set default GT, > is an internal VM call executed on app startup. In > context of .dlls with full VM, such "app startup" > has no meaning. In such case a different stub would > be needed, something like Przemek posted. I can > add support for such thing to hbmk2, but first we > should clear up any issues with it. > I'm doing a pretty strange thing, I don't know if it is worth adding to hbmk2, while I think having a .c file to include to start-up the HVM could be a more general and useful thing. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Przemyslaw,
I've just tested your code and it does not work, it seems hb_vmInit() is not
called.
My simpler code was to call hb_vmInit() explicitly.
Maurilio.
Przemysław Czerpak wrote:
> On Wed, 10 Mar 2010, Maurilio Longo wrote:
>
> Hi,
>
>> it does not work :(
>> Question: do I have to startup the HVM or does it start up by itself as soon
>> as the .dll is loaded?
>
> You haven't added any code to initialize HVM after loading DLL file.
> You are creating DLL which uses its own HVM and you have to initialize it.
> For single thread support it's quite simple and the code below should be
> enough. I haven't tested it.
>
> best regards,
> Przemek
>
>
>#include "hbvm.h"
>#include
>
>extern void hb_winmainArgInit( HANDLE hInstance, HANDLE hPrevInstance, int
> iCmdShow );
>
>#if defined( HB_OS_WIN_CE ) && ( defined( _MSC_VER ) || defined( __POCC__
> ) )
>BOOL WINAPI HB_DLL_ENTRY_POINT( HANDLE hInstance, DWORD dwReason, PVOID
> pvReserved )
>#else
>BOOL WINAPI HB_DLL_ENTRY_POINT( HINSTANCE hInstance, DWORD dwReason, PVOID
> pvReserved )
>#endif
>{
> hb_winmainArgInit( hInstance, 0, 0 );
> HB_SYMBOL_UNUSED( pvReserved );
>
> switch( fdwReason )
> {
> case DLL_PROCESS_ATTACH:
> hb_vmInit( HB_FALSE );
> break;
> case DLL_PROCESS_DETACH:
> hb_vmQuit();
> break;
> }
> return TRUE;
>}
>
>#if defined( __DMC__ ) || defined( __WATCOMC__ )
> HB_EXTERN_BEGIN
> void hb_forceLinkMainWin( void ) {}
> void hb_forceLinkMainStd( void ) {}
> HB_EXTERN_END
>#endif
> _______
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Przemyslaw, -gui on hbmk2 command line is not enough, I've found the answer in an old message of Viktor, I had to add to my .prg code procedure HB_GT_SYS() REQUEST HB_GT_GUI_DEFAULT return This did the trick :) Maurilio. Przemysław Czerpak wrote: > On Wed, 10 Mar 2010, Maurilio Longo wrote: > > Hi, > >> No, it was not working with my .cmd file, either adding -gtnul to hbmk2 or >> adding -lgtgui to list of .dll it still asked for gtwin with an unresolved >> external. > > Yes and it should. Please look at harbour/doc/gtapi.txt. The second part > of this file is copy of may message I sent to this list few years ago. > Please read about: >ANNOUNCE HB_GTSYS > and how it works. > >> But, now that hbmk2 with the correct order of parameters works I can simply >> call it like this: >> hbmk2 -strip -st -gtgui -hbdyn -hbnolib- my.prg my_c.c >> and I get my.dll without errors. >> Now I just have to see if it works :) > > I think that you may want to add code to initialize HVM. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Hi Przemyslaw,
Yes I did put a call to hb_vmInit( FALSE ); in my code and it was enough.
I'll add you code, though, and I fully second your idea to have an include
which has all the needed code to start-up the hvm.
Thanks a lot.
Maurilio.
Przemysław Czerpak wrote:
> On Wed, 10 Mar 2010, Maurilio Longo wrote:
>
> Hi,
>
>> it does not work :(
>> Question: do I have to startup the HVM or does it start up by itself as soon
>> as the .dll is loaded?
>
> You haven't added any code to initialize HVM after loading DLL file.
> You are creating DLL which uses its own HVM and you have to initialize it.
> For single thread support it's quite simple and the code below should be
> enough. I haven't tested it.
>
> best regards,
> Przemek
>
>
>#include "hbvm.h"
>#include
>
>extern void hb_winmainArgInit( HANDLE hInstance, HANDLE hPrevInstance, int
> iCmdShow );
>
>#if defined( HB_OS_WIN_CE ) && ( defined( _MSC_VER ) || defined( __POCC__
> ) )
>BOOL WINAPI HB_DLL_ENTRY_POINT( HANDLE hInstance, DWORD dwReason, PVOID
> pvReserved )
>#else
>BOOL WINAPI HB_DLL_ENTRY_POINT( HINSTANCE hInstance, DWORD dwReason, PVOID
> pvReserved )
>#endif
>{
> hb_winmainArgInit( hInstance, 0, 0 );
> HB_SYMBOL_UNUSED( pvReserved );
>
> switch( fdwReason )
> {
> case DLL_PROCESS_ATTACH:
> hb_vmInit( HB_FALSE );
> break;
> case DLL_PROCESS_DETACH:
> hb_vmQuit();
> break;
> }
> return TRUE;
>}
>
>#if defined( __DMC__ ) || defined( __WATCOMC__ )
> HB_EXTERN_BEGIN
> void hb_forceLinkMainWin( void ) {}
> void hb_forceLinkMainStd( void ) {}
> HB_EXTERN_END
>#endif
> _______
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
No, it does not work :( Question: do I have to startup the HVM or does it start up by itself as soon as the .dll is loaded? Thanks. Maurilio. Maurilio Longo wrote: > Przemyslaw, > > Przemysław Czerpak wrote: >> I rather think that you haven't added trailing - to this switch. >> When '-hbdyn' disables linking with Harbour binaries. '-nohblib-' >> reenable this libraries so for sure it should pacify the problem >> of unresolved HVM/HBRTL functions. >> If you want to check which libraries are used in link command then >> use -trace hbmk2 switch. > > I did add it, but I had -hbdyn _after_ -nohblib-, so it was overrinding it :) > and I had -hbdyn after because I thought that -hbdyn required after it the > name of the module to build as a .dll (like -o in gcc), I was wrong, though. > >>> BTW, there is no gtnul drivers, it keeps asking for gtwin, but I'm creating >>> a >> Not true. It is. It's always present in HBRTL. >> It's not possible to create any Harbour application with GTNUL. >> >>> .dll so I don't need output. Using gtgui make no difference, it still >>> requires >>> gtwin. > > No, it was not working with my .cmd file, either adding -gtnul to hbmk2 or > adding -lgtgui to list of .dll it still asked for gtwin with an unresolved > external. > > But, now that hbmk2 with the correct order of parameters works I can simply > call it like this: > > hbmk2 -strip -st -gtgui -hbdyn -hbnolib- my.prg my_c.c > > and I get my.dll without errors. > > Now I just have to see if it works :) > > Thanks for helping me, guys. > > Maurilio. > > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Przemyslaw, Przemysław Czerpak wrote: > I rather think that you haven't added trailing - to this switch. > When '-hbdyn' disables linking with Harbour binaries. '-nohblib-' > reenable this libraries so for sure it should pacify the problem > of unresolved HVM/HBRTL functions. > If you want to check which libraries are used in link command then > use -trace hbmk2 switch. I did add it, but I had -hbdyn _after_ -nohblib-, so it was overrinding it :) and I had -hbdyn after because I thought that -hbdyn required after it the name of the module to build as a .dll (like -o in gcc), I was wrong, though. > >> BTW, there is no gtnul drivers, it keeps asking for gtwin, but I'm creating a > > Not true. It is. It's always present in HBRTL. > It's not possible to create any Harbour application with GTNUL. > >> .dll so I don't need output. Using gtgui make no difference, it still >> requires >> gtwin. > No, it was not working with my .cmd file, either adding -gtnul to hbmk2 or adding -lgtgui to list of .dll it still asked for gtwin with an unresolved external. But, now that hbmk2 with the correct order of parameters works I can simply call it like this: hbmk2 -strip -st -gtgui -hbdyn -hbnolib- my.prg my_c.c and I get my.dll without errors. Now I just have to see if it works :) Thanks for helping me, guys. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] standalone .dll with full harbour RTL+VM
Viktor,
no, its the other way around, I need to have the full RTL plus the HVM because
my exported (from the .dll) C code calls some .prg code.
Best regards.
Maurilio.
Viktor Szakáts wrote:
> Hi Maurilio,
>
> Try '-nohblib-' option. It should make the link
> errors disappear, but I'm not sure if it's enough
> to reach your final goal.
>
> Brgds,
> Viktor
>
> On 2010 Mar 10, at 15:33, Maurilio Longo wrote:
>
>> Viktor and all,
>>
>> I have a little piece of code I built long ago with xharbour which was
>> producing a win32 .dll which was self-contained and was able to export some
>> function names to make it possible to create .cdx indexes from a program
>> written in another language and which was dinamically loading my .dll.
>>
>> I try to be clearer.
>>
>> mysource.c
>>
>> HB_EXPORT void __stdcall xhb_dbUseArea( BOOL lNewArea,
>>char * cDBE,
>>char * cFileName,
>>char * cAlias,
>>BOOL lShared,
>>BOOL lReadonly ) {
>>
>> static PHB_DYNS Dyns = NULL;
>>
>> if ( ! Dyns ) {
>> Dyns = hb_dynsymFind( "_DBUSEAREA" );
>> }
>>
>> if ( Dyns ) {
>>hb_vmPushDynSym( Dyns );
>> hb_vmPushNil();
>> hb_vmPushLogical( lNewArea );
>> hb_vmPushString( cDBE, strlen( cDBE ) );
>> hb_vmPushString( cFileName, strlen( cFileName ) );
>> hb_vmPushString( cAlias, strlen( cAlias ) );
>> hb_vmPushLogical( lShared );
>> hb_vmPushLogical( lReadonly );
>> hb_vmDo( 6 );
>>
>> return;
>> }
>> }
>>
>>
>> mysource.prg
>>
>> function _dbUseArea()
>>
>> does what it's name says, that is it calls
>> harbour dbUseArea() to open a .dbf file
>> return nil
>>
>>
>> Now, using hbmk2 I'm not able to build my .dll
>>
>> All I get is a long list of unresolved externals.
>>
>> I call it with
>>
>> hbmk2 -st -hbdyn mysource.prg mysource.c
>>
>> I'd expect to have mysource.dll which contains the full harbour RTL+VM so
>> that
>> the exported xhb_dbUseArea() is able to run.
>>
>> Any idea how I could reach such a goal?
>>
>> I can share the sources, they're not very clean or well thought over, but
>> were
>> able to work as expected :)
>>
>> Thanks.
>>
>> Maurilio.
>>
>>
>> --
>> __
>> | | | |__| Maurilio Longo
>> |_|_|_|| farmaconsult s.r.l.
>>
>>
>> ___
>> Harbour mailing list (attachment size limit: 40KB)
>> Harbour@harbour-project.org
>> http://lists.harbour-project.org/mailman/listinfo/harbour
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] standalone .dll with full harbour RTL+VM
Viktor and all,
I have a little piece of code I built long ago with xharbour which was
producing a win32 .dll which was self-contained and was able to export some
function names to make it possible to create .cdx indexes from a program
written in another language and which was dinamically loading my .dll.
I try to be clearer.
mysource.c
HB_EXPORT void __stdcall xhb_dbUseArea( BOOL lNewArea,
char * cDBE,
char * cFileName,
char * cAlias,
BOOL lShared,
BOOL lReadonly ) {
static PHB_DYNS Dyns = NULL;
if ( ! Dyns ) {
Dyns = hb_dynsymFind( "_DBUSEAREA" );
}
if ( Dyns ) {
hb_vmPushDynSym( Dyns );
hb_vmPushNil();
hb_vmPushLogical( lNewArea );
hb_vmPushString( cDBE, strlen( cDBE ) );
hb_vmPushString( cFileName, strlen( cFileName ) );
hb_vmPushString( cAlias, strlen( cAlias ) );
hb_vmPushLogical( lShared );
hb_vmPushLogical( lReadonly );
hb_vmDo( 6 );
return;
}
}
mysource.prg
function _dbUseArea()
does what it's name says, that is it calls
harbour dbUseArea() to open a .dbf file
return nil
Now, using hbmk2 I'm not able to build my .dll
All I get is a long list of unresolved externals.
I call it with
hbmk2 -st -hbdyn mysource.prg mysource.c
I'd expect to have mysource.dll which contains the full harbour RTL+VM so that
the exported xhb_dbUseArea() is able to run.
Any idea how I could reach such a goal?
I can share the sources, they're not very clean or well thought over, but were
able to work as expected :)
Thanks.
Maurilio.
--
______
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] recommended C compiler for Win
Viktor, if I read it correctly a dwarf2 .exe which loads a .dll which has an exception inside itself cannot work, since you're traversing a stack frame which receives an exception from windows. Am I right? Maurilio. PS. I've installed dragon media, smartsvn and I was able to build harbour on win32 very smoothly. Viktor Szakáts wrote: > Hi Maurilio, > >> I had the same impression about mingw being a nightmare to install and make >> it >> work. >> >> I'll try dragon media :) >> >> One more question, for harbour should I use sjlj unwinding or dwarf2? > > It only matters if you want to use HBQT. For 4.5.x > you need SJLJ, for 4.6.x you need DWARF-2. > > If you don't use HBQT, it just doesn't matter for > Harbour. > > Brgds, > Viktor > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] recommended C compiler for Win
Viktor, I had the same impression about mingw being a nightmare to install and make it work. I'll try dragon media :) One more question, for harbour should I use sjlj unwinding or dwarf2? Thanks. Maurilio. Viktor Szakáts wrote: > Hi Maurilio, > >> what are the differences between mingw and dragon media? > > tdragon release is easy to setup/install, while mingw > is extremely time-consuming and frustrating experience > (and it doesn't get any better with newer versions). > > tdragon was also more agile in releasing usable packages > (now at gcc 4.4.1), official mingw tend to wait years between > releases (recently released 4.4.0, but was stuck at 3.4.5 > for many many years) > > tdragon has sjlj default unwinding, with dwarf-2 as easy > to install option, while official 4.4.0 is fixed to dwarf-2, > previous releases fixed to sjlj. (important for QT in > regards of Harbour). Note that dwarf-2 in tdragon has > special tool postfix. > > tdragon has a usable homepage, mingw has the most > frustrating (and broken) homepage of all open source projects > we have to interface with in regards of Harbour. > > Besides unwinding, from a C programmers POV they seem > pretty much identical, but I personally haven't done > any side-by-side speed / executable size / etc comparison, > theoretically they should be pretty close as well. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] recommended C compiler for Win
Smu, what are the differences between mingw and dragon media? Maurilio. smu johnson wrote: > It should be stated that the best one might be the one Harbour uses, > which is not the official MinGW release, but Twilight Dragon Media's > release, which is a build of a newer version of MinGW GCC. > > On Tue, Mar 9, 2010 at 2:05 AM, Viktor Szakáts <mailto:harbour...@syenar.hu>> wrote: > > > is mingw able to create stand-alone .EXEs and or .DLLs or does it > require to > > deliver some runtime code with them? > > mingw in context of Harbour requires only standard msvcrt.dll. > > (hbqt additionally requires mingwm10.dll, but it's an "issue" > with QT) > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org <mailto:Harbour@harbour-project.org> > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > -- > smu johnson mailto:smujohn...@gmail.com>> > > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] recommended C compiler for Win
Viktor, is mingw able to create stand-alone .EXEs and or .DLLs or does it require to deliver some runtime code with them? Best regards. Maurilio. Viktor Szakáts wrote: > Hi, > >> which is the harbour recommended C compiler for the windows platform? > > mingw (4.4), or msvc (2005 or upper). > > [ these msvc versions don't support Win9x, if that's a concern. ] > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] dlmalloc on OS/2
Przemyslaw, Przemysław Czerpak wrote: > On Mon, 08 Mar 2010, Maurilio Longo wrote: > > I believe that you are right but test on shared volumes is not an answer > because it may depend on host system behavior which can be different then > native OS2 one so it would be nice if you can verify it for native local > volumes too. Just to be sure :) > Tested on a local JFS volume, files with 'A' and 'R' or without flags are shown by current Directory() call. > I can try to help in this process but final tests have to be done by real > OS2 users. > Seems that the following files should be updated: >filesys.c (hb_fsOpen(), hb_fsCreate(), hb_fsCreateEx(), hb_fsClose(), > hb_fsSetDevMode()?, hb_fsIsDevice()? > hb_fsGetFileTime(), hb_fsEof(), > hb_fsRead(), hb_fsWrite(), hb_fsReadLarge(), hb_fsWriteLarge(), > hb_fsReadAt() (64bit offsets support), > hb_fsWriteAt() (64bit offsets support), > hb_fsTruncAt() (64bit offsets support), > hb_fsLockLarge() (64bit offsets support), > hb_fsSeekLarge() (64bit offsets support), > hb_fsDelete(), hb_fsRename(), hb_fsMkDir(), hb_fsChDir(), > hb_fsRmDir() >fstemp.c >fssize.c (it should be updated also for native MS-Win builds to eliminate > CRTL stat() function) >hbffind.c (hb_fsFindNextLow() (64bit file size support)) > > Do you seen any potential problems in switching to native OS2 API in above > functions? > I don't think that there could be problems, given that in the end CRTL uses the same APIs. The only problem could come from calling some CRTL with handles received by native APIs which could not be known to the CRTL. I remember a problem when I moved a part of xHarbour calls to API native ones, but I don't remember all the details; that said, if all file I/O goes through native APIs there can be no problem at all. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] recommended C compiler for Win
Hi, which is the harbour recommended C compiler for the windows platform? best regards. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] dlmalloc on OS/2
Przemyslaw, Przemysław Czerpak wrote: > The description suggests that files with attribute READONLY or ARCHIVE are > not shown if MAY bits are not set. It's not Clipper compatible behavior. > So it should be definitely fixed or the description is wrong. > I think description is wrong, see MUST_HAVE_ARCHIVED (0x2000) Must-Have Archive bit; excludes files without the archive bit set if bit 13 is set to 1. Files may have the Archive bit set if bit 13 is set to 0. and FILE_ARCHIVED (0x0020) May-Have Archive bit; includes files with the Archive bit set if bit 5 is set to 1. Excludes files with the Archive bit set if bit 5 is set to 0. I've also done a little test on a shared volume, all files with 'A' and one with 'R' flag set, Directory() returns the name of them all. So, docs are wrong :) >>> BTW what errors do you have? >> Error 8, that is ERROR_NOT_ENOUGH_MEMORY. > > Looks like some internal problem, i.e. with memory alignment. > yes, I think the problem could be caused by some old 16bit code, the strange thing is that, before my latest change, it was not failing always, but just from time to time apart in a test case I have, where two calls to Directory() for two different files, one ok and the other failing! > If it's memory alignment problem then such modification should resolve it. > Anyhow such things should be documented. > I was not able to find a reference to this issue googling for several hours :( > I think that we should clean current file IO code and use only native > OS2 API instead of current mixed OS2 and CRTL calls. We can also add > support for 64bit file API if it's available in OS2. > Yes, using APIs only could be a good thing, at least for code quality. Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: dlmalloc on OS/2
Massimo, I'm sure it's easy, it's just we can't do it .) Maurilio. Massimo Belgrano wrote: > The good news is that not is easy port your Clipper source to harbour > and porting your XPP source to harbour you can use HBNETIO > > > 2010/3/8 Maurilio Longo : >> Przemyslaw, >> >> I'm, at the moment, sharing them between DOS Clipper/XPP/Harbour, so, HBNETIO >> is not a solution to my problem, even if I'd like a lot to use it! >> >> Maurilio. >> > > > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: dlmalloc on OS/2
Przemyslaw, I'm, at the moment, sharing them between DOS Clipper/XPP/Harbour, so, HBNETIO is not a solution to my problem, even if I'd like a lot to use it! Maurilio. Przemysław Czerpak wrote: > On Fri, 05 Mar 2010, Maurilio Longo wrote: > > Hi, > >>> 2.c) Can you prepare to manage "64bit file support" ? I think yes >>> So you will be ready for future :-) >> It requires a lot more changes than DosFindFirst() >>> 2.d) I know you are aware of every movement which happen in OS/2 world, >>> and maybe you tested already, ... but maybe no >>> Days ago I removed "NETBIOS over TCP/IP" and installed .wpi files for >>> Samba 3.0.37, from NetLabs >>> ( Samba Server version 3.0.37 for eComStation (OS/2) 1.0.3 ) >>> - Migrated shares >>> - Everything is working fine to/from OS/2 and WinXPPSP2, Linux Mandriva >>> - Problems with shares/visibility between OS/2 and rest are gone >> I have problems with client access (OS/2 accessing a share), my server is >> samba, but on OpenSolaris. > > Please remember that for sharing DBFs HBNETIO can be used in such case. > It give to client 64bit file API if it's supported on the server side > (it doesn't matter what is the client OS) and resolves the problems with > syncing locks used by different programs working on different OS-es. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: dlmalloc on OS/2
David Arturo Macias Corona wrote: > 0) I do not know/understand what mean information above > Not a good start! :) Just kidding!! > 1) so, I do not know how your changes/considerations impact rest of OS/2 > users ( you are now aware we are many :-) ) > No impact, OBJ_TILE is supported since OS/2 2.x > 2) Based on that, I make some comments: > > 2.a) Is convenient to follow firefox path ? I think yes > So you can manage old and new kernels > The difference is that 'L' ending calls can return values bigger than 4Gb. > 2.b) Is convenient to manage files larger than 2 Gb ? I think yes > Sure. > 2.c) Can you prepare to manage "64bit file support" ? I think yes > So you will be ready for future :-) > It requires a lot more changes than DosFindFirst() > 2.d) I know you are aware of every movement which happen in OS/2 world, > and maybe you tested already, ... but maybe no > Days ago I removed "NETBIOS over TCP/IP" and installed .wpi files for > Samba 3.0.37, from NetLabs > ( Samba Server version 3.0.37 for eComStation (OS/2) 1.0.3 ) > - Migrated shares > - Everything is working fine to/from OS/2 and WinXPPSP2, Linux Mandriva > - Problems with shares/visibility between OS/2 and rest are gone > I have problems with client access (OS/2 accessing a share), my server is samba, but on OpenSolaris. > So as in this way we do not have: "... going throug IBM LanManager (aka > CIFS client) ..." I do not know if Harbour need some adjustment related > to samba and/or 2Gb and/or 64bit files and/or your recent change > I have eCS 2.0 silver, samba (eCS EVFS IFS) client does not handle locks and file access rights at all! So I have to use old IBM LanManager. Did you made tests with record/file locks, and exclusive access to files? Best regards. Maurilio -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wrong hbsms
It is 'the cathedral and the bazaar' :) http://catb.org/~esr/writings/homesteading/cathedral-bazaar/ and not 'market', sic! :) Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Wrong hbsms
Viktor, I did contribute tp_ on xharbour as a 'proof of concept' for a program I was developing on linux which needed serial communication and compatibility with the original telepathy API. The project was cancelled a few weeks after my contribution. My code was a refinement of a previous library I found googling around and, in its limited scope, was able to communicate through a modem. Now, the midnight bug could have been fixed by me or by any other one using it; I think it is against the 'market and bazaar' idea upon which free software is built to remove every contribution which is not fully bug-free. And, it is also against the very same idea to feel personally committed in keeping code sent to contrib when someone finds a bug. I mean, keep it easy, if you don't have time to fix each and every reported bug, don't do it. If someone needs that bug-fix _he_ will find a way to fix it and/or will search for some other solution. Removing your code you make harbour as a whole less inspiring and less able to solve problems, which is against what a compiler/language should be, IMHO, in the first place. My best regards. Maurilio. Viktor Szakáts wrote: >> - Original Message - From: "Jaroslaw Kadziola" >> To: "Harbour Project Main Developer List." >> Sent: Friday, March 05, 2010 8:25 AM >> Subject: Re: [Harbour] Wrong hbsms >> >> >>> To send sms' i'm using Nokia phone plugged to usb port. >>> In system must be installed modem driver (for this phone model). >> >> as messaging device, we currently use industrial siemens box [it is fixed, >> not portable], plugged into serial/com, custom made vb6 app using >> mscomm32.ocx, running on win/2003/64, but also sometimes having hangouts >> while waiting on gsm responses/confirmations, so i am seeking for some >> improvements > > hbsms was a generic solution using standard AT > modem commands via serial communication to the > device. > > I don't want to offend anyone here by contributing > code and not being able to give "proper" support > for it, and seemingly no one else wanted to touch > it with a stick, so it's better for everyone if > such abandoned piece of code is missing from our > SVN. Anyhow the code is accessible, so those who > find it useful can keep using it. As for telepathy > which is another buggy piece of code in Harbour, > I hope one day someone will fix it. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBI_PASSWORD
Enrico, it has a bigger problem (I think it still has :)) in that indexes are not encrypted and so your keys leak informations. Maurilio. Enrico Maria Giordano wrote: > Dear friends, is there any technical reason why DBI_PASSWORD can't be > used to crypt DBFs with memo fields? Even leaving memo fields uncrypted > while crypting all the other fields would be welcome. > > Thank you in advance. > > EMG > > -- > EMAG Software Homepage: http://www.emagsoftware.it > The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum > The Best of Spectrum Games: http://www.emagsoftware.it/tbosg > The EMG Music page: http://www.emagsoftware.it/emgmusic > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF download statistics 1.0.1 vs 2.0.0
>From David statistics, they're all moving to harbour on OS/2 :D Regards. Maurilio. Lorenzo Fiorini wrote: > binaries-windows > 1.0.0 -> 2.824 > 1.0.1 -> 13.150 > > 2.0.0 -> 4.215 > > the trend is similar for binaries-ubuntu and source > > Are developers waiting for 2.0.1 :) or are there still a lot of them > using 1.0.1? > > What do you read in the stats ( or stars )? > > best regards, > Lorenzo > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Microsoft's SMB2 in Vista and above crippling your network apps?
Smu, MS09-050: Vulnerabilities in SMB could allow remote code execution Are you sure this has anything to do with data corruption of .dbf/.cdx files? Maurilio. smu johnson wrote: > Well we have a ton of people who still use Windows, and because of that > we need a Windows solution. > > I am happy to report that after about 30 mins of Googling, I came across > this page, which solved the problem, if you disable SMB2. > > http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx > > It's amazing, as we have spent countless hours Googling for this months > ago, and relied on .bat files that worked 80% of the time. So far, this > works 100% of the time. > > This is a miracle for us!!! We've worried for 6 years about this problem. > > > On Tue, Mar 2, 2010 at 6:24 PM, Angel Pais <mailto:amigo...@adinet.com.uy>> wrote: > > The solution to your problems is NETIO. > It also allows you to host your dbfs in a linux box. > It is also more secure because users don`t have direct access to > your data. > > HTH > Angel > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org <mailto:Harbour@harbour-project.org> > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > -- > smu johnson mailto:smujohn...@gmail.com>> > > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] dlmalloc on OS/2
Ok,
I've found out :)
I have version 4.0 toolkit documentation, that is, OS/2 Warp4 level, the
lastest is 4.5, in 4.5 documentation you can read:
-8<---
Information levels designated L should be used in order to get complete size
information for files larger than 2GB. If information levels designated L are
not used, a size of one byte will be returned for files which are >2GB in size.
->8---
Given that in harbour there is no (at the moment at least) 64bit file support
for OS/2 I'd leave the current call.
Maurilio.
Maurilio Longo wrote:
> BTW,
>
> firefox 3.x for OS/2 has this code
>
> if (isWSEB)
> {
> rc = DosFindFirst( filename,
>&d->d_hdl,
>FILE_DIRECTORY | FILE_HIDDEN,
>&(d->d_entry.large),
>sizeof(d->d_entry.large),
>&numEntries,
>FIL_STANDARDL);
> }
> else
> {
> rc = DosFindFirst( filename,
>&d->d_hdl,
>FILE_DIRECTORY | FILE_HIDDEN,
>&(d->d_entry.small),
>sizeof(d->d_entry.small),
>&numEntries,
>FIL_STANDARD);
> }
>
> So it seems newer kernels can/have to(?) use the FIL_STANDARDL flag but,
> maybe, they work with the old one as well (my kernel is the last one).
>
> Maurilio.
>
>
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] dlmalloc on OS/2
BTW,
firefox 3.x for OS/2 has this code
if (isWSEB)
{
rc = DosFindFirst( filename,
&d->d_hdl,
FILE_DIRECTORY | FILE_HIDDEN,
&(d->d_entry.large),
sizeof(d->d_entry.large),
&numEntries,
FIL_STANDARDL);
}
else
{
rc = DosFindFirst( filename,
&d->d_hdl,
FILE_DIRECTORY | FILE_HIDDEN,
&(d->d_entry.small),
sizeof(d->d_entry.small),
&numEntries,
FIL_STANDARD);
}
So it seems newer kernels can/have to(?) use the FIL_STANDARDL flag but,
maybe, they work with the old one as well (my kernel is the last one).
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] dlmalloc on OS/2
Przemysław Czerpak wrote: > I cannot help you here. Information about DosFindFirst() in OS2 returned > by google suggest that our implementation should not work correctly, i.e.: > >Level 1 File Information (ulInfoLevel == FIL_STANDARD) >On output, pfindbuf contains the FILEFINDBUF3 data structure _without_ >the last two fields cchName and achName. This is used without EAs. > > If the above is true then you should use FIL_STANDARDL and FILEFINDBUF3L > structure. > I saw that on Control API docs as well, but I think this is wrong or, at least, not completely true. Here I always get file names with FIL_STANDARD, even with my last change which is able to retrieve nearly one hundred file names per DosFindFirst() call. > Also seems that flAttribute parameter has wrongly value. > Without ORing with FILE_ARCHIVED and FILE_READONLY files with above > attribute should be excluded. > bits 5..0 are MAY-have, that is, file name is returned either it has that attribute set or it has not. If you want only those files with attributes set, then you have to use must-have values, 13 MUST_HAVE_ARCHIVED (0x2000) Must-Have Archive bit; excludes files without the archive bit set if bit 13 is set to 1. Files may have the Archive bit set if bit 13 is set to 0. 12 MUST_HAVE_DIRECTORY (0x1000) Must-Have Subdirectory bit; excludes files that are not subdirectories if bit 12 is set to 1. Files may have the Subdirectory bit set if bit 12 is set to 0. 11 Reserved; must be 0. 10 MUST_HAVE_SYSTEM (0x0400) Must-Have System File bit; excludes nonsystem files if bit 10 is set to 1. Files may be system files if bit 10 is set to 0. 9 MUST_HAVE_HIDDEN (0x0200) Must-Have Hidden File bit; excludes nonhidden files if bit 9 is set to 1. Files may be nonhidden if bit 9 is set to 0. 8 MUST_HAVE_READONLY (0x0100) Must-Have Read-Only File bit; excludes writeable files if bit 8 is set to 1. Files may be read-only if bit 8 is set to 0. > BTW what errors do you have? > Error 8, that is ERROR_NOT_ENOUGH_MEMORY. With my last change, which uses a block obtained with a DosAlloc() with OBJ_TILE, that is a block aligned to a 64Kb segment, in low memory and with 16bit selectors set, it always works. This is on a SMP kernel searching for a file on a samba share, so going throug IBM LanManager (aka CIFS client) which is an old piece of code which might have some old 16bit/protect mode code inside. I'll commit this change shortly. >> Now, can you tell me if _all_ memory allocations, made via hb_xgrab(), when >> using dlmalloc.c go through dlmalloc.c line 1338, that is through os2mmap() > > Inside DLMALLOC _all_ memory is allocated by os2mmap() function. > Ok, thanks, at first I thought of changing it, but it is not enough since it seems to me that dlmalloc sub-allocs bigger blocks (which is correct, imho) but this makes DosFindFirst() fail from time to time. BTW, if we could be sure that some memory never goes to a DosXXX() call, we could add a OBJ_ANY to the call, making OS/2 use memory above the 512Mb limit that OBJ_TILE has; anyway, this is so a little improvement in every day code, I don't think it's worth the time I've spent writing about it here :) >> even if I'm not mmapping() nothing? > > MMAP is optionally used only in *nix DLMALLOC builds to improve performance > of memory allocation. It does not exists in MS-Windows and OS2 so it cannot > be used in such builds. > ok. >> Or there are other paths to memory allocations? > > Maybe but not inside DLMALLOC code, i.e. some CRTL functions may > allocate memory using different memory manager but DLMALLOC uses > only above function in OS2 builds. > Ok, perfect, I was interested in hb_xgrab() calls. Thanks a lot. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] pcode 0.3
Ok, I've found out what is my problem. hbtest uses harbour.dll, but the one used is the one inside path and not the one inside bin\os2\gcc, so the one on the path is the old one, with pcodever 2. Sorry for that. Maurilio. Maurilio Longo wrote: > And this is what gets written inside .c files created from .prg ones: > > HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HBTEST, "../../../hbtest.prg", 0x0, > 0x0003 ) > > So it seems it is writing 3 as it should, or not? > > Maurilio > > Maurilio Longo wrote: >> Lorenzo, >> >> I don't know what to do next, I've been building harbour for several months >> now, without problems. >> >> Now, I do a clean, a make and, on completely new .exes, I get >> >> B_LEGACY_TYPES_OFF -oxbptreeview.o -c xbptreeview.c >> ../../../../../bin/os2/gcc/harbour.exe ../../../xbpwindow.prg >> -I../../../../../ >> ontrib/hbqt -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 >> -D >> B_LEGACY_TYPES_OFF -oxbpwindow.o -c xbpwindow.c >> ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbxbp.a & >> ..\..\..\ >> .\..\config\os2rm -f __lib__.tmp >> >> (E:\REPOSITORY\HARBOUR)bin\os2\gcc\hbtest >> >> Unrecoverable error 9000: Module '../../../hbtest.prg' >> was compiled with unsupported PCODE version 0.3. >> Please recompile. >> >> hbsetup.h is at revision 14027 and contains >> >> /* *** >> * Define PCODE version number >> * HB_PCODE_VER_MIN define minimum supported PCODE by HVM >> */ >> >> #define HB_PCODE_VER 0x0003 >> #define HB_PCODE_VER_MIN 0x0002 >> >> Why is it saying it's not ok?? >> >> Maurilio. >> >> >> Lorenzo Fiorini wrote: >>> On Tue, Mar 2, 2010 at 9:53 AM, Maurilio Longo >>> wrote: >>> >>>> I'm at the third full rebuild, make clean, make and I keep getting this, >>>> am I >>>> the only one? What's wrong with my hvm? >>> I've just done a make -s clean make install under Linux/gcc and it seems ok. >>> >>> No errors and hbtest works as expected. >>> >>> best regards, >>> Lorenzo >>> ___ >>> Harbour mailing list (attachment size limit: 40KB) >>> Harbour@harbour-project.org >>> http://lists.harbour-project.org/mailman/listinfo/harbour >>> > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] pcode 0.3
And this is what gets written inside .c files created from .prg ones: HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HBTEST, "../../../hbtest.prg", 0x0, 0x0003 ) So it seems it is writing 3 as it should, or not? Maurilio Maurilio Longo wrote: > Lorenzo, > > I don't know what to do next, I've been building harbour for several months > now, without problems. > > Now, I do a clean, a make and, on completely new .exes, I get > > B_LEGACY_TYPES_OFF -oxbptreeview.o -c xbptreeview.c > ../../../../../bin/os2/gcc/harbour.exe ../../../xbpwindow.prg > -I../../../../../ > ontrib/hbqt -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l > gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 > -D > B_LEGACY_TYPES_OFF -oxbpwindow.o -c xbpwindow.c > ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbxbp.a & > ..\..\..\ > .\..\config\os2rm -f __lib__.tmp > > (E:\REPOSITORY\HARBOUR)bin\os2\gcc\hbtest > > Unrecoverable error 9000: Module '../../../hbtest.prg' > was compiled with unsupported PCODE version 0.3. > Please recompile. > > hbsetup.h is at revision 14027 and contains > > /* *** > * Define PCODE version number > * HB_PCODE_VER_MIN define minimum supported PCODE by HVM > */ > > #define HB_PCODE_VER 0x0003 > #define HB_PCODE_VER_MIN 0x0002 > > Why is it saying it's not ok?? > > Maurilio. > > > Lorenzo Fiorini wrote: >> On Tue, Mar 2, 2010 at 9:53 AM, Maurilio Longo >> wrote: >> >>> I'm at the third full rebuild, make clean, make and I keep getting this, am >>> I >>> the only one? What's wrong with my hvm? >> I've just done a make -s clean make install under Linux/gcc and it seems ok. >> >> No errors and hbtest works as expected. >> >> best regards, >> Lorenzo >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] pcode 0.3
Lorenzo, I don't know what to do next, I've been building harbour for several months now, without problems. Now, I do a clean, a make and, on completely new .exes, I get B_LEGACY_TYPES_OFF -oxbptreeview.o -c xbptreeview.c ../../../../../bin/os2/gcc/harbour.exe ../../../xbpwindow.prg -I../../../../../ ontrib/hbqt -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 -D B_LEGACY_TYPES_OFF -oxbpwindow.o -c xbpwindow.c ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbxbp.a & ..\..\..\ .\..\config\os2rm -f __lib__.tmp (E:\REPOSITORY\HARBOUR)bin\os2\gcc\hbtest Unrecoverable error 9000: Module '../../../hbtest.prg' was compiled with unsupported PCODE version 0.3. Please recompile. hbsetup.h is at revision 14027 and contains /* *** * Define PCODE version number * HB_PCODE_VER_MIN define minimum supported PCODE by HVM */ #define HB_PCODE_VER 0x0003 #define HB_PCODE_VER_MIN 0x0002 Why is it saying it's not ok?? Maurilio. Lorenzo Fiorini wrote: > On Tue, Mar 2, 2010 at 9:53 AM, Maurilio Longo > wrote: > >> I'm at the third full rebuild, make clean, make and I keep getting this, am I >> the only one? What's wrong with my hvm? > > I've just done a make -s clean make install under Linux/gcc and it seems ok. > > No errors and hbtest works as expected. > > best regards, > Lorenzo > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] pcode 0.3
Guys, I'm at the third full rebuild, make clean, make and I keep getting this, am I the only one? What's wrong with my hvm? These are the files: 2/03/10 9:43 4.845124 a--- arrayshb.o 2/03/10 9:43 2.119124 a--- asort.o 2/03/10 9:43163124 a--- break.o 2/03/10 9:43 4.966124 a--- cmdarg.o 2/03/10 9:43 2.787124 a--- debug.o 2/03/10 9:43 2.933124 a--- dynlibhb.o 2/03/10 9:43 4.405124 a--- eval.o 2/03/10 9:43497124 a--- evalhb.o 2/03/10 9:43 1.320124 a--- extrap.o 2/03/10 9:43 2.360124 a--- harbinit.c 2/03/10 9:43 1.508124 a--- harbinit.o 2/03/10 9:43 9.010124 a--- hashfunc.o 2/03/10 9:43331.738124 a--- hvmall.o 2/03/10 9:43117124 a--- initexit.o 2/03/10 9:43 4.194124 a--- initsymb.o 2/03/10 9:43264124 a--- mainstd.o 2/03/10 9:43615124 a--- memvclip.o 2/03/10 9:43205124 a--- pcount.o 2/03/10 9:43 2.585124 a--- proc.o 2/03/10 9:43 3.432124 a--- procaddr.o 2/03/10 9:43496124 a--- pvalue.o 2/03/10 9:43 7.256124 a--- runner.o 2/03/10 9:43580124 a--- vm.o 25 file(s) 388.395 bytes used 179.056.009 K bytes free I've just rebuilt them!?! Maurilio. Maurilio Longo wrote: > Hi, > > code at svn 14032, full rebuid, on OS/2 gives: > > B_LEGACY_TYPES_OFF -oxbptoolbar.o -c xbptoolbar.c > gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 > -DH > B_LEGACY_TYPES_OFF -oxbptreeview.o -c xbptreeview.c > gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 > -DH > B_LEGACY_TYPES_OFF -oxbpwindow.o -c xbpwindow.c > ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbxbp.a & > ..\..\..\. > .\..\config\os2rm -f __lib__.tmp > > (E:\REPOSITORY\HARBOUR)bin\os2\gcc\hbtest > > Unrecoverable error 9000: Module '../../../hbtest.prg' > was compiled with unsupported PCODE version 0.3. > Please recompile. > > (E:\REPOSITORY\HARBOUR) > > Any idea? > > Maurilio. > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] dlmalloc on OS/2
Przemyslaw, I'm facing an error on OS/2 which I'm beginning to suspect it is due to the fact that we're not allocating the correct type of memory when calling DosFindFirst(). Now, can you tell me if _all_ memory allocations, made via hb_xgrab(), when using dlmalloc.c go through dlmalloc.c line 1338, that is through os2mmap() even if I'm not mmapping() nothing? Or there are other paths to memory allocations? Thanks. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] pcode 0.3
Hi, code at svn 14032, full rebuid, on OS/2 gives: B_LEGACY_TYPES_OFF -oxbptoolbar.o -c xbptoolbar.c gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 -DH B_LEGACY_TYPES_OFF -oxbptreeview.o -c xbptreeview.c gcc -I../../../../../contrib/hbqt -I. -I../../../../../include -Wall -W -O3 -DH B_LEGACY_TYPES_OFF -oxbpwindow.o -c xbpwindow.c ar -M < __lib__.tmp & strip -S ../../../../../lib/os2/gcc/hbxbp.a & ..\..\..\. .\..\config\os2rm -f __lib__.tmp (E:\REPOSITORY\HARBOUR)bin\os2\gcc\hbtest Unrecoverable error 9000: Module '../../../hbtest.prg' was compiled with unsupported PCODE version 0.3. Please recompile. (E:\REPOSITORY\HARBOUR) Any idea? Maurilio. -- ______ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13991] trunk/harbour
Przemyslaw, by the way, how comes that a call to ::atStart() does not give an error given I've no ::atStart() method in a class I've sublcassed from Thread() ? I'm referring to the ::execute() method which calls ::atStart() without testing for its presence. Maurilio. dru...@users.sourceforge.net wrote: > Revision: 13991 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13991&view=rev > Author: druzus > Date: 2010-02-25 13:32:21 + (Thu, 25 Feb 2010) > > Log Message: > --- > 2010-02-25 14:32 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/contrib/hbxpp/tthreadx.prg > + added paramter validation in THREAD:setInterval() and > THREAD:setStartTime() > + added support for THREAD:startTime > * updated TODO notes > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbxpp/tthreadx.prg > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13987] trunk/harbour
Thanks a lot Przemyslaw. Maurilio. dru...@users.sourceforge.net wrote: > Revision: 13987 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13987&view=rev > Author: druzus > Date: 2010-02-25 07:40:37 + (Thu, 25 Feb 2010) > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13971] trunk/harbour
Przemyslaw, > Just for information. > Any special reasons for this modification? > xpp doc says it's an iVar > > * ::threadSelf() method moved to HIDDEN section > > This one broke ThreadWait() and ThreadWaitAll() functions which now > cannot work with thread objects passed as parameter. I'm sorry, I'll revert this change tomorrow morning, I've made it because xpp thread class does not have a threadSelf() method. Best regards. Maurilio. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13980] trunk/harbour
Przemyslaw, dru...@users.sourceforge.net wrote: > * use DosQueryCurrentDir() instead of DosQCurDir() macro DosQCurDir() is the old 16 bit API. OS/2 was 16bit protect mode in its beginning. Maurilio. BTW, I was fixing CurDrive() this morning using _getcwd1(), is this telepathy?? -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] tthreadx.prg
Przemyslaw, ok thanks, I did not look into thfuncx! :), that said, it does not need to be inside while ::active enddo loop, since, in case the code is executed several times, the thread object executing it is always the same, am I right? Maurilio. Przemysław Czerpak wrote: > On Tue, 23 Feb 2010, Maurilio Longo wrote: > > Hi, > >> there is a call to >> ThreadObject( Self ) >> inside ::start() method of tthread class, is it needed? What does it really >> does given that the result is thrown away? > > Look at ThreadObject() implementation in thfuncx.prg. > It sets value which is later returned by ThreadObject() function. > If you find it more clear then you can divide current ThreadObject() > function into two different functions: > >THREAD STATIC t_oThread > >FUNCTION ThreadObject() > RETURN t_oThread > >FUNCTION __SetThreadObject( oThread ) > IF PCount() > 0 > t_oThread := oThread > ENDIF >RETURN NIL > > or move above ThreadObject() function and 'THREAD STATIC t_oThread' to > tthreadx.prg and replace: > ThreadObject( Self ) > with: > t_oThread := oThread > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] stuff.c
Sorry, already answered question :) -8<--- It cannot be done inside STUFF() due to strictly defined Clipper compatible syntax. To optimize code which make := STUFF( , , , ) it's necessary to detect that result of STUFF() function is assigned to the same variable as its 1-st parameter and replace above code by new funtcion which will operate on parameter passed by reference, i.e.: __STUFF( @, , , ) So it needs new function and compile time optimization. >8--- Maurilio. Maurilio Longo wrote: > Hi, > > why is Stuff() copying received parameter into a new item even when the number > of deleted chars equals the number of inserted ones or, more in general, when > current item can hold the result of the stuff() call without need to resize > it? > > Best regards. > > Maurilio. > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] stuff.c
Hi, why is Stuff() copying received parameter into a new item even when the number of deleted chars equals the number of inserted ones or, more in general, when current item can hold the result of the stuff() call without need to resize it? Best regards. Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] tthreadx.prg
Przemyslaw, I mean contrib/hbxpp/tthreadx.prg's tthread class. Maurilio. Maurilio Longo wrote: > Przemyslaw, > > there is a call to > > ThreadObject( Self ) > > inside ::start() method of tthread class, is it needed? What does it really > does given that the result is thrown away? > > Thanks > > Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] tthreadx.prg
Przemyslaw, there is a call to ThreadObject( Self ) inside ::start() method of tthread class, is it needed? What does it really does given that the result is thrown away? Thanks Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
David, could we put a request to the downloaders to write a short message telling us what they're doing with harbour? Just to know a little more. Maurilio. David Arturo Macias Corona wrote: > Maurilio: > >>Viktor Szakáts wrote: >>> The explanation is that 'os2-contrib' binary package >>> is offered as default download for all users not coming >>> from a Windows machine (it has the latest "release date"), >>> and probably many users download this package by mistake. >>> There is a total of 80 downloads for each core OS/2 binary >>> packages, and 280 for contrib, which causes the boost in >>> total OS/2 downloads. >>> >>This makes a lot more sense to me, I'm still surprised by that 80 core >>downloads, let's say they're really 30 or 40 unique users... well, it's >>really >>nice to know there are so many die-harders out there. > >>:) > > Right now sourceforge values are: > > harbour-2.0.0.contrib-os2.zip 280 > harbour-2.0.0.bin-os2.gcc335aout.zip 80 > harbour-2.0.0.bin-os2.gcc433.zip 80 > harbour-2.0.0.bin-os2.gcc335omf.zip 65 > harbour-2.0.0.bin-os2.watcom.zip116 > > so excluding contrib we have 621-280=341 downloads of core binaries, > released 26 Dec 2009 > > They are not only downloading Harbour 2.0.0 but even old releases > For example, beta3 grow from 236 to 251 since 26 Dec 2009, and other > releases too. They are playing and comparing > > And many of those die-harders prefer OpenWatcom :-) > > David Macias > > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
Viktor, Viktor Szakáts wrote: > The explanation is that 'os2-contrib' binary package > is offered as default download for all users not coming > from a Windows machine (it has the latest "release date"), > and probably many users download this package by mistake. > There is a total of 80 downloads for each core OS/2 binary > packages, and 280 for contrib, which causes the boost in > total OS/2 downloads. > This makes a lot more sense to me, I'm still surprised by that 80 core downloads, let's say they're really 30 or 40 unique users... well, it's really nice to know there are so many die-harders out there. :) Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Switch to detect undeclared vars being used
Viktor, Viktor Szakáts wrote: > > Or maybe, and if technically possible: > QOUT( ( NUMERIC ) x ) > Yes, a lot better, even if I still can't grasp the usefulness of such a code for a typeless language which would, anyway, print x. Maurilio. -- ______ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Switch to detect undeclared vars being used
Przemyslaw, Przemysław Czerpak wrote: > We have some initial code used for class declaration and strong typing but > it was never fully functional. Do we need strong typing to spot undeclared variables? > The last part is casting and here we probably have the biggest problem. > Now it's possible to use > AS > i.e.: > >func f( x as usual ) as string > if valtype( x ) == "N" > x := str( x as numeric ) > elseif valtype( x ) != "C" > x := "" > endif >return x as string > What's the need to write x := str( x as numeric ) given that I'm calling str? It seems to me just a waste of typing, even more so given the previous valtype which confirms it is a number. > other method is using some new operator which will work well with PP. > I.e. instead of 'AS' we can use '.AS.' because expressions like > .AS. are recognized by PP s single expression, i.e. > >? x .as. numeric > > is well preprocessed by PP to: > >QOUT( x .as. numeric ) > I really don't like this solution, .Something. operators are logical for me, while this one would be different. I'd say, what about x:toNumber() to treat it like an (implicit) object? Maurilio. -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13961] trunk/harbour
Viktor, just to know, what does -Wl really mean to the compiler? Best regards. Maurilio. vszak...@users.sourceforge.net wrote: > Revision: 13961 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13961&view=rev > Author: vszakats > Date: 2010-02-22 16:24:59 + (Mon, 22 Feb 2010) > > Log Message: > --- > 2010-02-22 17:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbqt/hbqt_hbdbfmodel.cpp > * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > * contrib/hbqt/hbqt_hbqtableview.cpp > * contrib/hbqt/hbqt_hbevents.cpp > * contrib/hbqt/hbqt_destruct.cpp > * contrib/hbqt/hbqt_utils.cpp > * contrib/hbqt/hbqt_hbqmainwindow.cpp > * contrib/hbqt/hbqt_hbqplaintextedit.cpp > * contrib/hbqt/hbqt_base.cpp > * contrib/hbqt/hbqt_hbslots.cpp > * Cleaned header inclusion order after adding hbapi.h to hbqt.h. > > * config/os2/gcc.mk > ! Fixed to use '-Wl,' trick proposed by Przemek, to forward obj list > script filename directly to linker. > This gets around the problem where gcc tries to pass expanded > scripts to subprocesses (ld) via cmdline, thus imposing a 32K > limit also to script files. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/config/os2/gcc.mk > trunk/harbour/contrib/hbqt/hbqt_base.cpp > trunk/harbour/contrib/hbqt/hbqt_destruct.cpp > trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.cpp > trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqmainwindow.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqplaintextedit.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp > trunk/harbour/contrib/hbqt/hbqt_hbqtableview.cpp > trunk/harbour/contrib/hbqt/hbqt_hbslots.cpp > trunk/harbour/contrib/hbqt/hbqt_utils.cpp > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: OS/2: -DTCPV40HDRS
Viktor, I'm not aware of such a macro, in the last twenty years, at least, OS/2 APIs didn't change, so maybe there was not such a need and TCPV40HDRS was introduced for one of the very few, if not the only one, subsystems to change APIs during all those years. Maurilio. Viktor Szakáts wrote: >> Viktor, >> >> I'd say a ver command should return a version >= 4.00 >> >> (E:\harbour\ftpd)ver >> >> The Operating System/2 Version is 4.50 > > That tells us the host OS version. We need > a way to tell the version of OS/2 we're > building _for_ though. Similar to _WIN32_WINNT > macro. > > Such macro may have some default defined > by headers, and it's also possible to > override it by user. This is the generic way > to force a build which targets and older > version of the OS environment (or even > newer, if the default is an older version). > >> The issue, though, is not when building on a warp 3 system, but trying to use >> a program built without this option on a warp 3 system. More or less like >> running the code to find out interface addresses on a win95 pc, because such >> a >> program requires libraries not available on and for warp 3. > > (pls see above) > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
