Re: lcTaskList Performance
You may want to consider having a reputable dev do all that for you, and then pay you royalties on all sales after that, should it go commercial. Bob On May 25, 2012, at 7:57 AM, Peter M. Brigham, MD wrote: > Unless I were heading towards creating a commercial product, which I have > dreamed of in my idle moments But I don't have enough idle moments to > actually do that. I figured I'd have to devote at least 2 months full-time > work to tune this up and get it fully ready for commercial primetime, and I > would need help in building in a licensing and registration schema, and a > good legal consultation, as well as someone to do marketing, which I know > nothing about and am not interested in learning. It really would be a change > in profession for me. I am getting to what many consider retirement age, but > I can't afford to retire, or to take a flyer on the bet it would pay off. > > I'll probably content myself with making standalone utilities to help > supplement the software I'm about to have to use. I'm already working on > something that will display drug interactions for a list of meds. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lcTaskList Performance
After some testing I am certain that my problem does not arise from the speed at which the plugin indexes the scripts. I also, for now, do not believe it has anything to do with sqlYoga. I have stepped through code that calls sqlYoga without problems. There is something I am doing in my code that is causing code execution to abort and leave LC in an unstable state. This does not happen with the plugin window closed, or if the plugin is not installed. I still have more testing to do, but it's difficult because stepping seems to bypass the problem and everything works. Bob ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lcTaskList Performance
On May 25, 2012, at 12:27 AM, Paul Looney wrote: > Peter, > > Suppose there was a database built with LiveCode, that required no SQL, that > worked with your data, that made your data multi-user, that provided > encryption for the network, that ran really fast, that let you tweak your > data and interface as you wished? > > Would this interest you? Yes, in the abstract. However, since I won't be able to use my software at all fairly soon, trying to restructure it now seems pointless. Unless I were heading towards creating a commercial product, which I have dreamed of in my idle moments But I don't have enough idle moments to actually do that. I figured I'd have to devote at least 2 months full-time work to tune this up and get it fully ready for commercial primetime, and I would need help in building in a licensing and registration schema, and a good legal consultation, as well as someone to do marketing, which I know nothing about and am not interested in learning. It really would be a change in profession for me. I am getting to what many consider retirement age, but I can't afford to retire, or to take a flyer on the bet it would pay off. I'll probably content myself with making standalone utilities to help supplement the software I'm about to have to use. I'm already working on something that will display drug interactions for a list of meds. > On May 24, 2012, at 8:16 PM, Peter M. Brigham, MD wrote: > >> On May 24, 2012, at 6:36 PM, Paul Looney wrote: >> >>> Bill, >>> >>> I've been following the RunRev list comments about lcTaskList speed. >>> >>> For what it is worth >>> 1. I have 46 large stacks open on my desktop (just for testing, I don't >>> work this way) >>> 2. Some of these are substacks, most are main stacks >>> 3. I have two large, 2000+ lines, stack scripts open in the Script Editor >>> 4. The largest stack has 510 fields and 282 buttons >>> 5. The largest stack script is 2327 lines of code >>> 6. I'm guessing that, in open plugins, substacks, btns and flds, there are >>> over 100,000 lines >>> 7. I'm testing with and without the script editor open and the message box >>> displayed >>> 8. The TaskList is correctly displaying 23 FIXMEs >>> >>> Updating the TaskList is almost instantaneous - too fast to time - >>> certainly less than 2 seconds. Could not ask for better! >>> >>> MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4 >> >> I'm guessing that the reason for the discrepancy between your case and mine >> is that my main stack has 700+ cards, so Bill's plugin has to search over >> 200 controls on 700+ cards to index the scripts, plus the 44 other stacks. I >> know, I shouldn't be storing data in individual cards, I know >> >> My stack system, Psychopharmica, is the way it is because I started the >> whole thing over 20 years ago in Hypercard and had a card for every patient, >> and I continued that model through my RunRev/LiveCode transition, not >> appreciating the importance of separating data from GUI. I have continued >> this antiquated structure for several reasons: my customized search routines >> depend heavily on HC/LC's find and mark commands, which are blindingly fast, >> and to try to duplicate even some of the functionality using database >> searches would be prohibitively labor intensive -- I really don't have the >> time to learn SQL commands given that I already have three half-time jobs. >> Not to mention all the other wrinkles I would have to iron out to change to >> a database-centered system. I know I have painted myself into a corner here, >> but my system has worked so well up to now and is so complex that making the >> paradigm shift is overwhelming. >> >> Plus there is an even more compelling reason for not putting energy into the >> necessary changes. If I were in a position to devote more time to it and it >> had a future that could be ported into a commercial venture, I'd tackle the >> job, but everyone in the medical field is moving towards electronic medical >> records and my system was designed from the beginning to print hard copy >> paper notes for a paper chart. To move this thing into an electronic medical >> record system would require me to learn networking and encryption along with >> the database management (not to mention developing an intimate familiarity >> with the HIPPA laws regarding medical confidentiality). I am essentially >> just a (pretty experienced) LC hobbyist with another profession that I have >> used LC to support, not a real IT person. I'm not prepared to create an >> entire EMR system single-handedly. >> >> So the end of the usefulness of Psychopharmica is heaving into sight. My >> group practice is about to adopt an EMR system this summer, so I will not be >> able to use my own customized LC system any more. I am not looking forward >> to having to use a piece of software that I can't tweak at will to make it >> do exactly what I want it to, and I'm
Re: lcTaskList Performance
On May 25, 2012, at 12:14 AM, Bill Vlahos wrote: > Peter, > > So you have over 140,000 objects to search through and it does that in 20 > seconds? How long does it take the LiveCode Find and Replace function to > search all of that? Searching through all those objects in 20 seconds might > not be all that bad considering that LiveCode does't handle lots of cards in > a stack that well. > > The progress indicator advances with each open stack. Try opening 5 small > stacks with your big stack in the middle of the order. How does the progress > indicator advance? I would assume it will be still while it searches through > your big stack and advances quickly before and after. The LC find & replace panel takes about 7-8 seconds to search, and its progress bar runs fairly smoothly from left to right. Your plugin takes longer, and the progress bar hangs at about 15% for the bulk of that time, then speeds rapidly to the end in the last 2 seconds. > I would suggest turning off the automatic reindexing in the preferences and > just click the index button manually to time it. Yes, I'll do that. > Do you have a splash screen to run your program or do you run it in the IDE > when using it? IDE. I kept meaning to turn it into a standalone but never got there. > It sounds like you have a terrifically useful program that you wrote. Sorry > to hear it will be obsolete for you soon. Thanks for the sympathy. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lcTaskList Performance
Paul, That would be of interest to me. What do you have cooking? -= Mike On May 25, 2012, at 12:27 AM, Paul Looney wrote: > Peter, > > Suppose there was a database built with LiveCode, that required no SQL, that > worked with your data, that made your data multi-user, that provided > encryption for the network, that ran really fast, that let you tweak your > data and interface as you wished? > > Would this interest you? > > Paul Looney > > On May 24, 2012, at 8:16 PM, Peter M. Brigham, MD wrote: > >> On May 24, 2012, at 6:36 PM, Paul Looney wrote: >> >>> Bill, >>> >>> I've been following the RunRev list comments about lcTaskList speed. >>> >>> For what it is worth >>> 1. I have 46 large stacks open on my desktop (just for testing, I don't >>> work this way) >>> 2. Some of these are substacks, most are main stacks >>> 3. I have two large, 2000+ lines, stack scripts open in the Script Editor >>> 4. The largest stack has 510 fields and 282 buttons >>> 5. The largest stack script is 2327 lines of code >>> 6. I'm guessing that, in open plugins, substacks, btns and flds, there are >>> over 100,000 lines >>> 7. I'm testing with and without the script editor open and the message box >>> displayed >>> 8. The TaskList is correctly displaying 23 FIXMEs >>> >>> Updating the TaskList is almost instantaneous - too fast to time - >>> certainly less than 2 seconds. Could not ask for better! >>> >>> MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4 >> >> I'm guessing that the reason for the discrepancy between your case and mine >> is that my main stack has 700+ cards, so Bill's plugin has to search over >> 200 controls on 700+ cards to index the scripts, plus the 44 other stacks. I >> know, I shouldn't be storing data in individual cards, I know >> >> My stack system, Psychopharmica, is the way it is because I started the >> whole thing over 20 years ago in Hypercard and had a card for every patient, >> and I continued that model through my RunRev/LiveCode transition, not >> appreciating the importance of separating data from GUI. I have continued >> this antiquated structure for several reasons: my customized search routines >> depend heavily on HC/LC's find and mark commands, which are blindingly fast, >> and to try to duplicate even some of the functionality using database >> searches would be prohibitively labor intensive -- I really don't have the >> time to learn SQL commands given that I already have three half-time jobs. >> Not to mention all the other wrinkles I would have to iron out to change to >> a database-centered system. I know I have painted myself into a corner here, >> but my system has worked so well up to now and is so complex that making the >> paradigm shift is overwhelming. >> >> Plus there is an even more compelling reason for not putting energy into the >> necessary changes. If I were in a position to devote more time to it and it >> had a future that could be ported into a commercial venture, I'd tackle the >> job, but everyone in the medical field is moving towards electronic medical >> records and my system was designed from the beginning to print hard copy >> paper notes for a paper chart. To move this thing into an electronic medical >> record system would require me to learn networking and encryption along with >> the database management (not to mention developing an intimate familiarity >> with the HIPPA laws regarding medical confidentiality). I am essentially >> just a (pretty experienced) LC hobbyist with another profession that I have >> used LC to support, not a real IT person. I'm not prepared to create an >> entire EMR system single-handedly. >> >> So the end of the usefulness of Psychopharmica is heaving into sight. My >> group practice is about to adopt an EMR system this summer, so I will not be >> able to use my own customized LC system any more. I am not looking forward >> to having to use a piece of software that I can't tweak at will to make it >> do exactly what I want it to, and I'm preparing myself for daily cursing as >> I use the new software. (The two other psychiatrists in the practice that >> use Psychopharmica are also feeling bleak -- they appreciate how nicely this >> software is attuned to the actual workflow of a busy practice, and it's >> about to die.) >> >> Sorry for the long, tangential, and somewhat bitter aside -- I didn't start >> out this post thinking that I'd write all this. I guess I'm in mourning >> already and needed to vent. It's been 20 years now that I've been spoiled by >> having a truly perfect tool -- one that evolved with my needs, not someone >> else's. Now it's time to say goodbye. >> >> ;-( >> >> -- Peter >> >> Peter M. Brigham >> pmb...@gmail.com >> http://home.comcast.net/~pmbrig >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and ma
Re: lcTaskList Performance
Peter, Suppose there was a database built with LiveCode, that required no SQL, that worked with your data, that made your data multi-user, that provided encryption for the network, that ran really fast, that let you tweak your data and interface as you wished? Would this interest you? Paul Looney On May 24, 2012, at 8:16 PM, Peter M. Brigham, MD wrote: > On May 24, 2012, at 6:36 PM, Paul Looney wrote: > >> Bill, >> >> I've been following the RunRev list comments about lcTaskList speed. >> >> For what it is worth >> 1. I have 46 large stacks open on my desktop (just for testing, I don't work >> this way) >> 2. Some of these are substacks, most are main stacks >> 3. I have two large, 2000+ lines, stack scripts open in the Script Editor >> 4. The largest stack has 510 fields and 282 buttons >> 5. The largest stack script is 2327 lines of code >> 6. I'm guessing that, in open plugins, substacks, btns and flds, there are >> over 100,000 lines >> 7. I'm testing with and without the script editor open and the message box >> displayed >> 8. The TaskList is correctly displaying 23 FIXMEs >> >> Updating the TaskList is almost instantaneous - too fast to time - certainly >> less than 2 seconds. Could not ask for better! >> >> MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4 > > I'm guessing that the reason for the discrepancy between your case and mine > is that my main stack has 700+ cards, so Bill's plugin has to search over 200 > controls on 700+ cards to index the scripts, plus the 44 other stacks. I > know, I shouldn't be storing data in individual cards, I know > > My stack system, Psychopharmica, is the way it is because I started the whole > thing over 20 years ago in Hypercard and had a card for every patient, and I > continued that model through my RunRev/LiveCode transition, not appreciating > the importance of separating data from GUI. I have continued this antiquated > structure for several reasons: my customized search routines depend heavily > on HC/LC's find and mark commands, which are blindingly fast, and to try to > duplicate even some of the functionality using database searches would be > prohibitively labor intensive -- I really don't have the time to learn SQL > commands given that I already have three half-time jobs. Not to mention all > the other wrinkles I would have to iron out to change to a database-centered > system. I know I have painted myself into a corner here, but my system has > worked so well up to now and is so complex that making the paradigm shift is > overwhelming. > > Plus there is an even more compelling reason for not putting energy into the > necessary changes. If I were in a position to devote more time to it and it > had a future that could be ported into a commercial venture, I'd tackle the > job, but everyone in the medical field is moving towards electronic medical > records and my system was designed from the beginning to print hard copy > paper notes for a paper chart. To move this thing into an electronic medical > record system would require me to learn networking and encryption along with > the database management (not to mention developing an intimate familiarity > with the HIPPA laws regarding medical confidentiality). I am essentially just > a (pretty experienced) LC hobbyist with another profession that I have used > LC to support, not a real IT person. I'm not prepared to create an entire EMR > system single-handedly. > > So the end of the usefulness of Psychopharmica is heaving into sight. My > group practice is about to adopt an EMR system this summer, so I will not be > able to use my own customized LC system any more. I am not looking forward to > having to use a piece of software that I can't tweak at will to make it do > exactly what I want it to, and I'm preparing myself for daily cursing as I > use the new software. (The two other psychiatrists in the practice that use > Psychopharmica are also feeling bleak -- they appreciate how nicely this > software is attuned to the actual workflow of a busy practice, and it's about > to die.) > > Sorry for the long, tangential, and somewhat bitter aside -- I didn't start > out this post thinking that I'd write all this. I guess I'm in mourning > already and needed to vent. It's been 20 years now that I've been spoiled by > having a truly perfect tool -- one that evolved with my needs, not someone > else's. Now it's time to say goodbye. > > ;-( > > -- Peter > > Peter M. Brigham > pmb...@gmail.com > http://home.comcast.net/~pmbrig > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, uns
Re: lcTaskList Performance
Peter, So you have over 140,000 objects to search through and it does that in 20 seconds? How long does it take the LiveCode Find and Replace function to search all of that? Searching through all those objects in 20 seconds might not be all that bad considering that LiveCode does't handle lots of cards in a stack that well. The progress indicator advances with each open stack. Try opening 5 small stacks with your big stack in the middle of the order. How does the progress indicator advance? I would assume it will be still while it searches through your big stack and advances quickly before and after. I would suggest turning off the automatic reindexing in the preferences and just click the index button manually to time it. Do you have a splash screen to run your program or do you run it in the IDE when using it? It sounds like you have a terrifically useful program that you wrote. Sorry to hear it will be obsolete for you soon. Bill Vlahos _ InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure. lcTaskList: (http://www.infowallet.com/lctasklist/index.htm) On May 24, 2012, at 8:16 PM, Peter M. Brigham, MD wrote: > I'm guessing that the reason for the discrepancy between your case and mine > is that my main stack has 700+ cards, so Bill's plugin has to search over 200 > controls on 700+ cards to index the scripts, plus the 44 other stacks. I > know, I shouldn't be storing data in individual cards, I know > > My stack system, Psychopharmica, is the way it is because I started the whole > thing over 20 years ago in Hypercard and had a card for every patient, and I > continued that model through my RunRev/LiveCode transition, not appreciating > the importance of separating data from GUI. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lcTaskList Performance
On May 24, 2012, at 6:36 PM, Paul Looney wrote: > Bill, > > I've been following the RunRev list comments about lcTaskList speed. > > For what it is worth > 1. I have 46 large stacks open on my desktop (just for testing, I don't work > this way) > 2. Some of these are substacks, most are main stacks > 3. I have two large, 2000+ lines, stack scripts open in the Script Editor > 4. The largest stack has 510 fields and 282 buttons > 5. The largest stack script is 2327 lines of code > 6. I'm guessing that, in open plugins, substacks, btns and flds, there are > over 100,000 lines > 7. I'm testing with and without the script editor open and the message box > displayed > 8. The TaskList is correctly displaying 23 FIXMEs > > Updating the TaskList is almost instantaneous - too fast to time - certainly > less than 2 seconds. Could not ask for better! > > MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4 I'm guessing that the reason for the discrepancy between your case and mine is that my main stack has 700+ cards, so Bill's plugin has to search over 200 controls on 700+ cards to index the scripts, plus the 44 other stacks. I know, I shouldn't be storing data in individual cards, I know My stack system, Psychopharmica, is the way it is because I started the whole thing over 20 years ago in Hypercard and had a card for every patient, and I continued that model through my RunRev/LiveCode transition, not appreciating the importance of separating data from GUI. I have continued this antiquated structure for several reasons: my customized search routines depend heavily on HC/LC's find and mark commands, which are blindingly fast, and to try to duplicate even some of the functionality using database searches would be prohibitively labor intensive -- I really don't have the time to learn SQL commands given that I already have three half-time jobs. Not to mention all the other wrinkles I would have to iron out to change to a database-centered system. I know I have painted myself into a corner here, but my system has worked so well up to now and is so complex that making the paradigm shift is overwhelming. Plus there is an even more compelling reason for not putting energy into the necessary changes. If I were in a position to devote more time to it and it had a future that could be ported into a commercial venture, I'd tackle the job, but everyone in the medical field is moving towards electronic medical records and my system was designed from the beginning to print hard copy paper notes for a paper chart. To move this thing into an electronic medical record system would require me to learn networking and encryption along with the database management (not to mention developing an intimate familiarity with the HIPPA laws regarding medical confidentiality). I am essentially just a (pretty experienced) LC hobbyist with another profession that I have used LC to support, not a real IT person. I'm not prepared to create an entire EMR system single-handedly. So the end of the usefulness of Psychopharmica is heaving into sight. My group practice is about to adopt an EMR system this summer, so I will not be able to use my own customized LC system any more. I am not looking forward to having to use a piece of software that I can't tweak at will to make it do exactly what I want it to, and I'm preparing myself for daily cursing as I use the new software. (The two other psychiatrists in the practice that use Psychopharmica are also feeling bleak -- they appreciate how nicely this software is attuned to the actual workflow of a busy practice, and it's about to die.) Sorry for the long, tangential, and somewhat bitter aside -- I didn't start out this post thinking that I'd write all this. I guess I'm in mourning already and needed to vent. It's been 20 years now that I've been spoiled by having a truly perfect tool -- one that evolved with my needs, not someone else's. Now it's time to say goodbye. ;-( -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
lcTaskList Performance
Bill, I've been following the RunRev list comments about lcTaskList speed. For what it is worth 1. I have 46 large stacks open on my desktop (just for testing, I don't work this way) 2. Some of these are substacks, most are main stacks 3. I have two large, 2000+ lines, stack scripts open in the Script Editor 4. The largest stack has 510 fields and 282 buttons 5. The largest stack script is 2327 lines of code 6. I'm guessing that, in open plugins, substacks, btns and flds, there are over 100,000 lines 7. I'm testing with and without the script editor open and the message box displayed 8. The TaskList is correctly displaying 23 FIXMEs Updating the TaskList is almost instantaneous - too fast to time - certainly less than 2 seconds. Could not ask for better! MacBook Pro, 2.2 GHz Core i7, 4 GB 1333 Mhz DD3, OS X 10.7.4 Paul Looney ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
