carl8's comments

I'm going through converting a Chrome extension to Safari 14, and the process isn't nearly as seamless as shown, although it's nice to have the converter tool.

Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill

Here's some incompatibilities between Chrome and Firefox to consider: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Also had some html/css glitches to fix in Safari. Some other issues others have mentioned such as notifications and webRequest APIs.

I made something similar, called PlasmaJS which you can view here: http://plasmajs.com

Back in 1995 I wrote a library for creating BBS Door games using RIP graphics, in QuickBasic 4.5. Also created a RIP Door Game of the classic Battleship game. It never went anywhere as most of my local BBSs started shutting down the following year.

I wrote some JavaScript that draws RIP files into a web canvas, and an experimental RIP to SVG converter. It's still incomplete. Here's the source: https://github.com/cgorringe/RIPtermJS

Here's a Demo page where you can see some RIP files rendered in a canvas and as SVG: https://carl.gorringe.org/pub/code/javascript/RIPtermJS/

Specs for v1.54, v2, and v3 can be downloaded here: https://carl.gorringe.org/pub/code/javascript/RIPtermJS/docs...

Some issues with the RIP format:

1. RIPscrip v1.54, the most popular version, was targeted towards 640x350 px EGA graphics, which is an odd resolution with non-square pixels. They tried fixing this in later versions, but they weren't as popular.

2. Non-standard bezier curves and the flood fill algorithm caused issues with rendering. I've had a lot of issues trying to get it working right as the flood fill would leak through holes in lines which aren't rendered exactly like RIPterm did. And the specs don't give details on how they did it.

I wonder how this would compare to Judy arrays. Would anyone like to benchmark this?

https://en.wikipedia.org/wiki/Judy_array http://judy.sourceforge.net

To install the Judy C lib:

  brew install judy
  apt-get install libjudy-dev

Then compile with -lJudy and #include <Judy.h>

Example: http://judy.sourceforge.net/doc/JudyL_3x.htm

Back in the late '90's there was the All BASIC Code (ABC) repository, which was a large collection of the best Basic code at the time. Some of my code made it there. Found this copy here: https://github.com/qb40/abcarchive

I used to be active on the QB FIDOnet forums in the mid-90's until many of the BBSs shut down. It was my favorite language during my teen years!

> If I was Google I would be providing ... a loose social network that encouraged links to other sites (perhaps similar to HN on a larger scale) that would be easy for third-parties to integrate.

They did. It was called OpenSocial, which originally released in late 2007, and was implemented by MySpace and others to compete against the Facebook platform (also released in 2007). I remember when I first looked at its complex XML documentation, that it was much easier just to use the Facebook API.

https://en.wikipedia.org/wiki/OpenSocial

I had done some work on a RIP viewer in Javascript a year ago if anyone's interested. It's not yet complete. There's a link to a demo to view some examples.

https://github.com/cgorringe/RIPtermJS

I tried writing a RIPscript generator in javascript a few years ago. I thought it would be easy, but it's surprisingly not.

It's unfinished, but here it is if you'd like to try it out: http://carl.gorringe.org/pub/code/javascript/RIPview/ripview...

Was just going to site that last one:

2/8/12

"Today 92 percent of the taxi fleet is comprised of hybrid or CNG vehicles. There are 1,318 alternative fuel vehicles out of a total of 1,432 eligible vehicles. CNG vehicles account for 89 of those and the hybrids account for 1,229."

Good Story!

I have a little story of my own. :-)

I met Logan Green the day that he first launched Zimride, at a student-run conference on climate change at UC Berkeley, in March 2007.

At the time I was working on a very similar social carpooling website "GotALift", but it wasn't yet ready to launch. I had also planned to announce my website launch to the exact same group of college students, so when he beat me to it with an almost identical product, I was a bit disappointed.

When I met him and got the chance to speak with him, I wanted to see if we could work together. No sense both working on competing websites!

At one point I jokingly suggested that we could rename Zimride to GotALift.

Zimride was really rough and buggy at launch, as he was the sole person working on it, and it was clearly rushed to make in time for the conference. I offered to help fix it up. At one point he offered to split the company 50/50 with me, but then changed his mind. Something about talking it over with his friend, who was going to help him get some funding so that they could contract out the development work rather than have me on as a tech cofounder. I thought that was a bit silly, since he had no money at that point and sharing equity wouldn't have cost him anything! I could understand him being cautious, but I thought we could have worked something out. Sadly it didn't end up happening.

Zimride became rapidly more popular during that summer since it rode the wave of new applications on Facebook's new platform. I ended up scrapping my unfinished social carpooling website because I didn't want people thinking I was making a Zimride copycat (a mistake, looking back), and I ended up rewriting it into a search engine with the goal to searching multiple carpooling websites, the "Kayak of Carpooling". I figured there were all these rideshare websites popping up which could use a way to search them all. That project went nowhere, other than a contracting gig for a local transit agency.

Fast forward to 2012. Zimride finally releases a mobile app, then their Lyft app shortly thereafter.

Next year, Zimride renames their company to Lyft!

Here's the solution that I came up with prior to following the link or reading any comments.

We're given 1 million integers from 0 to 99,999,999. We only have 1MB of RAM, or an average ~8 bits for each of the million numbers. So we can't store the numbers directly since they take ~27 bits each.

First thought was to use a bitset but that would require 100 million bits, and we only have ~8 million bits RAM, so that's not going to work. Also need to deal with duplicates.

How about this. Something similar to a selection sort algorithm that stores deltas of distances between sorted numbers. As a number is streamed in, we start scanning from the beginning of the list until it's correct position found, where it is inserted and then push down the remaining numbers. This will be O(n^2).

Since the average delta distance between numbers is about 100, we'll use 8-bits to store the delta value. Value 0 means the number is a duplicate of the current number. Values 1-254 mean add this number to the current number for the new number. Value 255 means add 255, then use the next byte as the delta value (repeat until the value != 255).

(Case 1) 1 million ints exactly 100 apart: 0, 100, 200, 300, 400, ..., 99999800, 99999900 Stored as a list of 8-bit delta values: 0, 100, 100, 100, 100, ..., 100, 100 (1 million bytes total)

(Case 2) 1/2 million zeros, then 1/2 million values of 99999999. Stored as: start: 0, 0, 0, 0, ... (1/2 million zero deltas) then: 255, 255, 255, 255, ... (99999999 / 255 = 392,156 times repeated, which gets us to number 99,999,780) then: 219, 0, 0, 0, 0, ... (another 1/2 million zero deltas)

So the total amount of storage for Case 2, which I presume is worse case (but correct me if I'm wrong!) is: 500,000 + 392,156 + 1 + 500,000 = 1,392,157 bytes to store the delta values.

1MB = 1,048,576 bytes, so I'm over by 343,581 bytes... (so close!)

We'll have to modify this scheme so that we reduce the number of 255 values, which should not be hard to do and will get us under the 1MB size limit. Or we could try something fancier like huffman coding to reduce the size of the delta values.

Every year someone comes up with an idea for a ridesharing website. There are over 100+ out there, so it's not like chris123 had this idea first. Some get traction, some don't. Many successful ones are companies you may have never heard of because they sell custom versions to government agencies instead of marketing them directly to end-users.

I had launched a website similar to RideJoy 4 years ago, although I gave up on it before getting as far as they are now since mine didn't get much traction. I even returned Craigslist postings in my search engine similar to what RideJoy does.

I came to realize that with all of the ridesharing systems out there, we really should start working together to keep the userbase from fracturing into too many systems. Any useful rideshare system requires a critical mass for it to be useful, and I worried that having too many websites, each separated on their own island, would divide up the userbase by too much.

The answer to this: Share data between services, or otherwise aggregate searches on multiple services. If we did this, then it wouldn't matter how many new rideshare websites launched as we'd still be able to search the aggregate of trips posted instead of dividing up the pie even further.

A few years ago I invited people from the rideshare industry, then developed and evangelized OpenTrip, a common data exchange protocol for sharing rideshare trips among the various systems.

I had some backing from a government agency at first. Unfortunately, this too didn't end up taking off. Perhaps I was too much of an idealist to think "open sourcing" carpooling could take off.

I am happy to see new interest in this with RideJoy. I hope you guys are successful. I would especially like to see you guys take on Zimride as I feel that they have too much of a monopoly on the university market, and haven't done a very good job innovating. (For example, they've yet to develop a mobile app.)

I'm still interested in this niche field and would be glad to talk with you guys sometime, as I'm also here in SF.

Thanks for posting my tribute to Steve!

If anyone's interested in the source: At a prompt, type CATALOG to see a list of files, LOAD FILENAME then LIST to view a program's source code. RUN to run it.

CTRL-S to pause. Reset button or CTRL-C to break out of a running program.

There's also an easter egg. :)