That seems risky.

Much water has passed under bridges, yet there are dozens of us even creating new ones and doing all sorts of weird things with this great hobby.

The Multi User Dungeon discord is nowadays the place to meet like-minded people who like, or code, or balance, or design, or write or use clients for, MUDs. Join us at https://discord.gg/multi-user-dungeon-279748146316312576

IAC WILL MUD

> 6. No Discrimination Against Fields of Endeavor > The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

So if you wish to restrict the use of the Software "in a business" (or in other endeavours), it won't be considered "open source".

The CC licenses aren't great for software, either, IMO. They're great for things like assets, basically... and that's about it.

That said, there's plenty "code available" licenses you may use. You just can't then call them "open source" since they're not.

Another way to put it: say I provide a patch to that software for you. I release it under the same terms as you provided. If you use it, well... you can't use it in your commercial product... as the license forbids it? ;-)

Turns out, it's not _too_ hard to make it useful, fast, and mostly bug-free.

Thanks to Github Actions, there are binaries for Linux, MacOS and even Windows.

If you find it useful, it'd be great to hear. If you'd like to comment on the code... that, too.

Comments URL: https://news.ycombinator.com/item?id=40989667

Points: 1

# Comments: 1

Because running those tests in your environment ensures that... that module can run in your environment.

By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.

Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.

> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server

I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.

I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.

But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.

Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.

My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.

Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.

A "perl 7" would.

There's https://metacpan.org/dist/perl/view/pod/perlclass.pod, which (granted) is experimental, but it's actively being worked on.

> Still no working exception handling!

There's https://metacpan.org/dist/perl/view/pod/perlsyn.pod#Try-Catc... which is now (5.40) no longer an experiment, _aside from_ the use of `finally`, which warns.

> trying to guarantee backwards compat for all the legacy code

Not "all", as there are indeed deprecations added over time, but _most_. I really, really like that I can, more often than not, take a program I wrote decades ago and it will still run properly.

You likely need all of them ;-)

IIRC it "fixes" terminfo stuff "within tmux" for kitty regardless of what $TERM is set. Mind you, I was using the latest tmux at that time. tmux 3.2?

Here's the issue I had: https://github.com/kovidgoyal/kitty/issues/3018

Looks like it should be fixed on a very recent tmux; otherwise this MIGHT help:

    set-option -as terminal-features ',xterm-kitty:RGB'

My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.

It's fine for those few systems I very often connect to, of course.

But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.

Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.

wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.

Happy days.

    set -g default-terminal xterm-256color
    set-option -sa terminal-overrides ',xterm-kitty:RGB'
    set-option -ga terminal-overrides ",xterm*:Tc:smcup@:rmcup@"
    set-option -ga terminal-overrides ",screen*:Tc:smcup@:rmcup@"
    set-option -ga terminal-overrides ",tmux*:Tc:smcup@:rmcup@"

Rather than "reduced" motion, I'd really look forward to "no" motion.

Like I had with i3wm... practically _instantaneous_ switch between spaces/virtual desktops.

Looks like there's a bunch of stuff that might opinably fit, depending on who those 10 clients were or what your company does.

- Regulated industries such as: Financial products and services / Investment and brokerage services - Money transmitters, currency exchange services and other money services businesses - Neobanks / challenger banks - Other financial institutions - Credit card and identity theft protection services - Other age restricted goods or services - Virtual and cryptocurrencies, non-fungible tokens (NFTs), and mining services - Sale of stored value or credits maintained, accepted and issued by anyone other than the seller - Businesses where sellers get their revenue both from selling items and from signing up new sellers - When you sign up for Stripe Issuing, you share with Stripe the location of your business, the physical address of your beneficial owners, and the jurisdiction in which your business is registered. Stripe requires that the physical location of your business, its jurisdiction of registration, and the physical address of at least one of your beneficial owners all match. Furthermore, you must use Issuing cards primarily in the same jurisdiction - Use of Stripe's services for any dealings, engagement, or sale of goods/services linked directly or indirectly with jurisdictions Stripe has deemed high risk, such as Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk Regions, or persons Stripe has deemed high risk, such as those individuals or entities named to a restricted person or party list of the U.S., United Kingdom, European Union or United Nations, including the sanctions lists maintained by the U.S. Office of Foreign Assets Control or the Denied Persons List or Entity List maintained by the U.S. Department of Commerce, is prohibited. Additionally, it is prohibited to use Stripe's products and services to directly or indirectly export, reexport, sell, or supply accounting, trust and corporate formation, management consulting services, architecture services or engineering services to any person located in Russia. Further, it is prohibited to use Stripe’s products and services directly or indirectly related to any goods prohibited by law (e.g. luxury goods) from Russia.

From a cursory search of email, name, company... I find it plausible that something above might've matched. Or maybe it's a matter of who those 10 clients were, and where they're located. Iran? Cuba? Crimea? Russia? That might do it.

Maybe your competitor also matches, which might be ground for -- if Stripe doesn't want that kind of business on their platform -- for shooting them off, too.

Or maybe it's not a matter of the business type, but of where the clients reside.

Unfortunately only Stripe could help here. :/

    { package Point;
      use Moose;
      has 'x' => (is => 'ro', isa => 'Int', required => 1);
      has 'y' => (is => 'ro', isa => 'Int', required => 1);
      sub as_string {
        my $self = shift;
        return sprintf '(%d,%d)', $self->x, $self->y;
      }
    }
    my $origin = Point->new(0, 0);
    say $origin->as_string;