|
i remember doing a small app for uiq3 just for fun...need to do this for android so I too will now be a developer amen.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Congratulations!
If I only had known that before...
Just tapping the Build Number 7 times
instead of wasting my time with learning, reading documentation, developing etc.
|
|
|
|
|
 Did that and all I got was "Developer mode now enabled".
It clearly knew who I was! 
|
|
|
|
|
Maybe Cp-Coder tapped the Build Number more thoroughly than you?
|
|
|
|
|
This image is the pulley arrangement of a Precor C024ES machine.
Image
I think the arrangement produces a 2:1 mechanical advantage, but empirical testing is causing me to doubt the exact number.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
That arrangement gives no mechanical advantage. It just redirects the direction of the force.
Pulleys with mechanical advantage are an assembly where one of the wheels is suspended from the other.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Since the top pulley moves, there is a definite advantage, I just don't know by how much.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Pulley - Wikipedia[^]
My assumption from the diagram is that both wheels are held fixed. Although the normal advantage is usually done with a "block and tackle" configuration, as you can see in the wikipedia image, they may be separated.
In the normal Block-and-Tackle configuration, the advantage comes from the lower pulley doing the lifting when it's ropes are shortened and the amount of shortening is proportion to the number of wraps around the pair (usually - 1 for the first wrap over the top wheel). You pull 1m and it shortens the configuration by 1/n m, lifting the weight with a mechanical advantage of n.
If a wheels can move, aside from turning, not evident from the image, it can possibly be a 2:1.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote:
My assumption from the diagram is that both wheels are held fixed.
Yes, but as I noted, the top pulley moves up & down with the lever.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
David Crow wrote: with the lever.
Then it is, in pulley terms, fixed. On the other hand, if the rope is held fast, the mechanical advantage of the lever comes into play.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
As W∴ Balboos, GHB says, it isn't a pulley problem. It is a moment arm problem. As I attempt to show in this crappy force diagram, if you are lifting a 100 lb weight, the wheel closest to the lifter will be pulling down on the top bar with a force of 200 lb at the wheel connection point, and the pin location will be pulling down on the top bar with a force of 100 lb. That is an incomplete force diagram, but may get you started thinking about the physics.
|
|
|
|
|
The greatest advantage is gained by having someone else perform the work.
|
|
|
|
|
A bit more than 2:1 as the anchoring point of the cable on the upper right also moves up relative to the lower pulley, but not as much as the upper pulley.
|
|
|
|
|
Not 2:1. The upper wheel and the anchor point do not move upward at the same distance. The difference is because they are along the lever which means the lift will be a function of the distance from the fulcrum and the angle through which the lever moves. That is just the pulleys alone. You also have to take the total length of the lever into account to get the total mechanical advantage.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
OK, I'll have a stab (retired aero engineer, if I get this horribly wrong my excuse is that I have been going down the pub for the last 10 years): assuming some approximate dimensions for simplicity
location: Lift pt pulley 2 pulley 1 cable att pivot
distance from pivot: 1 3/4 1/2 1/4 0
fixed/moves: m m f m f
If the lifting lever rises by 1 unit, then the weight rises by the sum of the cable extensions:
* cable att: cable extends by 1/4
* p1 has no effect as it is fixed
* p2 cable extends 3/4 * 2 = 1.5 (this is a pulley effect - cable must extend on both sides of pulley)
So total cable lift is 1.75, ie force at lift point = 1.75 * weight.
|
|
|
|
|
I'm writing my first Linux application using threads, and I'm discovering how much Linux thread management is dumb wrt Windows.
First, threads are actually miniprocesses, they can't even return the pid of their parent process because they are by all purposes separate. Well mate, if I wanted a process I would have forkinged...
Second, there is no critical section, which is only natural given point 1. So every mutex is a kernel mode transition.
Third, apparently threads continuously poll mutexes isntead of going in WAIT. To use a proper thread wait you'd need a condition variable AND a mutex. No reason at all.
After years of development under Windows, targetting mostly XP (2002 tech), I feel as if I traveled in the past. Like that episode with Scotty...
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Can anyone with Linux experience confirm this? It sounds like pure shite. What do they do for POSIX threads? For the functions added to std::atomic_flag[^] in C++20?
|
|
|
|
|
No experience of Linux, but a quick scan of Wikipedia seems to back this up:
the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
1. UNIX, which Linux effectively is, was designed long before Windows.
2. Why does it matter?
|
|
|
|
|
If he's porting a design where the threads think they're running under the same process, whose id they will all return, that design will have to be reworked.
If threads actually remap memory in the way that processes do, context switching between threads would be far more expensive. OP works on embedded systems where this could be unacceptable.
Having to drop into kernel mode to acquire or release a mutex is another overhead. If threads poll a mutex, that's about as idiotic as it gets if it's truly a spinlock. Having to introduce a condition variable (which has problems of its own) to avoid this would be yet another non-portable overhead.
I would bet that somewhere, someone implemented lightweight threads on Linux. The change may have been rejected by a collection of bozos, in which case it might be available as a variant from some vendor.
|
|
|
|
|
I'm shocked at this. I have done a huge amount of multi-threaded stuff under Windows which was fairly easy to do, coordinating the threads, etc. I happened to not have done any of this under Linux so I never realized how hard this would be. I'll stick to Windows a little longer I think.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
One thing I noticed pretty soon is the lack of a wakeable sleep. I used to pace my threads with wakeable Sleeps, so that I had instant response when I needed it and ensured a periodical run if anything went wrong.
Also asynchronous I/O requires a lot more boilerplate code wrt the magnificient Win32 API. Yes, they are harder to learn, but they make writing async I/O code a breeze.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Totally off the top of my head, but Linux, like it's UNIX parent, seems to try to make "everything" look the same. Making it a process, although involving addition overhead in your coding may give it some advantages. If he parent keeps track, as well it should, it keeps working.
What abilities does a process have, or avail itself of, that would not be available if the subprocess were as in Windows. For example, and I don't know why one would do it except to stop a train wreck, one can access a process and stop it uniquely even from outside the application.
Usually, Linux is based upon enabling. What can you do now that you couldn't before (and since you couldn't you'd not think about doing it).
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I think you simply need to learn more about Linux threads. It's not worse, it's just different.
|
|
|
|
|
If the descriptions in this thread are accurate, it's different and worse, at least if you care about portability and performance.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
