OpenXTalk Forums

Okay, thanks for the file.
Can you tell me what you've changed?

Please don't take the following as a criticism or a personal attack, or anything like that. I'm simply querying bits.

I can see you've changed the 'Web' tab, and it can in theory deploy to WASM, but even though I have this selected, it does not think I have a target selected. These values may also need clearing, but it would be helpful if you can detail what you changed. Github wouldn't track changes in a .rev stack either, so this is my point on keeping manual notes - it's why I use the approach I do, - and once again: NOT a criticism aimed at you.

I have just tested the Standalone builder 'Sonoma patching' in a more recent version of MacOS (the most recent I can lay my hands on, which is monterey 12.7.4) - I would have liked to test on MacOS Sonoma 14.x of course, but I don't have anything here that will run it

There's a lot to unpack in that screenshot, but the crux of it is that it's building two 64-bit only binaries, one with a sonoma menu patch, the other without.
My next step will be bundling this into a test update, and I'll probably do a 'testing' version of v1.08 soon so people can try it out.

OK, Chubby-Cheeks: I'll bite, but ONLY if you can give me a link to some sort of unified DMG file that I can download onto my MacOS 15 Sequoia machine containing a version of OXT Lite with the 'Sonomarised' standalone builder.
- -
Standing by . . . .

richmond62 wrote: ↑Tue Aug 27, 2024 2:08 pm ...but ONLY if you can give me a link to some sort of unified DMG file that I can download onto my MacOS 15 Sequoia machine containing a version of OXT Lite with the 'Sonomarised' standalone builder.

Not meaning to state the obvious, and say you had jumped the gun a little... but, you'd jumped the gun a little.

richmond62 wrote: ↑Tue Aug 27, 2024 2:08 pm Standing by . . . .

ETA 12 mins...

Waiting with bated breath.
-

Yeah, my upload speed is terrible.
Please try it here.

After supper: upload before download.

richmond62 wrote: ↑Tue Aug 27, 2024 4:43 pm After supper: upload before download.

And there was me thinking you were in a rush
I'll try and test your Devawriter, as mentioned here, but won't be able to do that until the kiddos are tucked up asleep in bed.

I'm not in any sort of rush.

BUT, something is being overlooked a bit:

1. LC appear to be indulging themselves in a 'Debbie Harry' moment.

2. If what I think is happening over there is happening, the sooner we can provide something reasonably robust as a viable alternative, the better.

So, as some sort of 'collective' (that's a word very near the top of my sh*t list) it behooves us (and 'behoove' is very near the top of my list of favourite English words) to get a move on before all those who vanished almost overnight when KM made is blunt and unsympathetic announcement about 3 years syne get overly disjaskit (one of my favourite Scots words) hingin aroond.

tperry2x wrote: ↑Tue Aug 27, 2024 4:58 pm ...but won't be able to do that until the kiddos are tucked up asleep in bed.

Ignore that. Tested it now, as they are happy enough.

richmond62 wrote: ↑Tue Aug 27, 2024 5:22 pm ...If what I think is happening over there is happening...

And what do you think is happening , the mind boggles.
If there's a chance of getting more interest in OXT for whatever reason, then that might be a good thing. I think I'd steer these new users towards Paul's OXT, not mine.

Not even slightly funny.

An electric cut halfway through building standalones of Devawriter Pro with you 108 tester on MacOS 15 beta.

Dunno when we'll get current back.

mwieder wrote: ↑Mon Aug 26, 2024 8:37 pm

how would anyone know which 300+ files you'd changed and where? - can you just download an archive of ONLY the recent changes, from a given date?.... I already know that the answer to this is no, which is another reason I don't use it - it takes too long to go through finding what has changed recently, instead of downloading a zip file with changes.

Dude... that's exactly what git / github is for. Only have to download / upload the deltas.
And gitk (built into git) gives you a visual glimpse into the changes historically.

Not to pile on to this but Mark is correct, that literally is the purpose of Git.

When you push changes, you can also attach comments on it to help you remember why some files were changed, useful those for binary files that GitHub doesn't scan. That's much the same as keeping notes in a text file, and hopefully the changes are also commented in the IDE scripts themselves (I often forget to).

Most of the IDE UI has limited amounts of script in the actual UI stack, because they had spent time refactored them all to be scriptOnly or stack + scriptOnly behavior-scripts, specifically so that they can use with available version control systems like Git. So most of the time it's maybe a few lines changed in some UI stack, but bulk of functionality is coming from script only libraries or behavior scripts, which work very well with Git.

I do understand the the sentiment, it does seem overly complicated, but you can do a lot with it and it's highly efficient (Delta means only sending/receiving lines that were actually changed). I've actually gotten away from using it mostly because a LOT of people in the community don't seem to like using it, and because I've messed up a few times pushing/pulling changes from different versions from different machines.

But some things you're saying about it are just not accurate, you can see list of changes, and images can indeed be compared in GitHub Desktop or in GitHubs Web interface. Images changes are displayed side by side like this: I think Github is actually pretty good for collaborative graphics work.

GitHub has built-in support for a handful of other binary or non-plain-text code files, like .tsv (tabbed separated values) and .svg files.

All I was meaning, was each to their own - I wasn't telling Mark not to use it, but I can only mention how I find it.
I'm glad it works for people who rely on it, and that's great they can get out of it what they need to.

Same as most people like the Microsoft 'Ribbon' in Word. I can't stand it.
These things say more about me, no doubt. And that's fine. Are we not all entitled to our own opinion?

not sure I should be putting my oar in here, will probably muddy the waters.. now there a mixed metaphor .. or maybe it's not mixed .. and I definitely don't want to incense anyone's sensibilities by hitting them over the head with my oar ...

I don't see how OxT can move ahead, merging the two forks which appear to be diverging rather rapidly with Tom's frankly brilliant work on the interface and Paul's on the engine which I believe is equally brilliant but I haven't really had the chance to look in to, and most importantly bringing in new collaborators, like Mark Wieder, who are most clearly needed, unless a common development strategy is settled on. And that is surely got to be GitHub, I know of no other. Like Tom, I hate GitHub. And I am guessing like Tom, I hate it because when I used it I really didn't read the manual so messed up to the great annoyance of my collaborator.

Tell me to butt out if this has all been sorted, and Tom and Paul have worked out a way for Tom to use his own way way of working but eventually (and not tooo eeeventuually) to merge into Paul's work. But there has to be a clear path for others like Mark to join in because there is too much stuff to do.

I think we're just trying to convey some of the benefits to working with GitHub (or GitLab or whichever) that you may not have considered. But it's certainly not a requirement, I believe that requirement was part of why LC didn't get all that many contributions to their opens-source efforts.

tperry2x wrote: ↑Tue Aug 27, 2024 10:01 pm Same as most people like the Microsoft 'Ribbon' in Word. I can't stand it.
These things say more about me, no doubt. And that's fine. Are we not all entitled to our own opinion?

I can't stand any of MS Office suite, at all, I've hated it since about 1991 or so.

I get all these points, and they are indeed valid.
I mean, yes - I'm kind of doing my own thing with Lite - but I'm also taking suggestions on it from people, so it's hopefully coming together as a collaborative effort.
The great thing about it, as we all know, is you can drop the entire IDE into a version control system of your choice and track changes to the IDE part.
(just that I don't get on with a lot of them, and GitHub is a prime example) - that's not to say that the idea is not sound (double negative), just that I hate it. It must be possible to take the essential collaborative concept from github and 'roll our own' version control system as they say?

I never did get around to looking at other version control systems, but there are probably more user-friendly ones out there.

The engine side of things, that could remain in github - would just be nice to have a 'releases' section where you can download compiled binaries of the engine eventually. As these are essentially 'drop in' replacements into the folder containing the IDE files, they can be tested separately from anyone's efforts who might be tweaking the IDE (stack files). - as long as nothing too 'earth shattering' is changed. (I mean, you can't just drop the engine from version 7 or 8 into the stack files from version 9 of LCC - because so much got changed by the look of it). Hopefully it's only bug fixes at this stage to the engine, rather than a complete overhaul - and I'm sure no syntax has been deleted, but I have no idea how it's coming along.

But you can drop in an alternative 9.x-based engine into 9.x-based stack files. Which is what I did with that RC4 version of your 'Don't panic edition' I mocked up for you. Just so there's no registration requirement for the DPE users on Linux.
The point being, the engine can be tweaked in github to our heart's content. As long as a compiled version exists, it can be replaced to bring both sides of the project together as need be.

So, after an all night electric cut (outside temperature 36 degrees C):
- -
A candle is too dim to read by.

- - -
Standalone builder stopped (first attempt: 64-bit Mac % Sonoma special selected).

Standalone builder crashed the whole shebang (just 64-bit Mac selected).

MacOS 15 beta something (Sequioa).

richmond62 wrote: ↑Wed Aug 28, 2024 7:48 am MacOS 15 beta something (Sequioa).

Interesting*... can you try building on a version of MacOS that isn't a beta, and see how that goes.
If you send me the stack via PM or dropbox, I'm happy to give that a go in Monterey at some point.

* when I say "interesting" of course I mean it's a pain in the posterior.
I'll be boring and quote myself from here though.

...but it's not at all surprising to me if a MacOS beta or mainstream update suddenly decides not to run OXT one day soon. I'm kind of expecting it to be honest.

The engine side of things, that could remain in github - would just be nice to have a 'releases' section where you can download compiled binaries of the engine eventually. As these are essentially 'drop in' replacements into the folder containing the IDE files, they can be tested separately from anyone's efforts who might be tweaking the IDE (stack files). - as long as nothing too 'earth shattering' is changed. (I mean, you can't just drop the engine from version 7 or 8 into the stack files from version 9 of LCC - because so much got changed by the look of it). Hopefully it's only bug fixes at this stage to the engine, rather than a complete overhaul - and I'm sure no syntax has been deleted, but I have no idea how it's coming along.

Ooookaaayy ... not sure that counts as a "development strategy", but if you and Paul are happy with it, and it works when the engine gets some changes that need tweaking the IDE side (and v.v), then fine. I'm hoping Mark can join in, because he was a key contributor in the other place. And maybe that means I can get my "regexp" version of the sqlite library real soon, pretty please?