Re: Taking quotes on building LC external for RethinkDB
Mark W.. I know it shouldn't be this difficult, but would you mind sending your handshake code? I'm probably overthinking but can't figure out how to get it to work. On Sat, Aug 5, 2017 at 11:21 PM, Mark Wieder via use-livecode < use-livecode@lists.runrev.com> wrote: > On 08/05/2017 01:36 PM, Mark Waddingham via use-livecode wrote: > >> Err - given that revDB is an *SQL* database wrapper and MongoDB is not an >> SQL database you can imagine that creating an abstraction layer to deal >> with both might be 'quite' hard - if not impossible. >> > > Not so much. What I was attempting was to get some of the existing syntax > in place, so that things like revOpenDatabase would work rather than create > a whole new syntax. RethinkDB is also a nosql database, so I assume it's > also not going to fit into the existing command structure. > > Other than that, I'm gonna stay out of this and let you all handle it. > > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Taking quotes on building LC external for RethinkDB
On 08/05/2017 01:36 PM, Mark Waddingham via use-livecode wrote: Err - given that revDB is an *SQL* database wrapper and MongoDB is not an SQL database you can imagine that creating an abstraction layer to deal with both might be 'quite' hard - if not impossible. Not so much. What I was attempting was to get some of the existing syntax in place, so that things like revOpenDatabase would work rather than create a whole new syntax. RethinkDB is also a nosql database, so I assume it's also not going to fit into the existing command structure. Other than that, I'm gonna stay out of this and let you all handle it. -- Mark Wieder ahsoftw...@gmail.com ___ 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: Taking quotes on building LC external for RethinkDB
On 08/05/2017 04:42 PM, Tom Glod via use-livecode wrote: So it doesn't really need to have anything to do with the current revdatabase functionswhich the posts seem to be talking about. I'm not asking for a rewrite of db layer. Ah. In that case, I'm a bit confused. What does this have to do with LiveCode if you're not trying to tie into the existing functions? It would be more perform ant to build this as an external and closer to the engine...as far as I know anyways. unless thats completely wrong. From my brief scanning of the rethinkdb website, I don't think it would make a big difference. All the heavy lifting is being done by the database itself. You'd just be sending data back and forth over a socket connection between LC and the database app. I just spent about a half hour with this and fwiw I'm communicating with the rethinkdb server. Thanks for making me aware of the past efforts with RethinkDB. No, nothing to do with RethinkDB itself. Sorry if I gave that impression. -- Mark Wieder ahsoftw...@gmail.com ___ 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: Taking quotes on building LC external for RethinkDB
Fantastic. I look forward to the details of the quote. Thanks On Aug 5, 2017 9:58 PM, "Mark Waddingham via use-livecode" < use-livecode@lists.runrev.com> wrote: Hi Tom, Nothing in my previous post was to do with your request - we will get back to you as quickly as we can with a quote for what you asked. Whether that is a driver for revDB or a direct wrapper for the low-level C API raised to a suitable level of abstraction will depend on the analysis we do. The functionality you need is the important thing here and not the manner or means. Warmest Regards, Mark. Sent from my iPhone > On 6 Aug 2017, at 01:42, Tom Glod via use-livecode < use-livecode@lists.runrev.com> wrote: > > Hi Mark, > > I don't really know what to make of that thread and I wouldn't pretend to > understand everything thats being talked about here or thereso i'm jst > thinking out loud. > > I believe I might have mis-spoken by calling it a driver. its really a > LC external that acts as a driver. > > If you go to this page . the specs say that it all happens through an > tcp/ip connection where you make a connection, serialize the query and > send it the db driver port receives queries, and streams data from > the db via the TCP/IP back to "subscribed" client. > > So it doesn't really need to have anything to do with the current > revdatabase functionswhich the posts seem to be talking about. I'm not > asking for a rewrite of db layer. > > It would be more perform ant to build this as an external and closer to the > engine...as far as I know anyways. unless thats completely wrong. > > Here is the link again... > > https://www.rethinkdb.com/docs/writing-drivers/ > > Thanks for making me aware of the past efforts with RethinkDB. > > On Sat, Aug 5, 2017 at 4:36 PM, Mark Waddingham via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Err - given that revDB is an *SQL* database wrapper and MongoDB is not an >> SQL database you can imagine that creating an abstraction layer to deal >> with both might be 'quite' hard - if not impossible. >> >> So, given that we've now been open source for over four years and as such >> that code has been open for others to contribute to for four years please >> feel free to try and propose an API which works relatively seemlessly for >> all types of databases that exist today - I'll happily review it and help >> ensure it is worthwhile. >> >> Less 'rants' and more actual intellectual effort please. This isn't down >> to static and dynamic libraries, that is just the colour of the bikeshed at >> this level - and trying to claim that anything related to that is the issue >> here is just misleading people. >> >> Warmest Regards, >> >> Mark. >> >> P.S. My point here is simply that whilst their may be an abstraction which >> unifies all databases it sits so far up in the abstraction hierarchy that >> trying to make revDB do it would be entirely pointless. The 'revDB' rewrite >> you speak of has been subsumed by a number of db libraries which solve the >> issue of low-level access that revDB provides. Whether that be dblib, >> sqlyoga, or the way to abstract in a domain specific case as typified in >> many apps (e.g. The photo app in the createit course) have provided. >> Indeed, let's not pretend that the issue with supporting all kinds of >> 'database' here is at the C / API level because it really isn't. >> >> P.P.S. Abstractions are what makes things easy - abstracting too far and >> all you end up doing is proving that 1 = 1 in numerous not particularly >> interesting ways. What you might call "category theory 101". >> >> Sent from my iPhone >> >>> On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: I have to admit that rethinkdb sounds really interesting - I hadn't >> heard of it until your posting. Might be worth a crowdfunding / donation request to spread the cost; >> while I don't have a *need* for it, it might be a worthy target for (a >> small amount) of my optional spending of my 'pocket money' ;-) >>> >>> >>> http://quality.livecode.com/show_bug.cgi?id=3662 >>> >>> >>> >>> In 2006 all existing database bugs in bugzilla were rolled into one >> omnibus 'revDB review' bug report, and the individual report statuses were >> all changed as 'resolved'. This in favor of 'We will shortly be reviewing >> revDB' for a major rewrite of the database layer. >>> >>> Had this actually been done anytime in the intervening eleven years, >> adding new database types would be much easier. At some point I tried to >> add mongodb to the engine and eventually hit a brick wall because of an >> incompatibility with the existing library structure (a clash of static and >> dynamic libraries, IIRC) >>> >>> I realize revamping the database layer is a bigger task than trying to >> shoehorn more database types into the existing bucket, but I think it's >>
Re: Taking quotes on building LC external for RethinkDB
Hi Tom, Nothing in my previous post was to do with your request - we will get back to you as quickly as we can with a quote for what you asked. Whether that is a driver for revDB or a direct wrapper for the low-level C API raised to a suitable level of abstraction will depend on the analysis we do. The functionality you need is the important thing here and not the manner or means. Warmest Regards, Mark. Sent from my iPhone > On 6 Aug 2017, at 01:42, Tom Glod via use-livecode > wrote: > > Hi Mark, > > I don't really know what to make of that thread and I wouldn't pretend to > understand everything thats being talked about here or thereso i'm jst > thinking out loud. > > I believe I might have mis-spoken by calling it a driver. its really a > LC external that acts as a driver. > > If you go to this page . the specs say that it all happens through an > tcp/ip connection where you make a connection, serialize the query and > send it the db driver port receives queries, and streams data from > the db via the TCP/IP back to "subscribed" client. > > So it doesn't really need to have anything to do with the current > revdatabase functionswhich the posts seem to be talking about. I'm not > asking for a rewrite of db layer. > > It would be more perform ant to build this as an external and closer to the > engine...as far as I know anyways. unless thats completely wrong. > > Here is the link again... > > https://www.rethinkdb.com/docs/writing-drivers/ > > Thanks for making me aware of the past efforts with RethinkDB. > > On Sat, Aug 5, 2017 at 4:36 PM, Mark Waddingham via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Err - given that revDB is an *SQL* database wrapper and MongoDB is not an >> SQL database you can imagine that creating an abstraction layer to deal >> with both might be 'quite' hard - if not impossible. >> >> So, given that we've now been open source for over four years and as such >> that code has been open for others to contribute to for four years please >> feel free to try and propose an API which works relatively seemlessly for >> all types of databases that exist today - I'll happily review it and help >> ensure it is worthwhile. >> >> Less 'rants' and more actual intellectual effort please. This isn't down >> to static and dynamic libraries, that is just the colour of the bikeshed at >> this level - and trying to claim that anything related to that is the issue >> here is just misleading people. >> >> Warmest Regards, >> >> Mark. >> >> P.S. My point here is simply that whilst their may be an abstraction which >> unifies all databases it sits so far up in the abstraction hierarchy that >> trying to make revDB do it would be entirely pointless. The 'revDB' rewrite >> you speak of has been subsumed by a number of db libraries which solve the >> issue of low-level access that revDB provides. Whether that be dblib, >> sqlyoga, or the way to abstract in a domain specific case as typified in >> many apps (e.g. The photo app in the createit course) have provided. >> Indeed, let's not pretend that the issue with supporting all kinds of >> 'database' here is at the C / API level because it really isn't. >> >> P.P.S. Abstractions are what makes things easy - abstracting too far and >> all you end up doing is proving that 1 = 1 in numerous not particularly >> interesting ways. What you might call "category theory 101". >> >> Sent from my iPhone >> >>> On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: I have to admit that rethinkdb sounds really interesting - I hadn't >> heard of it until your posting. Might be worth a crowdfunding / donation request to spread the cost; >> while I don't have a *need* for it, it might be a worthy target for (a >> small amount) of my optional spending of my 'pocket money' ;-) >>> >>> >>> http://quality.livecode.com/show_bug.cgi?id=3662 >>> >>> >>> >>> In 2006 all existing database bugs in bugzilla were rolled into one >> omnibus 'revDB review' bug report, and the individual report statuses were >> all changed as 'resolved'. This in favor of 'We will shortly be reviewing >> revDB' for a major rewrite of the database layer. >>> >>> Had this actually been done anytime in the intervening eleven years, >> adding new database types would be much easier. At some point I tried to >> add mongodb to the engine and eventually hit a brick wall because of an >> incompatibility with the existing library structure (a clash of static and >> dynamic libraries, IIRC) >>> >>> I realize revamping the database layer is a bigger task than trying to >> shoehorn more database types into the existing bucket, but I think it's >> high time to revisit (crowdfund) this. Otherwise we're just digging >> ourselves deeper into the existing muck. >>> >>> >>> -- >>> Mark Wieder >>> ahsoftw...@gmail.com
Re: Understanding LiveCode Source [BOM Issue with livecodescript URLs]
The best way is to ask 'us' (as in the engineers that have worked on the entirety of the LiveCode source base for many years). This isn't any different from any other open source project which has 1.5m lines of code (I don't think at least...). We can certainly provide an insight at where to start looking in terms of working on most issues - although don't be surprised if some result in a littany of 'that would be nice but...' type response. (The engine, in particular, has yaks needing shaving all over - as the years go by they are getting increasingly sweaty and tetchy because of it). It is easy to get disheartened (slightly?) when working on the engine itself - but please don't be. We (as the maintainers) of the source base will offer as much help as we can, but do have to balance that with everything else we do. I'd like to think that we do better than the RTFS responses you see in many other projects - but it really does come down to that in many cases (as we have to do that ourselves!). However, we are are more than happy to dig out the 'lower hanging fruit' to help ease learning - you've already found one of those... I think you've found (one of) the good spot(s) to start - handling BOMs needs to occur at the point the engine reads in the text of the stackfile script as data and then use it with an 'external representation' bool flag to the decode API call in libfoundation (MCStringCreate...). I think that flag is currently unimplemented (so a small yak shave but not in anyway huge). You've already got a handle on the processes we use internally, and do expect every contributor to follow those processes, and sometimes we might sound blunt, but please always understand that in terms of ensuring what is done (in terms of mutation of the source - I use the term 'mutation' specifically as any change to a large existing, and existing entity can only be considered as such) is 'correct' (at least as far as the collective knowledge we hold is understood - and by 'we' I mean all that contribute). In terms of best places to interact on these matters then here (the use-list) is probably not great - gitter is good for direct answers but our quality centre is better as it provides a much better permanent and grokable record (indeed - we try to file an issue for every change to make it traceable globally)... At least until a PR is submitted. Also we *could* invite dedicated external contributors to our private Slack - not something we've done as yet but it's a very tangible possibility. (And this is not a matter of privacy - but of pragmatic information exchange - those that work for LiveCode directly have time constraints on responding to input - that's all). So, anyway, perhaps a much longer response than you expected. However it was not aimed at you (Brian) specifically, but generally. We don't expect contribution from anyone, but are always incredibly happy and as supportive as we can be when it occurs. LiveCode is a wealth of interesting problems, if nothing else, and you can learn a lot from it (as I have done in my 13 year tenure as 'chief engineer'). Warmest Regards, Mark. P.S. I made a comment recently about 'caution being one of the best tools to effect change' and it applies to any long standing entity - of which LiveCode is one. I completely reserve the right (as 'BDFL' which is perhaps my title in that space) to cessate anything which I do not think is right (usually by closing a PR ;)), but I have an open mind - 'trust' is an important factor here on a technical level. I limit myself on what I do to the engine (in particular!) because it is very hard to get it 'right' when taking into the account the breadth of applicability - there are huge constraints which only become articulable when faced with direct reasons for any change. i.e. Start small and work up - anything else will result in a *seemingly* dismissive response. (ie don't expect huge support from us for very broad changes without long running interaction and justification). P.P.S. I've learnt the above from tangible and *very* direct cost. The only reason I make these kinds of statements is because I care so much about what we are trying to be and do. Sent from my iPhone > On 5 Aug 2017, at 22:12, Brian Milby via use-livecode > wrote: > > Is there anything posted that gives an overview of how the source code to > LiveCode works/is organized? I know that the source is all there and I can > read it, but that would take a long time :) I'm still learning C++ (been > many years, but I learned C while in college), but following the code > doesn't seem too bad. > > I'm specifically looking at the parsing of livecodescript stacks with > BOMs. I think I know where the file is ultimately processed (the stream of > it anyway), but I can only work backward so far and get stuck. > > So, I guess a more specific question would be where to start on the handoff > between the IDE and the
Re: Taking quotes on building LC external for RethinkDB
Hi Mark, I don't really know what to make of that thread and I wouldn't pretend to understand everything thats being talked about here or thereso i'm jst thinking out loud. I believe I might have mis-spoken by calling it a driver. its really a LC external that acts as a driver. If you go to this page . the specs say that it all happens through an tcp/ip connection where you make a connection, serialize the query and send it the db driver port receives queries, and streams data from the db via the TCP/IP back to "subscribed" client. So it doesn't really need to have anything to do with the current revdatabase functionswhich the posts seem to be talking about. I'm not asking for a rewrite of db layer. It would be more perform ant to build this as an external and closer to the engine...as far as I know anyways. unless thats completely wrong. Here is the link again... https://www.rethinkdb.com/docs/writing-drivers/ Thanks for making me aware of the past efforts with RethinkDB. On Sat, Aug 5, 2017 at 4:36 PM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > Err - given that revDB is an *SQL* database wrapper and MongoDB is not an > SQL database you can imagine that creating an abstraction layer to deal > with both might be 'quite' hard - if not impossible. > > So, given that we've now been open source for over four years and as such > that code has been open for others to contribute to for four years please > feel free to try and propose an API which works relatively seemlessly for > all types of databases that exist today - I'll happily review it and help > ensure it is worthwhile. > > Less 'rants' and more actual intellectual effort please. This isn't down > to static and dynamic libraries, that is just the colour of the bikeshed at > this level - and trying to claim that anything related to that is the issue > here is just misleading people. > > Warmest Regards, > > Mark. > > P.S. My point here is simply that whilst their may be an abstraction which > unifies all databases it sits so far up in the abstraction hierarchy that > trying to make revDB do it would be entirely pointless. The 'revDB' rewrite > you speak of has been subsumed by a number of db libraries which solve the > issue of low-level access that revDB provides. Whether that be dblib, > sqlyoga, or the way to abstract in a domain specific case as typified in > many apps (e.g. The photo app in the createit course) have provided. > Indeed, let's not pretend that the issue with supporting all kinds of > 'database' here is at the C / API level because it really isn't. > > P.P.S. Abstractions are what makes things easy - abstracting too far and > all you end up doing is proving that 1 = 1 in numerous not particularly > interesting ways. What you might call "category theory 101". > > Sent from my iPhone > > > On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > >> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: > >> I have to admit that rethinkdb sounds really interesting - I hadn't > heard of it until your posting. > >> Might be worth a crowdfunding / donation request to spread the cost; > while I don't have a *need* for it, it might be a worthy target for (a > small amount) of my optional spending of my 'pocket money' ;-) > > > > > > http://quality.livecode.com/show_bug.cgi?id=3662 > > > > > > > > In 2006 all existing database bugs in bugzilla were rolled into one > omnibus 'revDB review' bug report, and the individual report statuses were > all changed as 'resolved'. This in favor of 'We will shortly be reviewing > revDB' for a major rewrite of the database layer. > > > > Had this actually been done anytime in the intervening eleven years, > adding new database types would be much easier. At some point I tried to > add mongodb to the engine and eventually hit a brick wall because of an > incompatibility with the existing library structure (a clash of static and > dynamic libraries, IIRC) > > > > I realize revamping the database layer is a bigger task than trying to > shoehorn more database types into the existing bucket, but I think it's > high time to revisit (crowdfund) this. Otherwise we're just digging > ourselves deeper into the existing muck. > > > > > > -- > > Mark Wieder > > ahsoftw...@gmail.com > > > > ___ > > 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, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecod
Re: Taking quotes on building LC external for RethinkDB
Err - given that revDB is an *SQL* database wrapper and MongoDB is not an SQL database you can imagine that creating an abstraction layer to deal with both might be 'quite' hard - if not impossible. So, given that we've now been open source for over four years and as such that code has been open for others to contribute to for four years please feel free to try and propose an API which works relatively seemlessly for all types of databases that exist today - I'll happily review it and help ensure it is worthwhile. Less 'rants' and more actual intellectual effort please. This isn't down to static and dynamic libraries, that is just the colour of the bikeshed at this level - and trying to claim that anything related to that is the issue here is just misleading people. Warmest Regards, Mark. P.S. My point here is simply that whilst their may be an abstraction which unifies all databases it sits so far up in the abstraction hierarchy that trying to make revDB do it would be entirely pointless. The 'revDB' rewrite you speak of has been subsumed by a number of db libraries which solve the issue of low-level access that revDB provides. Whether that be dblib, sqlyoga, or the way to abstract in a domain specific case as typified in many apps (e.g. The photo app in the createit course) have provided. Indeed, let's not pretend that the issue with supporting all kinds of 'database' here is at the C / API level because it really isn't. P.P.S. Abstractions are what makes things easy - abstracting too far and all you end up doing is proving that 1 = 1 in numerous not particularly interesting ways. What you might call "category theory 101". Sent from my iPhone > On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode > wrote: > >> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: >> I have to admit that rethinkdb sounds really interesting - I hadn't heard of >> it until your posting. >> Might be worth a crowdfunding / donation request to spread the cost; while I >> don't have a *need* for it, it might be a worthy target for (a small amount) >> of my optional spending of my 'pocket money' ;-) > > > http://quality.livecode.com/show_bug.cgi?id=3662 > > > > In 2006 all existing database bugs in bugzilla were rolled into one omnibus > 'revDB review' bug report, and the individual report statuses were all > changed as 'resolved'. This in favor of 'We will shortly be reviewing revDB' > for a major rewrite of the database layer. > > Had this actually been done anytime in the intervening eleven years, adding > new database types would be much easier. At some point I tried to add mongodb > to the engine and eventually hit a brick wall because of an incompatibility > with the existing library structure (a clash of static and dynamic libraries, > IIRC) > > I realize revamping the database layer is a bigger task than trying to > shoehorn more database types into the existing bucket, but I think it's high > time to revisit (crowdfund) this. Otherwise we're just digging ourselves > deeper into the existing muck. > > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Understanding LiveCode Source [BOM Issue with livecodescript URLs]
Is there anything posted that gives an overview of how the source code to LiveCode works/is organized? I know that the source is all there and I can read it, but that would take a long time :) I'm still learning C++ (been many years, but I learned C while in college), but following the code doesn't seem too bad. I'm specifically looking at the parsing of livecodescript stacks with BOMs. I think I know where the file is ultimately processed (the stream of it anyway), but I can only work backward so far and get stuck. So, I guess a more specific question would be where to start on the handoff between the IDE and the engine. As an example, I can see that when you turn off debug mode, the message box ends up with "send script pScript to pObject". I want to follow the problem statements through to see where they lead and compare what works to what doesn't. I'm using the message box (single line) to test syntax. I get the same results whether debug mode is on or off. The local file includes the UTF8 BOM (verified by getting the first 3 bytes). The actual file I'm using is the Scriptifier (URL from an earlier thread). I get the same results for "binfile:/" and "https://"; forms, so I've only included one below. I observe that "url" keyword is required (will need to adjust the documentation syntax, looks to be the same back to at least 7). So far I've observed the following fails silently (no error message returned): go [to] url "binfile:/...livecodescript" --should work The following fail with an error (LC9 gives "message" as hint, LC8 gives the actual script line as a hint "go..."): go [to] [stack] "https:...livecode" --missing url go [to] [stack] "binfile:/...livecodescript" --missing url go [to] stack url "binfile:/...livecodescript" --should work These work: go [to] [stack] url "https:...livecode" go [to] [stack] "/(full path)/Scriptifier.livecodescript" go [to] [stack] byte 4 to -1 of url "binfile:/...livecodescript" --assumes UTF8 BOM The current develop build has the same issues (at least for me). I can see in the code where it looks like the BOM should be accounted for (MCDispatch::doreadfile or MCDispatch::trytoreadscriptonlystackofsize depending on branch). It looks like the URL keyword will correctly parse a binary stack, but fails on livecodescript with a BOM. I put 2 files on a server that I control (with and without the UTF8 BOM), and the livecodescript will load fine from https:// if no BOM is included. Apologize for the long post, but wanting to contribute to the community if I can. Thanks, Brian ___ 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: Taking quotes on building LC external for RethinkDB
On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote: I have to admit that rethinkdb sounds really interesting - I hadn't heard of it until your posting. Might be worth a crowdfunding / donation request to spread the cost; while I don't have a *need* for it, it might be a worthy target for (a small amount) of my optional spending of my 'pocket money' ;-) http://quality.livecode.com/show_bug.cgi?id=3662 In 2006 all existing database bugs in bugzilla were rolled into one omnibus 'revDB review' bug report, and the individual report statuses were all changed as 'resolved'. This in favor of 'We will shortly be reviewing revDB' for a major rewrite of the database layer. Had this actually been done anytime in the intervening eleven years, adding new database types would be much easier. At some point I tried to add mongodb to the engine and eventually hit a brick wall because of an incompatibility with the existing library structure (a clash of static and dynamic libraries, IIRC) I realize revamping the database layer is a bigger task than trying to shoehorn more database types into the existing bucket, but I think it's high time to revisit (crowdfund) this. Otherwise we're just digging ourselves deeper into the existing muck. -- Mark Wieder ahsoftw...@gmail.com ___ 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: [OT-ish] Updating MacBook from El Capitan to Sierra to install Xcode 8.3+
Thanks Jerry et al! I did the upgrade with no problems. I would caution anyone doing this (or any major upgrade/install) is to be patient. The install progress bar froze for an hour or more. It appeared to be cut into stone with no estimated time to completion. This was after the install progress bar logged that there were 20 minutes left for about 1.5 hours. I went to bed and in the am it was finished and I logged in with no problems. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Jerry Jensen via use-livecode Sent: Thursday, August 03, 2017 10:41 PM To: How to use LiveCode Cc: Jerry Jensen Subject: Re: [OT-ish] Updating MacBook from El Capitan to Sierra to install Xcode 8.3+ As others have said, Sierra (10.12.x) is good old (?) HFS+. High Sierra (10.13.x) introduces APFS and is still in developer preview beta. I have upgraded 8 or so macs to Sierra with few problems. My biggest headache was going from 10.12.5 to 10.12.6 on only one machine that got in a fight with an ancient hp printer driver kext. That was a B#$^%^ to find. Other than that its been smooth. You have already CCC’ed to a fresh drive, so you shouldn’t have any rotten bits. CCC is indispensable! .Jerry > On Aug 3, 2017, at 12:28 PM, Ralph DiMola via use-livecode > wrote: > > I'm going to do this Friday night and was looking for any > advice/tricks to make this go smooth(as much as possible). I have read > about a few disasters online when upgrading from HFS+ to the new APFS file > system. ___ 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, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: preOpenStack problem
confirmed.. happening here… I've been getting this since 8.1.5, never cause serious problem, and had no recipe, so could not report it.. but yes exactly this debug breaking on preopenstack when closing up stacks. BR On 8/4/17, 11:06 PM, "use-livecode on behalf of Richmond Mathewson via use-livecode" wrote: why on earth is LiveCode trawling through "preOpenStack" when it's closing the thing? ___ 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: menuHistory & menuPick
On Sat, August 5, 2017 2:52 pm, Klaus major-k via use-livecode wrote: > >> Am 05.08.2017 um 14:15 schrieb jbv via use-livecode >> : >> >> >> well, not exactly... > > But it answered exactly your initial question, Sir! > > >> here's the thing : I have a hidden option button with several choices : >> choice1 choice2 choice2 >> >> At some point the content of the btn gets updated and it becomes >> visible with the following script : put "choice4" & return & "choice5" & >> return & "choice6" into btn 1 set label of btn 1 to line 2 of btn 1 set >> menuhistory of btn 1 to 2 >> >> The purpose of the "menuhistory" line is, when user press the btn, >> to have all the choices "centered around" the visible one on the label, >> which is more elegant imho... > > Well, this is a completely different situation and I am a bit clueless. > Now do you want to execute the menupick handler or not? > Nope, I want to bypass the menupick message. Your suggestion to block messages would block all messages, not just menupick. As mentioned in my original post, I managed to do it with a boolean variable. I was just wondering about the availability of a more elegant solution, using LC built-in features for instance... Best regards ___ 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: menuHistory & menuPick
> Am 05.08.2017 um 14:15 schrieb jbv via use-livecode > : > > well, not exactly... But it answered exactly your initial question, Sir! > here's the thing : I have a hidden option button with several choices : > choice1 > choice2 > choice2 > > At some point the content of the btn gets updated and it becomes visible > with the following script : > put "choice4" & return & "choice5" & return & "choice6" into btn 1 > set label of btn 1 to line 2 of btn 1 > set menuhistory of btn 1 to 2 > > The purpose of the "menuhistory" line is, when user press the btn, > to have all the choices "centered around" the visible one on the label, > which is more elegant imho... Well, this is a completely different situation and I am a bit clueless. Now do you want to execute the menupick handler or not? Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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: menuHistory & menuPick
well, not exactly... here's the thing : I have a hidden option button with several choices : choice1 choice2 choice2 At some point the content of the btn gets updated and it becomes visible with the following script : put "choice4" & return & "choice5" & return & "choice6" into btn 1 set label of btn 1 to line 2 of btn 1 set menuhistory of btn 1 to 2 The purpose of the "menuhistory" line is, when user press the btn, to have all the choices "centered around" the visible one on the label, which is more elegant imho... jbv On Sat, August 5, 2017 1:10 pm, Klaus major-k via use-livecode wrote: > >> Am 04.08.2017 um 23:27 schrieb Bob Sneidar via use-livecode >> : >> >> >> Hi JB. >> >> >> To set the menu display value without triggering menuPick, set the >> label of the menu button. In order to trigger the menuPick handler when >> changing the value, use menuHistory. No need to suspend messages or >> anything fancy like that. >> >> Bob S >> > > and the winner is: Mr. Bob S.! :-) > >>> On Aug 4, 2017, at 11:04 , jbv via use-livecode >>> wrote: >>> >>> >>> Hi >>> According to the doc, when you set the menuHistory property, a >>> menuPick message is sent to the button. I managed to block the menupick >>> message with a boolean variable, but is there an easier/more elegant >>> way to momentary block that message when setting menuhistory ? >>> >>> Thanks in advance. >>> jbv > > Best > > > Klaus > > > -- > Klaus Major > http://www.major-k.de > kl...@major-k.de > > > ___ > 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, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: menuHistory & menuPick
> Am 04.08.2017 um 23:27 schrieb Bob Sneidar via use-livecode > : > > Hi JB. > > To set the menu display value without triggering menuPick, set the label of > the menu button. In order to trigger the menuPick handler when changing the > value, use menuHistory. No need to suspend messages or anything fancy like > that. > > Bob S and the winner is: Mr. Bob S.! :-) >> On Aug 4, 2017, at 11:04 , jbv via use-livecode >> wrote: >> >> Hi >> According to the doc, when you set the menuHistory property, a menuPick >> message is sent to the button. >> I managed to block the menupick message with a boolean variable, but is >> there an easier/more elegant way to momentary block that message when >> setting menuhistory ? >> >> Thanks in advance. >> jbv Best Klaus -- Klaus Major http://www.major-k.de kl...@major-k.de ___ 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
preOpenStack problem
So, in the most recent version of my Devawriter Pro I have a script in the preOpenStack section of the stackScript: on preOpenStack send "mouseUp" to btn "CHECKIT" end preOpenStack btn "CHECKIT" checks the end-user's computer's MAC address against a list of MAC addresses in a scrolling list field. When I quit LiveCode LiveCode "throws a bluey" and opens up the stackScript and puts a "yellow thingy of death" next to send "mouseUp" to btn "CHECKIT" and says "no such object" which is, obviously, rubbish & why on earth is LiveCode trawling through "preOpenStack" when it's closing the thing? this is not "fatal" as I notice it doesn't happen in a standalone. Richmond. ___ 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
