I just read myself, I meant runtime errors, not compile-time errors. One big
complain I hear from people used to compiled languages - when they first use
dynamic and interpreter languages - is the idea of having errors occur at
runtime, which ‘should’ have been picked up by the interpreter bef
On Wed, 29 Apr 2020 21:38:49 +0200, Dexter Lagan
wrote:
>Thanks so much for your reply, it's very nice to see another perspective. I
>added specific comments below :
>
>They say that Racket is slow. I would like to know who are "they".
>>
>
> Same here, never had a problem, but I do understand t
(Not directly related to Rhombus) Speaking of “how to contribute”, I find
that it is not friendly at all to setup stuff in order to contribute to
Racket core and main distribution. According to
https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html,
if I want to make a change to,
You could both send packages to the package catalog and instruct your users
to use a different package source if they wish to use old versions. I
don't see these two options in conflict with each other.
As an application writer, I am on the other side of this problem, by
depending on other pa
At Wed, 29 Apr 2020 12:46:50 -0400, David Storrs wrote:
> In related news, a question for the list: Once I have a handle on this, I
> would like to write a "How to Contribute to Racket Documentation" guide.
> Where would be the right place for this? Should it be an expansion to an
> existing docu
You’ve always been very inspiring to me. I’ll do my best to better the docs
if there’s a guide on how to do so. Bear with me, I have no background in
computer science and I don’t even know what a pull request is. I only recently
started using version control. I’ve always worked alone, until re
See the comment I just left in this PR:
https://github.com/racket/scribble/pull/223
Sam
On Wed, Apr 29, 2020 at 5:10 PM Dexter Lagan wrote:
>
> I’d like to help too, so if I understand this pull request correctly,
> there’s demand for a guide on how to update the docs? I was about to ask
> p
I’d like to help too, so if I understand this pull request correctly, there’s
demand for a guide on how to update the docs? I was about to ask precisely
that, how to contribute to the docs. If there’s JavaScript to make, I can take
a look. I don’t use Slack, is there an alternative?
Cheers,
Greg Hendershott writes:
> Although I haven't tried to use it hands-on, the description of the
> imperative flavor makes me think it might be intended to help with this?
>
> https://docs.racket-lang.org/web-server/dispatch.html#%28part._.Imperative_.Dispatch_.Containers%29
Hm, that's interestin
Thanks so much for your reply, it's very nice to see another perspective. I
added specific comments below :
They say that Racket is slow. I would like to know who are "they".
>
Same here, never had a problem, but I do understand there may be
requirements for real-time apps and system programmin
On Wed, Apr 29, 2020 at 12:47 PM Sage Gerard wrote:
> April 9th in the #general Slack channel taught me that there was no clean
> way to
> release a breaking change in a package. I'm open to working on version
> pinning
> support in raco pkg provided that a maintainer can walk me through some
> c
I currently deal with semantic data on a daily basis and a year ago I
started to work on a project in Racket that involved building RDF toolset
that I was hoping to open source and use it for implementing the proposal
outlined in the issue I've just started.
Unfortunately lack of existing toolse
To be clear, I have never had a problem with Racket's performance, I'm
just thinking about ways to push for a wider adoption. Personally, anything
faster than Python is more than enough, especially with a good FFI. I'm
guessing a lot of people look at Rust and Go just because it's supposed to
be
>
>
> They say that Racket is slow. I would like to know who are "they".
>
> Racket can be surprising. For example - our GUI application on RPi has a
> start-up time of 24s... But when we compile it using `raco exe`, it goes
> down under 2s including some hardware setup the program does. Usuall
April 9th in the #general Slack channel taught me that there was no clean way to
release a breaking change in a package. I'm open to working on version pinning
support in raco pkg provided that a maintainer can walk me through some code.
In the meantime, as much as I appreciate the efforts made in
On Wed, Apr 29, 2020 at 11:15 AM Jeffrey Edgington
wrote:
>
> Greetings,
>
> I would be interested as well.
>
> Thanks,
>
> Jeff
>
>
Sam and I started to do this on Slack and will connect again later to do
more. I'm taking thorough notes and will pass them along once I've got
something worked ou
Apologies if this is a tired question, and please link me to any answer I
missed.
If Racket is a component of the overall system, does that imply that it can
"reach out" from it's new home in the ecosystem and use all of the new features
available beyond Phase 4?
~slg
‐‐‐ Original Messag
Cool, thanks! Ping sent.
On Wed, Apr 29, 2020 at 10:27 AM Sam Tobin-Hochstadt
wrote:
> Hi David,
>
> If you ping me on Slack, I'll be happy to walk you through how to make
> changes to the docs. And maybe you can lend a hand to finally
> completing https://github.com/racket/racket/pull/874 which
Hi,
I can't leave this without reaction...
>
> To the point: what would make Racket2 the ultimate tool (for me):
>
> * Performance. Faster startup times, shorter execution times in
> general. Optionally, a ‘lite’ version of Racket that compiles
> directly to no-deps binaries, bypass
Hi David,
If you ping me on Slack, I'll be happy to walk you through how to make
changes to the docs. And maybe you can lend a hand to finally
completing https://github.com/racket/racket/pull/874 which I think is
mostly a matter of JavaScript programming now.
Sam
On Wed, Apr 29, 2020 at 9:35 AM
On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt wrote:
> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
> > To the point: what would make Racket2 the ultimate tool (for me):
> > Performance. Faster startup times, shorter execution times in general.
> > Optionally, a ‘lite’ version of Rac
At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
> To the point: what would make Racket2 the ultimate tool (for me):
> Performance. Faster startup times, shorter execution times in general.
> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps
> binaries, bypassing t
Hi all,
I had written a few of my early thoughts about ‘racket2’, but after mulling
over all this for a good year, I’d like to write something more definitive.
My background: I started programming in BASIC on C64, followed by ADA,
Pascal, C and macro-assembly on 8086 with MASM in the 90’s.
23 matches
Mail list logo
