|
I think you mean 1.44MB.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Well, if you're going to go all new-fangled on me ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I toyed with a similar idea... And rejected it when I realised what a pain Electron programming was going to be, and what an even bigger pain deployment was going to be, especially as I was depending on external C libraries (libxml2 and libxslt).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
You can find some alternatives here: tools-for-building-cross-platform-desktop-apps-with-web-technologies[^]
What I have heard is that besides the large footprint, it is also very difficult to write good behaving applications in Electron, so I would not recommend it for any complex application unless you have a team of developers behind you that can solve all the issues.
|
|
|
|
|
I am a team of 1.
Ever since the "cross-platform" idea was invented, it's been rediscovered time-and-again, that the juice ain't worth the squeeze, and targeting one platform is always the best idea. That was back in the mid-80's.
35 years later, nothing has really changed. And that's sad.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I've been investigating Electron for an app I want to rewrite but I got put on hold when I read an article ?somewhere? on uSofts new framework to be released with .NET 6. Microsoft unveils .NET MAUI for cross-platform apps | InfoWorld[^].
I don't know if it will be something I can use or not, but I'm too busy right now anyway.
|
|
|
|
|
It looks like Maui is a no-go for me because they didn't mention linux (that I noticed). I don't care about or need to support mobile devices, or even Macs. I want linux and windows desktop.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
That was the one draw back for me also, but hoping they add support in the future.
I won't be able to start my project for some time and there's no hurry.
I started rewriting it in WPF with MahApps and it is decent enough but Widows only1
The last version of the app was pretty popular but the one thing that was a no go was lack of support for other platforms, in particular IOS, some Linux.
|
|
|
|
|
Quote: it is decent enough but Widows only1 I must protest against this blatant example of positive discrimination!
|
|
|
|
|
I identify as a Windows user.
|
|
|
|
|
I've heard you can run WPF apps in Linux if you use .Net 5 instead of .Net Framework. Of course, you have to jump through some hoops to get kit there, but you might want to look at that.
(funny - when I first typed that it said, "I've heard you can ruin WPF apps in Linux...". Freudian slip?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: ruin WPF apps in Linux..
Probably truth in that?
|
|
|
|
|
Mike Hankey wrote: but Widows only1
When I worked in Japan many moons ago, I went to a computer exhibition. The Microsoft booth had a giant sign - Microsoft Widows.
Ain't spell-check wonderful...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
LOL, I can image there are quite a few.
That's how my first ex and I ended up exes.
|
|
|
|
|
I've recently created numerous ElectronJS projects.
Gratuitous Self Promotion ==> My CYaPass app is an ElectronJS app[^] which I successfully deployed to the Windows store.
Let me know, maybe I can help.
|
|
|
|
|
It's bad enough that multithreaded code is nondeterministic.
I propose that it is also meta-nondeterministic: You can not even count on it to be non-deterministic
When you need it to be unpredictable, the scheduler will inexplicably run your timeslices the exact same way, even when threads are executing on different cores, and even reboot to reboot.
I'm stuck on creating an *example* simply because I cannot create a situation wherein two secondary threads appear to be in competition (with the third thread being the main application thread) on a dual core ESP32 running FreeRTOS. I can do it where one thread is in competition with the primary thread, but it's as if the scheduler is just a dog when it comes to scheduling between two threads on the same core or something. Grrr.
It's bizarre.
Real programmers use butterflies
|
|
|
|
|
Threads are like fireflies. They tend to synchronize into repeated patterns.
|
|
|
|
|
Unless you need them to.
Real programmers use butterflies
|
|
|
|
|
I thought that was women and their...never mind.
|
|
|
|
|
Hmm. No criticism here, just old fart woolgathering.
After a long time developing multithreaded applications (including UI's), I've come to some observations:
- Thinking "adding a separate thread" will fix a problem generally won't.
- If you pay attention to timeslices, you're doing it wrong.
- If threads care about sequence of execution, you are doomed to failure.
Sleep(0) to force a context switch in Windows is A Bad Idea.Sleep(n > 0) is even worse.- Indiscriminately adding synchronization primitives like critical sections, mutexes, semaphores, and so on without understanding what you're doing gives you a false sense of security.
- Modifying thread priorities is bad karma. Please don't.
Software Zen: delete this;
|
|
|
|
|
You're not wrong at least in the general case, however:
1. This isn't about adding a separate thread in my case. I'm writing a library to allow you to use threads more easily than FreeRTOS otherwise lets you
2. This isn't true if you're writing a library that includes a threadpooler on a system with a primitive scheduler that's prone to starvation.
3. Threads don't care. Hell, my code doesn't care. But it's sure hard to demonstrate out of order execution and resyncing execution order for a *demo* when I can't get the execution order to scramble in the first place
4. Yeah, but this isn't windows, see also, craptastic scheduler
5. If you're doing that to force a context switch I'm not sure what's wrong with you. =)
6. Absolutely true. To that end my library provides you access to *none* of those. Seriously though, it offers you a message passing system in the alternative
7. See also, craptastic scheduler
Real programmers use butterflies
|
|
|
|
|
Quote: Absolutely true. To that end my library provides you access to *none* of those. Laugh | Seriously though, it offers you a message passing system in the alternative
Message passing is probably the only way to rein in the complexity of threads. Message-queues is the easiest message-passing interface you will find.
I recently did a simple message queueing library (based on pthreads) for a personal project and still managed to get the system to deadlock eventually (only happened on Windows due to different scheduling algorithm[1]). After fixing it I realised that there was no value in a linked-list queue.
I implemented my message-queue library as a double-linked list, so that any thread taking a message off of the queue does not block any thread trying to put a message onto the queue. My intention was that threads removing messages from the queue would never hold a lock that threads posting messages to the queue would need (and vice versa).
Unfortunately all threads still have to lock the entire queue just to check if (head==tail) in case there is only one item in the queue (then that item is both the head and the tail).
This is the stupid way of doing this. Don't do what I did. Instead, do one of the following:
1. Use a fixed-length message queue (either fixed at runtime or fixed at compile-time). This removes quite a lot of the unnecessary complexity; you're going to lock the entire queue for any posting or removal, but you're going to do that anyway with linked-lists too, so no big deal.
2. Address the fixed-length queue using modulus of the length (with appropriate locks); this gives you a circular buffer with no if statements.
message_t messages[BUFLEN];
...
messages[index % BUFLEN] = new_message; ...
message_t mymessage = messages[index % BUFLEN];
The problem with doing this is that it would automatically drop old messages (which, strategically, may be something you want, actually). Also, if you're not using C++ (no smart pointers) that's going to be a memory leak.
3. If your target platform and implementation allows (which it will), use #defines to define a CMPXCHG macro that expands to the assembly of the cmpxchg opcode. You can then use that for a superfast single lock with a sleep in nanoseconds or milliseconds that gradually decrements by a fixed amount so that no thread will starve. Doing this using your platforms mutex could be a lot slower than you think.
And, in case you're wondering, I am intending to update my implementation of a message queue to use fixed-length queues (probably settable at by the caller at runtime, with a sane default set at compile-time).
I'm not so happy about the cmpxchg thing as my queue library is supposed to be working on all pthreads platforms, and I'll need an implementation of cmpxchg for each platform. Not too much of a problem for things like ARM7 and later devices as I'm an embedded dev and am surrounded by various boards, but still a problem for platforms I don't have easy access to (one of my open source projects recently received a bug report for a bug that occurs on Z/OS).
[1] Which is why it's important to test code on multiple platforms, even if you never intend to ship on any of them - different platforms shake out different bugs.
|
|
|
|
|
1. I don't write my own concurrency safe queues because FreeRTOS has one and so does .NET so I've not had the need.
2. Yeah, when I wrote a ring buffer in C# I did that
3. I don't know a good reason to use that over say, std::atomic. In my experience, anything that won't support std::atomic won't support atomic CMPXCHG operations at the CPU level anyway, at least not that way. With the atMega2560 for example, IIRC it doesn't have one, forcing you to disable interrupts and then reenable them after the operation is complete. Don't quote me on the mega's capabilities, I'm not an AVR expert. It might be a bad example.
Particularly, #3 is curious to me. Why wouldn't you use for example, std::atomic_int?
Is it because it's a C++ thing? I use C++ even on 8-bit machines with 4kb of RAM. I just severely limit my use of things like The STL to the bare minimum. std::atomic is one area I use. std::chrono is another. Why? Because writing cross platform CMPXCHNG and timer code is error prone and i don't have access to all that hardware.
Real programmers use butterflies
|
|
|
|
|
Yes, it's because it's a C++ thing, and my queueing library is a C thing (My mention of pthreads should have given it away )
|
|
|
|
|
I've used pthreads from C++, so it didn't give it away for me.
I was about to write a top level post pondering the overall utility of writing *new* code in C.
I love C, but I just can't think of any hardware I've coded for (and i code for little devices) that can't at least host a binary compiled with a C++ compiler.
Given that I don't use *most* of C++ (like the STL) when I'm targeting an 8 bit monster, but classes and RAII still help with code management, for example.
Real programmers use butterflies
|
|
|
|
|