Re: [xHarbour-developers] CHANGELOG: 2009-12-01 01:37 UTC-0800 Brian Hays
Przemek: Thanks. If I hear no other feedback, I'll remove the RTE so the code you described can still work. Does anyone else have an opinion as to whether it's useful to add the feature of an explicit NIL value to mean to return to default direction ? Or is it not worth the trouble, and unlikely to be supported in other RDDs anyway? -- Brian Hays -Original Message- From: Przemysław Czerpak [mailto:dru...@acn.waw.pl] Sent: Tuesday, December 01, 2009 3:15 PM To: bhays; 'Viktor Szakáts'; Harbour Project Main Developer List. Subject: Re: CHANGELOG: 2009-12-01 01:37 UTC-0800 Brian Hays On Tue, 01 Dec 2009, Brian Hays wrote: I need help with a decision on whether to throw an error or not. Please see discussion below. 2009-12-01 01:37 UTC-0800 Brian Hays bhays/at/abacuslaw.com Dynamic DESCEND flag is not supported also in many Clipper RDDs. So far the standard way in Clipper and [x]Harbour to check if dynamic descending order is supported was checking the value returned by: ordDescend( [tag], [bag] ) just after: ordDescend( [tag], [bag], lOnOff ) i.e.: ordDescend( nTag,, .T. ) ? order:, iif( ordDescend( nTag ), descending, ascending ) such code works for any RDDs and will work also for ADS if you do not enable such RTE. In all core native RDDs (NTX, CDX, NSX) I implemented dynamic descend flags so such RTE cannot be generated so I think that it will be most important for ADS users which without RTE can easy create the same code for different ADS versions. A second question: AdsSetIndexDirection takes an unusual flag that EITHER takes 0 to return to the original state, or TRUE to reverse the direction from the current state IOW, they have the ability to “go back to normal which IIUC Clipper/(x)Harbour does NOT. To clarify some technical issues. In indexes like CDX, ADI or NSX there is no normal state. Physically they exist only in ascending order and descending order is done by logical flag (BTW I'm surprised why adding user interface to change such logical flag took such long time ADS authors) so we can talk only about default settings for this flag stored in index header. Only NTX format uses reverted key orders in index file to implement default descending sorting so in our DBFNTX I implemented both versions and it's possible to use dynamic switching too just like in CDX or NSX formats. I guess that you are asking about method of resetting DESCEND flag to value chose by RDD when index is open. So far we do not have such functionality though it can be easy implemented if we agree how to inform RDD that we want to reset this flag. Am I missing something? It would be nice to have a value to return to native state in our syntax instead of requiring a close/re-open of the file. Note: Once the direction has been dynamically changed, ordDescend() is only capable of returning the CURRENT state; there is no api to get the Original direction setting. Please remember that we are always in native state. The order direction is in practice only logical flag. Usually structural code have to safe and restore descend flag settings because it cannot assume that it was in the same state as after opening table. Operation like resetting order DESCEND flag to the same state as after opening table are not structural so are less usable in most of code. Probably the only one type of code I can imagine is some DBU like program which may want to display some information with default order settings. In some COMIX functions, there was the difference between an explicit NIL and an ignored parameter to distinguish between intentions. I never liked having to explain it to people, BUT this may be an instance where explicitly passing NIL as the third arg could be the flag to revert to the original state of the index. NIL can be used for such job. In such case it's necessary to modify ordDescend() in dbcmd53.c and change: pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); to: pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL ); if( pOrderInfo.itmNewVal ) pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_NIL ); Is there a good way to add the extended value/functionality of either learning or setting the original direction? The other method is defining new DBOI_* action for dbInfo() to extract default DESCEND flag settings which can be used as ordDescend() parameter. best regards, Przemek No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.426 / Virus Database: 270.14.67/2506 - Release Date: 12/01/09 07:59:00 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
Re: [xHarbour-developers] RDD: ADT - ADSADT
Przemek and Mindaugas: Thanks for the clarification. I missed the finer point when Mindaugas first discussed ADS, but then the second paragraph said I propose to rename RDD from ADT ... as you noticed, I thought we were still talking about just ADS. So, yes, I would agree ADSADT is better than also supporting ADT. It might be good to find out how many people might be impacted, but if it's just a question of changing the rddSetDefault line, and if an obvious error is generated after the change that makes it clear what the programmer should fix if he missed the change, then it sounds like a good fix. As for the additional idea of removing ADS and: so in fact you had over four years to update your code Was it my mistake that I left ADS RDD? I never really thought that being left for backward compatibility implied a suggestion for changing code. For me personally, just changing the rddSetDefault line is no problem. BUT I wouldn't recommend breaking users' apps if the only reason is to remove the backwards compatibility for cleanliness sake. Though I go back that many years, thousands of new users may very well have used that syntax up to present day, especially in light of the lack of significant documentation for rddads. Have new users been directed to examples or guidelines that suggest the newer syntax and *not* using ADS? One more point: to reduce the ADS RDDs to *just* the specific rdds MAY imply the temptation to remove the ability to just set the FileType from one to the other (e.g. from ADT to DBF and back again) in the same workarea. If this is where we're headed, it would break a LOT of people's code and probably create a lot of grief for people who just get a Harbour update, then suddenly find themselves having to debug and fixup potentially large amounts of code. I'm not arguing for clinging to bad design, but concern for our users' sanity is a virtue. Thanks for all your work, -- Brian Hays -Original Message- From: Przemysław Czerpak [mailto:dru...@acn.waw.pl] Sent: Thursday, November 26, 2009 8:16 PM To: Xharbour-Developers List; Harbour Project Main Developer List. Subject: Re: [xHarbour-developers] RDD: ADT - ADSADT On Thu, 26 Nov 2009, Brian Hays wrote: Hi Brian, The addition of specific sub-rdds of ADSCDX etc. came years later. I, and I imagine a lot of other people who started using rddads early on, never had a need to explicitly use those other rdds by name. Any one who has code like: proc copy_table( cSrc, cSrcRDD, cDst, cDstRDD ) use (cSrc) via (cSrcRDD) copy to (cDst) via (cDstRDD) return designed to work with different RDDs in Clipper, needs ADS* RDDs to port his code without introducing unnecessary and incompatible with other RDDs modifications which are necessary to make working code like: copy_table( sales, ADSCDX, sales2, ADSADT ) In fact ADS RDD can be safely removed because the only one reason to keep it are user habbits but ADS* RDDs cannot be removed without reducing important functionality - working VIA clause in different command/functions which allows to easy switch between RDDs. Are you suggesting that we should now have to re-write our apps by converting ADS to ADSADT? But wait: IIRC (I'm not sure), ADSCDX is the DEFAULT for ADS, so converting it to ADT doesn't really make sense, does it? If you're suggesting a change that would require people to change code that's been growing for 9 years, there needs to be a stronger reason to force the change than just compatibility with other rdds, IMHO. Or am I missing something? Mindaugas wants to change only ADT RDD to ADSADT and you are not using it so it's not a problem for you. Anyhow you wrote that it's 9 years code. In the past I left ADS RDD only for backward compatibility: 2005-09-02 20:10 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + register ADS as three separate RDDs: ADSNTX, ADSCDX, ADT (ADS RDD left for backward compatibility) - they do not need to set table type. so in fact you had over four years to update your code. This suggests that forcing some modification immediately is better because four years ago it was only 5 years code ;-) Was it my mistake that I left ADS RDD? best regards, Przemek --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.426 / Virus Database:
Re: [xHarbour-developers] RDD: ADT - ADSADT
Mindaugas: I'm not sure why you're making the suggestion. Right now, the original ADS is an all-inclusive rdd that lets you switch the file type to cdx, ntx, etc. in different workareas. The addition of specific sub-rdds of ADSCDX etc. came years later. I, and I imagine a lot of other people who started using rddads early on, never had a need to explicitly use those other rdds by name. Are you suggesting that we should now have to re-write our apps by converting ADS to ADSADT? But wait: IIRC (I'm not sure), ADSCDX is the DEFAULT for ADS, so converting it to ADT doesn't really make sense, does it? If you're suggesting a change that would require people to change code that's been growing for 9 years, there needs to be a stronger reason to force the change than just compatibility with other rdds, IMHO. Or am I missing something? -- Brian Hays -Original Message- From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt] Sent: Thursday, November 26, 2009 4:55 PM To: Xharbour-Developers List Subject: [xHarbour-developers] RDD: ADT - ADSADT Hi, current ADS RDD is registered using names: ADS, ADT, ADSCDX, ADSNTX, ADSVFP. RDD SYSNAME method (i.e., RDDNAME()) can return one of the following values: ADSADT, ADSCDX, ADSNTX, ADSVFP. Original C level ADS defines for different database types are: ADS_CDX, ADS_NTX, ADS_VFP, ADT_ADT. I propose to rename RDD from ADT to ADSADT, thus making both correct RDDNAME() return value and to be compatible with naming scheme of another ADS RDDs. Any objections? Regards, Mindaugas --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.426 / Virus Database: 270.14.67/2506 - Release Date: 11/26/09 09:10:00 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] RDD: ADT - ADSADT
Mindaugas: If you intended it for the Harbour project, please keep this xHarbour group and/or me in the conversation. I have continued to work with Viktor and Przemek to keep rddads coordinated as much as possible in both projects. It may be worthwhile to forward my concerns to the other project too, or please inform me if I'm incorrect on any points. Thanks, -- Brian Hays -Original Message- From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt] Sent: Thursday, November 26, 2009 6:29 PM To: Xharbour-Developers List Subject: Re: [xHarbour-developers] RDD: ADT - ADSADT Mindaugas Kavaliauskas wrote: current ADS RDD is registered using names: ADS, ADT, ADSCDX, ADSNTX, ... Sorry, wrong mailing list. Regards, Mindaugas --- --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.426 / Virus Database: 270.14.67/2506 - Release Date: 11/26/09 09:10:00 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] CHANGELOG 2009-07-16 19:30 UTC-0800 Brian Hays bhays/at/abacuslaw.com
2009-07-16 19:30 UTC-0800 Brian Hays bhays/at/abacuslaw.com * contrib\rdd_ads\ads1.c * fixed buffer handling for adsScopeSet and GetValue and related funcs. Since way back, buffers were short by 1 byte, and ace calls were throwing errors that were essentially ignored. It only worked because the one missing byte was of course the trailing null. But all errors other than eof were ignored. Fix provided by Przemyslaw Czerpak (Thanks!) based on: 2009-05-14 19:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/rddads/ads1.c ! fixed minimal record buffer size calculation ! fixed adsGetValue() method hacked to not report errors due to too small field buffer. Warning! Now ADS RDD will report any error as RTE if sth wrong will happen in one of AdsGet*() function when field is read so it's possible that also some other hidden bugs will be exploited and you will see RTE. Please test it. -- Brian Hays -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] rddads is broken
Miguel: I found the problem. In previous code, that last call in adsGetValue sets the ITEM with: hb_itemPutCL( pItem, ( char * ) pBuffer, pField-uiLen ); NOW, it uses: hb_itemPutCL( pItem, ( char * ) pBuffer, u32Length ); For a 50-byte field (for example), u32Length is set to 51 to include the trailing NULL, so for normal fields this code is wrong. It's strange that the bad behavior doesn't show up more dramatically. Shouldn't this line be reverted to the original hb_itemPutCL( pItem, ( char * ) pBuffer, pField-uiLen ); ? Is there any reason why the item would ever be set to anything other than the field length? If the new HB_FT_VARLENGTH types need to be different, then I suggest setting u32Length back to pField-uiLen for HB_FT_STRING. It *might* be OK to use u32Length - 1, BUT the other code has been stable for years, and we can't know for sure what might happen for data that contains nulls, or if ADS guarantees there's always a NULL that can be omitted. Thanks, -- Brian Hays Abacus Data Systems, Inc. From: bhays [mailto:bh...@abacuslaw.com] Sent: Saturday, July 11, 2009 12:22 AM To: 'xharbour developer list' Subject: [xHarbour-developers] rddads Miguel: I'm trying to look over the changes to ads1.c to help with the character field length problem. There are a few changes I don't understand. Why was the explicit NUMERIC test else if( hb_itemType( pKey ) HB_IT_NUMERIC ) changed to else if( HB_IS_NUMERIC( pKey ) ) ? Is this your change? HB_IS_NUMERIC( pKey ) includes DATES and single-byte strings. I have lots of single character fields, some with indexes on them, and I would expect errors to occur if these are treated like numbers at the C level when interacting with ADS index keys and scopes. Was this change done explicitly to include these other types, or was someone perhaps thinking it was functionally the same but cleaner code? Thanks, -- Brian Hays Abacus Data Systems, Inc. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.12.94/2208 - Release Date: 07/10/09 07:05:00 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] hb_uncompress in hbcomprs.c returns anunstable string
Ron: Yes, thank you, the string returned from hb_uncompress can be macro compiled now. May I ask: 1. What was the difference in the ITEM; why could it be written to a log and appear perfect, yet it wouldn't compile? 2. What are the rules for when to use hb_retclenAdoptRaw vs. hb_retclenAdopt ?? Thanks! -- Brian Hays Abacus Data Systems, Inc. From: Ron Pinkas [mailto:ron.pin...@xharbour.com] Sent: Friday, July 10, 2009 8:22 AM To: bhays; 'xharbour developer list' Subject: Re: [xHarbour-developers] hb_uncompress in hbcomprs.c returns anunstable string Brian, Please advise if fixed after: 2009-07-10 10:49 UTC-0430 Ron Pinkas ron.pinkas/at/xharbour.com Ron From: bhays mailto:bh...@abacuslaw.com Sent: Monday, July 06, 2009 1:55 AM To: 'xharbour developer list' mailto:xharbour-developers@lists.sourceforge.net Subject: [xHarbour-developers] hb_uncompress in hbcomprs.c returns anunstable string Ron and friends: This function returns an xgrabbed memory block in this way, and does not release it: hb_retclenAdoptRaw( cDest, ulDstlen ); Notice the RAW. Can you please tell me if this is currently accepted code, or does it return an unstable pointer to something that might get released or mangled? The attached isolated test shows that if I try to macro compile a string that was returned to a variable from hb_uncompress, the () line throws an error. Here are the 2 lines of code in question: cOrgStr := hb_UnCompress( nOrgLen, cCompressed ) ? ( cOrgStr ) If I hack an EXACT COPY of the string with this: cCopy := alltrim( cOrgStr + ) the cCopy WILL compile, even though it traces out as the exact same string. There's some internal property of the uncompressed string that causes an instability with the operator. Thanks! -- Brian Hays _ -- _ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.12.94/2208 - Release Date: 07/10/09 07:05:00 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] rddads
Miguel: I'm trying to look over the changes to ads1.c to help with the character field length problem. There are a few changes I don't understand. Why was the explicit NUMERIC test else if( hb_itemType( pKey ) HB_IT_NUMERIC ) changed to else if( HB_IS_NUMERIC( pKey ) ) ? Is this your change? HB_IS_NUMERIC( pKey ) includes DATES and single-byte strings. I have lots of single character fields, some with indexes on them, and I would expect errors to occur if these are treated like numbers at the C level when interacting with ADS index keys and scopes. Was this change done explicitly to include these other types, or was someone perhaps thinking it was functionally the same but cleaner code? Thanks, -- Brian Hays Abacus Data Systems, Inc. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-04-27 17:49 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net
Miguel: RDDADS has had its own flavor of timestamps for a long time. Do you expect this new change to work with that, or is it a different system that still needs to be integrated? Thanks, -- Brian Hays -Original Message- From: Miguel Angel Marchuet [mailto:miguelan...@marchuet.net] Sent: Monday, April 27, 2009 1:42 AM To: xharbour developer list Subject: [xHarbour-developers] 2009-04-27 17:49 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net 2009-04-27 17:49 UTC+0100 Miguel Angel Marchuet miguelan...@marchuet.net * source\rdd\bmdbfcdx\bmdbfcdx1.c * source\rdd\dbfcdx\dbfcdx1.c * minor adjusts, an added a few comments. * tests\datetime.prg * Added DbSkip( 0 ) to clarify how works STAMPED fieldtype TIMESTAMP. Best regards, Miguel Angel Marchuet __ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 4035 (20090425) __ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com --- --- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.0/2066 - Release Date: 04/26/09 09:44:00 -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Upper() and codepage.
Ron: The difference is: We have always built with this function available, and there is NO discernable overhead. Building with debug info DOES have discernable overhead. So if people use this call, they will have a surprise after shipping with the new build and eventually trying to use it and having it fail. If users have been implementing it who just get binaries, you've just created a new problem and new tech support issues. Also, have you ever had the experience of an app having a gpf/hangup, and then you put a rebuilt full debug build in place, and the problem shifts and doesn't gpf anymore? Having some trouble-shooting ability in your app, if it has no runtime overhead nor size bloating, is a good thing. We're OK for us, but I'd still recommend leaving it in for xHarbour users. We're taking something away from them with no benefit in return. -- Brian Hays -Original Message- From: Ron Pinkas [mailto:ron.pin...@xharbour.com] Sent: Wednesday, March 11, 2009 6:49 AM To: Patrick Mast, xHarbour.; xharbour developer list Subject: Re: [xHarbour-developers] Upper() and codepage. Patrick, Brian, IMO, such features should only be enabled in a DEBUG build, or debug version of the libs (i.e. vmd.lib). Please note that similarly we don't compile with prg debug info by default, although one could need this, just as much or more than, the tracing prg calls facility. Ron -- From: Patrick Mast, xHarbour. patrick.m...@xharbour.com Sent: Wednesday, March 11, 2009 1:21 AM To: xharbour developer list xharbour- develop...@lists.sourceforge.net Subject: Re: [xHarbour-developers] Upper() and codepage. Hello, So we will be building xHarbour for ourselves with the new #define to enable this function, but FWIW I don't think we should be changing default behaviors without being able to demonstrate any real benefit. I agree. We also need this in release software. It should be enabled by default. Patrick - - Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers --- --- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.8/1985 - Release Date: 03/10/09 07:19:00 -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] ADS / xHarbour newsgroup
I met with our Sybase/iAnywhere/AdvantageDatabase reps today, and they mentioned they were seriously looking at adding an xHarbour newsgroup if a few people would commit to monitoring it. I said I would be happy to be involved. If anyone else wants to volunteer, tell me and I'll forward your name and email address to them and make a case for why they should definitely get this rolling. Thanks, -- Brian Hays -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-17 16:55 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
Francesco: Would it make sense to have this feed into the existing hblog functionality, which has all the features to go email, file, inet ports, etc.? -- Brian Hays Abacus Data Systems, Inc. -Original Message- From: Francesco Saverio Giudice [mailto:i...@fsgiudice.com] Sent: Saturday, January 17, 2009 7:58 AM To: xHarbour-Developers Subject: [xHarbour-developers] 2009-01-17 16:55 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com) 2009-01-17 16:55 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com) * xharbour/source/rtl/hblog.prg + Added ::Out(...) method to class hb_LogConsole() + Added hb_LogDbf class to log messages into a dbf * xharbour/source/rtl/hblognet.prg + Added METHOD Connections() - nConnections that returns how many connections HB_LogInetPort class is handling + Added METHOD BroadcastMessage( cMessage ) that send a message to any available connections Best regards Francesco --- --- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 1/16/2009 3:09 PM -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2009-01-17 16:55 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com)
Francesco: Could you kindly explain better ? No, no, my mistake, I read it wrong. I thought from the first post about the new logging rdd that you had duplicated some of the functionality of hblog. Thanks for another great contribution! -- Brian Hays -Original Message- From: Francesco Saverio Giudice [mailto:i...@fsgiudice.com] Sent: Saturday, January 17, 2009 3:30 PM To: 'xharbour developer list' Subject: Re: [xHarbour-developers] 2009-01-17 16:55 UTC+0100 Francesco Saverio Giudice (info/at/fsgiudice.com) Hi Brian, Il 17/01/2009 19.36, bhays ha scritto: Francesco: Would it make sense to have this feed into the existing hblog functionality, which has all the features to go email, file, inet ports, etc.? Sorry I don't understand, surely due to my poor english, but do you mean that my additions to hblog/hblognet are not corrected/redundant ? Could you kindly explain better ? Best regards, Francesco -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] More on the profiler issues
Miguel: It sounds like you're saying that if you build cvs with HB_NO_PROFILER (the default), and then try to call any of the profiler functions, you get a gpf. If so, this isn't OK to ship. We've always supported transparent calls (no error, just no results) to the profiler funcs when its pieces are not linked in, and now users would get a gpf instead of whatever happened before. We would need to fix it to either throw a linker error because the functions themselves are not linked in (this isn't compatible with prior behavior but at least generates a useful error), or make sure that the current gpf is fixed. -- Brian Hays -Original Message- From: Miguel Angel Marchuet [mailto:miguelan...@marchuet.net] Sent: Friday, January 16, 2009 10:12 AM To: Luis Krause Mantilla; xharbour developer list Subject: Re: [xHarbour-developers] More on the profiler issues Luis Krause Mantilla escribió: Even compiling source\rtl\profiler with -D__TEST__ gpf's as well. Any ideas where the problem lies? to compile xharbour with profiler wout need compile it with macro HB_USE_PROFILER it was implemented few days ago. in other case setup automatically add HB_NO_PROFILER and then profiler generate GPF Best regards, Miguel Angel Marchuet -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Current CVS stable?
Patrick: I understand. But if we're going to release a build that causes unidentifiable crashing, shouldn't we consider putting something in the build to identify it? Wouldn't incrementing the PCode version accomplish this, even if it was an item structure change instead of pcode change that causes the crash? If not, shouldn't we consider something similar to avoid an onslaught of support problems and questions? -- Brian Hays Thanks. Is it possible for us to catch this at link time instead of waiting for untraceable gpfs? Was there a pcode version change, and if not shouldn't there be? I use this XBP file to rebuild Fivehmx.lib http://www.xHarbour.net/Downloads/Fivehmx_xHB.lib.zip -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Current CVS stable?
Patrick: I think the point is that there's nothing special about FWH; any other 3rd party lib will need its PRGs compiled, right? (let me know if I'm wrong) In which case forcing this up front, as much as it creates headaches, is far better than finding out at app runtime. -- Brian Hays -Original Message- From: Patrick Mast, xHarbour. [mailto:patrick.m...@xharbour.com] Sent: Wednesday, January 07, 2009 9:21 AM To: Luis Krause Mantilla Cc: xHarbour-Developers Subject: Re: [xHarbour-developers] Current CVS stable? Hey Luis, Thanks for the info. Ok, so than I think we have a group consensus on PCode change? All? Patrick On Wed, Jan 7, 2009 at 5:31 PM, Luis Krause Mantilla lkrau...@shaw.ca wrote: Patrick: That GPF was caused by a FWH .prg file that wasn't in our own modified collection of FWH code (listbox.prg). When a true RTE happen, the listbox object created by the FWH error dialog bombed when an AEval occured inside TListbox():Default(). As soon as I pulled this prg from FWH into our pool of modified FWH files the problem went away and FWH error dialog now showed correctly as expected and no more GPF. As Brian mentioned, it would be extremely useful if a similar error as the one we do with a PCode change could be added to avoid hours of chasing this kind of error. We do have Harb2Lib (made many years ago by Jorge Mason) which I've been using from time to time when a full FWH prg compile is needed so we're covered in that aspect. Regards, Patrick Mast, xHarbour. wrote: That is, once we fixed brian's GPF off course! ;-) On Wed, Jan 7, 2009 at 11:51 AM, Patrick Mast, xHarbour. patrick.m...@xharbour.com wrote: Andi, Very stable! :-) Than I think the moment arrived to start preparing for a new release, right? This has been on the table for long now. Patrick -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers -- Luis Krause Mantilla lkrausem at shaw dot ca luis_krause at hotmail dot com May the Source be with GNU - - Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers --- --- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 1/6/2009 7:56 AM -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Current CVS stable?
With the current cvs, our ErrorSys in Fivewin apps is throwing a gpf. We're debugging now and will let you know as soon as we identify what's different between this and earlier builds. -- Brian Hays Abacus Data Systems, Inc. -Original Message- From: Patrick Mast [mailto:patrick.m...@xharbour.com] Sent: Tuesday, January 06, 2009 6:35 AM To: xHarbour-Developers Subject: [xHarbour-developers] Current CVS stable? Hello, For all of use, Happy New Year! ;-) I was wondering.. Since I did not see any bugreports anymore for current CVS, is current CVS stable? Does anyone have any pending bugreports? Thanks! Patrick --- --- ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 1/5/2009 9:44 AM -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Current CVS stable?
Enrico: Thanks. Is it possible for us to catch this at link time instead of waiting for untraceable gpfs? Was there a pcode version change, and if not shouldn't there be? -- Brian Hays -Original Message- From: Enrico Maria Giordano [mailto:e.m.giord...@emagsoftware.it] Sent: Tuesday, January 06, 2009 2:07 PM To: bhays; 'xHarbour-Developers' Subject: Re: [xHarbour-developers] Current CVS stable? -Messaggio Originale- Da: bhays bh...@abacuslaw.com A: 'xHarbour-Developers' xharbour-developers@lists.sourceforge.net Data invio: martedì 6 gennaio 2009 21.22 Oggetto: Re: [xHarbour-developers] Current CVS stable? With the current cvs, our ErrorSys in Fivewin apps is throwing a gpf. We're debugging now and will let you know as soon as we identify what's different between this and earlier builds. You have to recompile all FWH PRGs. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic --- --- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1872 - Release Date: 1/6/2009 7:56 AM -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] 2008-11-29 12:10 UTC+0100 Miguel AngelMarchuet [EMAIL PROTECTED]
Sorry to chime in so late on this, but I don't think HB_LEGACY_LEVEL is good terminology. Two years from now what we do today will be Legacy, and the reference becomes ambiguous. Is there any reason it cannot instead refer to the last PCODE version that was parallel to the change in item structure? Also, the word Level doesn't indicate what scale it operates on. And though I tried to skim all the messages I did not follow it closely (sorry, we've been very busy), were all the changes related to Profiler elements in structures? In which case, shouldn't this flag be something like HB_Vxx_COMPATIBILITY or HB_Vxx_PROFILER_COMPATIBILITY or HB_Vxx_ITEM_COMPATIBILITY ? Again, sorry if it's too late to raise this; it wouldn't be the end of the world if it shipped as-is. -- Brian Hays -Original Message- From: Miguel Angel Marchuet [mailto:[EMAIL PROTECTED] Sent: Saturday, November 29, 2008 6:58 AM To: Enrico Maria Giordano Cc: Xharbour-Developers List Subject: Re: [xHarbour-developers] 2008-11-29 12:10 UTC+0100 Miguel AngelMarchuet [EMAIL PROTECTED] if you want to use older versions of 3rd party libreries you need to add HB_LEGACY_LEVEL remove HB_NO_PROFILER make xharbour a lot of slow. better if you add two macros for release programs. Best regards, Miguel Angel Marchuet Enrico Maria Giordano escribió: -Messaggio Originale- Da: Miguel Angel Marchuet [EMAIL PROTECTED] A: Xharbour-Developers List xharbour- [EMAIL PROTECTED] Data invio: sabato 29 novembre 2008 12.12 Oggetto: [xHarbour-developers] 2008-11-29 12:10 UTC+0100 Miguel AngelMarchuet [EMAIL PROTECTED] 2008-11-29 12:10 UTC+0100 Miguel Angel Marchuet [EMAIL PROTECTED] * include\classes.h * include\hbvmpub.h * to use old 3rd party libs, is needed to build xharbour with macro HB_LEGACY_LEVEL, because profiler structural variables are eliminated from its structure when are not needed. Are also removed on HB_NO_PROFILER. Does it mean that HB_NO_PROFILER is enough or we have to add HB_LEGACY_LEVEL too? EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic __ Información de ESET Smart Security, versión de la base de firmas de virus 3650 (20081128) __ ESET Smart Security ha comprobado este mensaje. http://www.eset.com --- -- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.3/1788 - Release Date: 11/28/2008 8:17 AM - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] debugger fails in fwh apps
I hadn't used the debugger with a Fivewin app in a while. It had been working some over the previous year or so. Now, the console window stays black, ; no UI paints, and it just hangs on altd(). If I don't call altd() anywhere the app does run, but the debugger console never shows anything. -- Brian Hays - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] New release
Has anyone fully tested InetRecvAll() ? We have an unresolved problem with the Internet communication functions. We've been unable to reduce it to a small sample, so I don't expect this to stop finalizing a release. But it would be good to know if a lot of people have done a lot of testing of the changes from a few months back regarding buffers. We have two programs, a server and a client, that talk to each other ultimately using nLength := InetRecv( ::Socket, @s_cRequest ) nBytesRead := InetRecvAll( ::Socket, @s_cResponse, nLength ) and METHOD Send( cSend, nLen )INLINE InetSend( ::Socket, cSend, nLen ) METHOD SendAll( cSend, nLen ) INLINE InetSendAll( ::Socket, cSend, nLen ) Initial custom handshaking using InetRecv() works fine to establish the length of the real buffer to transfer down from the server (current test is just 270 bytes). But when the server sends it, the client fails on the first call to InetRecvAll() which just reports zero bytes read. This code was working great for years, the last build was with last September's xHarbour. We didn't need to touch until this past April when we found the problem, and we've gone in circles a couple of times trying to chase it. The real problem is that it is intermittent. Using the exact same executables, if I start the server and test the client it may work. If it does, it usually will work for even a dozen tests. Eventually it fails. If I restart the server, the client may fail the first time. When it does, it usually fails consistently. So behavior seems to be dependent upon random startup issues, who knows what... Perhaps it works if the server is started during on an even-numbered second but not if the time is on and odd-numbered second. It's very weird, and hard to debug. Does anyone have any ideas? TIA, -- Brian Hays From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Mast, xHarbour.com Sent: Saturday, August 02, 2008 3:52 AM To: xHarbour-Developers Subject: [xHarbour-developers] New release Hey Guys, I'd like to call for a release freeze if there are no pending bug fixes. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] latest cvs performs worse on stress tests
Ron: Using the cvs from June 4, my app performed wonderfully (the best ever) under our stress test, although manual testing with some windows did have those errors Luis was discussing. The new cvs after your fixes does indeed seem to fix those errors, but now the stress test is failing. There's a significant memory leak, and the test fails after as few as 150 repetitions, where before it went over 1000 every time. Though manual usage of the program has not yet shown any visible problems, the drop in performance on the stress test is so significant I'd expect other people to be seeing a problem too. It's been a long time since I needed to chase unreleased memory blocks and such. Do we have a doc that covers the current state of debugging techniques? FM_STATISTICS handling changed since the last time I touched it; is that the recommended starting point? Thanks, -- Brian Hays - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] Random GPF at ending FWH app
Ron: MAKE_B32 CLEAN will continue to rebuild ALL. If your intention is to clean existing files but just do a core build, it's pretty awkward. Did we arrive at a consensus to have that command just CLEAN files, and require a second command to rebuild? I believe I've seen 3 informal votes to change it back to this. Are there any votes to have MAKE_B32 CLEAN do a full build? -- Brian Hays -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Pinkas Sent: Thursday, June 12, 2008 9:53 AM To: [EMAIL PROTECTED] Cc: xharbour-developers@lists.sourceforge.net Subject: Re: [xHarbour-developers] Random GPF at ending FWH app Toninho, Why not? The customer is not likely to see serious difference. Here's what you need to do: 1. Set EnvVar as per my previous reply. 2. MAKE_B32 CLEAN 3. Build your app with that debug build of xHarbour, using same compile and link flags as per above, and make sure to link cg32.lib as FIRST library. The resulting EXE will be slightly bigger, and little slower, but otherwise it should work the same, and should not bother your customer. Then after GPF, forward the YourAppName.cgl file, it should have all info we need to quickly resolve the problem. Ron On Jun 11, 2008, at 4:34 PM, [EMAIL PROTECTED] wrote: Toninho, With full C debug build it's easy to know exactly the problem, as you get the exact call trace for the offensive line. Please see my reply to Luis. Ron, I'll try but is very hard to get this GPF, and I can't send a full C debug EXE to my client... Regards, Toninho. --- -- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.3.0/1499 - Release Date: 6/12/2008 7:13 AM - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] PREMATURE ARRAY/OBJECT RELEASE DETECTED O 16BA914
Ron: Thanks. In the meantime, we have been able to reproduce it in the app with a few keystrokes. It seems to be related to having a TBrowse of a very large array. But even then, creating and closing multiple times doesn't trigger it; something else has to happen too. I have still not duplicated it yet on a dev machine, but I'll copy the data over as needed to try. Are you referring to the just in time debugging debugger? Also, which level of debug build are you referring to? It's been years since I had to hunt at that level... BTW, we did run our stress tests on a similar build just two weeks ago, and again with this one. That test does include exercising this same window. The test ran better than ever in terms of mem usage, and seems like it will run forever. So the extent of our real data seems to touch some specific boundary conditions. -- Brian Hays -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Pinkas Sent: Thursday, June 05, 2008 4:46 PM To: bhays Cc: 'xHarbour-Developers' Subject: Re: [xHarbour-developers] PREMATURE ARRAY/OBJECT RELEASE DETECTED O 16BA914 Brian, This happens when an Array or Object is being released, and LATER some C code calls hb_itemClear( pItem ) or indirectly by means of hb_itemRelease( pItem ). The last changes that might be related were: 2008-01-10 11:47 UTC+0100 Miguel Angel Marchuet miguelangel/at/ marchuet.net 2008-01-14 11:00 UTC-0200 Walter Negro anegro/at/overnet.com.ar Otherwise I'm not aware of any core change that might be related, in very long time. I'd add traces to hb_arrayNew() as well as hb_arrayReleaseBase() and hb_arrayReleaseGarbage() to track the creation and release of each array, and I'd log pBaseArray as well as pBaseArray-uiClass (when in hb_arrayReleaseBase() and hb_arrayReleaseGarbage()). I'll shortly also add an assert(0) just before that error is raised, so that a Debug Build will trigger your debugger, where you may discover more details. Ron On Jun 5, 2008, at 11:32 AM, bhays wrote: This is a CRITICAL error. Users of my full Fivewin app are getting this Unrecoverable error when closing an MDI child window. This is when the garbage collector gets invoked (there are dialogs on my MDI windows, and FWH calls hb_gcAll() upon closing a dialog). There are other MDI child windows open, there's no attempt to close the app. It's intermittent but pretty common and can happen within 5 minutes of using the program. We have NOT been able to reduce the steps to create the problem, let alone create a small sample. This is the first build using the xHarbour CVS since a few months back. We have never seen this before in my app. Any ideas how to put enough traces in to narrow down the cause? -- Brian Hays - - --- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers --- -- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.0.0/1485 - Release Date: 6/5/2008 10:07 AM - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
Re: [xHarbour-developers] ChangeLog: 2008-05-22 05:00 UTC+0700 Andi Jahja harbour/AT/cbn/net/id
Andi and all: I have spent many hours over the past week trying to deal with all the new features done to rddads in Harbour. Since what I've been talking about is a whole replacement of the source files, any posts you do now would have to be re-synced with the new files. Are you prepared to re-do that after I replace all the files? Note that a few of the other changes you did are already handled in the new sources. If you are proposing that we instead diverge from the Harbour RDDs, then that is a huge problem. Our build process need not follow Harbour's lead, and I have no problem with a better way to handle the ace32.lib issue, but we should be doing that with the new sources, not the old ones. Shall I just upload the sources that I cannot yet get compiled correctly and have everyone help get it going? -- Brian Hays -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Jahja Sent: Thursday, May 22, 2008 3:11 PM To: 'xHarbour-Developers' Subject: [xHarbour-developers] ChangeLog: 2008-05-22 05:00 UTC+0700 Andi Jahja harbour/AT/cbn/net/id 2008-05-22 05:00 UTC+0700 Andi Jahja harbour/AT/cbn/net/id * common.mak * compile.mak + new module ace32.c added. + contrib/rdd_ads/ace32.c ! definition of functions in ace32.lib * contrib/rdd_ads/adsfunc.c * contrib/rdd_ads/rddads.h ! move definition of AdsDeleteFile() to rddads.h * contrib/rdd_ads/ads1.c * guarded use of ADS_SYS_ADMIN_CONNECTION for version lower than 9.0 * contrib/rdd_ads/ace.h + function list synced with version 9.0 /* Now that ACE32.LIB IS NO LONGER REQUIRED when using rddads because it has now embedded in the library. This should solve import-lib jobs and, miss-match with ace32.dll should have been brought to the least minimum, if not nil. As this is a new approach, kindly test it. */ -- Andi --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.0/1460 - Release Date: 5/22/2008 7:06 AM - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] Reinaldo not getting msgs
I just got confirmation from reinaldo that he was not subscribed to the list and has not seen all the nice welcome messages. -- Brian Hays - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
[xHarbour-developers] Getting Reinaldo developer status
Reinaldo Crespo-Bazán has been giving me code for enhancing rddads off and on for a while now. I think we should give him full developer status so he can post his changes directly to the cvs. I can review from there, and work with him on the enhancements we want to do to support the newest ADS versions more fully. -- Brian Hays - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
