Re: [Harbour] SF.net SVN: harbour-project:[13489] trunk/harbour
Very good news! can we plan & promote a 2.1 with GTnet and hbide is some month? 2010/1/7 Przemysław Czerpak : > On Wed, 06 Jan 2010, Pritpal Bedi wrote: > > Hi, > >> I can sense this commit is the basis for NETRDD or NETGT of future. >> Am I right ? > > It can be useful for both but in fact it's side effect of some other > job not directly related to Harbour. > Anyhow I plan to work on GTNET in the nearest future so above code > should greatly help. > -- Massimo Belgrano ___ 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:[13489] trunk/harbour
Hi Przemysław Czerpak wrote: > > Anyhow I plan to work on GTNET in the nearest future so above code > should greatly help. > I could not hear a better with than above few words, for 2010. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055841.html Sent from the Harbour - Dev 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] runtime error and segfault in demoxbp
Hi Lorenzo Fiorini-2 wrote: > > Just a report, probably it has a known issue. To reproduce: > > - click on the browse > - using mouse wheel or down arrow try to go past the last row > - you'll get a runtime error message > - click ok > - the segfault > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb6c87710 (LWP 1929)] > 0xb75dd925 in QWidget::~QWidget () from /usr/lib/libQtGui.so.4 > (gdb) bt > #0 0xb75dd925 in QWidget::~QWidget () from /usr/lib/libQtGui.so.4 > #1 0xb79d9531 in QMainWindow::~QMainWindow () from /usr/lib/libQtGui.so.4 > No, it is not a known issue, never reported. On my system Windows XP Professional browser works perfect. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/runtime-error-and-segfault-in-demoxbp-tp27055409p27055818.html Sent from the Harbour - Dev 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] C (++) question
Hi,
Thank you for the clarification.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 7. 7:42
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] C (++) question
On Wed, 06 Jan 2010, Bisz István wrote:
Hi,
> In may analyzis of the assemble code of the:
> if ( nSize == 0 ) nSize = 1;,
> was more efficient that:
> if ( !size ) size++;
> at least with Keil C compiler for Dallas DS80C320, how do you think? Thank
> you in advance.
Yes in most of CPUs it's faster (but not all, i.e some CPUs have instruction
to INC/DEC memory cell but have no instruction to assing direct value so
such operation has to be done indirectly by register) and of course
if( !size ) size = 1;
is cleaner. I should not write the previous version and confuse user.
Anyhow modern C compilers can fully optimize such C code and generate
the same optimal code for both versions, i.e. try this:
/* tst.c */
static int size = 0;
void f1( void ) { if( !size ) size = 1; }
void f2( void ) { if( !size ) size++; }
void f3( void ) { if( !size ) ++size; }
with
gcc -O3 tst.c -S
and you will find that for f1(), f2() and f3() the same code
is generated. The difference is only with older compilers which
do not make advanced optimizations.
Sorry for confusion but each of us has some habits and I also was
using 8 computers in the past and sometime I use some constructions
which were better optimized but in this case I probably wanted to
safe one character in example ;-) I do not even remember because
it was unimportant for me and I know that it does not make any
difference for advanced optimizations in modern C compilers.
best regards,
Przemek
___
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] SF.net SVN: harbour-project:[13489] trunk/harbour
On Wed, 06 Jan 2010, Pritpal Bedi wrote: Hi, > I can sense this commit is the basis for NETRDD or NETGT of future. > Am I right ? It can be useful for both but in fact it's side effect of some other job not directly related to Harbour. Anyhow I plan to work on GTNET in the nearest future so above code should greatly help. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbwin wapi_GetLastError() issue.
On Thu, 07 Jan 2010, Xavi wrote: Hi, > I agree with that current code committed by Viktor is better but > disagree with don't have acces to repository and update my code > directly. I hope Viktor add you to developer list soon. Please only try to remember that we cannot check each commit so try be careful when you update core code. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] C (++) question
On Wed, 06 Jan 2010, Bisz István wrote:
Hi,
> In may analyzis of the assemble code of the:
> if ( nSize == 0 ) nSize = 1;,
> was more efficient that:
> if ( !size ) size++;
> at least with Keil C compiler for Dallas DS80C320, how do you think? Thank
> you in advance.
Yes in most of CPUs it's faster (but not all, i.e some CPUs have instruction
to INC/DEC memory cell but have no instruction to assing direct value so
such operation has to be done indirectly by register) and of course
if( !size ) size = 1;
is cleaner. I should not write the previous version and confuse user.
Anyhow modern C compilers can fully optimize such C code and generate
the same optimal code for both versions, i.e. try this:
/* tst.c */
static int size = 0;
void f1( void ) { if( !size ) size = 1; }
void f2( void ) { if( !size ) size++; }
void f3( void ) { if( !size ) ++size; }
with
gcc -O3 tst.c -S
and you will find that for f1(), f2() and f3() the same code
is generated. The difference is only with older compilers which
do not make advanced optimizations.
Sorry for confusion but each of us has some habits and I also was
using 8 computers in the past and sometime I use some constructions
which were better optimized but in this case I probably wanted to
safe one character in example ;-) I do not even remember because
it was unimportant for me and I know that it does not make any
difference for advanced optimizations in modern C compilers.
best regards,
Przemek
___
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:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> PROC main()
> ? netio_connect()
> ? NETIO_PROCEXISTS("STR")
> RETURN
> prints:
> .T.
> .T.
> but
> PROC main()
> ? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
> RETURN
> prints:
> .F.
> What I'm missing?
It's working for me in my Linux box so I can only guess that it's a
problem with socket initialization in windows builds. Please try:
PROC main()
HB_INETINIT()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
We have in netiocli.c:
HB_CALL_ON_STARTUP_BEGIN( _hb_file_netio_init_ )
s_netio_init();
HB_CALL_ON_STARTUP_END( _hb_file_netio_init_ )
but it's possible that when it's executed as startup code then
such initialization do not work and we should use hb_vmAtInit()
function. Can you verify it?
best regards,
Przemek
___
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:[13489] trunk/harbour
On Thu, 07 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> Mindaugas Kavaliauskas wrote:
> >homework.prg (test module):
> >PROC main()
> > ? netio_connect()
> > ? NETIO_PROCEXISTS("HB_HRBLOAD")
> > ? NETIO_PROCEXISTS("HELLO")
> > ? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
> > ? NETIO_PROCEXISTS("HELLO")
> > ? NETIO_FUNCEXEC("HELLO")
> >RETURN
> >Unfortunately test code prints:
> >.T.
> >.T.
> >.F.
> >and application hangs up.
> Sorry. It was a simple typo, should be:
>? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework1.hrb"))
> This method works!
Yes and it's _exactly_ what I have in mind though I haven't thought
about using #pragma __streaminclude. Very nice solution.
Thank you very much.
It also shows what clever programmer can do if he knows well HVM
internals. It's enough to leave even small peace code and he can
make what he only wants and it's the reason why protection by
available function list can work only if this is rather short list
of small and simple functions well known that work without any side
effects.
> BTW, results for this test are:
[...]
> I.e. every second time existing function is destroyed by
> unsuccessful overload. I'm not sure (not tested the details) if it
> is a bug in runner.c or some strange side effect, like: the second
> time code s_hHrb := HB_HRBLOAD("...") is called, HB_HRBLOAD() fails
> because Hello() already exists.
It's not a bug. See include/hbhrb.ch.
HRB module was loaded with HB_HRB_BIND_DEFAULT what means:
/* do not overwrite any functions, ignore
public HRB functions if functions with
the same names already exist in HVM */
So when it's loaded second time public HELLO() function still exists
in HVM as part of previously loaded module and the new one is ignored.
Just after loading the new module you cleared s_hHrb so the old module
with HELLO() function was unloaded so all is correct.
> So, HB_HRBLOAD() returns empty value
> and destroys the last pointer to loaded hrb module in static
> variable. The next time module does not clashes with existing
> functions, so, it's loaded again.
> Modification of homework1.prg solves the problem:
> STATIC s_hHrb
> INIT PROC LoadHello()
> IF EMPTY(s_hHrb)
> #pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
> ENDIF
> RETURN
Yes it's enough. Other solution is clearing the old module before
registering the new one so its public functions will not be used,
i.e.:
STATIC s_hHrb
INIT PROC LoadHello()
s_hHrb := NIL // clear the old module
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
RETURN
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] runtime error and segfault in demoxbp
Just a report, probably it has a known issue. To reproduce: - click on the browse - using mouse wheel or down arrow try to go past the last row - you'll get a runtime error message - click ok - the segfault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6c87710 (LWP 1929)] 0xb75dd925 in QWidget::~QWidget () from /usr/lib/libQtGui.so.4 (gdb) bt #0 0xb75dd925 in QWidget::~QWidget () from /usr/lib/libQtGui.so.4 #1 0xb79d9531 in QMainWindow::~QMainWindow () from /usr/lib/libQtGui.so.4 #2 0x0809294e in HBQMainWindow::~HBQMainWindow () #3 0x08092152 in release_HBQMainWindow () #4 0x080908c9 in Q_release () #5 0x08137cd9 in hb_gcRefFree () #6 0x0814619b in hb_itemClear () #7 0x08168ee4 in hb_arrayGarbageRelease () #8 0x08137cd9 in hb_gcRefFree () #9 0x0814619b in hb_itemClear () #10 0x08168ee4 in hb_arrayGarbageRelease () #11 0x08137b12 in hb_gcReleaseAll () #12 0x0816c353 in hb_vmQuit () #13 0x081708f3 in main () best regards, Lorenzo ___ 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:[13489] trunk/harbour
Hello Przemek > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c > ! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > Time and again you through bliss on us in terms of highly useful and advanced features, this is one in those gems, thank you very much. I can sense this commit is the basis for NETRDD or NETGT of future. Am I right ? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13489--trunk-harbour-tp27046268p27055352.html Sent from the Harbour - Dev 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] hbide problems
Hi Got hold of message after long, so the context is also old, but... Viktor Szakáts wrote: > >>> - I'd personally use much much less (or rather no) gradient effects as >>> backgrounds. It just slows down things (f.e. when working remote, or >>> VM) and it just distracting after the initial impact. >> >> I've tried to compile and run hbide.exe a few times, but it is not a >> useful tool for me (yet). The most important things I expect is >> comfortable source editor with column mark blocks, multi-file search and >> replace, block copy and move operations between opened source files. >> shortcuts for editing commands. All other things like themes, background >> gradients are totally not important for me, and I would like to switch it >> off in my setup. > > You pretty much summed up my needs as well. > For me too. As we all know hbIDE is only 1 month 19 days old PLUS the whole learning curve to exploit Qt PLUS the memory ploblems of hbQT, I feel hbIDE is at a pretty good grounds. It is a general programming fact that a developer tends to drift with fascinations and knowledge points and I, with hbIDE, is not an exception. Sometimes you start some feature but end up implementing altogether different, because, in the process of implemention of planned feature you learned entirely new which in turn get implemented out of sheer curisity and fascination. Block copy/paste is a real challenge and Qt does not provide for any built-in functionality. So it is taking a time. As far as editing and building a project, hbIDE has got some grounds. >> I know hbide is at very alpha stage and I do not want to say, that themes >> are not important for a good product, but it is not that we need to begin >> using the application. > > We can certainly discuss priorities (even HBQT is > far from stable yet), but eventually some sort of > "theming" or color setup is inevitable I guess. > I'd only be happier if the default would be more > clean cut MSVS/Eclipse/NetBeans-like, and not overly > colored. I think this would be give a more > familiar and more professional look to it. Easy > to change anytime though. > > I'm mostly concerned about general stability, speed, > and the features you mentioned. > Colors are OK and it is a mtter of half an hour for someone to supply me the values and I will be more than happy to include them in sources. Anybody with MSVS/Eclispse, etc IDE's color schemes? Today I implemented speed optimization, it is worth watching. Another point is the speed of syntax highlighting the first time text is pushed into editor where Qt tends to format the whole document at once. To me it sounds bug. It should been like highlighting the viewport full of lines. But I have an idea how to control. Once I get hold of it, speed issue will be resolved for ever. For rest of the features it is just a matter of time which I have in plenty at this moment. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/hbide-problems-tp27037344p27055270.html Sent from the Harbour - Dev 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:[13497] trunk/harbour
Revision: 13497 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13497&view=rev Author: vouchcac Date: 2010-01-07 02:58:58 + (Thu, 07 Jan 2010) Log Message: --- 2010-01-06 18:57 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideactions.prg * contrib/hbide/ideprojmanager.prg * contrib/hbide/idestylesheets.prg ! Fixed few more artifacts. ! Recent Files and Projects Menu was growing crazy, was a result of not deleting the menu item in XbpMenu() class. More attention is required yet. ! Fixed Viktor's reported bug. * contrib/hbxbp/xbpmenubar.prg ! Fixed a very bad type, copy/paste syndrome. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/idestylesheets.prg trunk/harbour/contrib/hbxbp/xbpmenubar.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] hbwin wapi_GetLastError() issue.
Thank you very much Przemek,
Yes I know, if we start 32,536 threads .-
Procedure Main()
Local i, nETS := Seconds()
? 'Begin in', nETS, 'System Seconds.'
wapi_SetLastError( 0 )
? 'Main Process'
for i := 1 to 32536
hb_threadStart( @thFunc(), i )
? 'Thread', i
next
? 'End Time Elapsed', Seconds() - nETS, 'Seconds.'
Wait
return
Procedure thFunc( nThr )
wapi_SetLastError( nThr )
return
In my system generates a maximum of 1,140 pairs.
This means that a maximum of 1.140 pairs will be generated for all not in every
thread.
If we start 16 threads is generate 16 pairs and most multi-threaded programs using less than 16 threads that are alive until the
end. Sorry, I think it's not so bad _first solution where before we had a issue_.
I agree with that current code committed by Viktor is better but disagree with don't have acces to repository and update my code
directly.
best regards,
--
Xavi
El 06/01/2010 4:56, Przemysław Czerpak escribió:
On Wed, 06 Jan 2010, Xavi wrote:
Hi,
Only activating HB_TRACE() with any example of /test/mt and adding
wapi_SetLastError() you can see that this is not true.
Just store only a single ID/lasterror pairs by thread and these pairs
can be made easily accessible from another thread.
I think that C don't have the problems of spoken language such as English.
But sorry, I use my code resources made before and It's maybe the reason
for not having seen another solution for Harbour.
Please note that the code you sent creates an array of thread IDs.
Each unique thread ID ever given by the system to thread needs separate
entry. It's not guarantied that OS tries to use as small pool of thread
IDs as possible. Usually not because such condition needs additional
operation and creates potential problems for programmers so this is
rather range of numbers cyclically reused when free.
It means that in long running programs creating a lot of (even very short
life) threads this array is systematically growing up until it reach the
size of thread IDs range used by OS.
Then for each StoreLastError() operation this code makes covered by
mutex linear scan of this array to locate calling thread entry.
Because the array is big (probably few thousands of entries for each thread
which existed before and called at least once StoreLastError()) then it's
strongly time consuming operation which usually cost much more then the
whole operation setting it. It will kill the performance. Additionally
it strongly reduce scalability because this expensive and quite frequently
used in all WIN API functions which needs to store LastError scan operation
is covered by mutex.
Current code committed by Viktor use TLS on HVM stack what resolve such
problems. Anyhow such code used even without HVM should be fixed and it
can be easy done. Just simply call:
static DWORD s_dwTlsIndex = TLS_OUT_OF_INDEXES;
[...]
void StoreLastError( DWORD dwError )
{
if( s_dwTlsIndex == TLS_OUT_OF_INDEXES )
{
/* call it at least once before the 1-st thread is created to
avoid race condition and potential resource leak */
s_dwTlsIndex = TlsAlloc();
}
TlsSetValue( s_dwTlsIndex, ( LPVOID ) dwError );
}
DWORD RetrieveLastError( void )
{
return ( DWORD ) TlsGetValue( s_dwTlsIndex );
}
Please remember that size of TLS data is limited. In bigger programs
I suggest to make s_dwTlsIndex global variable initialized at startup
and then store inside pointer to dynamically allocated structure. In
such case your code will use only one TLS item just like Harbour for
HVM stack.
If it's necessary to access such structure also by other threads then
they should be additionally linked in some public list. This is also
done by HVM which keeps list of all HVM stacks.
HTH
best regards,
Przemek
___
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] Re: SF.net SVN: harbour-project:[13495] trunk/harbour
Hi > There is still gradient fill on toolbar and menu background. I think it it presents a very good contrast, should not be a problem, IMO. > I'm also getting am RTE whenever I try to open a project > or I have it one open: > Message not found: HBIDE:LOADPROJECTPROPERTIES How do you open ? I mean from which option ? Regards Pritpal Bedi _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390707/direct/01/___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13495] trunk/harbour
> Log Message: > --- > 2010-01-06 17:10 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbide/projects/hbide.hbi >! Deleted hard-coded -o directive, no longer needed. >! Project paths are now shown without meta-dat. > > * contrib/hbide/resources/projectproperties.ui >! Changed components background behavior not to use gradients. > Now it is plain vanila white. Thank you, much better now. There is still gradient fill on toolbar and menu background. I'm also getting am RTE whenever I try to open a project or I have it one open: Message not found: HBIDE:LOADPROJECTPROPERTIES 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:[13496] trunk/harbour
Revision: 13496 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13496&view=rev Author: vouchcac Date: 2010-01-07 01:52:03 + (Thu, 07 Jan 2010) Log Message: --- 2010-01-06 17:53 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/ideprojmanager.prg ! Small fix to prev. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/ideprojmanager.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] SF.net SVN: harbour-project:[13486] trunk/harbour
Hi > >> P.S. BTW, was this your Christmas gift? :) > > > > No, not yet and I do not know when I'll find time to finish it :-( > > But you've just committed a RPC code, so, we must understand that > something even more great is waiting for us. :) I can sense, out of the two: NETRDD or NETGT. Current commit was a must to implement any of them. This is how Przemek always works. My guess is more towards NETRDD. Regards Pritpal Bedi, a student of software analysis and design http://www.vouch.in | Vouch, the software that GROWS with you http://www.vouch32.com | Home of Vouch32 ActiveX Server http://www.vouchcac.com/vouch32/vouch32.htm | A Free Windows Extended Utilities Library for Clipper, Xbase++ and (x)Harbour http://www.help.vouch.info | Online Vouch Help http://www.harbour.vouch.info | Online Harbour Help _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390707/direct/01/___ 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:[13495] trunk/harbour
Revision: 13495 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13495&view=rev Author: vouchcac Date: 2010-01-07 01:33:15 + (Thu, 07 Jan 2010) Log Message: --- 2010-01-06 17:10 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/projects/hbide.hbi ! Deleted hard-coded -o directive, no longer needed. ! Project paths are now shown without meta-dat. * contrib/hbide/resources/projectproperties.ui ! Changed components background behavior not to use gradients. Now it is plain vanila white. * contrib/hbide/hbide.prg * contrib/hbide/idedocks.prg * contrib/hbide/ideeditor.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideobject.prg * contrib/hbide/ideprojmanager.prg * contrib/hbide/idesaveload.prg * contrib/hbide/idestylesheets.prg ! Another round of reforms. And I am almost done with them. But wait... ! Started implementation of .env concept. What was missing from hbIDE => hbMK2 were the shell commands minimum necessary to let hbMK2 engine take control of. Now it can be done via QProcess:setEnvironment() call. I have left under the commented code in ideprojmanager.prg: /* Mechanism to supply environment variables to called process */ /* I do not know nixes but assume that Qt must be issueing proper */ /* shell command for the target OS to set them. */ /* If I am not wrong, HBMK2 can have these variables alread set */ /* and hence developer can choose any compiler of his choice. */ /* */ /* Actually, this was the intension in hbIDE.env I commited in IDE root */ I am been able to compile/link/execute hbIDE.exe after setting ( WinXP ) qListSets := QStringList():new() qListSets:append( "HB_WITH_QT=c:\qt\4.5.3\lib" ) ::qProcess:setEnvironment( qListSets ) just before triggering the process. Your input is desired as I know nothing about make system. ! Fixed many artifacts difficult to jot-down. + Implemented not to load any source until brought forward for view. This has increased the loading speed extremely fast and always consistent in timing. This feature was hanging on my drawing board since begining. This effectively means that sessions with any number of source tabs will not pose speed panelty. TODO: Syntax highlighting is a slow process, to speed-up. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideobject.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/idesaveload.prg trunk/harbour/contrib/hbide/idestylesheets.prg trunk/harbour/contrib/hbide/projects/hbide.hbi trunk/harbour/contrib/hbide/resources/projectproperties.ui 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] SF.net SVN: harbour-project:[13486] trunk/harbour
Hi, Przemysław Czerpak wrote: P.S. BTW, was this your Christmas gift? :) No, not yet and I do not know when I'll find time to finish it :-( But you've just committed a RPC code, so, we must understand that something even more great is waiting for us. :) Regards, Mindaugas ___ 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:[13489] trunk/harbour
Hi,
Mindaugas Kavaliauskas wrote:
homework.prg (test module):
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("HB_HRBLOAD")
? NETIO_PROCEXISTS("HELLO")
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
? NETIO_PROCEXISTS("HELLO")
? NETIO_FUNCEXEC("HELLO")
RETURN
Unfortunately test code prints:
.T.
.T.
.F.
and application hangs up.
Sorry. It was a simple typo, should be:
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework1.hrb"))
^ ^^^
This method works!
BTW, results for this test are:
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.T.
.T.
.F.
NIL
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.F.
.T.
.T.
Hello, World! :)
C:\harbour\contrib\hbnetio\tests>homework.exe
.T.
.T.
.T.
.T.
.F.
NIL
I.e. every second time existing function is destroyed by unsuccessful
overload. I'm not sure (not tested the details) if it is a bug in
runner.c or some strange side effect, like: the second time code s_hHrb
:= HB_HRBLOAD("...") is called, HB_HRBLOAD() fails because Hello()
already exists. So, HB_HRBLOAD() returns empty value and destroys the
last pointer to loaded hrb module in static variable. The next time
module does not clashes with existing functions, so, it's loaded again.
Modification of homework1.prg solves the problem:
STATIC s_hHrb
INIT PROC LoadHello()
IF EMPTY(s_hHrb)
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
ENDIF
RETURN
Regards,
Mindaugas
___
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:[13494] trunk/harbour
Revision: 13494 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13494&view=rev Author: vszakats Date: 2010-01-07 00:41:10 + (Thu, 07 Jan 2010) Log Message: --- 2010-01-07 01:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/Makefile - contrib/hbwin/win_err.c + contrib/hbwin/wapi_err.c * contrib/hbwin/hbwin.h * contrib/hbwin/hbwapi.h * contrib/hbwin/wapi_winbase.c * contrib/hbwin/wapi_winuser.c * contrib/hbwin/wapi_winbase_mutex.c * Naming cleanup of recent change. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/wapi_winbase_mutex.c trunk/harbour/contrib/hbwin/wapi_winuser.c Added Paths: --- trunk/harbour/contrib/hbwin/wapi_err.c Removed Paths: - trunk/harbour/contrib/hbwin/win_err.c 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] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
Przemysław Czerpak wrote:
On Wed, 06 Jan 2010, Lorenzo Fiorini wrote:
It's only important that the functions you want to execute are
linked with server code or where loaded dynamically. you can
even make sth like:
netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) )
BTW a small homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.
What does it mean "with default core functions"? Can I include
HB_HRBLOAD()? Or this should be done without uncommenting REQUEST
__HB_EXTERN__ in netiosrv.prg?
If linking of HB_HRBLOAD() is allowed, I propose solution:
homework2.prg (any functions to be registered):
FUNC Hello()
RETURN "Hello, World! :)"
homework1.prg (registrator module):
STATIC s_hHrb
INIT PROC LoadHello()
#pragma __streaminclude "homework2.hrb"|s_hHrb := HB_HRBLOAD(%s)
RETURN
homework.prg (test module):
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("HB_HRBLOAD")
? NETIO_PROCEXISTS("HELLO")
? NETIO_PROCEXECW("HB_HRBLOAD", HB_MEMOREAD("homework2.prg"))
? NETIO_PROCEXISTS("HELLO")
? NETIO_FUNCEXEC("HELLO")
RETURN
Unfortunately test code prints:
.T.
.T.
.F.
and application hangs up. I can not force HB_HRBLOAD() to work on server
side, though:
? NETIO_FUNCEXEC("STR", 5.1, 7, 2)
prints the expected result.
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Why not release all 2.01? imo TOMERGE 2.0 must be written in all 2.01 version all hbide modify not have to merge 2.0 for example IMO Merging is error what part of 2.01 not be include in next release? 2010/1/7 Viktor Szakáts : > For those interested in problem-free fixing of bugs in last > final release, 2.0.x branch was created at the time of the release, > and such work shall be done there. Volunteers may start it right > away by merging '[TOMERGE 2.0]' marked patches from trunk to > 2.0.x branch. This will ensure that users won't have to wait > for next major release to get any bugs fixed, but they can get > it much more quickly with 2.0.1. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
> As I see, maybe undesirable, as this list is declared a developers' list, > but there are a lot of users in this list requesting knowledge from (us). The fact that ppl are waiting for answers doesn't make this a support list. We have support forums/lists which are meant to solve these issues, and there are even companies offering paid support. Such support issues on the development list just distract developers from real development, and forces developers to spend their time on issues they a) are not necessarily the best candidates to solve b) didn't choose to solve when subscribing to the list c) could spend on enhancing the software. I'm personally subscribed to this list because I'm willing to offer my free time for _development_, not support. All in all, we can much efficiently use our scarce resources if we keep discussions on topic on the proper medium. And for those users who now think how rude this sounds, I have to again remind them, that this is a free project, so never, ever, ever expect more from volunteers than you yourself gave to the community. Also remember that you already got a superb compiler for free. IOW, if you feel you don't get enough support, or you don't get it quickly enough, think again, and try to actively answer those questions which you know the answer for. Do it on the harbour-users list, or on our forum. > I don't know, but we are compulsively to serve them, but now we are far away > from our starting point. We should generate less protuberance in the system > under development, if it is possible. It was just light observation leading > in this discussion now, sorry, it's time to finish it. Sorry but I strongly disagree. We've just released 2.0.0 final and one of the main point of such release, is that we can catch up with development with less concern that we temporarily break something. For those interested in problem-free fixing of bugs in last final release, 2.0.x branch was created at the time of the release, and such work shall be done there. Volunteers may start it right away by merging '[TOMERGE 2.0]' marked patches from trunk to 2.0.x branch. This will ensure that users won't have to wait for next major release to get any bugs fixed, but they can get it much more quickly with 2.0.1. 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:[13493] trunk/harbour
Revision: 13493 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13493&view=rev Author: vszakats Date: 2010-01-06 23:59:16 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-07 00:52 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_err.c * contrib/hbwin/hbwin.h * contrib/hbwin/wapi_winbase_mutex.c * Changed low-level hbwin_SetLastError() to accept lasterror as parameter. * contrib/hbwin/wapi_winbase.c * contrib/hbwin/wapi_winuser.c + Added internal handling of GetLastError(). This fixes lost GetLastError() values with apps linked with MT HVM. [ I didn't review wapi_commctrl.c, but some lazy checking on MSDN showed that these are generally not setting GetLastError(). ] * WAPI_GETSCROLLRANGE() now set ref params even in case of failure. ; TODO: Do some final renaming and rearrangement on the low-level. * contrib/hbwin/wapi_winbase_mutex.c * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/wapi_winbase.c trunk/harbour/contrib/hbwin/wapi_winbase_mutex.c trunk/harbour/contrib/hbwin/wapi_winuser.c trunk/harbour/contrib/hbwin/win_err.c 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] SF.net SVN: harbour-project:[13489] trunk/harbour
Hi,
All above functions use default connection set by NETIO_CONNECT()
for RPCs but it's also possible to specify server address and port
in / just like in parameter in RDD
functions, i.e.:
NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" )
PROC main()
? netio_connect()
? NETIO_PROCEXISTS("STR")
RETURN
prints:
.T.
.T.
but
PROC main()
? NETIO_PROCEXISTS("127.0.0.1:2941:STR")
RETURN
prints:
.F.
What I'm missing?
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
As I see, maybe undesirable, as this list is declared a developers' list, but there are a lot of users in this list requesting knowledge from (us). I don't know, but we are compulsively to serve them, but now we are far away from our starting point. We should generate less protuberance in the system under development, if it is possible. It was just light observation leading in this discussion now, sorry, it's time to finish it. Best regards, István ___ 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:[13492] trunk/harbour
Revision: 13492 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13492&view=rev Author: vszakats Date: 2010-01-06 22:54:39 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 23:53 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_err.c ! Fixed GetLastError() in MT mode. * utils/hbmk2/hbmk2.prg % nSize++ -> nSize = 1 * contrib/hbide/hbide.hbp ! Typo in comment. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.hbp trunk/harbour/contrib/hbwin/win_err.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
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
> Dear Viktor, > > You are right, the first goal is the software quality, but don't forget that > there are peoples without so much knowledge about the inner things. Maybe I still can't see what your point is. > sometimes should be useful to put yourself in their position. But please > consider these words, without any negative intentions, as an advice from a > people coming from harbour external world. Thanks for the advice, but first, this is a developers' list so talking and acting technical shouldn't be something unwelcome and a certain level of expertise is rightly expected from participants, second, SVN trunk is meant for development. It's not obligatory for users, so I still fail to see what point do you want to make here. Rewind Harbour 2-3-4 years, and you'll notice that it was much more difficult to do most things that everyone can now take for granted and this and the rest documented in INSTALL. That involved some many man month of free development from my part alone. Reading your words this was a waste of time, but in this case someone will have to hire a teacher here to try to fix the situation. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Dear Viktor, You are right, the first goal is the software quality, but don't forget that there are peoples without so much knowledge about the inner things. Maybe sometimes should be useful to put yourself in their position. But please consider these words, without any negative intentions, as an advice from a people coming from harbour external world. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
On 2010 Jan 6, at 23:11, Bisz István wrote: > Hi Viktor, > > We should made changes in a way that a "general user isn't affected" if it > is possible. This is a general rule in every system life cycle. > No problem we can handle it, as we are in development phase, forget it. Sorry I don't understand what you mean :( Affected by what exactly? default hbcppmm setting? Generl way of handling hbmk2 options? Method to control this setting? If the first, I shall remind everyone that HBQT is in alpha stage, so we should rather focus on finding and fixing its bugs, and general user isn't the primary target audience yet. Anyhow hbcppmm is probably better to be enabled even on the long run as its likely to give better performance at least on Windows systems. We can fine tune that later. First it should work. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Hi Viktor, We should made changes in a way that a "general user isn't affected" if it is possible. This is a general rule in every system life cycle. No problem we can handle it, as we are in development phase, forget it. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
On 2010 Jan 6, at 22:54, Bisz István wrote: > Hi Viktor, > > For me is OK thank you, but we always should think about a general user. I don't understand you. It's also meant for general users, it's simply how it works, and it's even logical. If you put options on the command line they are processed in left to right order that's all. "Fixing" that would generate the real strange and unusual effects. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Hi Viktor, For me is OK thank you, but we always should think about a general user. Best regards, István -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2010. január 6. 22:27 To: Harbour Project Main Developer List. Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test Hi Istvan, > The hbmk2 nohbcppmm is ineffective for hbide, so now we cant test hbide on linux, maybe it is specific just to Fedora12. To disable hbcppmm for hbide, pls try this command line: hbmk2 hbide.hbp -nohbcppmm The order of options is significant. If you issue -nohbcppmm first, it will be overridden (by hbide.hbp -> hbxbp.hbc -> hbqt.hbc -> hbcppmm=yes). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] C (++) question
Hi Przemek, I am coming initially from an 8BIT world, my main task was until your mailing list is to write things on a predefined processor in a completely different world no linux no windows etc. I am engaged on this list to implement a test software to my devices historically started with clipper, I dont know the original version, so is a long history, unimportant. It is not related to this list, but personally I am interesting your opinion about this issue. If you havent enough time ignore it. In may analyzis of the assemble code of the: if ( nSize == 0 ) nSize = 1;, was more efficient that: if ( !size ) size++; at least with Keil C compiler for Dallas DS80C320, how do you think? Thank you in advance. Best regards, István ___ 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:[13491] trunk/harbour
Revision: 13491 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13491&view=rev Author: vszakats Date: 2010-01-06 21:27:33 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 22:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL ! Fixed instructions for .deb binary build. * contrib/hbide/hbide.hbp + Comment extended. * utils/hbmk2/hbmk2.prg + Comment extended. * config/globsh.mk ! Fixed typos in nt clean commands. [TOMERGE 2.0] * ChangeLog + Added TOMERGE 2.0 to prev entry. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/config/globsh.mk trunk/harbour/contrib/hbide/hbide.hbp 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
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Hi Istvan, > The hbmk2 –nohbcppmm is ineffective for hbide, so now we can’t test hbide on > linux, maybe it is specific just to Fedora12. To disable hbcppmm for hbide, pls try this command line: hbmk2 hbide.hbp -nohbcppmm The order of options is significant. If you issue -nohbcppmm first, it will be overridden (by hbide.hbp -> hbxbp.hbc -> hbqt.hbc -> hbcppmm=yes). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 2.0.0 for OS X x86_64 binaries online
as subject. (NOTE: I had to employ little patch to mpkg_tgz.sh to be able to make it) 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:[13490] trunk/harbour
Revision: 13490 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13490&view=rev Author: vszakats Date: 2010-01-06 20:13:24 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 21:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * mpkg_tgz.sh ! Fixed to detect case when tar is mapped to bsdtar (such is the case on Snow Leopard). Use slightly modified tar command in this case. Please review. ; TOFIX?: Unpacking stub script always uses 'tar', maybe this needs to be fixed, although current command should work on Snow Leopard. - Deleted comment no longer valid. * utils/hbmk2/hbmk2.prg ! Fixed C++ memory manager override to handle zero size memory request and added protection when free operations are called with NULL. Thanks Istvan Bisz and Przemek for input. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/mpkg_tgz.sh 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
Re: [Harbour] SF.net SVN: harbour-project:[13486] trunk/harbour
On Wed, 06 Jan 2010, Mindaugas Kavaliauskas wrote: Hi, > Name of hb_znetInetInitialize() makes me think that this function > should be implemented in hbznet.c. I think hb_inet*() is a better > namespace if we can have more socket filters implemented using this > API. OK, I'll change it. > PHB_ZNETSTREAM should be changed to void* in HB_SOCKET_STRUCT in > general case, but let's leave it as it is now. It is void* because hbinet.c does not set _HB_ZNET_INTERNAL_ macro. > P.S. BTW, was this your Christmas gift? :) No, not yet and I do not know when I'll find time to finish it :-( > P.S.2. Some brainstorming... All this sounds like a case of a > general solution of adding filters/hooks in IO: znet, netio. If we > add some BlowFish encoding filter to sockets, we will soon need to > add both Z-compression and BF. This requires to implement additional > filter having both of features. Current architecture does not allow > to stack one filter onto another. These modification contains two things. One is support for ZLIB compression in sockets and the second is option to register it as filter in PRG level HB_INET*() sockets. You are right that I haven't added mechanism for multiple filters but it needs much deeper modifications to make it well and I do not know if I want to fight with HB_INET*() code. Sooner or later it will be replaced by new PRG INET API where I would like to implement few things in different way. Now I only want to add an option to current hb_znet*() functions to enable blowfish encryption. Please also remember that encryption has to be after compression because it's not possible to compress well encrypted data. I hope I'll add it soon and then add support for compression and encryption to NETIO code. best regards, Przemek ___ 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:[13489] trunk/harbour
> On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
>> Too smoothen the security edge of this feature,
>> maybe it would be nice to allow to limit the set
>> of functions made available through RPC on the
>> server side. This way programmer could have total
>> control over this aspect without worrying about
>> function being linked without knowledge or intent,
>> and keep verifying .map files to find out.
>
> Any limits by function list are usually very easy to exploit.
> As long as you do not plan to give access to some very small
> set of functions then sooner or later hacker find a way to
> pass some string to macrocompiler and make what he only wants
> i.e. if you allow to execute ordListAdd() then he can create
> index file with key expression having functions you wanted to
> block, etc. Such things has to be resolved inside HVM. See
> information I left about it in xhb-diff.txt at the end of
> NAMESPACEs section.
> Now instead of implementing feature which gives rather illusion
> of security instead of real protection I suggest to add very
> simply extension. User function which can be registered in
> NETIO socket and executed instead of really requested functions
> so if user thinks that such list is enough for him then he can
> make sth like:
>
> static s_funcLst := { "STR"=>, "DATE"=>, "TIME"=> }
> func mywrapper( sFunc, ... )
> if sFunc:name $ s_funcLst
> return sFunc:exec( ... )
> endif
> return nil
Perfectly fits what I had in mind.
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:[13489] trunk/harbour
On Wed, 06 Jan 2010, Szak�ts Viktor wrote:
> Too smoothen the security edge of this feature,
> maybe it would be nice to allow to limit the set
> of functions made available through RPC on the
> server side. This way programmer could have total
> control over this aspect without worrying about
> function being linked without knowledge or intent,
> and keep verifying .map files to find out.
Any limits by function list are usually very easy to exploit.
As long as you do not plan to give access to some very small
set of functions then sooner or later hacker find a way to
pass some string to macrocompiler and make what he only wants
i.e. if you allow to execute ordListAdd() then he can create
index file with key expression having functions you wanted to
block, etc. Such things has to be resolved inside HVM. See
information I left about it in xhb-diff.txt at the end of
NAMESPACEs section.
Now instead of implementing feature which gives rather illusion
of security instead of real protection I suggest to add very
simply extension. User function which can be registered in
NETIO socket and executed instead of really requested functions
so if user thinks that such list is enough for him then he can
make sth like:
static s_funcLst := { "STR"=>, "DATE"=>, "TIME"=> }
func mywrapper( sFunc, ... )
if sFunc:name $ s_funcLst
return sFunc:exec( ... )
endif
return nil
best regards,
Przemek
___
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:[13489] trunk/harbour
On Wed, 06 Jan 2010, Lorenzo Fiorini wrote:
> > It's only important that the functions you want to execute are
> > linked with server code or where loaded dynamically. you can
> > even make sth like:
> > netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) )
> > result := netio_funcexec( "MYFUNC1", param1, param2, param3 )
> > ? netio_funcexec( "MYFUNC2", result )
> Do you mean that all the functions inside the "mycode.hrb" are
> automatically registered and available without defining them DYNAMIC?
Yes but not all function. Only public functions inside loaded .hrb
module will be available and static not. Anyhow I made mistake here.
In current code HRB modules are automatically unloaded if you do not
store return value with pointer to HRB module in some visible for HVM
variable. To eliminate this effect you can create your own procedure
like:
proc my_hrbLoad( cHrb )
static s_aHrbHandles := {}
aadd( s_aHrbHandles, hb_hrbLoad( cHrb ) )
return
and link it with the netio server.
BTW a small homework ;-) Test for HVM knowledge.
Find a method to register dynamically in HVM such function from
client side using NETIO server which is linked only with default
core functions without any custom extensions.
> I mean can it be a way to have dynamic non binary libs of functions?
Yes, you can load HRB modules or dynamic libraries which register new
functions and they will be available for RPC sever just like are available
for macro compiler.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
On Wed, 06 Jan 2010, Szak�ts Viktor wrote: > So maybe the problem is that our malloc/realloc doesn't > handle zero size, while std version do. > In this case, we should probably allow zero size too. DLMALLOC malloc()/realloc() allow to use 0 bytes. Only inside hb_xgrab()/hb_xalloc() we have code which generate internal error when argument is 0 and it really can create problems for some C++ code. The hack with 'if( !size ) size++;' inside overloaded operators is sufficient workaround for it. Please also remember that in some cases it maybe necessary to use hb_xalloc() instead of hb_xgrab() - internal error when it's not enough memory can also create problems though here there is very small chance that some code will exploits it. There is bigger chance that we find some code which calls free( NULL ); which also causes internal error in hb_xfree() so some protection like 'if( ptr ) hb_xfree( ptr );' can be useful. Anyhow I still suggest to 1-st check which code exploited the problem and if it's our own code then we should try to fix it. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Hi, Maybe the following thread: http://lists.trolltech.com/qt-interest/2000-09/thread3-0.html contains the answer for your chew over this issue. Best regards, István -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2010. január 6. 19:01 To: Harbour Project Main Developer List. Subject: Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test So maybe the problem is that our malloc/realloc doesn't handle zero size, while std version do. In this case, we should probably allow zero size too. Brgds, Viktor On 2010 Jan 6, at 18:46, Bisz István wrote: > Hi, > > Finally, I was able to put in work the hbcppmm on Fedora12 by inserting the > "' if ( nSize == 0 ) nSize = 1;' > + Chr( 10 ) +;" > line in hbmk2.prg for both new operators generator sequences. As I understood > correctly this is the "hack" of GCC to handle zero sized object allocation. > If not, correct me. > > Please fin attached the trace files generated on Fedora12 for fully > functional demoqt, demoxbp and hbide. > > Best regards, > István > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13489] trunk/harbour
Viktor Szakáts escribió: Great feature. Thanks a lot for it. Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about function being linked without knowledge or intent, and keep verifying .map files to find out. Brgds, Viktor Maybe this could be achieved thru a registering mechamism ( public array ) of allowed remote funcions/procedures. This way the programmer has total control over security. HTH Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13489] trunk/harbour
Thank you, thank you, thank you !!! Did I thank you yet ? This is a dream coming true !!! Angel ___ 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:[13488] trunk/harbour
Just tested it, and there are still gradient backgrounds in Project properties dialog. BTW, now clicking on any line of the project tree, will select it, but it instantly loses focus, which makes it feel strange. Brgds, Viktor On 2010 Jan 6, at 09:31, vouch...@users.sourceforge.net wrote: > Revision: 13488 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13488&view=rev > Author: vouchcac > Date: 2010-01-06 08:31:20 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 00:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbide/hbide.prg > * contrib/hbide/idedocks.prg > * contrib/hbide/idemisc.prg > * contrib/hbide/ideprojmanager.prg >! Many artifacts corrected. >! Build process is now very satisfying if selected an > option with right-click on project node in Project Tree window. >! Diabled gradients in any window. Is it ok to fine tune > the windows with plain colors ? > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbide/hbide.prg >trunk/harbour/contrib/hbide/idedocks.prg >trunk/harbour/contrib/hbide/idemisc.prg >trunk/harbour/contrib/hbide/ideprojmanager.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
So maybe the problem is that our malloc/realloc doesn't handle zero size, while std version do. In this case, we should probably allow zero size too. Brgds, Viktor On 2010 Jan 6, at 18:46, Bisz István wrote: > Hi, > > Finally, I was able to put in work the hbcppmm on Fedora12 by inserting the > "' if ( nSize == 0 ) nSize = 1;' > + Chr( 10 ) +;" > line in hbmk2.prg for both new operators generator sequences. As I understood > correctly this is the "hack" of GCC to handle zero sized object allocation. > If not, correct me. > > Please fin attached the trace files generated on Fedora12 for fully > functional demoqt, demoxbp and hbide. > > Best regards, > István > > ___ > 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] SF.net SVN: harbour-project:[13489] trunk/harbour
Great feature. Thanks a lot for it. Too smoothen the security edge of this feature, maybe it would be nice to allow to limit the set of functions made available through RPC on the server side. This way programmer could have total control over this aspect without worrying about function being linked without knowledge or intent, and keep verifying .map files to find out. Brgds, Viktor On 2010 Jan 6, at 17:16, dru...@users.sourceforge.net wrote: > Revision: 13489 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489&view=rev > Author: druzus > Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c >! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c >+ implemented RPC in HBNETIO protocol >+ added the following client functions: > check if function/procedure exists on the server side: > NETIO_PROCEXISTS( ) -> > execute function/procedure on server the side, > do not wait for confirmation: > NETIO_PROCEXEC( [, ] ) -> > execute function/procedure on the server side and wait for > confirmation: > NETIO_PROCEXECW( [, ] ) -> > execute function on the server side and wait for its return value: > NETIO_FUNCEXEC( [, ] ) -> > All above functions use default connection set by NETIO_CONNECT() > for RPCs but it's also possible to specify server address and port > in / just like in parameter in RDD > functions, i.e.: > NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" ) >+ added new server side functions to enable/disable/check RPC support: > NETIO_RPC( | [, ] ) > -> > if RPC is enabled for listen socket then connection sockets inherit > this setting. >+ added 4-th parameter to NETIO_LISTEN() function. .T. enable > RPC support in returned listen socket which is later inherited by > connection sockets >* changed protocol version ID - current NETIO clients and servers > cannot be used with old code > > * harbour/contrib/hbnetio/utils/netiosrv.prg >* added option to enable RPC support in NETIO server > > If you want to make some test then you can execute netiosrv with > non empty 4-th parameter as server, i.e.: > ./netiosrv "" "" "" 1 > and try this code as client: > > proc main() > // pass server address to netio_connect() for non localhost tests > ? "NETIO_CONNECT():", netio_connect() > ? > ? "DATE() function is supported:", netio_procexists( "DATE" ) > ? "QOUT() function is supported:", netio_procexists( "DATE" ) > ? "HB_DATETIME() function is supported:", ; > netio_procexists( "HB_DATETIME" ) > ? > ? netio_procexec( "QOUT", repl( "=", 50 ) ) > ? netio_procexec( "QOUT", "This is RPC TEST", date(), hb_datetime() ) > ? netio_procexecw( "QOUT", repl( "=", 50 ) ) > ? > ? "SERVER DATE:", netio_funcexec( "DATE" ) > ? "SERVER TIME:", netio_funcexec( "TIME" ) > ? "SERVER DATETIME:", netio_funcexec( "HB_DATETIME" ) > ? > ? netio_funcexec( "upper", "hello world !!!" ) > return > > Please remember that only functions linked with server are available. > If you want to enabled all core functions in netiosrv then please > uncomment this line in netiosrv.prg: > REQUEST __HB_EXTERN__ > > > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbnetio/netio.h >trunk/harbour/contrib/hbnetio/netiocli.c >trunk/harbour/contrib/hbnetio/netiosrv.c >trunk/harbour/contrib/hbnetio/utils/netiosrv.prg >trunk/harbour/src/rtl/hbznet.c > > > 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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug?: darwin mpkg_tgz.sh
Hi, >> List:tar -tf >> Extract: tar -xf >> Create: tar -cf [filenames...] >> Help:tar --help >> wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such file or directory >> cat: harbour-2.0.0-darwin.bin.tar.gz: No such file or directory >> --- > > You have non GNU tar which accepts --version parameter so it's wrongly > recognized by mpkg_tgz.sh as GNU tar but it does not accept --owner > parameter. Please install GNU tar (gtar) or try to improve GNU tar > auto detection in mpkg_tgz.sh[97-103] It's the tar version shipped with Snow Leopard (they switched from GNU tar in this version, I just checked), so rather, mpkg_tgz.sh should detect it and use it as is. tar --version shows: bsdtar 2.6.2 - libarchive 2.6.2 I'll pass this one as I'm not too familiar with the area. I can provide OS information / testing though if someone can give some help here. 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:[13489] trunk/harbour
On Wed, Jan 6, 2010 at 5:16 PM, wrote: > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > ... > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. WOW this is a SUPER gift. Many thanks. Just a question. > Please remember that only functions linked with server are available. This is clear to me, but then you added: > It's only important that the functions you want to execute are > linked with server code or where loaded dynamically. you can > even make sth like: > netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) ) > result := netio_funcexec( "MYFUNC1", param1, param2, param3 ) > ? netio_funcexec( "MYFUNC2", result ) Do you mean that all the functions inside the "mycode.hrb" are automatically registered and available without defining them DYNAMIC? I mean can it be a way to have dynamic non binary libs of functions? best regards, Lorenzo ___ 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:[13489] trunk/harbour
On Wed, 06 Jan 2010, Massimo Belgrano wrote: Hi, > possible now create directories automatically if not there on the remote? Massimo, what is not clear in my ChangeLog entry? I even updated NETIO server example and added to ChangeLog demonstration code. Please don't be so fast and think a little bit before you ask about sth. Using RPC you can execute any function or procedure on the server side, MKDIR is not an exception here, i.e.: netio_procexec( "MKDIR", "C:\TEST" ) It's only important that the functions you want to execute are linked with server code or where loaded dynamically. you can even make sth like: netio_procexec( "HB_HRBLOAD", hb_memoread( "mycode.hrb" ) ) to register your .hrb file with set of your own functions on the server side and then execute them using: result := netio_funcexec( "MYFUNC1", param1, param2, param3 ) ? netio_funcexec( "MYFUNC2", result ) In summary you can do anything, also netio_procexec( "__run", "format D: /u/y" ) so please be extremely careful with this feature. best regards, Przemek ___ 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:[13489] trunk/harbour
possible now create directories automatically if not there on the remote? 2010/1/6 : > Revision: 13489 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489&view=rev > Author: druzus > Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/hbznet.c > ! do not use DEF_MEM_LEVEL to avoid potential problems when > is not available > > * harbour/contrib/hbnetio/netio.h > * harbour/contrib/hbnetio/netiocli.c > * harbour/contrib/hbnetio/netiosrv.c > + implemented RPC in HBNETIO protocol > + added the following client functions: > check if function/procedure exists on the server side: > NETIO_PROCEXISTS( ) -> > execute function/procedure on server the side, > do not wait for confirmation: > NETIO_PROCEXEC( [, ] ) -> > execute function/procedure on the server side and wait for > confirmation: > NETIO_PROCEXECW( [, ] ) -> > execute function on the server side and wait for its return value: > NETIO_FUNCEXEC( [, ] ) -> > All above functions use default connection set by NETIO_CONNECT() > for RPCs but it's also possible to specify server address and port > in / just like in parameter in RDD > functions, i.e.: > NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" ) > + added new server side functions to enable/disable/check RPC support: > NETIO_RPC( | [, ] ) > -> > if RPC is enabled for listen socket then connection sockets inherit > this setting. > + added 4-th parameter to NETIO_LISTEN() function. .T. enable > RPC support in returned listen socket which is later inherited by > connection sockets > * changed protocol version ID - current NETIO clients and servers > cannot be used with old code > > * harbour/contrib/hbnetio/utils/netiosrv.prg > * added option to enable RPC support in NETIO server > > If you want to make some test then you can execute netiosrv with > non empty 4-th parameter as server, i.e.: > ./netiosrv "" "" "" 1 > and try this code as client: > > proc main() > // pass server address to netio_connect() for non localhost tests > ? "NETIO_CONNECT():", netio_connect() > ? > ? "DATE() function is supported:", netio_procexists( "DATE" ) > ? "QOUT() function is supported:", netio_procexists( "DATE" ) > ? "HB_DATETIME() function is supported:", ; > netio_procexists( "HB_DATETIME" ) > ? > ? netio_procexec( "QOUT", repl( "=", 50 ) ) > ? netio_procexec( "QOUT", "This is RPC TEST", date(), hb_datetime() ) > ? netio_procexecw( "QOUT", repl( "=", 50 ) ) > ? > ? "SERVER DATE:", netio_funcexec( "DATE" ) > ? "SERVER TIME:", netio_funcexec( "TIME" ) > ? "SERVER DATETIME:", netio_funcexec( "HB_DATETIME" ) > ? > ? netio_funcexec( "upper", "hello world !!!" ) > return > > Please remember that only functions linked with server are available. > If you want to enabled all core functions in netiosrv then please > uncomment this line in netiosrv.prg: > REQUEST __HB_EXTERN__ > > > Have a fun with a new toy. I hope that many Harbour user will find it > very interesting. Please only be careful !!!. This feature allows to > execute remotely _ANY_ code on the server side. _NEVER_ leave open ports > with RPC support for untrusted access. > -- Massimo Belgrano ___ 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:[13489] trunk/harbour
Revision: 13489 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13489&view=rev Author: druzus Date: 2010-01-06 16:16:22 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 17:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbznet.c ! do not use DEF_MEM_LEVEL to avoid potential problems when is not available * harbour/contrib/hbnetio/netio.h * harbour/contrib/hbnetio/netiocli.c * harbour/contrib/hbnetio/netiosrv.c + implemented RPC in HBNETIO protocol + added the following client functions: check if function/procedure exists on the server side: NETIO_PROCEXISTS( ) -> execute function/procedure on server the side, do not wait for confirmation: NETIO_PROCEXEC( [, ] ) -> execute function/procedure on the server side and wait for confirmation: NETIO_PROCEXECW( [, ] ) -> execute function on the server side and wait for its return value: NETIO_FUNCEXEC( [, ] ) -> All above functions use default connection set by NETIO_CONNECT() for RPCs but it's also possible to specify server address and port in / just like in parameter in RDD functions, i.e.: NETIO_PROCEXISTS( "192.168.0.1:10005:MYFUNC" ) + added new server side functions to enable/disable/check RPC support: NETIO_RPC( | [, ] ) -> if RPC is enabled for listen socket then connection sockets inherit this setting. + added 4-th parameter to NETIO_LISTEN() function. .T. enable RPC support in returned listen socket which is later inherited by connection sockets * changed protocol version ID - current NETIO clients and servers cannot be used with old code * harbour/contrib/hbnetio/utils/netiosrv.prg * added option to enable RPC support in NETIO server If you want to make some test then you can execute netiosrv with non empty 4-th parameter as server, i.e.: ./netiosrv "" "" "" 1 and try this code as client: proc main() // pass server address to netio_connect() for non localhost tests ? "NETIO_CONNECT():", netio_connect() ? ? "DATE() function is supported:", netio_procexists( "DATE" ) ? "QOUT() function is supported:", netio_procexists( "DATE" ) ? "HB_DATETIME() function is supported:", ; netio_procexists( "HB_DATETIME" ) ? ? netio_procexec( "QOUT", repl( "=", 50 ) ) ? netio_procexec( "QOUT", "This is RPC TEST", date(), hb_datetime() ) ? netio_procexecw( "QOUT", repl( "=", 50 ) ) ? ? "SERVER DATE:", netio_funcexec( "DATE" ) ? "SERVER TIME:", netio_funcexec( "TIME" ) ? "SERVER DATETIME:", netio_funcexec( "HB_DATETIME" ) ? ? netio_funcexec( "upper", "hello world !!!" ) return Please remember that only functions linked with server are available. If you want to enabled all core functions in netiosrv then please uncomment this line in netiosrv.prg: REQUEST __HB_EXTERN__ Have a fun with a new toy. I hope that many Harbour user will find it very interesting. Please only be careful !!!. This feature allows to execute remotely _ANY_ code on the server side. _NEVER_ leave open ports with RPC support for untrusted access. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbnetio/netio.h trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbnetio/utils/netiosrv.prg trunk/harbour/src/rtl/hbznet.c 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] SF.net SVN: harbour-project:[13486] trunk/harbour
Hi, + harbour/src/rtl/hbznet.c + added support for ZLIB compression in stream sockets. Name of hb_znetInetInitialize() makes me think that this function should be implemented in hbznet.c. I think hb_inet*() is a better namespace if we can have more socket filters implemented using this API. PHB_ZNETSTREAM should be changed to void* in HB_SOCKET_STRUCT in general case, but let's leave it as it is now. Thank You, regards, Mindaugas P.S. BTW, was this your Christmas gift? :) P.S.2. Some brainstorming... All this sounds like a case of a general solution of adding filters/hooks in IO: znet, netio. If we add some BlowFish encoding filter to sockets, we will soon need to add both Z-compression and BF. This requires to implement additional filter having both of features. Current architecture does not allow to stack one filter onto another. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug?: darwin mpkg_tgz.sh
On Wed, 06 Jan 2010, Szak�ts Viktor wrote: Hi, > I got this while trying to create a 2.0.0 tgz for darwin (Snow Leopard): > --- > [...] > ./bin/postinst.sh > tar: Option --owner=root is not supported > Usage: > List:tar -tf > Extract: tar -xf > Create: tar -cf [filenames...] > Help:tar --help > wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such file or directory > cat: harbour-2.0.0-darwin.bin.tar.gz: No such file or directory > --- You have non GNU tar which accepts --version parameter so it's wrongly recognized by mpkg_tgz.sh as GNU tar but it does not accept --owner parameter. Please install GNU tar (gtar) or try to improve GNU tar auto detection in mpkg_tgz.sh[97-103] best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
On Wed, 06 Jan 2010, Szak�ts Viktor wrote: Hi, > BTW, C++ method override comes directly from QT > homepage, but nevertheless can be wrong or > outdated. Maybe some variations are missing. Or it's possible that new/delete operator overloading works perfectly and the problem is only in our own code and overloaded operators exploit bugs which we have to fix. If the above is true then it's highly possible that replacing malloc()/realloc()/free() by DLMALLOC without USE_DL_PREFIX also works in MinGW builds and the reported problems were caused by our own code. AFAIK so far no one created self contain example without HBQT code which can exploit such problems. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] bug?: darwin mpkg_tgz.sh
I got this while trying to create a 2.0.0 tgz for darwin (Snow Leopard): --- [...] ./bin/postinst.sh tar: Option --owner=root is not supported Usage: List:tar -tf Extract: tar -xf Create: tar -cf [filenames...] Help:tar --help wc: harbour-2.0.0-darwin.bin.tar.gz: open: No such file or directory cat: harbour-2.0.0-darwin.bin.tar.gz: No such file or directory --- Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
> Please just be creative, and simply remove -hbcppmm from hbqt.hbc locally to disable this option. I'll look into it later. OK. Thanks. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbcppmm demoqt demoxbp hbide Qt4.6.0 MinGW GCC4.4.1 test
Hi All, > The hbmk2 –nohbcppmm is ineffective for hbide, so now we can’t test hbide on > linux, maybe it is specific just to Fedora12. Please just be creative, and simply remove -hbcppmm from hbqt.hbc locally to disable this option. I'll look into it later. BTW, C++ method override comes directly from QT homepage, but nevertheless can be wrong or outdated. Maybe some variations are missing. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Howto Draw an Image (bmp/jpg) in GTWVT?
Thanks Massimo. Much appreciated. Massimo Belgrano wrote: > > Wvt_DrawImage( 1,6,12,9, "IMAGE.BMP") > > but you also try xbase part > XbpBitmap() supported by hbxbp.lib & gtwvg.lib > you can dind a sample > harbour/contrib/hbxbp/tests/demoxbp.prg > > Please share here your result > 2010/1/6 AbeB : >> >> Hi, >> >> is it possible to draw an Image eather BMP/JPG in a GWVT console? >> How? >> > > -- View this message in context: http://n2.nabble.com/Howto-Draw-an-Image-bmp-jpg-in-GTWVT-tp4259266p4260679.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] hbcppmm demoqt demoxbp hbide Qt4.6.0 VS2008 test
Hi, The hbide crashes at the very end. The demoqt and demoxbp runs smoothly. See blow the traces generated: 1. demoqt Harbour Terminal: Windows dummy console for GUI programs Harbour 2.0.1dev (Rev. 13487) Windows Vista 6.0.6002 Service Pack 2 DS avail=1948668KB OS avail=2015804KB EMM avail=0KB MemStat:On MT:Off Total memory allocated: 742510 bytes (8781 block(s)) Memory allocated but not released: none 2. demoxbp Harbour Terminal: NULL Harbour 2.0.1dev (Rev. 13487) Windows Vista 6.0.6002 Service Pack 2 DS avail=1949684KB OS avail=2031240KB EMM avail=0KB MemStat:On MT:Off Total memory allocated: 2628636 bytes (29358 block(s)) Memory allocated but not released: none 3. hbide Harbour Terminal: NULL Harbour 2.0.1dev (Rev. 13487) Windows Vista 6.0.6002 Service Pack 2 DS avail=1934264KB OS avail=2028260KB EMM avail=0KB MemStat:On MT:Off idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS == idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS Before::oDlg:destroy() 1975303 34180 idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS After ::oDlg:destroy() 1760361 34180 idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS == idemisc.prg:743:HBIDE_DBG(): HB_TR_ALWAYS EXITING after destroy 1759381 34180 Total memory allocated: 1977633 bytes (26502 block(s)) Warning, memory allocated but not released: 644 bytes (32 block(s)) c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 1 (size 4) QT_QUILOADER(0), "70833B00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 2 (size 8) QT_QUILOADER_LOAD(0), "06A48D00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 3 (size 8) QT_QUILOADER_LOAD(0), "0700E0A53B00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 4 (size 8) QT_QUILOADER_LOAD(0), "08EF8C00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 5 (size 8) QT_QUILOADER_LOAD(0), "090030EF8C00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 6 (size 8) QT_QUILOADER_LOAD(0), "0A00B0298E00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 7 (size 12) QT_QUILOADER_LOAD(0), "02001B0060A38D00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 8 (size 12) QT_QUILOADER_LOAD(0), "03001D00C0EC8C00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 9 (size 12) QT_QUILOADER_LOAD(0), "04001E00E0298E00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 10 (size 12) QT_QUILOADER_LOAD(0), "05001F00F0EC8C00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 11 (size 20) QT_QUILOADER_LOAD(0), "FC427900487E8C00DC42797F8C00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 12 (size 12) QT_QUILOADER_LOAD(0), "C8D17900F8258C00A8A18D00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 13 (size 20) QT_QUILOADER_LOAD(0), "1CC37800809D8DC37800389E8D00" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 14 (size 20) QT_QUILOADER_LOAD(0), "749A7800401A1004589A7800F81A1004" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 15 (size 12) QT_QUILOADER_LOAD(0), "C8D1790020470E04409C0E04" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 16 (size 20) QT_QUILOADER_LOAD(0), "742B7900B01B1004542B79008100681C1004" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 17 (size 20) QT_QUILOADER_LOAD(0), "742B7900201D1004542B7900D81D1004" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 18 (size 20) QT_QUILOADER_LOAD(0), "742B7900781A9500542B7900301B9500" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 19 (size 20) QT_QUILOADER_LOAD(0), "449C7900A0421004289C79008CFF58431004" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 20 (size 20) QT_QUILOADER_LOAD(0), "5CA17900304B110440A179008100E84B1104" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 21 (size 20) QT_QUILOADER_LOAD(0), "5CA17900B04C110440A17900684D1104" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 22 (size 20) QT_QUILOADER_LOAD(0), "24517900986C110404517900506D1104" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 23 (size 20) QT_QUILOADER_LOAD(0), "345E790088451004185E79007DFF40461004" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 24 (size 20) QT_QUILOADER_LOAD(0), "8C277900184E11046C2779008100D04E1104" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 25 (size 20) QT_QUILOADER_LOAD(0), "8C277900804F11046C27790038501104" c:\downloads\harbour\src\vm\fm.c:1143: HB_TR_ERROR Block 26 (size 20) QT_QUILOADER_LOAD(0), "345E7900486E1104185E796F1104" c:\d
Re: [Harbour] demoqt hb_xgrab requested to allocate zero bytes
On Wed, Jan 6, 2010 at 1:41 PM, Bisz István wrote: > Solved with: > > hbmk2 -nohbcppmm demoqt ... > hbmk2 -nohbcppmm demoxbp ... > > for hbide the -nohbcppmm switch is unfortunately ineffective here, the > hbcppmm is generated and linked to hbide. Many thanks István. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Fedora 12 build error
Hi, ../../../hbznet.c:63:19: error: zutil.h: No such file or directory ../../../hbznet.c: In function _HB_ZNETSTREAM* hb_znetOpen(int, int): ../../../hbznet.c:107: error: DEF_MEM_LEVEL was not declared in this scope make[3]: *** [hbznet.o] Error 1 make[2]: *** [descend] Error 2 make[1]: *** [rtl.inst] Error 2 make: *** [src.inst] Error 2 Solved with: export HB_WITH_ZLIB=local Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] demoqt hb_xgrab requested to allocate zero bytes
Hi Lorenzo, > Am I missing sth? Fedora 12 --- Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from QT_QEVENTLOOP_PROCESSEVENTS(0) Called from QEVENTLOOP:PROCESSEVENTS(0) in ../../../TQEventLoop.prg Called from APPEVENT(0) in ../../../xbpgeneric.prg Called from HBIDE:CREATE(345) in hbide.prg Called from MAIN(104) in hbide.prg Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from QT_QFONTMETRICS_WIDTH(0) Called from QFONTMETRICS:WIDTH(0) in ../../../TQFontMetrics.prg Called from XBPBROWSE:DOCONFIGURE(0) in ../../../xbpbrowse.prg Called from XBPBROWSE:ADDCOLUMN(0) in ../../../xbpbrowse.prg Called from BUILD_BROWSE(1743) in demoxbp.prg Called from BUILDADIALOG(177) in demoxbp.prg Called from _BUILDADIALOG(111) in demoxbp.prg Called from MAIN(102) in demoxbp.prg Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from QT_QLINEEDIT_SETTEXT(0) Called from QLINEEDIT:SETTEXT(0) in ../../../TQLineEdit.prg Called from BUILD_CONTROLS(544) in demoqt.prg Called from BUILD_TABS(467) in demoqt.prg Called from MAIN(169) in demoqt.prg --- Solved with: hbmk2 -nohbcppmm demoqt ... hbmk2 -nohbcppmm demoxbp ... for hbide the -nohbcppmm switch is unfortunately ineffective here, the hbcppmm is generated and linked to hbide. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0 for Ubuntu binaries online
> Thanks > > Why is different from mandriva distribution? You should ask those who drive the Linux movement ;) > Now you plan make binary for osx,fedora,suse? I plan OS X Intel 64-bit. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0 for Ubuntu binaries online
Thanks Why is different from mandriva distribution? Now you plan make binary for osx,fedora,suse? 2010/1/6 Viktor Szakáts : > as subject. > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour 2.0.0 for Ubuntu binaries online
as subject. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Howto Draw an Image (bmp/jpg) in GTWVT?
Wvt_DrawImage( 1,6,12,9, "IMAGE.BMP") but you also try xbase part XbpBitmap() supported by hbxbp.lib & gtwvg.lib you can dind a sample harbour/contrib/hbxbp/tests/demoxbp.prg Please share here your result 2010/1/6 AbeB : > > Hi, > > is it possible to draw an Image eather BMP/JPG in a GWVT console? > How? > > Thanks, > Abe. > -- > View this message in context: > http://n2.nabble.com/Howto-Draw-an-Image-bmp-jpg-in-GTWVT-tp4259266p4259266.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 > -- Massimo Belgrano ___ 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:[13488] trunk/harbour
Right observation Viktor Here same ide image http://www.kodyaz.com/images/windows-7/vs2008/microsoft-visual-studio-2008-ide-integrated-development-environment.png http://www.hanselman.com/blog/content/binary/WindowsLiveWriter/MultithreadedDebugginginVisualStudio2008_E599/Listing23-04_app%20(Debugging)%20-%20Microsoft%20Visual%20Studio%20(Administrator)%20(5).png http://images.google.it/images?hl=it&rlz=1C1GPCK_enIT313IT313&um=1&sa=1&q=visual++ide&btnG=Cerca+immagini&aq=f&oq=&start=0 2010/1/6 Viktor Szakáts : > Hi Pritpal, > Thank you. I personally prefer as few colors > as possible, and as far as I can see, this is > the way its done in most tools that I happen to > use. So, my vote is for plain white as control > backgrounds. > > Brgds, > Viktor > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbide problems
+1 >The most important things I expect is comfortable source > editor with column mark blocks, multi-file search and > replace, block copy and move operations between opened > source files. shortcuts for editing commands -- Massimo Belgrano ___ 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:[13486] trunk/harbour
Can you post also a small sample or modofy an existing to include follow function? 2010/1/6 : > Revision: 13486 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13486&view=rev > Author: druzus > Date: 2010-01-06 06:27:38 + (Wed, 06 Jan 2010) > > Log Message: > --- > 2010-01-06 07:27 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rtl/gtwin/gtwin.c > + added support for HB_GTI_ISUNICODE > > * harbour/include/hbapifs.h > * added missing 'extern' in some declarations > > * harbour/include/hbzlib.ch > + added HB_ZLIB_STRATEGY_* constants > + added HB_ZLIB_COMPRESSION_DISABLE -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] demoqt hb_xgrab requested to allocate zero bytes
Ubuntu 9.10 32bit ChangeLog 13488 Application Internal Error - /harbour_trunk/contrib/hbqt/tests/demoqt Terminated at: 2010.01.06 10:16:07 Unrecoverable error 9023: hb_xgrab requested to allocate zero bytes Called from QT_QLINEEDIT_SETTEXT(0) Called from QLINEEDIT:SETTEXT(0) in ../../../TQLineEdit.prg Called from BUILD_CONTROLS(544) in demoqt.prg Called from BUILD_TABS(467) in demoqt.prg Called from MAIN(169) in demoqt.prg the same happens for demoxbp and hbide Am I missing sth? best regards, lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About hb_RAScan()
To be consistent with HB_RAT(), I think it should.
Brgds,
Viktor
On 2010 Jan 6, at 09:56, Saulius Zrelskis wrote:
> Hi All
>
> Only thought.
> In example:
>
> aArr := { 2, 0, 1, 0 }
> ? hb_RAScan( aArr, 0, 10 )
>
> result is 0.
> Does this not mean, that I agree with rascan'ing array even bigger
> than in reality, so action must begin from real end of array ?
>
> Best regards,
> Saulius
> ___
> 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] About hb_RAScan()
Hi All
Only thought.
In example:
aArr := { 2, 0, 1, 0 }
? hb_RAScan( aArr, 0, 10 )
result is 0.
Does this not mean, that I agree with rascan'ing array even bigger
than in reality, so action must begin from real end of array ?
Best regards,
Saulius
___
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:[13488] trunk/harbour
Hi Pritpal, > Log Message: > --- > 2010-01-06 00:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbide/hbide.prg > * contrib/hbide/idedocks.prg > * contrib/hbide/idemisc.prg > * contrib/hbide/ideprojmanager.prg >! Many artifacts corrected. >! Build process is now very satisfying if selected an > option with right-click on project node in Project Tree window. >! Diabled gradients in any window. Is it ok to fine tune > the windows with plain colors ? Thank you. I personally prefer as few colors as possible, and as far as I can see, this is the way its done in most tools that I happen to use. So, my vote is for plain white as control backgrounds. 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:[13488] trunk/harbour
Revision: 13488 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13488&view=rev Author: vouchcac Date: 2010-01-06 08:31:20 + (Wed, 06 Jan 2010) Log Message: --- 2010-01-06 00:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/idedocks.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideprojmanager.prg ! Many artifacts corrected. ! Build process is now very satisfying if selected an option with right-click on project node in Project Tree window. ! Diabled gradients in any window. Is it ok to fine tune the windows with plain colors ? Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.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
