
Pretty much the same result

Anyway I’m very happy with this, so thanks to everyone who made it go!

Oh, I used unsafe-fx+
etc in the Racket version, so if I timed the right thing, that might explain RacketCS beating Chez

I would be happy to host a Riot for the Racket community. https://riot.im/app/ @asumu knows this well and I am sure can also vouch for it.

I can setup a testing server in the next few days for people to take a look.

Both seem active - but I cant tell if they are running?

there is also discord. Identical to slack as far as I can tell - the only benefit to me is I can do screen sharing. it doesnt seem to have an archive limit. I can link to the first message (from @notjack) from 11 Sep https://discordapp.com/channels/571040468092321801/618895179343986688/621436392362213377

Isn’t the Racket CS vs. Chez Scheme difference less GC? And probably that reflects less frequent major GCs due to a larger heap (due to all the extra stuff in Racket).

there are a number of IRC integrations Of course it only has a few users like slack only a small percentage of the registered users are active. For the racket discord it it probably 5% of the 200+ registered are active.
if you want to look the server invite link will get you straight in https://discord.gg/6Zq8sH5

I noticed that and wondered if it was related to the unsafe-fx+

would you expect racket to have a longer start up cost?

I don’t think this is going to matter in general, but I did notice it here

The simple answer is that Racket is slower to start up, but it’s complicated. On my machine, Chez Scheme default startup is 60ms, but Chez Scheme startup with the vfasl files that Racket CS uses is 30ms, and then Racket CS startup without even racket/base
is 70 ms; in other words, before loading any Racket libraries, there’s a kind of one step forward and 1.5 steps backward on startup time. Loading just racket/base
makes startup 110ms (and a standalone executable that uses racket/base
is about the same). Loading racket
(instead of racket/base
) is 280ms.

At some point I attempted to buy a personal Slack license in order to see the Archives. I was then quoted the price for then entire Racket slack. Then I chickened out.

(Can’t remember the price).

per month

oh, I see I’m loading too many libraries, that would make a difference

It should be possible in Edwin’s case to compile Idris in something like the way Racket itself is compiled, which could get down to roughly the 70 ms point Matthew mentioned, but that isn’t something that’s easy to do

it’s not really a big deal anyway, I’d usually expect everything else to dwarf that cost

it’s only in the situation where it’s being run as a query on a source file, to do some editing action, where it would be nice to eliminate it

(that’s how it currently interacts with vim)

So that’s about 10x everything we currently spend per month

I was happy with google groups, but understand that could disappear on a whim too

I think there are some different options that have advantages over Slack if we started from scratch, but the community presence here is the important thing, and it would require a real consensus to move to something else, which would be hard to achieve

Having a mailing list is also good, but a chat system serves a different purpose

I feel fro people sufferign from the issue of wanting to see a discussion from before march 2020, but searching chat is terrible anyway so even if it wasn’t archived, you probable couldn’t find what you were looking for anyway.

In the long term, I would prefer to move away from slack tbh. I think if the core team would say: “Lets all move to http://talk.racket-lang.org\|talk.racket-lang.org or racket-lang.community” then people would move. But it would have to come from above. Such a server could easily be setup with riot. I am working on setting up such a thing for my local council as well. Igalia, where me and @asumu are also uses riot.

or zulip, there is also https://github.com/discourse/discourse\|discourse but is real time but feels closer to a forum than a chat

Both let you use your own domain. Probably true for rocket and gitter too. (all oss)

FYI lang <chat> and <forum> haskell are IRC and Discourse Rust are discord and discourse scala gitter and discourse python irc slack and MyBB + reddit ruby irc and mailing list (mailman?) erlang irc slack and mailing list clojure (no clojure chat?) and Question2Answer PHP forum (unofficially they have slack, discord and reddit) Kotlin slack and reddit typescript discord - no forum/mailing list swift - no chat , discourse forum lua irc telegram and mailing list processing - no chat - discourse Dart gitter and reddit Julia slack and Discourse groovy slack and mailing lists Pharo smalltalk discord and mailing lists Chez irc and mailing list

it looks like I could apply (with SFC permission) for the Slack for Non-profits, and maybe that would just be free.

bear in mind that if you went over the 250 users an %85 discount on $2000 is still ~$300/month How are active users measured?


it’s unclear whether 250 is “active” users (we have around 90) or total members (we have 1100)

go to https://racket.slack.com/home click plans (rocket in top right) choose standard (https://racket.slack.com/plans/standard?ui_element=53&ui_step=222\|link ) click ‘<https://app.slack.com/checkout/T06V8J4SU|upgrade today>’

Yes, for billing it’s clearly active users. But the “Slack for Nonprofits” talks about members.

I see what you mean.

I’m a big fan of making a note if you learn something https://github.com/racket/racket/wiki/Artifacts (most of these were already there, but I’ve added 1 or two)

Wasn’t someone talking about https://delta.chat before? How does that mesh with the mailing lists?

I don’t remember seeing that. I think a switch from Google Groups would require making it transparent for people who use email currently, and I don’t know of anything that is totally transparent.

From my understanding, it can supplement the Google groups.

Unless I misunderstood how it worked.

I’m pretty sure delta.chat it a chat ui over email.

I tried it on my phone but ti seemed pretty beta. and very dependent on a mailserver that played ball.

Ah

I’ll try again - it was in active development.


I just configured delta.chat with gmail for my phone ios and pc macos - after downloading the respective apps and setting up two-step authentication I created new passwords for each device. It seem to be more a replacement for person to person chat, than chatrooms. I’m not keen to ‘chat’ as I cant see any facility for channels or rooms.

delta looks something for 1-on–1 chats or in really tiny groups. does it work for larger groups?

I think the biggest issue with self-hosted services is maintenance. somebody needs to take care of it. maybe discord or gitter might be a better solution

I agree — I would not be in favor of something self hosted

I actually like Slack. Much better than irc. Never “clicked” with Discord. Also no archive may be a good thing - it makes chat more informal than the mailing list.

> does it work for larger groups?
No I tested it

Slack is fine as it is. I think paying for archive access is a waste of time imo because it is a poor way to store and retrieve knowledge. A pr to the documentation is not hard. A question is a cue to add an example.

@mflatt Re: your email here https://groups.google.com/d/msg/racket-dev/dHAFwzlFwNA/xfVGxIYaAgAJ
> You can even set config-tethered-console-bin-dir
and > config-tethered-gui-bin-dir
to get project-local racket
, raco
, > etc., executables that have the right configuration path built in, > instead of having to use something like environment variables to select > a project’s configuration. Does this imply that whenever I want a custom installation, I have to build a new Racket from scratch each time? Can I generate a new set of executables with only modified configuration paths without any other work?

(Assuming I don’t want to use envvars or CLI switches)

No. raco setup
will create the executables when the current configuration has config-tethered-console-bin-dir
, but the intent is that you’re chaining to another installation and running the raco
from there.

That’s what I was hoping. Thanks.

> I think paying for archive access is a waste of time imo because it is a poor way to store and retrieve knowledge. I get that, but there’s knowledge from here that I wanted to recall, but can no longer ever get. That’s good enough reason to go back to the user list, personally.

Anyone uses raco setup --fix-pkg-deps
on NixOS here? I get lots of “cannot delete file” errors: http://pasterack.org/pastes/89870 and info.rkt
is not updated, as this tutorial promises https://blog.racket-lang.org/2017/10/tutorial-creating-a-package.html

Is this worth leaving a warning somewhere?

Personally I think “this is a chatroom” is enough warning about that already. I understand your frustration though. We should do a better job of encouraging people to take useful chat threads and transfer them into more permanent homes.

Which means things like scribble docs, comments, wiki pages, the website, StackOverflow questions, and error messages. Not mailing list posts.

For, reasons, I’m trying to implement the contract dict/c
to be similar to hash/c
except for generic dictionaries. However I’m running into problems with chaperones, blame, and the existing prop:dict/contract
.
There is no chaperone-dict
function like chaperone-hash
, so I’m having the contract projections produce a new struct which implements prop:dict/contract
instead. However when I do this, the blame information is wrong. For example: (dict-ref (contract (dict/c symbol? symbol?) (hash 1 2) 'pos 'neg) 1)
This should raise a blame error that blames 'pos
and says the contract is from 'pos
. Similarly: (dict-ref (contract (dict/c symbol? symbol?) (make-hash '([a . b])) 'pos 'neg) 1)
Should raise a blame error that blames 'neg
and says the contract is from 'pos
. But instead the blame parties come from the boundary between <collects>/racket/dict.rkt
and whichever module imported it.
Is there a way to fix this so the blame information comes from the contract
form where the contract is attached, and not the point where the dict operations are exported from?

@alexknauth there is a dict/c
in one of Carl Eastlund’s packages iirc

The mischief package (https://pkgs.racket-lang.org/package/mischief) in the mischief/contract
module

Oh, that uses a much different approach from what I was trying with prop:dict/contract

Not sure if it does what you are doing

And it handles blame much better

Maybe prop:dict/contract
was just a mistake and I should never have tried to use it.

The mischief
version looks like it passes projections through more explicitly than I was, so its blame behavior is much better

@samth set the channel purpose: General discussion about racket-lang. Invite others through https://racket-slack.herokuapp.com/

@samth set the channel topic: Racket — http://racket-lang.org — http://pasterack.org - Slack invite link: http://racket-slack.herokuapp.com — Not logged/history expires after about a month


@alexknauth You might also be interested in the shenanigans I had to perform in order to implement contract combinators for comparator?
objects in Rebellion https://github.com/jackfirth/rebellion/blob/master/private/comparator.rkt#L146

tl;dr: it’s really easy for an API owner to mess up and not give you the tools you need to properly implement contract combinators (if they didn’t implement them already)

The choice%
control has a lot of padding inside the field part, on the right side, which you can see if you select a popup list choice (that wasn’t set to have a stretchable width) in the DrRacket preferences, e.g. Colors / Background / Parenthesis color scheme. I’m seeing that in macos, don’t know if it’s platform-specific. Is it intentional and there’s some rationale? Is there a safe approach to reduce it? Maybe it could be populated with a bogus list of shorter strings first which then get replaced by the real list, but I’m not sure how much shorter is safe (especially with proportional fonts).