Re: [Harbour] hb_InetAddress()
Thanks guys, and, there's no way to list interface addresses in a portable way, is there? Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the best way to go. Maurilio. Przemysław Czerpak wrote: On Thu, 18 Feb 2010, Mindaugas Kavaliauskas wrote: Hi, Testing hb_InetAddress() on a listening socket I get back 0.0.0.0 while hb_InetPort() works as expected. hb_InetAddress() works when called on a connected socket where it returns the caller IP address. Is this the correct behavior? Perhaps, yes. I guess you have not specified the listen address, so, socket is listening on all available interfaces (eg. 127.0.0.1, 192.168.1.1, and so on on multihomed machine) and hb_InetAddress() returns 0.0.0.0 (=INADDR_ANY). Exactly. Local server address in this context is interface address. 0.0.0.0 means that socket is listening on all interfaces. 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] hb_InetAddress()
Maurilio Longo wrote: Thanks guys, and, there's no way to list interface addresses in a portable way, is there? Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the best way to go. Maurilio. AFAIK, it's the nearest thing to an official and portable procedure that has been invented for that purpose. I was a bit puzzled too when I was searching for the official way to get your interface addresses, and I found that this was the way... Giancarlo. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
On Fri, 19 Feb 2010, Maurilio Longo wrote:
Hi,
Thanks guys,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ ifname, ifaddr, bcastaddr, netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
On Fri, 19 Feb 2010, Giancarlo Niccolai wrote: Hi Giancarlo, Nice to see your message here. My best wishes to you. Maurilio Longo wrote: Thanks guys, and, there's no way to list interface addresses in a portable way, is there? Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the best way to go. Maurilio. AFAIK, it's the nearest thing to an official and portable procedure that has been invented for that purpose. I was a bit puzzled too when I was searching for the official way to get your interface addresses, and I found that this was the way... So probably the code I have cannot be ported to windows. But maybe it's possible to create windows only code with the same functionality. Let's see. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi! As I have proposed to write new HBQt demos, I had an idea today: Maybe the first of them could be a basic visual NanForum command help editor, that scans the correct Harbour folder, hides the NF format for the contributors, by presenting the respective fields as PlainText boxes, and agregate all .txt with $doc$ / $end$ declarations accessible within one interface, so people can stop thinking about the help format and start to write documentation in fact. By doing the properly folder scan, I can extend it to multilanguage also. I developed an tool some months ago that reads all the source code on folder /harbour/src + /harbour/contrib and compare it with the existing documentation in /harbour/doc and show me what has documented and what source files are modified. This tool works as a visual front-end to edit the documentation in the form NF. Additionally wrote an application that reads the format NF and exports to HTML + CSS into an format to integrate the project site ... I just did it as temporary tool, specific to this need and I developed it in Delphi (which is a language I know well) to run on my CPU with Windows and for my needs it is helping me as well, although it lacks some details to be completely ready . Since I could not waste time because our time is short, I opted for that for me it was faster ... Do you think this could be useful in this process? Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13841
David, Knut says gcc does not create a response file, but what happens if we call ld or/and emxomfld directly, without passing through gcc, after having created the correct response file? We could end up with a solution which works with every version of gcc without requiring a patch at all. BTW, they build mozilla or firebird, can it be possibile that those monster projects have fewer files than harbour? Maurilio. David Arturo Macias Corona wrote: Viktor: It's also possible they parse the disk option file, convert it to string and pass it as plain command-line (with 32KB limit) to subprocess. While disk option files are not _only_ meant to get around cmdline length limitations, but this is one of their primary functions, so IMO this is a bug in OS/2 GCC implementation and should be reported and fixed. Otherwise it defeats the purpose of disk option file almost completely. We know we are in same state as months ago and with Harbour grow the future catched us I send a public request to some well-known people in OS/2 world The first response few minutes later is from Knut St. Osmundsen (bird), the brain in Netlabs os2gcc development years ago ( gcc335 age ) and now brain of Sun VirtualBox too Message is included below and is very clear I hope Paul Smedley can trace this case and based in Knut proposal then implement some solution David Macias David Arturo Macias Corona wrote: Hi All: As I do not know who/where can help us I send this message to all of you with hope of a solution Please review, response and/or redirect to proper people In Harbour for OS/2 development ( www.harbour-project.org ) we face from long time a problem using os2gcc compilers when we try to build some .dll files Tracing I found an now famous 32 Kb limit: - Somewhere gcc is using 32 Kb limit for our case gcc -- emxomfld.exe ( ld.exe ) ( or is OS/2 limit ? :-) ) Yes, this is an OS/2 limitation. The usual workaround is to pass the arguments in a response file (emxomfld @filename.rsp). Without checking all the relevant code, I'm pretty sure that the compiler/linker driver (gcc) will not create a response file when invoking sub programs like as, ld or emxomfld. The easiest way to hack it into doing this would be to change pexecute() in libiberty/pexecute.c to create a response file for arguments exceeding, say, 24 KB. http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/libiberty/pexecute.c#L803 For all future communication, could you and your team please use the libc/gcc mailing list: http://svn.netlabs.org/libc#MailinglistBugs You can file bugs in the ticket tracker on that site, although, if it's gcc related and you want it fixed soon you're probably better off filing them with Paul's bug tracker. :-) -- __ | | | |__| 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] hb_InetAddress()
Przemysław Czerpak wrote: On Fri, 19 Feb 2010, Giancarlo Niccolai wrote: Hi Giancarlo, Nice to see your message here. My best wishes to you. :-) You're always in my mind. Respects. With regards to hb_InetGetHosts( NetName() ) If my memory is not wrong, it's the most portable way to know what's your address (or your addresses; GetHosts may return more than one interface known under your own name). As you said, to get the list of physically available interfaces there are system specific low-level APIs. More than POSIX, I think that's it's a system specific call (i.e. I think there are differences in BSD, Solaris, Haiku, and Linux; they can also be found under proc/, but not always in the same places; but I admit that my remembering may be wrong here). Having it multiplatform-ready at a simple call would galore :-). Giancarlo. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
On Fri, 19 Feb 2010, Przemysław Czerpak wrote:
Hi,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's
the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ ifname, ifaddr, bcastaddr, netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
Looking at header files seems that I can port it to OS2 (WATCOM) and
DOS-WATTCP but it will not work in MS-Windows builds so it will be
necessary to create independent implementation giving similar
functionality for this system only.
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OS/2: Harbour 13841
Hi, This is an option. We opted not to call ld directly for gcc compilers in general, but I think it's not a problem to make an exception for OS/2. Brgds, Viktor On 2010 Feb 19, at 11:29, Maurilio Longo wrote: David, Knut says gcc does not create a response file, but what happens if we call ld or/and emxomfld directly, without passing through gcc, after having created the correct response file? We could end up with a solution which works with every version of gcc without requiring a patch at all. BTW, they build mozilla or firebird, can it be possibile that those monster projects have fewer files than harbour? Maurilio. David Arturo Macias Corona wrote: Viktor: It's also possible they parse the disk option file, convert it to string and pass it as plain command-line (with 32KB limit) to subprocess. While disk option files are not _only_ meant to get around cmdline length limitations, but this is one of their primary functions, so IMO this is a bug in OS/2 GCC implementation and should be reported and fixed. Otherwise it defeats the purpose of disk option file almost completely. We know we are in same state as months ago and with Harbour grow the future catched us I send a public request to some well-known people in OS/2 world The first response few minutes later is from Knut St. Osmundsen (bird), the brain in Netlabs os2gcc development years ago ( gcc335 age ) and now brain of Sun VirtualBox too Message is included below and is very clear I hope Paul Smedley can trace this case and based in Knut proposal then implement some solution David Macias David Arturo Macias Corona wrote: Hi All: As I do not know who/where can help us I send this message to all of you with hope of a solution Please review, response and/or redirect to proper people In Harbour for OS/2 development ( www.harbour-project.org ) we face from long time a problem using os2gcc compilers when we try to build some .dll files Tracing I found an now famous 32 Kb limit: - Somewhere gcc is using 32 Kb limit for our case gcc -- emxomfld.exe ( ld.exe ) ( or is OS/2 limit ? :-) ) Yes, this is an OS/2 limitation. The usual workaround is to pass the arguments in a response file (emxomfld @filename.rsp). Without checking all the relevant code, I'm pretty sure that the compiler/linker driver (gcc) will not create a response file when invoking sub programs like as, ld or emxomfld. The easiest way to hack it into doing this would be to change pexecute() in libiberty/pexecute.c to create a response file for arguments exceeding, say, 24 KB. http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/libiberty/pexecute.c#L803 For all future communication, could you and your team please use the libc/gcc mailing list: http://svn.netlabs.org/libc#MailinglistBugs You can file bugs in the ticket tracker on that site, although, if it's gcc related and you want it fixed soon you're probably better off filing them with Paul's bug tracker. :-) -- __ | | | |__| 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
Re: [Harbour] hb_InetAddress()
Przemyslaw, I can surely test it, but I don't have multihomed OS/2 PCs anymore :( 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] thread.c TOFIX: comment
Przemyslaw, Thank you for the information. I know the syntax but AFAIR when we were talking about it last time you said that this function has build in race condition and when thread terminates before other thread calls DosWaitThread() then this function fails with error code set to ERROR_INVALID_THREADID. It's the reason why I added '|| rc == ERROR_INVALID_THREADID' in the line below my TOFIX note: return rc == NO_ERROR || rc == ERROR_INVALID_THREADID; I do not have OS2 so I haven't verified it but because the event interface also has build in race condition when used as conditional variables then it's highly possible I'm not even surprised. In message Re: [Harbour] Re: 2008-09-18 01:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) I was writing: b. there is race condition in using this function because thread can terminate before we call it. I'm not sure of this, but I think that if you call it with the ID of a terminated thread or a thread terminates while you're calling it with its ID you get back 309 ERROR_INVALID_THREADID So, maybe it was just a misunderstanding, anyway: Current code does not look nice but it's working so I probably I should replace TOFIX with TOCLEAN or even NOTE to not confuse users. Of course if you know cleaner solution then of course we should implement it. I can confirm, my ftpd server (MT and under OS/2) works like a charm, I've tested it with up to 10 clients downloading a directory tree of nearly 2Gbs in a thousand file/folders without problems for several runs. :) BTW have you noticed that some OS2 ports of open source projects like MySQL have exactly the same bug as early Harbour OS2 MT code? This bug is in PTHREAD emulation code. No, I've never checked, can you point me to some particular case so that I can forward this to the developers/porters; this is a BIG issue. Looks that it's common that programmers working with other systems do not expect API which has build race conditions and wrongly understand the OS2 documentation. I'm not sure DosWaitThread() has built in race condition, it seems a problem of a not so much clear documentation of the API (which, given IBM stopped developing it nearly 10 years ago!!, is not so surprisingly after all). That said, I cannot refrain, even this time, from thanking you for the outstandig work you did in supporting OS/2 (not to mention the general work in harbour). Best regards. Maurilio. PS. BTW, were it not enough clear, I love OS/2 like a child, I don't even know why, but that's it .) -- __ | | | |__| 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: About Harbour Documentation
Hi Renato can you Publish your delphi source samebody will convert in harbour Is possible a delphi2harbour.ch for convert sample application? 2010/2/19 Vailton Renato vail...@gmail.com: Hi! As I have proposed to write new HBQt demos, I had an idea today: Maybe the first of them could be a basic visual NanForum command help editor, that scans the correct Harbour folder, hides the NF format for the contributors, by presenting the respective fields as PlainText boxes, and agregate all .txt with $doc$ / $end$ declarations accessible within one interface, so people can stop thinking about the help format and start to write documentation in fact. By doing the properly folder scan, I can extend it to multilanguage also. I developed an tool some months ago that reads all the source code on folder /harbour/src + /harbour/contrib and compare it with the existing documentation in /harbour/doc and show me what has documented and what source files are modified. This tool works as a visual front-end to edit the documentation in the form NF. Additionally wrote an application that reads the format NF and exports to HTML + CSS into an format to integrate the project site ... I just did it as temporary tool, specific to this need and I developed it in Delphi (which is a language I know well) to run on my CPU with Windows and for my needs it is helping me as well, although it lacks some details to be completely ready . Since I could not waste time because our time is short, I opted for that for me it was faster ... Do you think this could be useful in this process? -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi! 2010/2/19 Massimo Belgrano mbelgr...@deltain.it: Hi Renato can you Publish your delphi source samebody will convert in harbour Is possible a delphi2harbour.ch for convert sample application? I honestly think something like this is hard to happen. I can even post the current code (which lacks some of the details yet) without problems, but I believe that to develop something similar or more specific would only postpone the most important work at the time: start writing the documentation. I ended up riding these tools for their own use without saying a word with the group, just not to open discussion about what GUI or LIB was better to do, just to save time and power and in a short period of time demonstrate the most important: documentation is produced and its outcome on the site. But I see no problems in releasing the code if someone wants to assess, but I am using for some tests on the site before actually produce the documentation itself, I think I need to finish one or two details before releasing the release final. Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
2010/2/19 Vailton Renato vail...@gmail.com: Hi! I honestly think something like this is hard to happen. I can even post the current code (which lacks some of the details yet) without problems, but I believe that to develop something similar or more specific would only postpone the most important work at the time: start writing the documentation. agree I ended up riding these tools for their own use without saying a word with the group, just not to open discussion about what GUI or LIB was better to do, just to save time and power and in a short period of time demonstrate the most important: documentation is produced and its outcome on the site. Very good Still compliment for your final resut But I see no problems in releasing the code if someone wants to assess, but I am using for some tests on the site before actually produce the documentation itself, I think I need to finish one or two details before releasing the release final. Good wait your final detail -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
On Fri, Feb 19, 2010 at 08:27, Vailton Renato vail...@gmail.com wrote: Hi! I developed an tool some months ago that reads all the source code on folder /harbour/src + /harbour/contrib and compare it with the existing documentation in /harbour/doc and show me what has documented and what source files are modified. This tool works as a visual front-end to edit the documentation in the form NF. Is this tool in Delphi too? I dont know if we was thinking the same thing, but anyway If yours are in Delphi I still want to do on mine, maybe some part can be used on HBIDE. As both tools work in NanForum format, both tools can be useful without conflicts. I am really focusing on easy of use, handling of all TXTs in doc/LANG and contrib/HBNNN/doc/LANG folders without manual loading, and multilanguage, but mine is starting and yours seems to be done. At least, with your tool and directly into the TXTs maybe someone can start writing documentation right now. Additionally wrote an application that reads the format NF and exports to HTML + CSS into an format to integrate the project site ... I just did it as temporary tool, specific to this need and I developed it in Delphi (which is a language I know well) to run on my CPU with Windows and for my needs it is helping me as well, although it lacks some details to be completely ready . Since I could not waste time because our time is short, I opted for that for me it was faster ... Do you think this could be useful in this process? I was thinking about parse into a database for the web, like mysql+php so we can search for commands online and so on, but this is a future step. For me, the lack of documentation is the true problem. As you already have this temporary tool, I believe that you can use it and share the result files somewere while we don't have another ready for use. Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Finally, If anyone really want to write documentation, there is no reason to wait for any tool, it's just a matter of pick up any text editor and start writing. Converting it into any other format after is the easy part. Nothing that copy+paste and some little formating won't do (just my opinion, anyway). Regards Bacco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
The next step will be a sync tool between all TXTs in doc/LANG with a wiki like proposed by Antonio One way not exclude the other 2010/2/19 Bacco carlosba...@gmail.com: On Fri, Feb 19, 2010 at 08:27, Vailton Renato vail...@gmail.com wrote: Hi! Is this tool in Delphi too? I dont know if we was thinking the same thing, but anyway If yours are in Delphi I still want to do on mine, maybe some part can be used on HBIDE. As both tools work in NanForum format, both tools can be useful without conflicts. I am really focusing on easy of use, handling of all TXTs in doc/LANG and contrib/HBNNN/doc/LANG folders without manual loading, and multilanguage, but mine is starting and yours seems to be done. At least, with your tool and directly into the TXTs maybe someone can start writing documentation right now. -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Przemek,
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
No problem, I've done MS-Windows only implementation that also includes MACs
address.
aAdapters == { {cType, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter} }
So if you provides functions names, file names, in short where putting it, I
think that don't it cost me a lot of work. :)
Best regards,
Xavi
El 19/02/2010 11:36, Przemysław Czerpak escribió:
On Fri, 19 Feb 2010, Przemysław Czerpak wrote:
Hi,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ifname,ifaddr,bcastaddr,netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
Looking at header files seems that I can port it to OS2 (WATCOM) and
DOS-WATTCP but it will not work in MS-Windows builds so it will be
necessary to create independent implementation giving similar
functionality for this system only.
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi I would like to help to make Official Harbour Documentation a reality. You have been done an excelent coding job here and harbour could be much more appreciated and enjoyed (yet) with a proper official documentation within. Unfortunatelly I have been following that writing Official Harbour Documentation counts on few cabaple heads and requires a lot more hands to be done. I am not sure of how and if this problem can be solved, but I feel like it worths the try to solve it, so I invite you to consider the execution of the following strategy: to form a Harbour Documentation Task Force. The Harbour Documentation Task Force would be conducted by at least three people on the following roles: 1 - Doc Writing Supervisor: writing productivity and the technical quality control of the document writing; 2 - Doc Tools Supervisor: development control of harbour documentation management tools; 3 - Doc Publishing Manager: gramatic and ortografic quality control of the documents, distribuition media and publishing management; 4 - General Coordinator: synchronize and coordinate the work of the 3 task forces; Task force 1 - Doc Writing The only goal of this task force is the most important: to write the text of the harbour documentation. The basic need to acomplish this task is human resources. So to be done this job needs a list of capable volunteers to write the text of the documentation. Considering the huge amount of code to be documented, this task has to be structured in topics. To minimize the debate about how such topic structure should be or look like, the same structure of harbour/src folder could be assumed as the list of topics for a start. Following such logic, documentation writing task would be distributed between Doc Writing Teams, each of which responsible for documenting one or more of the following code 14 topics: 1 - Codepage 2 - Common 3 - Compiler 4 - Debug 5 - Dynlib 6 - Hbextern 7 - Lang 8 - Macro 9 - Main 10 - Nortl 11 - PP, rdd, rtl and vm. There must be chosen a Doc Writing coordinator to synchronize this task to the general chronogram and supervise the quality of the writing. The first job this person should take care could be the calculation of how many teams (of how many people each) should be necessary to write the documentation of above 14 topics, considering the technical afinity among some of the topics and their weight differences, once some can have much more to be documented than others. Once that is defined, the following would be to recruit such amount of volunteers and allocate them to their tasks. Task force 2 - Doc Editing Tool This task force would initially develop a tool to make Doc Writing more organized and productive. Such tool should provide: 1 - documentation task status, comparing of harbour source files to harbour document files, classified by source folder; 2 - easy and simple interface to edit documents, so writers don't need to know or care about folders, files, markers etc, only about the text; 3 - document status control interface, where Doc Writing coordinator can sinalize and Doc Writers can see what documents are (and weather each document is) done, not started, incomplete or not good; Much of what it takes to provide the above seems to have been already achieved by Vailton using Delphy and they can be written in harbour. -- From: Bacco carlosba...@gmail.com Sent: Friday, February 19, 2010 9:56 AM To: Harbour Project Main Developer List. harbour@harbour-project.org Subject: Re: [Harbour] Re: About Harbour Documentation On Fri, Feb 19, 2010 at 08:27, Vailton Renato vail...@gmail.com wrote: Hi! I developed an tool some months ago that reads all the source code on folder /harbour/src + /harbour/contrib and compare it with the existing documentation in /harbour/doc and show me what has documented and what source files are modified. This tool works as a visual front-end to edit the documentation in the form NF. Is this tool in Delphi too? I dont know if we was thinking the same thing, but anyway If yours are in Delphi I still want to do on mine, maybe some part can be used on HBIDE. As both tools work in NanForum format, both tools can be useful without conflicts. I am really focusing on easy of use, handling of all TXTs in doc/LANG and contrib/HBNNN/doc/LANG folders without manual loading, and multilanguage, but mine is starting and yours seems to be done. At least, with your tool and directly into the TXTs maybe someone can start writing documentation right now. Additionally wrote an application that reads the format NF and exports to HTML + CSS into an format to integrate the project site ... I just did it as temporary tool, specific to this need and I developed it in Delphi (which is a language I know well) to run on my CPU with Windows and for my needs it is helping me as well, although it lacks some details to be completely ready . Since I could not
Re: [Harbour] Re: About Harbour Documentation
Hi all I would like to help to make Official Harbour Documentation a reality. Harbour Developers have been doing an excelent coding job here and Harbour Project could be much more appreciated and enjoyed with a proper official documentation. Unfortunatelly I have been following that writing Official Harbour Documentation counts on few capable heads and requires a much more than their two hands each to be done. I am not sure of how and if this problem can be solved, but I feel like it worths the try to solve it, so I invite you to consider the execution of the following strategy: to form a Harbour Documentation Task Force. The Harbour Documentation Task Force would be conducted by at least 4 people on the following roles: 1 - Doc Writing Manager: technical quality and productivity control of the document writing; 2 - Doc Tools Manager: functional quality and productivity control of harbour documentation management tools development; 3 - Doc Publishing Manager: language control of the documents, distribuition media and publishing management; 4 - Doc Task Coordinator: guide and synchronize the 3 task forces; Task force 1 - Doc Writing The only goal of this task force is the most important of all: write the text of the harbour documentation. The only resource to acomplish this task is capable and available people. So, to be accomplished, this task needs a list of technically capable volunteers to write the text of the documentation and a list os volunteers to rewrite compatible documentation from other sources. Considering the huge amount of code to be documented, this task has to be structured in topics. To minimize the debate about how such topic structure should be or look like, the same structure of harbour/src folder could be assumed as the list of topics for a start. Following such logic, writing task would be distributed between Doc Writing Teams, each of which responsible for documenting one or more of the following code 14 topics: 1 - Codepage 2 - Common 3 - Compiler 4 - Debug 5 - Dynlib 6 - Hbextern 7 - Lang 8 - Macro 9 - Main 10 - Nortl 11 - PP 12- RDD 13 - RTL 14 - VM. There must be chosen a Doc Writing coordinator to synchronize this task to the general chronogram and care for the technical quality of the writing. The first job this person should do would be to raise what is to be written and calc how many teams (of how many people each) should be necessary to document the 14 topics above, considering the technical afinity among some of the topics and their weight differences, once some can have much more to be documented than others. Once part of documentation was already written for others thanks to compatibility with Clipper it doesn't have to be reformulated, so if it cannot be directly incorporated to the doc repository, it should be manually read and retyped on text files - and to do that one doesn't get to know much about harbour internals, so many people could help on this. Once the size of the work is delimited and distribuited between the needed teams , the following job would be to recruit such amount of volunteers and allocate them to their jobs. Task force 2 - Doc Tools This task force would initially develop a tool to help Doc Writing Task Force on workflow uniformity, productivity and control. Such tool should initially provide : 1 - documentation task status, comparing of harbour source files to harbour document files, classified by source folder; 2 - easy and simple interface to edit documents, so writers don't need to know or care about folders, files, markers etc, only about the text; 3 - document status control interface, where Doc Writing coordinator can sinalize and Doc Writers can see what documents are (and weather each document is) done, not started, incomplete or not good; Much of what it takes to provide the above goods seems to have been already achieved by Vailton using Delphy and of course they can be done also using Harbour. I'm sure there will be plenty of volunteers to this task force, because most people oh the list codes very well, but we must consider that, without a capable team responsible for writing the docs there is not much sense to build such tools. Anyway, I believe the the 1st item above could help very much on Doc Writers recruiting, because once people know what exactly is to be written about each topic, it would be easier to manage the recruiting and volunteers could candidate to write about what they know, so I think this should be done first. Of course a lot of other things sure would have to be done by the Doc Tools team in near future, but I believe the above would be enough for a good start. Task force 3 - Doc Publishing This task force would be responsible for determining and providing (with Doc Tools team) the better distribution file formats and publishing media to the documentation. Maybe more imprtant than that, Doc Publishing task force would care for the language
Re: [Harbour] Re: About Harbour Documentation
Hi all I would like to help to make Official Harbour Documentation a reality. You have been done an excelent coding job here and harbour could be much more appreciated and enjoyed (yet) with a proper official documentation within. Unfortunatelly I have been following that writing Official Harbour Documentation counts on few cabable heads and requires a much more of their two hands to be done. I am not sure of how and if this problem can be solved, but I feel like it worths the try to solve it, so I invite you to consider the execution of the following strategy: to form a Harbour Documentation Task Force. The Harbour Documentation Task Force would be conducted by at least 4 people on the following roles: 1 - Doc Writing Supervisor: writing productivity and the technical quality control of the document writing; 2 - Doc Tools Supervisor: development control of harbour documentation management tools; 3 - Doc Publishing Manager: gramatic and ortografic quality control of the documents, distribuition media and publishing management; 4 - General Coordinator: synchronize and coordinate the work of the 3 task forces; Task force 1 - Doc Writing The only goal of this task force is the most important of all: to write the text of the harbour documentation. The basic need to acomplish this task is human resources. So to be done this job needs a list of capable volunteers to write the text of the documentation. Considering the huge amount of code to be documented, this task has to be structured in topics. To minimize the debate about how such topic structure should be or look like, the same structure of harbour/src folder could be assumed as the list of topics for a start. Following such logic, documentation writing task would be distributed between Doc Writing Teams, each of which responsible for documenting one or more of the following code 14 topics: 1 - Codepage 2 - Common 3 - Compiler 4 - Debug 5 - Dynlib 6 - Hbextern 7 - Lang 8 - Macro 9 - Main 10 - Nortl 11 - PP 12- RDD 13 - RTL 14 - VM. There must be chosen a Doc Writing coordinator to synchronize this task to the general chronogram and supervise the quality of the writing. The first job this person should take care could be the calculation of how many teams (of how many people each) should be necessary to write the documentation of above 14 topics, considering the technical afinity among some of the topics and their weight differences, once some can have much more to be documented than others. Once that is defined, the following job would be to recruit such amount of volunteers and allocate them to their tasks. Task force 2 - Doc Tools This task force would initially develop a tool to make Doc Writing more organized and productive. Such tool should initially provide : 1 - documentation task status, comparing of harbour source files to harbour document files, classified by source folder; 2 - easy and simple interface to edit documents, so writers don't need to know or care about folders, files, markers etc, only about the text; 3 - document status control interface, where Doc Writing coordinator can sinalize and Doc Writers can see what documents are (and weather each document is) done, not started, incomplete or not good; Much of what it takes to provide the above goods seems to have been already achieved by Vailton using Delphy and of course they can be done also using Harbour. I'm sure this is the task force that can be formed earlier, because most people here can code, but we must consider that, without a capable team responsible for writing the docs there is not much sense to build such tools. Anyway, I believe the the 1st item could help very much on the work Doc Writers recruiting, because once people know what exactly is to be written on each topic, it would be easier that they can candidate to write about this and that and maybe this task should be done in first place anyways. Of course a lot of other things sure would be asked from Doc Tools team in future, but I believe the above would be enough for the beginning. Task force 3 - Doc Publishing This task force would be responsible for determining the better distribution formats and publishing media and care for the gramatical and ortografical quality of the document text, as weel as all the aesthetic and text style considerations. Of course some of this job can be started right away, but sure its no sense at all to talk much about it before the documents start to be written. Sorry if I this was inconvenient and let me know if there is something else I can do to help. Best regards to all Leandro -- From: Bacco carlosba...@gmail.com Sent: Friday, February 19, 2010 9:56 AM To: Harbour Project Main Developer List. harbour@harbour-project.org Subject: Re: [Harbour] Re: About Harbour Documentation On Fri, Feb 19, 2010 at 08:27, Vailton Renato vail...@gmail.com wrote: Hi! I developed
[Harbour] Switch to detect undeclared vars being used
Hi, Since using Harbour from Clipper 5.2e, we'd have a few minor problems, and a lot of success. One thing that will make our lives easier in 100,000 lines of Clipper code is some sort of switch in Harbour / hbmk2 that will warn you if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR, etc etc... in a function. For example, if I do: FUNC GOOSE() LOCAL x, y FOR i := 1 TO 10 ? i NEXT RETURN It would warn me upon compilation that i isn't declared in the Function. Maybe I am asking too much, as I don't think it's technically wrong. Just that we have a lot of code where the original author forgot to keep his var declarations clean, and write LOCAL i after the FUNC declaration. I tried looking through the switches that Harbour.exe provides... but I couldn't find anything relevant. Thank you. Any thoughts / criticisms welcome. -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13922] trunk/harbour
Revision: 13922 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13922view=rev Author: vouchcac Date: 2010-02-20 01:20:08 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-19 17:22 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/resources/help.png + contrib/hbide/resources/sort.png + contrib/hbide/resources/sortdescend.png + Added new images and changed one old. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/resources/help.png Added Paths: --- trunk/harbour/contrib/hbide/resources/sort.png trunk/harbour/contrib/hbide/resources/sortdescend.png 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
[Harbour] Re: Hbide ready to use
Massimo Belgrano wrote: here is updated incremental guide for hbide http://harbourlanguage.blogspot.com/ Your blog is almost outdated now. Take a look at the interface with new goodies. A lot has changed. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Hbide-ready-to-use-tp4561432p4598130.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
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:[13878] trunk/harbour
From: vszak...@users.sourceforge.net Sent: Monday, February 15, 2010 12:14 PM Subject: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. Viktor, this change is incompatible with Clipper. Previous colours were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses RGBI palette, see here: * 4-bit RGBI palettes for explanation: http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI * EGA colour palette for hex values in implementation: http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette -- Regards from The Harbour Project mirror in Poland Andrzej P. Woźniak -- Hosting 2GB za 40 zl brutto http://www.klatka.pl ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
I think it's public.
http://groups.google.us/group/comp.lang.xharbour/browse_thread/thread/8a9348df065610fc#b8c7e71c405b7e52
Obviously adapted to the new Harbour.
Best regards,
Xavi
El 19/02/2010 19:11, Viktor Szakáts escribió:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
Hi Viktor,
Okay. I thought about it but waiting to see what says or does Przemek.
Hope the development list work, because the other participant are off topic.
Best regards,
Xavi
El 19/02/2010 20:06, Viktor Szakáts escribió:
Okay. Probably it would be better to change to load
the .dll dynamically, unless we want add this new
system .dll to default system lib libs for the sake
of one function. It's rarely used functionality, so
this would save all Harbour apps some load time and
memory consumption.
Brgds,
Viktor
On 2010 Feb 19, at 19:40, Xavi wrote:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
I think it's public.
http://groups.google.us/group/comp.lang.xharbour/browse_thread/thread/8a9348df065610fc#b8c7e71c405b7e52
Obviously adapted to the new Harbour.
Best regards,
Xavi
El 19/02/2010 19:11, Viktor Szakáts escribió:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlockHB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Switch to detect undeclared vars being used
smu johnson wrote: Since using Harbour from Clipper 5.2e, we'd have a few minor problems, and a lot of success. One thing that will make our lives easier in 100,000 lines of Clipper code is some sort of switch in Harbour / hbmk2 that will warn you if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR, etc etc... in a function. If tou want to detect such occurances: -w3 -es3 If you want to detect and ignore: -w0 -es2 - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Switch-to-detect-undeclared-vars-being-used-tp4601089p4601199.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13921] trunk/harbour
Revision: 13921 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13921view=rev Author: vszakats Date: 2010-02-20 00:11:43 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 01:03 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbsetup.h * Changed not to rely on _WIN32_WCE to detect WinCE. * config/wce/global.mk * utils/hbmk2/hbmk2.prg % Changed to not pre-define _WIN32_WCE to any value. This should be user choice. * contrib/hbfimage/fi_winfu.c ! Fixed for WinCE builds. Now only non-WinCE compatible parts are disabled and functions keep being defined on .prg level regardless. * contrib/hbfimage/fi_winfu.c * contrib/hbfimage/fi_wrp.c % Cleaned logic that guards '_WINDOWS_' definition. * contrib/hbwin/win_bmp.c ! Fixed to use hexadecimal notation instead of octal, because some compilers where getting confused and tried to match these with some codepages. * contrib/hbwin/win_prn1.c ! Fixed for poccarm, because Pelles C (even 6.0) forgets to map FONTENUMPROC to FONTENUMPROCW. * contrib/hbwin/win_prn3.c ! Added some extra WinCE guards to avoid warning for this platform. * src/debug/dbgentry.c * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/wce/global.mk trunk/harbour/contrib/hbfimage/fi_winfu.c trunk/harbour/contrib/hbfimage/fi_wrp.c trunk/harbour/contrib/hbwin/win_bmp.c trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_prn3.c trunk/harbour/include/hbsetup.h trunk/harbour/src/debug/dbgentry.c trunk/harbour/utils/hbmk2/hbmk2.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
[Harbour] SF.net SVN: harbour-project:[13923] trunk/harbour
Revision: 13923 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13923view=rev Author: vouchcac Date: 2010-02-20 01:37:31 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-19 17:40 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/resources/dbl2sglquote.png * contrib/hbide/resources/sgl2dblquote.png ! Changed contents. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/resources/dbl2sglquote.png trunk/harbour/contrib/hbide/resources/sgl2dblquote.png 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
Re: [Harbour] hb_InetAddress()
Okay. Probably it would be better to change to load
the .dll dynamically, unless we want add this new
system .dll to default system lib libs for the sake
of one function. It's rarely used functionality, so
this would save all Harbour apps some load time and
memory consumption.
Brgds,
Viktor
On 2010 Feb 19, at 19:40, Xavi wrote:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
I think it's public.
http://groups.google.us/group/comp.lang.xharbour/browse_thread/thread/8a9348df065610fc#b8c7e71c405b7e52
Obviously adapted to the new Harbour.
Best regards,
Xavi
El 19/02/2010 19:11, Viktor Szakáts escribió:
Okay. You can attach your source if you think so,
I'm sure it helps Przemek.
Something is definitely wrong with the list.
I've sent a msg to Phil.
Brgds,
Viktor
On 2010 Feb 19, at 18:59, Xavi wrote:
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway,
cAdapter, nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: About Harbour Documentation
στις 18/02/2010 17:27, O/H Viktor Szakáts έγραψε: Hi All, So, I'd like to ask prospective contributors to _ignore these_ and concentrate on our path. It has been said many times: There will only be a documentation (in any format, or medium), if someone actually writes them. There is no other way. Ok, let's (try to) write some documentation. But before we start we have to know, what format should adopt. I mean, is Nanforum format mandatory or we could follow a more human form? For example, I am going to start documenting the functions HB_DirExists(), HB_FileExists(), HB_FNameExists() found into src\rtl\hbfile.c I choose to reproduce the structure of, say, doc\en-EN\dir.txt, hence i have to write something like: /* * The following parts are Copyright of the individual authors. * www - http://www.harbour-project.org * * Copyright 2010 documentor's_name m...@myoffice.gr *Documentation for: HB_DirExists(), HB_FileExists(), HB_FNameExists() * * See COPYING for licensing terms. * */ /* $DOC$ * $TEMPLATE$ * Function * $NAME$ * HB_DirExists() * $CATEGORY$ * API * $SUBCATEGORY$ * FileSys * $ONELINER$ * Determine if a directory exists * $SYNTAX$ * HB_DirExists( [cDirName] ) -- lExists * $ARGUMENTS$ * cDirName Directory name you want to check if exist. * Can contain a path and Drive letter. * Wildcards are NOT supported. * If no path specified then the current path is used. * SET DEFAULT are not evaluated. * $RETURNS$ * HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE * $DESCRIPTION$ *Here goes a detailed and very time consuming 'bla-bla' about the function *for which bla-bla is better to been left for the second documantation wave *and why not as an imagination exercise for the potential reader) * * $EXAMPLES$ * #include 'common.ch' * Function Main( cDir ) *Default cDir to lib *QOUT(Current directory:CurDir() ) *QOUT(--) *QOUT( Directory:cDirdoes IIF( HB_DirExists(cDir), , NOT ) exist! ) *cDir := C:\ *QOUT( Directory:cDirdoes IIF( HB_DirExists(cDir), , NOT ) exist! ) *QOUT() *WAIT *RETURN Nil * * $STATUS$ * R * $COMPLIANCE$ * C * $PLATFORMS$ * All(LFN) * $FILES$ * Library is rtl * $SEEALSO$ * HB_FileExists(), HB_FNameExists() * $END$ */ Now i have one/two more questions: Are all those eye-bothering '$' '*' necesary? Also, are _all_ the above statements mandatory or we could leave out some of them like $SUBCATEGORY$ $STATUS$ $COMPLIANCE$ etc. to make the txt more compact and 'quick-readable' Supposing the answers are 'yes' let see how the above document could be written: -- /* $DOC$ FUNCNAME : HB_DirExists( cDirName ) -- lExists SHORTDESC : Determine if a directory exists ARGUMENTS : cDirName Directory name you want to check if exist. Can contain a path and Drive letter. Wildcards are NOT supported. If no path specified then the current path is used. SET DEFAULT are not evaluated. RETURNS : HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE DESCRIPTION: [Here goes a detailed and very time consuming 'bla-bla' about the function for which bla-bla is better to left for the second documantation wave (and why not as an imagination exersize for the potential reader) ... ...] EXAMPLES: #include 'common.ch' Function Main( cDir ) Default cDir to lib QOUT(Current directory:CurDir() ) QOUT(--) QOUT( Directory:cDirdoes IIF( HB_DirExists( cDir ), , NOT ) exist! ) cDir := C:\ QOUT( Directory:cDirdoes IIF( HB_DirExists( cDir ), , NOT ) exist! ) QOUT() WAIT RETURN Nil PLATFORMS: All(LFN) FILES: Library is rtl SEE ALSO: HB_FileExists(), HB_FNameExists() $END$ */ An other critical question is how do i decide to document what? That is, how do I know if the above documentation is not already written by someone else? Obviously, somebody has to monitor the whole process, keeping an eye on 'who is documenting what' to avoid overlapping writing. And of course, there are other things/questions that must be cleared up, but can't been discussed all at once.. regards, --- Pete ___ Harbour
Re: [Harbour] hb_InetAddress()
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#include Iphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
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
lot of success. One thing that will make our lives easier in 100,000 lines of Clipper code is some sort of switch in Harbour / hbmk2 that will warn you if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR, etc etc... in a function. If tou want to detect such occurances: -w3 -es3 You probably meant: -es2 (there is no -es3 option in Harbour (nor Clipper)) If you want to detect and ignore: -w0 -es2 Rather simply: -w3, -w2, or -w1 extra -es2 means: threat warnings as errors. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: error C2485 compiling hvm.c with vce 2007
Antonio, Seems that Windows CE does not support the __declspec(thread) attribute. But you're using HB_STACK_MACROS, remember .- http://lists.harbour-project.org/pipermail/harbour/2009-December/029344.html -- Xavi El 19/02/2010 3:41, Antonio Linares escribió: More on the C2485 error compiling with Microsoft Windows CE 6.x SDK cl.exe: We have found where the error is coming from. It was not a define: hb_stack_ptr is defined as: HB_TLS_ATTR PHB_STACK hb_stack_ptr = NULL; HB_TLS_ATTR is translated into __declspec( thread ) and that may be causing a mangled name for the variable name that makes the compiler itself to error. If we remove (just for a test) HB_TLS_ATTR from estack.c (line 93) and from hbstack.h (line 200) then those errors go away. Obviously that is not a solution but take us closer to find it. regards, Antonio ___ 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:[13878] trunk/harbour
Hi Andrzej, From: vszak...@users.sourceforge.net Sent: Monday, February 15, 2010 12:14 PM Subject: [Harbour] SF.net SVN: harbour-project:[13878] trunk/harbour Revision: 13878 [...] * contrib/hbwin/hbwin.ch * Changed to use full (0xFF) color components for RGB presets. Viktor, this change is incompatible with Clipper. Previous colours were too dark, but 0xFF should stand for BRIGHT colours. Clipper uses RGBI palette, see here: * 4-bit RGBI palettes for explanation: http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#4-bit_RGBI * EGA colour palette for hex values in implementation: http://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter#The_EGA_color_palette Clipper had no graphical printing, nor any special color printing support for that matter, nor did it determine the actual colors that appeared on screen, so it's by no means a Clipper compatibility issue. If you mean to mimic MS-DOS (or rather VGA/EGA) screen colors in Windows printing, I can't see strong reason why this would be desired. WIN_PRN class is meant to (sort of) emulate line printers on GUI printers, so if anything, these colors should mimic color selection of color printers. Maybe this was the original intent, but it's still very difficult to tell, but even in this case I have some doubts that color printers had chosen just these exact color components for these specific colors as a standard: --- (from old hbwin.ch) #define RGB_BLACK RGB( 0x00, 0x00, 0x00 ) #define RGB_BLUE RGB( 0x00, 0x00, 0x85 ) #define RGB_GREEN RGB( 0x00, 0x85, 0x00 ) #define RGB_CYAN RGB( 0x00, 0x85, 0x85 ) #define RGB_REDRGB( 0x85, 0x00, 0x00 ) #define RGB_MAGENTARGB( 0x85, 0x00, 0x85 ) #define RGB_BROWN RGB( 0x85, 0x85, 0x00 ) #define RGB_WHITE RGB( 0xC6, 0xC6, 0xC6 ) --- F.e. why isn't white 0x85/0x85/0x85 to be consistent with other colors, or even more, why isn't it pure white: 0xFF/0xFF/0xFF, instead of being grey? :) Please also notice these color macros in hbwin.ch are not printing specific ones, but generic color constants, and current colors are the most generic, pure versions of the base colors: --- (current hbwin.ch) /* Color constants for convenience */ #define HB_WIN_RGB_BLACKWIN_RGB( 0x00, 0x00, 0x00 ) #define HB_WIN_RGB_BLUE WIN_RGB( 0x00, 0x00, 0xFF ) #define HB_WIN_RGB_GREENWIN_RGB( 0x00, 0xFF, 0x00 ) #define HB_WIN_RGB_CYAN WIN_RGB( 0x00, 0xFF, 0xFF ) #define HB_WIN_RGB_RED WIN_RGB( 0xFF, 0x00, 0x00 ) #define HB_WIN_RGB_MAGENTA WIN_RGB( 0xFF, 0x00, 0xFF ) #define HB_WIN_RGB_BROWNWIN_RGB( 0xFF, 0xFF, 0x00 ) #define HB_WIN_RGB_WHITEWIN_RGB( 0xFF, 0xFF, 0xFF ) --- Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hb_InetAddress()
[ Not work the development mailing list ]
Hi Viktor,
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#include Iphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
Best regards,
Xavi
El 19/02/2010 16:02, Viktor Szakáts escribió:
Hi Xavi, Przemek,
To have similar features for all platform, either we
should support MAC address on non-win platforms, or
(if this is not possible or not portable) we should
move win-only MAC support to some additional hbwin
function.
Brgds,
Viktor
On 2010 Feb 19, at 15:56, Xavi wrote:
[ Seem that not work the development mailing list ]
Przemek,
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
No problem, I've done MS-Windows only implementation that also includes MACs
address.
aAdapters == { {cType, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter} }
So if you provides functions names, file names, in short where putting it, I
think that don't it cost me a lot of work. :)
Best regards,
Xavi
El 19/02/2010 11:36, Przemysław Czerpak escribió:
On Fri, 19 Feb 2010, Przemysław Czerpak wrote:
Hi,
and, there's no way to list interface addresses in a portable way, is there?
Right now I'm using a hb_InetGetHosts( NetName() ), but I'm not sure it's the
best way to go.
This may return only IP address to one interface.
I created code for POSIX systems which scans all
interfaces and return array with AF_INET interfaces
where each entry contains:
{ifname,ifaddr,bcastaddr,netmask }
I'll check if it can work with MS-Windows and other
systems and if yes then I'll port it to harbour.
Looking at header files seems that I can port it to OS2 (WATCOM) and
DOS-WATTCP but it will not work in MS-Windows builds so it will be
necessary to create independent implementation giving similar
functionality for this system only.
I can commit basic implementation for all systems except MS-Windows
(it would be nice if you can test it in OS2 GCC and OW builds) and
maybe later someone will create windows implementation.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: About Harbour Documentation
Hi Pete, Ok, let's (try to) write some documentation. But before we start we have to know, what format should adopt. I mean, is Nanforum format mandatory or we could follow a more human form? No, Nanforum format is mandatory. /* $DOC$ * $TEMPLATE$ * Function * $NAME$ * HB_DirExists() * $CATEGORY$ ... * $END$ */ Now i have one/two more questions: Are all those eye-bothering '$' '*' necesary? Also, are _all_ the above statements mandatory or we could leave out some of them like $SUBCATEGORY$ $STATUS$ $COMPLIANCE$ etc. to make the txt more compact and 'quick-readable' Supposing the answers are 'yes' let see how the above document could be written: It could be written in any way, but then you'd need to create parsers for each format ppl happened to use. We've choosen NANFORUM format, because it is already developed, fits our purpose, easy to use, and we have already created tools that can process it. Our goal in this project is _not_ to invent or reinvent a new documentation format. Our goal is to document Harbour functions using an existing _standard_. This standard is NANFORUM. -- An other critical question is how do i decide to document what? That is, how do I know if the above documentation is not already written by someone else? Obviously, somebody has to monitor the whole process, keeping an eye on 'who is documenting what' to avoid overlapping writing. It's simple: If something is not present in /doc/en-EN/ folder, it's safe to document. (Even if it's present, it can probably need a review/rewrite.) who writes what: It requires some very basic synchronization between documentation writers. I don't think we should develop some over-burocratic scheme for this yet. If someone is starting seriously on a given lib or set of source files, it's enough to drop here an e-mail. At the time when this becomes inadequate, we can use a simple text file on wiki or in SVN, called TODODOC.txt or similar. This file can have each Harbour function, grouped by source file, with a status: TODO [username] - DONE [username] - CHECKED [username] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] rtl/tthreadx.prg
Przemyslaw, you said that harbour cannot differentiate an iVar named ::atStart from a method with the same name. Now, this causes problems with xpp compatibility where such a possibility exists, but, in the beginning, we could say that when I call ::Start( mysymbol ) I'm probably not going to depend on a method ::atStart which can exist only in sublasses of TThread which I would start with a oMyT := oMyClass():New():Start() So, question is: is there a way to know if a class implements a method? In which case we could run the ::atStart() method which is better than nothing, IMHO. I see in changelog a __objHasMsgAssigned( object, msgName ) and then a __objHasMsg and a __objHasData, don't distinguish methods from ivars? Maurilio. PS. If it were possibile to add this xpp extension it would be a good thing :) I do understand though that it could require too much work to be considered a priority. -- __ | | | |__| 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] SF.net SVN: harbour-project:[13924] trunk/harbour
Revision: 13924 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13924view=rev Author: vszakats Date: 2010-02-20 02:50:22 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 03:44 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + Added support for -harbourhelp option which will result in the same output as 'harbour --help' command. + Added reference to -harbourhelp option which display Harbour compiler help. + Added support for -build option support in hbmk2. It will be passed to Harbour compiler. * contrib/hbwin/hbwin.ch * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/utils/hbmk2/hbmk2.hu_HU.po trunk/harbour/utils/hbmk2/hbmk2.prg trunk/harbour/utils/hbmk2/hbmk2.pt_BR.po 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
Re: [Harbour] Re: About Harbour Documentation
For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? 2010/2/19 Massimo Belgrano mbelgr...@deltain.it: The next step will be a sync tool between all TXTs in doc/LANG with a wiki like proposed by Antonio One way not exclude the other 2010/2/19 Bacco carlosba...@gmail.com: On Fri, Feb 19, 2010 at 08:27, Vailton Renato vail...@gmail.com wrote: Hi! Is this tool in Delphi too? I dont know if we was thinking the same thing, but anyway If yours are in Delphi I still want to do on mine, maybe some part can be used on HBIDE. As both tools work in NanForum format, both tools can be useful without conflicts. I am really focusing on easy of use, handling of all TXTs in doc/LANG and contrib/HBNNN/doc/LANG folders without manual loading, and multilanguage, but mine is starting and yours seems to be done. At least, with your tool and directly into the TXTs maybe someone can start writing documentation right now. -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Daniel Gonçalves Base4 Sistemas Ltda. [www.base4.com.br] [twitter.com/spanazzi] ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13925] trunk/harbour
Revision: 13925 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13925view=rev Author: vszakats Date: 2010-02-20 02:55:24 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 03:55 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) - contrib/rddads/doc/en + contrib/rddads/doc/en-EN * Renamed. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/rddads/doc/en-EN/ Removed Paths: - trunk/harbour/contrib/rddads/doc/en/ 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
Re: [Harbour] Re: About Harbour Documentation
For example, suppose I want to contribute documenting the hbsqlit3 contrib, wich is module I'm very interested. What I'm suposed to do? Create a directory /harbour/doc/en-EN/contrib/hbsqlit3 and write text files in NF format? All contribs are meant to be independent from core, so their docs should be stored in /contrib/name/doc/en-EN/* [similar to already existing documentation for 'rddads'] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13926] trunk/harbour
Revision: 13926 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13926view=rev Author: vszakats Date: 2010-02-20 03:00:17 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 03:59 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) - contrib/hbgt/doc/en + contrib/hbgt/doc/en-EN - contrib/hbgd/doc/hbgd.txt + contrib/hbgd/doc/en-EN + contrib/hbgd/doc/en-EN/hbgd.txt - contrib/hbmisc/doc/en + contrib/hbmisc/doc/en-EN + contrib/hbbtree/doc/en-EN + contrib/hbbtree/doc/en-EN/hb_btree.txt - contrib/hbbtree/doc/hb_btree.txt * Cleanup to existing doc locations. Modified Paths: -- trunk/harbour/ChangeLog Added Paths: --- trunk/harbour/contrib/hbbtree/doc/en-EN/ trunk/harbour/contrib/hbbtree/doc/en-EN/hb_btree.txt trunk/harbour/contrib/hbgd/doc/en-EN/ trunk/harbour/contrib/hbgd/doc/en-EN/hbgd.txt trunk/harbour/contrib/hbgt/doc/en-EN/ trunk/harbour/contrib/hbmisc/doc/en-EN/ Removed Paths: - trunk/harbour/contrib/hbbtree/doc/hb_btree.txt trunk/harbour/contrib/hbgd/doc/hbgd.txt trunk/harbour/contrib/hbgt/doc/en/ trunk/harbour/contrib/hbmisc/doc/en/ 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
[Harbour] SF.net SVN: harbour-project:[13920] trunk/harbour
Revision: 13920 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13920view=rev Author: mauriliolongo Date: 2010-02-19 17:53:09 + (Fri, 19 Feb 2010) Log Message: --- 2010-02-19 18:52 UTC+0100 Maurilio Longo (maurilio.lo...@libero.it) * source/rtl/tthreadx.prg ! fixed ::active iVar to be .F. while thread is not running / has ended. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/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
Re: [Harbour] hb_InetAddress()
Hi Viktor,
Ok, without nStatus.
I wait to see Przemek's changes.
The development list is still not working.
Przemek,
All information is provided by GetAdaptersInfo() in Windows.
It would be nice to have the MAC address on other OS.
Best regards,
Xavi
El 19/02/2010 18:31, Viktor Szakáts escribió:
Hi Xavi,
That's good, but pls work together with Przemek,
to offer a multiplatform solution in one portable
core function. And use hbwin only to provide the
extra functionality, if and only if those cannot
be done in portable way.
PRG .-
aAdapters := win_GetAdaptersInfo()
aAdapters == { {cTipo, cNameDes, cMAC, cAddress, cMask, cGateway, cAdapter,
nStatus} }
Sort by nStatus.
C .-
DWORD hbwin_GetAdaptersInfo( PHB_ITEM pItmArray )
File .-
contrin/hbwin/win_getadt.c
It need .-
#includeIphlpapi.h
Also I've an added nStatus to try sort it by relevance.
I don't know whether to bring it or not? .-
...
pMacro = hb_macroCompile( {|x,y|x[8]y[8]} );
if( pMacro ){
hb_macroRun( pMacro ); hb_macroDelete( pMacro );
pCodeBlock = hb_stackItemFromTop( -1 );
if( pCodeBlock HB_IS_BLOCK( pCodeBlock ) ){
hb_arraySort( pItmArray, NULL, NULL, pCodeBlock );
}
hb_stackPop();
}
...
I think such sorting is best to be done by the caller if
necessary. IMO it's not very good to make such low-level
code dependent on macro compiler, or make any internal
automatic sorting whatsoever (you can leave pCodeblock
to NULL), since it can be solved easily on .prg level,
thus it's redundant.
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: About Harbour Documentation
Viktor Szakáts wrote: No, Nanforum format is mandatory. /* $DOC$ * $TEMPLATE$ * Function * $NAME$ * HB_DirExists() * $CATEGORY$ ... * $END$ */ How many keywords are there in this format ? Probably a basic implementation can be provided in hbIDE within a couple of days. And later Bacco's or Vailton's tool will be pressed into service. hbIDE can parse the source and can provide readymade templates to be filled in by the writer. When saved, it will be in above format. Should I proceed ? - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/About-Harbour-Documentation-tp4587608p4601441.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13927] trunk/harbour
Revision: 13927 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13927view=rev Author: vszakats Date: 2010-02-20 03:31:25 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 04:29 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) - src/rtl/browdbx.prg - src/rtl/mousex.c * src/rtl/tbcolumn.prg - src/rtl/philesx.c * src/rtl/Makefile - src/rtl/thfuncx.prg - src/rtl/oemansix.c - src/rtl/tthreadx.prg - src/rtl/tgetx.prg - src/rtl/idlex.c * src/rtl/browdb.prg - src/rtl/typefilx.prg - src/rtl/binnumx.c * src/rtl/tbrowse.prg - src/rdd/dbjoinx.prg - src/rdd/dblistx.prg - src/rdd/dbtotalx.prg - src/rdd/dbstruxx.prg - src/rdd/dbsortx.prg * src/rdd/Makefile - src/rdd/dbcmdx.c - src/rdd/dbdetacx.c - src/rdd/dbupdatx.prg - src/rdd/dbfuncsx.prg * include/hbextern.ch * contrib/xpp/xppextrn.ch * contrib/xpp/binnumx.c * contrib/xpp/tthreadx.prg * Synced contrib/xpp compatibility lib source with core. - Deleted Xbase++ compatibility functions from core. ; NOTE: INCOMPATIBLE. If you use Xbase++ function, you should now link xpp lib. (the name of the lib is not yet finalized) ; TODO: Clean remaining four HB_COMPAT_XPP guards and delete this build-time option from core. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xpp/binnumx.c trunk/harbour/contrib/xpp/tthreadx.prg trunk/harbour/contrib/xpp/xppextrn.ch trunk/harbour/include/hbextern.ch trunk/harbour/src/rdd/Makefile trunk/harbour/src/rtl/Makefile trunk/harbour/src/rtl/browdb.prg trunk/harbour/src/rtl/tbcolumn.prg trunk/harbour/src/rtl/tbrowse.prg Removed Paths: - trunk/harbour/src/rdd/dbcmdx.c trunk/harbour/src/rdd/dbdetacx.c trunk/harbour/src/rdd/dbfuncsx.prg trunk/harbour/src/rdd/dbjoinx.prg trunk/harbour/src/rdd/dblistx.prg trunk/harbour/src/rdd/dbsortx.prg trunk/harbour/src/rdd/dbstruxx.prg trunk/harbour/src/rdd/dbtotalx.prg trunk/harbour/src/rdd/dbupdatx.prg trunk/harbour/src/rtl/binnumx.c trunk/harbour/src/rtl/browdbx.prg trunk/harbour/src/rtl/idlex.c trunk/harbour/src/rtl/mousex.c trunk/harbour/src/rtl/oemansix.c trunk/harbour/src/rtl/philesx.c trunk/harbour/src/rtl/tgetx.prg trunk/harbour/src/rtl/thfuncx.prg trunk/harbour/src/rtl/tthreadx.prg trunk/harbour/src/rtl/typefilx.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
Re: [Harbour] Re: About Harbour Documentation
Hi Pete. I am writing a tool that will hide all eye-bothering features you have mentioned at the edit time. It's an optional tool, but It will agregate access to all docs directory tree (as they are already specified in doc/dirstruc.txt) from a single interface, and provide separated fields for each entry. The /*, $DOC$ etc in the output file will be created by the tool when you include a new command. Also, by scanning all doc dirs, It will be able to list and do a quick search in all documented commands, without the need to loading one by one, so writers can start writing a missing command with a single click. On Fri, Feb 19, 2010 at 19:15, pete_westg pete_we...@yahoo.gr wrote: στις 18/02/2010 17:27, O/H Viktor Szakáts έγραψε: Hi All, So, I'd like to ask prospective contributors to _ignore these_ and concentrate on our path. It has been said many times: There will only be a documentation (in any format, or medium), if someone actually writes them. There is no other way. Ok, let's (try to) write some documentation. But before we start we have to know, what format should adopt. I mean, is Nanforum format mandatory or we could follow a more human form? For example, I am going to start documenting the functions HB_DirExists(), HB_FileExists(), HB_FNameExists() found into src\rtl\hbfile.c I choose to reproduce the structure of, say, doc\en-EN\dir.txt, hence i have to write something like: /* * The following parts are Copyright of the individual authors. * www - http://www.harbour-project.org * * Copyright 2010 documentor's_name m...@myoffice.gr * Documentation for: HB_DirExists(), HB_FileExists(), HB_FNameExists() * * See COPYING for licensing terms. * */ /* $DOC$ * $TEMPLATE$ * Function * $NAME$ * HB_DirExists() * $CATEGORY$ * API * $SUBCATEGORY$ * FileSys * $ONELINER$ * Determine if a directory exists * $SYNTAX$ * HB_DirExists( [cDirName] ) -- lExists * $ARGUMENTS$ * cDirName Directory name you want to check if exist. * Can contain a path and Drive letter. * Wildcards are NOT supported. * If no path specified then the current path is used. * SET DEFAULT are not evaluated. * $RETURNS$ * HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE * $DESCRIPTION$ * Here goes a detailed and very time consuming 'bla-bla' about the function * for which bla-bla is better to been left for the second documantation wave * and why not as an imagination exercise for the potential reader) * * $EXAMPLES$ * #include 'common.ch' * Function Main( cDir ) * Default cDir to lib * QOUT(Current directory: CurDir() ) * QOUT(--) * QOUT( Directory: cDir does IIF( HB_DirExists(cDir), , NOT ) exist! ) * cDir := C:\ * QOUT( Directory: cDir does IIF( HB_DirExists(cDir), , NOT ) exist! ) * QOUT() * WAIT * RETURN Nil * * $STATUS$ * R * $COMPLIANCE$ * C * $PLATFORMS$ * All(LFN) * $FILES$ * Library is rtl * $SEEALSO$ * HB_FileExists(), HB_FNameExists() * $END$ */ Now i have one/two more questions: Are all those eye-bothering '$' '*' necesary? Also, are _all_ the above statements mandatory or we could leave out some of them like $SUBCATEGORY$ $STATUS$ $COMPLIANCE$ etc. to make the txt more compact and 'quick-readable' Supposing the answers are 'yes' let see how the above document could be written: -- /* $DOC$ FUNCNAME : HB_DirExists( cDirName ) -- lExists SHORTDESC : Determine if a directory exists ARGUMENTS : cDirName Directory name you want to check if exist. Can contain a path and Drive letter. Wildcards are NOT supported. If no path specified then the current path is used. SET DEFAULT are not evaluated. RETURNS : HB_DirExists returns a logical TRUE if cDirName exists, otherwise FALSE DESCRIPTION: [Here goes a detailed and very time consuming 'bla-bla' about the function for which bla-bla is better to left for the second documantation wave (and why not as an imagination exersize for the potential reader) ... ...] EXAMPLES: #include 'common.ch' Function Main( cDir ) Default cDir to lib QOUT(Current directory: CurDir() ) QOUT(--) QOUT( Directory: cDir does IIF( HB_DirExists( cDir ), , NOT ) exist! ) cDir := C:\ QOUT( Directory: cDir does IIF(
[Harbour] SF.net SVN: harbour-project:[13928] trunk/harbour
Revision: 13928 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13928view=rev Author: vszakats Date: 2010-02-20 03:51:10 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 04:48 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbsetup.ch * src/common/hbverdsp.c - Deleted HB_COMPAT_XPP option. It's no longer used in Harbour. From this point all Xbase++ compatibility functions and core classes are implemented in 'xpp' contrib library (name tentative). Add it to your lib list, if you need Xbase++ compatible functions. IOW HB_COMPAT_XPP build time option got converted to a app link time option. * src/rtl/isprint.c - Deleted dirty Xbase++ extension of ISPRINTER(). Now it's purely Clipper compatible in default build. INCOMPATIBLE. For Xbase++ version, use XPP_ISPRINTER() (or HB_ISPRINTER() which is the exact same). * src/rtl/tobject.prg * src/rtl/transfrm.c * src/rtl/memoedit.prg * include/memoedit.ch * Replaced #ifdef HB_COMPAT_XPP with #ifndef HB_CLP_STRICT. Which means we've endorsed these extensions in Harbour, and they are always enabled except in strict compatibility builds. * src/rdd/nulsys/nulsys.c - Deleted HB_COMPAT_XPP guarded function. * contrib/xhb/xhbver.prg * Always return .T. for _HB_COMPAT_XPP in version info. * include/box.ch * contrib/xpp/xpp.ch + Added Xbase++ compatibility box.ch constants from core box.ch. INCOMPATIBLE if you use B_THIN or B_FAT box style. * utils/hbtest/hbtest.prg * examples/hbdoc2/tmplates.prg * examples/hbdoc2/hbdoc2.prg - Deleted parts dealing with HB_COMPAT_XPP option. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/xhbver.prg trunk/harbour/contrib/xpp/xpp.ch trunk/harbour/examples/hbdoc2/hbdoc2.prg trunk/harbour/examples/hbdoc2/tmplates.prg trunk/harbour/include/box.ch trunk/harbour/include/hbsetup.ch trunk/harbour/include/memoedit.ch trunk/harbour/src/common/hbverdsp.c trunk/harbour/src/rdd/nulsys/nulsys.c trunk/harbour/src/rtl/isprint.c trunk/harbour/src/rtl/memoedit.prg trunk/harbour/src/rtl/tobject.prg trunk/harbour/src/rtl/transfrm.c trunk/harbour/utils/hbtest/hbtest.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
[Harbour] Language folder names
Hi Viktor, As I noticed that you are renaming the en folders to en-EN, I would like if you tell the correct table of language codes that we should look-up when someone decides to create a dir on another language, (also to help the automatic tools development). ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Language folder names
Hi Bacco, I renamed them to be consistent along the whole SVN. We should use the w3c standard language code: http://www.w3.org/TR/REC-html40/struct/dirlang.html#langcodes Now, having said that 'en-EN' might not be correct, for generic English it seems to be plain 'en', but I hope someone with deeper insight of this standard will enlighten us. Another question is what codepage to use. I'd vote for UTF-8. For English this is theoretically not important, though I expect that some accents will slip in anyway, so I think we should set UTF-8 standard for all doc texts. This can be easily converted to any target CP. Brgds, Viktor On 2010 Feb 20, at 04:54, Bacco wrote: Hi Viktor, As I noticed that you are renaming the en folders to en-EN, I would like if you tell the correct table of language codes that we should look-up when someone decides to create a dir on another language, (also to help the automatic tools development). ___ 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] SF.net SVN: harbour-project:[13929] trunk/harbour
Revision: 13929 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13929view=rev Author: vszakats Date: 2010-02-20 04:13:01 + (Sat, 20 Feb 2010) Log Message: --- 2010-02-20 05:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) + contrib/hbziparc/doc + contrib/hbziparc/doc/en-EN + contrib/hbziparc/doc/en-EN/hbziparc.txt * contrib/hbziparc/hbziparc.prg + Separated docs from source code. * include/memoedit.ch * Replaced #ifdef HB_COMPAT_XPP with #ifndef HB_CLP_STRICT. Which means we've endorsed these extensions in Harbour, and they are always enabled except in strict compatibility builds. (one remaining occurence) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbziparc/hbziparc.prg trunk/harbour/include/memoedit.ch Added Paths: --- trunk/harbour/contrib/hbziparc/doc/ trunk/harbour/contrib/hbziparc/doc/en-EN/ trunk/harbour/contrib/hbziparc/doc/en-EN/hbziparc.txt 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
Re: [Harbour] Re: Hbide ready to use
I am working now can you point me a solution for haìving project file indipendent from location directory? 2010/2/19 Pritpal Bedi bediprit...@hotmail.com: Massimo Belgrano wrote: here is updated incremental guide for hbide http://harbourlanguage.blogspot.com/ Your blog is almost outdated now. Take a look at the interface with new goodies. A lot has changed. -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour-users] Re: XLS File Routine
Thank you very much Jan ! I will analize and test it soon ... Angel ___ Harbour-users mailing list (attachment size limit: 40KB) Harbour-users@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour-users
