Re: Enhanced HTTPD - native HTTP 1.1 Livecode Socket Server
David Bovill wrote: > I've been working for a while on a native server written in Livecode > using sockets. I feel it is definitely something that is sorely needed > - but to do it properly is more work that I initially thought. I need > to add HTTP 206 partial content support - > https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206. I expect > there to be other things that will need to be added. > > Is anyone interested / need this? Or does anyone already have something > they use? MC shipped with a simple HTTPd example included, and many years ago back when Pierre was still active here I dusted it off to add support for HTTP 1.1 so it would work with modern browsers: https://fourthworld.net/lc/mchttpd-4W.zip It's been years since I touched it, and IIRC the only other change I made was to use callbacks for both ends of the network I/O (for some reason Raney had used callbacks only on one side, tho I can't recall if his was on the write or read end). Callbacks for net I/O help a lot. If you're already far enough down the road to be thinking of 206 errors, there's likely nothing here you haven't already written. But as an example (slightly updated) of the sort of thing that used to ship with old versions to encourage exploration of network apps, it may be a fun trip down memory lane. A question, if interesting to answer: one of the reasons I set this aside was the beginning of a process of moving away from my own homegrown tools for generic commodities like socket servers. Apache and Node cover most of what I've needed since, and I don't have to maintain them, so I can focus on the stuff specific to my app. What are you working on these days? I stumbled across your chat with Ward Cunningham in the Full Moon Happening just a few months ago; good stuff. Curious if your interest in decentralization is still a focus, and whether it also includes things like IPSF and blockchains. Maybe offlist if it's not too LiveCodey is fine. Richard Gaskin FourthWorld.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
2 Qs about the OAuth2 bug fix in v10.x
The blog discussion re v10 mentions this fix to OAuth2: "OAuth2 redirect parameters are now correctly decoded" I was unable to find the corresponding bug report for that item. Does anyone here know the bug report ID for that? And can anyone on the team confirm if this will be backported to the v9.x series? Thanks in advance - -- Richard Gaskin FourthWorld.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: resizeControl wishes...
Craig Newman wrote: > “reSizeControl” is a message. What I mean by that is if you are already > running under script control, why do you need to send such a message at > all? Can’t your handler do whatever you needed to if the user did the > actual resize action? He's asking about resizing that takes place outside of direct user interaction with the pointer tool, such as during a resizeStack event. Paul Dupuis wrote: > resizeControl is sent "only sent when the user resizes a control by > dragging its handles. It is not sent if a handler changes the size > of a control by changing its properties (width, height, and so on)." That appears to be a documentation bug. IIRC the change you're looking for was introduced way back when the DataGrid premiered. Without it the DG wouldn't be able to cleanly update its internal groups. Here's a simple test stack confirming the change: https://fourthworld.net/lc/Resize%20Confirmation.livecode -- Card script: on resizeStack set the rect of grp 1 to the rect of this cd end resizeStack -- Group script: on resizeControl put item 2 of the loc of this card into tMid set the rect of fld 1 to the left of me,the top of me,the right of me,tMid set the rect of fld 2 to the left of me, tMid, the right of me, the bottom of me end resizeControl Tip: Set the lockLoc of such groups to true, to override the engine's default behavior of adjusting group size to fit contents. Now that the engine sends resizeControl to groups under both user interaction and script directive, handling the resizeStack message is MUCH easier than before. Among other things, it lets you encapsulate code within groups for reuse. But even if your groups are one-offs not needed elsewhere, the benefits of encapsulating the LOGIC of putting things where you want them is immense. It's so much easier to express the placement of objects within a group than relative to the group within a card. I'd guess that not having this sooner, and not documenting it after delivery, may contribute to the cottage industry of clck-click-click-click-click-click-click-click-click-click options for handling resizing with things like the Geometry Manager and various other tools and options. All of them are utimately responding to the resizeStack message, but in a generalized way that adds a large layer of complexity, and sometimes uncertainty. Handling resizeStack directly is with-the-grain; it uses the power of the engine to its most efficient, preditable, and robust advangage to put things exactly where you want them. -- Richard Gaskin FourthWorld.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: Comparative speed in switching among groups
Alex Tweedly wrote: > On 27/11/2023 00:02, ambassador--- via use-livecode wrote: >> I suspect most layouts won't encounter this much of a difference. After all, >> I did choose the elements I could put together quickly with rendering >> impairment >> in mind. > > But there is another consideration. When (if) you resize the stack, the > 'group' version will need to resize each of the groups (even when they > are hidden), and if the number of different groups is non-trivial, that > might make resizing slow. True, there are many other cases where rendering speed will show itself, and resizing is one that will come up throughout a session. My example only covered the transition speed as requested because I don't have the time I used to. LiveCode's decline in the market has me building a new business. It's been a long time since I've built a business from scratch; turns out it's not much easier than I remember it. :) The big performance difference here isn't so much the number of groups but what's in them. I'd guess the fields alone are the biggest time sink, calculating line wraps for 20k text with no carriage returns. With six of those fields it's almost silly to have that much text rendered below the fold at once; showing only the visible portion with a deferred loading of the rest would make things much snappier all around. I've made many layouts with deeply-nested groups. But outside of artificial stress tests like this I generally don't see load and save times as long as I see with this test stack. > > And now I'm curious: what are you working on where layout transition speed > > is critical? > > Hmmm. Doesn't your test case already take 2-1/2 seconds to change card ? > (13 seconds for 5 iterations). Yes, hindsight is always illuminating. :) But the question would not have been posed if the answer was known in advance. Given how often we use the card model provided, if the delay were this significant more often we all would have abandoned the practice long ago. But for most things card-to-card speed is more than adequate, and sometimes useful for organzing things during the development workflow. My own work has used both cards and groups, depending on particulars unique to the project. But now I'm also a little more aware of overall perfortmance degradation with line wrap calculations and images larger than their displayed size. Richard Gaskin FourthWorld.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: Comparative speed in switching among groups
An excuse to benchmark? Sure, I'll bite. :) I didn't test the third option because I feel confident we'd find it similar to the second but with the extra overhead of object/memory allocation. My hunch was that groups would be faster than cards, because everthing needs to be unpacked and ready to go on a card but when going card-to-card there's presumably some setup and teardown. But boy oh boy was I surprised by the difference. A bit about the test stack: I wanted a worst-case scenario, looking for things we know take a lot of rendering time. So I made a group with a field containing > 20k chars so there's a lot of line wrap calcs, a fairly sizable image shrunk small with resizing set to "best", and two buttons so the engine needs to coordinate with the OS. Then I replicated that group so there are three copies, grouped that and set a blue background, then made a copy of that bigger group and set it with a red background so we can tell them apart. Then I copied the blue group to a second card, the red to a third, and wrote a script that does the timing of each. The test stack I used is here (I added "SLIM" to the name because the first version I attempted had more than twice as many subgroups and took too long to work with, lots of beach balls on card-to-card and even saving): https://fourthworld.net/lc/TransitionTimingTest%20SLIM.livecode Bottom line, in millisecs for just 5 iterations on an M1 Mac: Groups: 141 Cards: 13619 And even that was after adding a couple details to the group hide/show so I could tell they've changed, with a lock/unlock and a wait 0 you probably wouldn't need in production. I suspect most layouts won't encounter this much of a difference. After all, I did choose the elements I could put together quickly with rendering impairment in mind. But I suspect the difference would still show itself in lighter layouts. And now I'm curious: what are you working on where layout transition speed is critical? -- Richard Gaskin FourthWorld.com David Epstein wrote: > Does anyone have practical experience or an understanding of the engine that > would > cast light on the relative speed of some alternative ways of doing things? I > want > to switch among a number of different groups, each of which may contain its > own > fields, graphics, buttons, and images. Possible approaches: > > - Have many different cards, each with a group peculiar to it, and GO TO each > card > as desired, or > > - Have one card, with many different groups, and SHOW/HIDE the groups as > desired, or > > - Have many different cards, each with a group peculiar to it, and COPY a > group from > an unseen card to a single card that is always seen (and DELETE the > unwanted group > on that single card). > > There are other considerations that affect a choice among these methods, but > my concern > here is the speed with which I can switch from displaying one group to > displaying > another. I am wondering whether at some level these methods all amount to > the same > thing from the engine’s point of view (since everything is in RAM in any > case). ___ 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: Windows maximization on desktops
Paul Dupuis wrote: > Is there a message sent when a user click the maximize icon (macOS > and Windows) in the titlebar of a window? As others have pointed out, resizeStack is sent. And by definition, wouldn't the windowBoundingRect be the maximized size? I'm curious: what does the app need to do differently if the user resized the window to that rect manually vs the Maximize button? -- Richard Gaskin Fourth World Systems ___ 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: Questions on Wasm export, licenses and file siz
David Bovill wrote: > With the old JavaScript export you had a separation between the engine > and stacks such that you could cache the engine part in the browser to > speed up the loading of the much smaller stacks. Is that the case (or > it is intended to be the case in the future) with the wasm export? A couple years ago Andre outlined the differences between JS and WASM, worth reviewing: https://www.mail-archive.com/use-livecode%40lists.runrev.com/msg08.html With your background you're probably well aware of the differences, but since we see so many conceptualizing WASM as "compiled JavaScript" it's worth taking a moment to review their respective boundaries. Given that WASM has no direct access to the DOM, and therefore no direct manipulation of controls or events, it is not a drop-in replacement for JS. In LC terms, it may be best to think about WASM's relationship to the browser as similar to what externals are to LC. Of course externals are very powerful; most of the v8 bullet points were new externals. But they still need LC Script to interface with our apps. The degree to which LC Ltd will be able to compile the whole engine into WASM is a good question, but it seems clear it will be limited in some ways, and it's unlikely we'll see compilation of LC Script to WASM for the foreseeable future. The good news is that the LC Community has a growing body of knowledge around JavaScript: some of the cooler widgets are just wrappers around a browser instance running JS/HTML/CSS. And given the vast amounts of web-native (JS/HTML/CSS) code out in the world, folks are continually finding new ways to integrate the native web stack with LC stack objects nicely. If web deployment is the goal, I see no downside and much to be gained from spending more time practicing JavaScript. While different from xTalk, it's a good language, and arguably closer to what xTalk might have looked like if HyperCard premiered 10 years later than it did. Being comfortable with JS means being able to fill in gaps between your LC work and LC's web export more easily, and even within LC today it's the gateway to vast components via the browser widget. JS is the only interactive language included in browsers. The best time to learn it was yesterday. The second best time is today. Like AppleScript, PowerShell, bash, and others, learning other languages opens new doors for integrating LC across a wide variety of systems. Bonus: the more you learn JS, the less you need to wait for with the feature completion in LC's web export. As for your question about deployment size, we can expect a WASMified engine to be smaller than its JS version, but there are so many factors that go into that it may just be too early to tell. If you do a web search for "WASM replace JavaScript" you'll not only get deeper discussions than what I've offered here, but also some confounding benchmarks where it's possible to have compiled WASM larger than the source code, and sometimes only slightly small, and then some amazingly smaller. So much will depend on so many implementation details... -- Richard Gaskin Fourth World Systems ___ 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
AW: LC 9.6.10 standalone with Pallette issues under Sonoma
Paul Dupuis wrote: >> We're just in the middle of testing, but we're seeing some issues >> where the contents of a palette window are not rendering (just an >> empty window) in a Livecode 9.6.10 standalone under macOS Sonoma. >> >> Anyone else see anything like this? > > Okay, this was all a false alarm and a code error. Some contractor > code was designed pre-Big Sur (and whatever version of LC fixed Big > Sus reporting as version 10.16) and only looked at if the first > number of the version was 10 to determine what if it was OSX. If it was to distinguish OSX from Classic you got a lot of life out of it, as Apple didn't change the major version number for decades. :) But I'm curious: was it just an errant condition triggering a hide, or did it trigger a deeper bug in the engine which prevents LC from rendering the content region of the window? -- Richard Gaskin Fourth World Systems ___ 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: Convert date
Neville Smythe wrote: > I seem to have hallucinated that the built-in convert handler recognised > the ISO date and dateTime formats (-MM-DD, -MM-DD > hh:mm:ss+-http://hh.ss, etc) but I must have written my own conversion > routines in a former life. > But one would have to ask… Why doesn’t it? > After all, the original ISO 8601 standard was adopted 1988! https://quality.livecode.com/show_bug.cgi?id=4636 -- Richard Gaskin Fourth World Systems ___ 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: Field highlited
Paul Dupuis wrote: > I have a LC9 field object - just a scrolling field (not a list field) with > a lot of text. The user selects some text and then click a button near > the field. I want the selection to remain highlighted, but when you > click outside the field the highlight goes away. Any simple solutions > to this. Some property I am just blanking on? In another app, I've used > the "selectionChanged" message to (1) set the background color of > the selection to a highlight color and store the start and end characters > as custom properties of the field. I'm hoping there is an easier way I am > just missing. > OR > There should be a feature enhancement: set the > preserveHighlight of field X to true That keeps the highlighted selection > unless or until you make a new one in that field https://quality.livecode.com/show_bug.cgi?id=3327 -- Richard Gaskin Fourth World Systems ___ 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: "template" stack in custom property
What are the advantage of instantiating the new stack from data in a prop rather than by cloning a substack? ___ 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: A problem with RunRev email account "sage.on-rev.com"
Robert J. Earp wrote: Jim, I’ve had this before with other accounts, albeit not run-rev. It’s always a problem with the server thinking I’m sending spam when eMailing to many addresses. Even if you get the IP address removed from a blacklist you run the risk of it getting put on again without any notification. I suggest you use MailChimp, it’s free and works like a charm. Or get a dedicated IP for your mail server, or become a mail admin and set up your own system for handling mail, or The other solution is to shut down vigilantism. Collective punishment is recognized by the Universal Declaration of Human Rights as flat-out wrong. Why do we tolerate it in cyberspace with spam vigilantes? I respect the difficulty of fighting spam, but knocking hundreds of legitimate accounts offline because one user of a machine is criminal is like shooting up a an entire neighborhood of families to get one bank robber. I've tried contacting some of the vigilante spam fighters to get white listed, with varying results. Many respond to such requests with a presumption of guilt, making it not only unnecessarily difficult to resolve the issue, but just plain rude as well. IP whitelisting must be made simple and straightforward. Vigilantes should recognize that it's far better to let a spammer slip through the prevention system than to risk preventing legitimate people from conducting their business through email. But they don't. So we need to take away their ropes and their hangin' trees, and turn their zeal down a few notches to rejoin a fair and just society. - rg/4w ___ 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: repeat with times
andrew at midwestcoastmedia.com wrote: I realize there are better and more efficient ways to construct that loop, but the fact that the original code does not throw an error in 9.0.5rc1 but does throw an error in 9.5dp1 made it seem like a regression. If the syntax is invalid, flagging it as an error isn't a regression, it's a fix. After re-reading the release notes I think this is probably the result of bug 20951 being squashed @ https://quality.livecode.com/show_bug.cgi?id=20951 That sounds like it. - rg/4w ___ 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: Livecode Array Encoding / Decoding using other platforms?
Tom Glod wrote: My LC written client will send to cloud for long term storage on the livecloud system.. but then I will have to pull the data to aggregate, count, and analyze it to show data interesting and useful points to the customers.. As much as I love LC I really want to do the right thing and use a high performing language to do that. Something like Rust. Rust has a reputation for performing on par or better than C++, but not C. If speed alone is the language determiner, why not C? Each new (1) customer (a school) will usually be 1500+ users who create 150,000+ records or more. So it will add up quickly. I don't know the details of the aggregate operations, but my first reaction to queries across millions of records is that storage and deserialization speed aren't as big an opportunity for performance as not brute-forcing your way through the records at all, using an index instead. -- rg/4w ___ 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: Livecode Array Encoding / Decoding using other platforms?
Tom Glod wrote: Thanks for that tip of undertanding about the array encoding. Explains why its really fast. Its not really the encoding / decoding speed i am thinking about. Lets see if I can explain better. I can try to read C code in the codebase to see if i can see how the data gets processedmaybe i will peek out of interest ...if i can even find the arrayencode function in the c codebase Its probably easier to encode into Json and baseencode any binary data..and just deal with text chunks instead of blobs. What will you be doing with the data? If both producer and consumer of the data are written in LiveCode, it's really hard to beat LSON (my pet name for encoded arrays). LSON is to LiveCode what JSON is to JavaScript, as BSON is to MongoDB. It is the most efficient, most with-the-grain serialization in this language. Of course, if you need to talk to things not written in LC, you'll have to write a parser in that language. My notes could help, but there would be no benefit. For interoperability, use JSON or XML. But if both client and server are LC, just enjoy LSON without even having to worry how it's made. Efficient, robust, easy to use - what's not to love? - rg/4w ___ 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: Livecode Array Encoding / Decoding using other platforms?
Tom Glod wrote: Hi Friends, I love the convenience of encoding arrays into binary chunks for saving and transport. But while doing data processing ideally I'd like to be able to decode my livecode arrays in other more high performance languages. LC's arrays are encoded and decoded in machine code. Just how fast do you need that? Is there some method by which this encoding happens that is standard and can be decoded using non livecode platforms? I have some notes on the older format I can see if I can pull together, based on things Mark Waddingham had written. But that was before the code base became relicensed as open source. The current code base would seem the best place for exploring the straight dope. - rg/4w ___ 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: Typesetting Fields
You may find the styledText array helpful. Richard GaskinFourth World Systems ___ 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
