|
this XPdf viewer is very good and I plan to wrap it into my software installer for users to read my manual.
diligent hands rule....
|
|
|
|
|
Good to hear. But any safe clicky link avaiable?
|
|
|
|
|
About 40 years ago I had a record (vinyl that time). I gave it away to a friend, but since about 30 years I'm looking for that.
The interpret was called approximatly 'bybatilax' or 'bibatylax' or ..., I can be easy wrong on spelling that. One song on that record -from which I was fascinated- was about thunderstorm with a great guitar part.
Any memories on something like that?
Thank you very much in advance
[Edit]
Neither google nor ChatGPT was successful 
modified 2hrs ago.
|
|
|
|
|
|
Nope, but thank you anyway 
You are most probably to young 
modified 1hr 10mins ago.
|
|
|
|
|
0x01AA wrote: You are most probably to young 
We had this conversation recently ... You said 40 years ago, so that puts me in my mid-teens... :P
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
That time (before 40 years) I counted as adult
|
|
|
|
|
You can't be that much older than me :P
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
1963
|
|
|
|
|
only by 5 years ... lol
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
Can you remember how it went at all? If so, this might help: Song stuck in your head? Just hum to search[^]
"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'm kind of rubber ducking you all, so bear with me (or skip) and thanks.
It's the wee hours here. I don't know what I changed in my code, but one minute it was working.
The next minute every time I start it it's like the procedure that builds all the windows exits halfway through without creating everything, and then the app doesn't exit. (It appears to, but you have to kill it in TaskMan)
I should pack it in but that leaves me for want of something to do (I woke up recently), and code in a known bad state.
All of this mess is to simply read and write serial ports in win32, but due to a sort of polarity mismatch between the Arduino and Win32 APIs I need to spin a thread to continually fetch data from the COM port. This seems to be what is causing the problem. It's not a race condition though - it's consistent.
I need to do this due to the presence of a peek() function which peeks the next character in the stream, and an available() function which returns the # of bytes waiting in the receive buffer. Win32 has no such facilities, so I need to emulate them.
I'm wondering if I can't just cooperatively thread the whole thing. I already have my main application loop where I could poll each com port, but due to separation of the various parts of Winduino I need to expose an uncomfortable amount of serial functionality "publicly" to make that happen.
It kind of makes me want to give up and play fallout, but I really don't want to leave my code in its present state.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Ok, without knowing the details of your coding. Here are some very dumb assumptions and a question.
I assume that since you used taskman to kill the app that the CPU was not pegged and memory was not pegged. It sounds like a resource issue or a locking issue.
Did you try rebooting and running the app on a fresh machine with nothing else running?
|
|
|
|
|
Oh it's definitely a deadlock. I'm just not sure where, and I think a lot of it has to do with me misunderstanding the behavior when reading COM ports under win32.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Time to start adding some debugging output to narrow done where....
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
This message has been flagged as potential spam and is awaiting moderation
|
|
|
|
|
Hello guys,
We are into healthcare application development.
I see there's a good amount of Standardization of the healthcare data. Like HL7 / FHIR etc.
All these are needed for interops between different HC systems.
The question is, Should our App DB schema that will be used internally should also adhere to FHIR standards?
I see these options:
1. Store App Data in application domain schema - just plain JSON with our own attributes. Snappy format helps faster transfers between the Apps.
2. Store App Data in FHIR transformation-compatible format. (Make it easier for ETL later into FHIR std). Schema needs some effort.
3. Sore App Data in full FHIR format. This makes the json payloads heap up like a landslide. A lot of effort upfront and bloated transport all around.
What would you recommend?
modified 8hrs 20mins ago.
|
|
|
|
|
If you have a standard, use it.
It means your apps can be more flexible, more generic - and can interface with other manufacturers apps, which is why we have standards in the first place!
"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!
|
|
|
|
|
Healthcare implementations are complex.
If you notice, Azure FHIR architecture examples never insist we store our Application Data in FHIR standard.
They say just go with what our App needs and don't worry about interop with external systems.
When there's a need for interop, Azure FHIR adaptors can transform the app domain data into standard Healthcaredata.
This has been the recommendation from different corners. But still want to hear from you guys here.
|
|
|
|
|
Apps have a shelf life. One day, someone is going to need to migrate the data in your (presumably) massive vertical healthcare application to some other system.
Use the standard, even if it's a lot of extra work up front. You'll recoup some of it on the back end, because you won't have to do things like document every nook and cranny rather than refer to existing standard docs for your data format.
Gosh just reading your post feeds into my burnout. Ugh, not your fault, it's just, my days of coding monolithic enterprise applications is over.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
This.
Otherwise when it comes to interoperability, you're just creating [standards]+1.
|
|
|
|
|
dandy72 wrote: you're just creating [standards]+1 xkcd: Standards[^]
FTFY
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I was going to link to that, and that is exactly what I had in mind what I wrote my post...
|
|
|
|
|
You store it in the form that normalization dictates; taking into consideration access paths; which means buying off the DBA to forget theory for a minute.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
