InsaneMultitasker

A million/year in royalties? Oh my.

The song reminds me of an old school demo program. As for the video content, well, I don't think I'll get that 4 minutes back...

I was driving the other day and we were behind this white Chevy. The plate caught my attention; I chuckled at the thought (albeit unlikely) that I might be following the author of our Geneve's Infocom interpreter.

I am using an SE3 (2022) with latest iOS / Sarari. I also tried Edge (it is installed for work purposes) and it also goes to the first post. My wife has an older ipad with iOS 13 or 15, I'll try the same thing with that device this week. Ah, when I read on my phone, I am not logged in. Maybe the default behavior for visitors is different? I'll try logging in on my phone. My desktop/laptop all go to the latest post, and I have never changed the setting while logged in. Verrrry interesting.

thank you. If I'm not working, I'll join one of the next few Zoom calls to listen in and/or clarify any points that I haven't articulated well in the forum (if needed).

Hello... When the last migration/update took place, I noticed that I could no longer tap on the most recent post time/date stamp to pull up the most recent message in a topic. I finally took a screenshot so that I could post a question Is there a way to do this now or can the functionality be implemented? Here's a screenshot from my phone: if I tap the circled date/time, I am brought to the first post in the topic, not the most recent. (I am using Sarari)

Short update for the group: @9640News and I have reconciled (sync'd) our OS code base. For my part, I leveraged Git desktop to identify differences. With exception of the CYA updates, we found one video XOP change for ABASIC that had been forgotten about. I'm looking forward to the ?W work that is happening in the TIPI-9640 dev topic, as that could make Git a more feasible option for some Geneve OS development. Additionally, I have started to pull together source for a few OS-specific items such as WIPE, the CRC detection utility, and PFM utilities. Maybe drivers can be added to this list, like mouse, ANSI and Windows. We've drawn the line in the sand and are now working to understand whether there is anything truly needed before we release 7.40. Getting close now...

Lately, I've noticed that a lot more of the spike lug nut covers are finding their way on all sorts of vehicles, seemingly for cosmetic reasons. Online they sell them in various lengths. Maybe I notice them more because of installations with more exposed lug nuts and a rim that extends beyond the wheel wall, like the picture below? I guess these things are legal but they still seem dangerous to me, especially in this configuration.

Can you knock out the brick to the left or right of the ladder? I have only reached level 5... I'll have to give this another go. I don't remember there being any cheat codes or hints booklets for the game.

I shortened my reply based on a re-read of the last few posts. In my mind, I had agreed with @9640Newss comment about being on target and had thought your post was easy to understand. Instead of writing that, I brought a shovel and dug myself into a device naming convention rabbit hole.

Ok, I copied the image from the "slow" card to another card. The transfer speed via TIPI seems OK now, I'll test more tomorrow to be sure. Thank you I pulled out a magnifying glass and here is what I could discern from the markings: "slow" card -- Kingston 8G, class (4) "fast" card -- Sandisk ultra, 16GB, class (10) I thought I used the Kingston with my TIPI a year or so ago but now I am not so sure. Is there a minimum class / speed requirement? Or is there something different with how the 3.x file system works? I'll keep the Kingston SD as-is in case you or @jedimatt42 want me to test something.

I encountered a problem that I don't know how to resolve. I recently updated my RPI/TIPI to the 3.x branch. I can read files from the RPI via the TIPI card and via the TIPI share without any issue. I can copy files from the PC to the TIPI share without any issue. However, tonight is the first time I have tried writing to the RPI via the TIPI card, and the file IO is extremely slow. The copy time for 50 files (2300 sectors) is 14 minutes. See the two screenshots for start/end times: When I built 3.x, I used a spare SD card. Since the write speeds via the TIPI share are fast, I figure the SD card is not the culprit? I restarted the RPI and there was no change to the slow write speed. If I re-insert my 2.40 SD card and copy files to the RPI via the TIPI card, the speed is normal. If I re-insert the 3.x SD card, the write speed is very slow. I found a CPU utilization command; here is a screenshot taken during the copy. I don't know if this is of any value. (when copying, the TIPIService utilization fluctuates between 15-30%). The TIPI log seemed normal and no errors that I could see. I'm willing to do some testing to determine the cause (hardware, software, gremlins) but I do not know my way around linux, so be kind.

Like the /4A, the Geneve is using TIPI. to communicate with the PI and TIPI device, and TIPI. is to be used for any of the TIPI configuration files and low level interaction. The TIP1. device name is only there to bridge a gap due to the OS-enforced naming convention of a three-character device + device number. That may change in the Geneve OS in a future release. Edit: the original response was intended to elaborate on @9640News 'explanation redirect' for TIP1. I removed the quoted fragment and simplified my response.

Cars are a good example of tactile feel and muscle memory tied to those feelings you describe along with a bit of nostalgia. My brother has our dad's 64 Chevy truck with its pull-on buttons, cable-attached dampers, floor-depressed high beams, simple ignition, etc. He used to have a 1965 truck with manual transmission and shifter on the column, a clutch that required almost-Herculean muscle strength, and manual steering that made for some interesting grocery store visits. Newer cars feel so detached by comparison.

Agreed. Single character subdirectories will maximize the depth, though at the expense of knowing what in the world you are looking at. Unless you like single-letters. This is certainly a possibility with the current maximum length. You can inadvertently lock yourself out of files doing this; hmm, this could double as a simple protection method for those who don't know the file system.

This article popped up on my start page tonight. The youtube video quality (audio) is pretty bad but mostly understandable. Nintendo Will Punish Hacker Gary Bowser For Rest Of His Life (kotaku.com)

Just to clarify one point: I am not considering any changes related to pathname length for the upcoming release. I do see benefits beyond JSON, such as being able to back up a folder without bumping into the 40 character limit. Regardless, we both agree the next step is to release MDOS 7.40 as there are fixes and enhancements that need to get out into the wild. A path length greater than 40 characters is possible if the device allows it, e.g., TIPI. I know there are programs that allow longer than 40 character paths outside of BASIC/XB but they might be more of an exception. Most of us take care not to exceed 40, so I'm not really sure. This too is a reason I wanted to at least have some discussion about it here, without the pressure of making it happen for the upcoming release.

The Geneve's DSR filename limit is 40 characters for the device+subdirectories+filename, the same limit imposed by the Myarc HFDC and carried through to other devices. I have identified the buffer and DSR code locations to update to increase the DSR limit. This would mean the ability to use additional subdirectory levels and improved "compatibility" with devices like the TIPI. The old limits would apply if ROMPAGE is in effect. The command line interpreter and the parse utility XOP also adhere to the 40 character limit. My concern/question is whether programs can recover from a parsed name that exceeds 40 characters; this depends on whether most programs rely upon the XOP to limit the length, or the program itself checks it. I'm putting this out here for discussion and contemplation.

I have used URIx to make life easier and I will try to read topics more diligently The challenge is often that artificial limitations were implemented based on hardware from that era. Early programs might ask for a disk number from 1-3 or generously allow 15 character disk device and file, e.g., "DSK5.FILENAME01". The HFDC DSR imposes a 40-character path.file limitation and I suppose that when 5MB hard drives were all the rage, deep subdirectory levels weren't that important; the same 40-character limitation was replicated in other DSRs and the Geneve OS. Fortunately, the TIPI doesn't adhere to certain past sins artificial limitations imposed by devices and programs/programmers. TIPI and @jedimatt42's dev approach helped to break me out of the old "must always remain compatible with xyz past device" mentality some time ago and for that I'm grateful.

The Myarc HFDC DSR imposed a maximum path.filename length of 40 characters and this carried through to the MDOS DSR and OS command line interface. I still have hopes that someday, this can be increased but it is not a simple change. In theory, you should see an error condition if you try to use a path.filename of greater than 40 characters.

Thank you. Adding "|[0]" to my selection returns the first element as a string -without- the quotes. I now think that I understand the difference. The link you provided to this interactive tutorial site JMESPath Tutorial — JMESPath has been very helpful as a learning aid, however, I am very ignorant when it comes to JSON. I definitely have some reading and learning ahead of me that is not TIPI specific. Did I mention that I really like this "?J" support? Very cool.

Upgrading to 3.5 went well. I completed all steps using my Geneve this time around, including the telnet session to localhost to expand the disk. Thank you for making the upgrade process so simple and easy to follow. I wrote a JSON test program to query a local file on the Rpi. When the values are returned, the strings include brackets and double quotation marks. e.g., if I query for "Directory Manager" the responses are ["Clint Pulley"] and ["2.62"]. The wiki states that "Simple strings, numbers, and booleans are presented in DISPLAY mode to the 4A without adornments such as surrounding quotes.", so I am sharing my program and the sample data for review. 1 !SAVE DSK8.JSONTEST 100 !OPEN #1:"TIP1.?J.JSON9640",DISPLAY ,VARIABLE 254 105 INPUT A$ 110 CALL QUERY(A$,AUTH$,LATEST$) :: PRINT A$;AUTH$;LATEST$ 120 GOTO 105 999 !query by program name 1000 SUB QUERY(PROG$,AUTH$,LATEST$) 1010 OPEN #1:"TIP1.?J.JSON9640",DISPLAY ,VARIABLE 254 1020 PRINT #1:"Geneve[?program=='"&PROG$&"'].Author" 1030 LINPUT #1:AUTH$ 1040 PRINT #1:"Geneve[?program=='"&PROG$&"'].Latest" 1050 LINPUT #1:LATEST$ 1060 CLOSE #1 1100 SUBEND Sample JSON file "JSON9640": JSON9640 (windows format file) { "Geneve": [ { "program": "Directory Manager", "Author": "Clint Pulley", "Mode": "MDOS", "Latest": "2.62", "Year": "2023" }, { "program": "GenWipe", "Author": "T. Tesch", "Mode": "MDOS", "Latest": "1.00", "Year": "2023" } ] }

I was posing the question in case it was as simple as changing the 2.x version text to inform users they are no longer on the most recent branch/version. I wasn't trying to waste anyone's time nor asking for another update. Anyway, the JSON feature caught my attention while reading the wiki for how to use the "?W" feature that @9640News mentioned to me. I was playing with "?J" and it didn't work; it wasn't obvious to me that I needed the 3.x branch update. I guess it was a matter of unfortunate timing but now I know how to proceed after reading the forum. Edit: crabby statement removed.

Understood, though it does me little good if I don't know there is a new road to follow. If 2.40 is the latest that will be reported for the 2.x road, then is there a way the 2.x "LATEST" value can nudge the user toward 3.x.

@jedimatt42 Is "PI.STATUS" intended to tell the user that there is an update from 2.x to 3.x? My TIPI reports 2.40 in the VERSION and LATEST values. I only happened upon the 3.x update posts by coincidence.