[racket-users] Re: Quickscript competition Deadline Extended till Tuesday Morning 4 Aug (uk time)

[Stephen De Gabrielle]

*"QuickScript is amazing, btw — chapeau !" *
- comment from participant in the DrRacket @racketlang Quickscript 
Competition (unofficial)

Quickscript is easy and fun - take a look at some examples to see how 
others made their scripts

https://github.com/Quickscript-Competiton/July2020entries/issues (19 
competition entries - will you be #20?)
https://github.com/Metaxal/quickscript-extra/tree/master/scripts (34 
scripts in the quickscript-extra collection)

Good luck & have fun!

Stephen

On Wednesday, July 29, 2020 at 10:38:00 PM UTC+1 Stephen De Gabrielle wrote:

> Quickscript competition Deadline Extended till Tuesday Morning 4 Aug (uk 
> time) https://github.com/Quickscript-Competiton/July2020entries

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/161c586f-d803-4e91-9f18-4336f5ee644en%40googlegroups.com.

[racket-users] lsp server

[Catonano]

I'm playing with a toy project in #Racket


I'd like to use the lsp server

https://docs.racket-lang.org/racket-language-server/index.html

How do I do that ?

Should I require it from my project code ?

Or is it meant to be installed "globally" ?

And after that, how do I connect to it from my Emacs based client ?

Through a network socket ?

Through a Unix socket ?


Thanks in advance

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAJ98PDw7q54Kj9VyzrwRW3Ds0qHoN_7yn%2Bg7PdhJEtR84u1OEQ%40mail.gmail.com.

Re: [racket-users] lsp server

[Stephen De Gabrielle]

I don’t know anything about this but I believe
https://github.com/cfinegan/atom-ide-racket is a working example.
Might be worth a look at the code to see how it works.

Sorry I can’t be of more help

Best wishes
Stephen

On Fri, 31 Jul 2020 at 19:46, Catonano  wrote:

> I'm playing with a toy project in #Racket
> 
>
> I'd like to use the lsp server
>
> https://docs.racket-lang.org/racket-language-server/index.html
>
> How do I do that ?
>
> Should I require it from my project code ?
>
> Or is it meant to be installed "globally" ?
>
> And after that, how do I connect to it from my Emacs based client ?
>
> Through a network socket ?
>
> Through a Unix socket ?
>
>
> Thanks in advance
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAJ98PDw7q54Kj9VyzrwRW3Ds0qHoN_7yn%2Bg7PdhJEtR84u1OEQ%40mail.gmail.com
> 
> .
>
-- 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAGHj7-%2BXJ%2BhgStY1-Kq_hsdOrhhQ1bz2CC6qW9XM9Shm2b-hdQ%40mail.gmail.com.

[racket-users] Advice wanted about new opengl binding

[Hendrik Boom]

I need advice from someone with more experience with openGL and/or 
Racket.

I am still working on updating the Racket openGL binding to the current 
openGL spec.

I'm doing this as in the old binding, machine-translating the formal 
part of the openGl standard, which now uses a competely new formalism.

I'm debugging it (for now) by comparing the old Racket include file with 
the new one on the theory that functions that were there a few years ago and 
are still there should have teh same Racket definitions now as then.

Running into a big snag.

There are a *lot* of glGet functions that grab data from the video 
processor and bring it to the CPU.
They give openGL a pointer to a storage area where it should return 
data.

For example, there's glGetCompressedTexImageARB.  It receivees a 
pointer to an image area and fills it in with a compressed image.
According the the Racket C interface, the way to write this 
would be:

(define-gl glGetCompressedTexImageARB 2 
  ( (target : _int32)
(level : _int32) 
(img : _pointer/intptr)
  -> _void -> img)
 (->> exact-integer? exact-integer? gl-pointer?)
 check-gl-error)

(here define-gl is a macro interal to the opengl binding that contains a 
number of input arguments and a contract for the manual as well as the 
actual c interface description, which of course is

  ( (target : _int32)
(level : _int32)
(img : _pointer/intptr) 
  -> _void -> img)

Here the '-> _void' specifies the value returned as function value from 
C, and ->img indicates what the Racket openGL bindig s to return as to 
the Racket calling program.

But the old binding instead used
 ( (target : _int32)
   (level : _int32)
   (img : _pointer/intptr)
  -> _void)

In other words, it ignored the fact that img is used as an output 
parameter.

Now what should I do with this?  As I said there are very many such 
functions.  It's not an isolated case.

Are all these glGet functions simply something that never happened to 
get used in Racket code so no one noticed the discrepancy?
Is there some idiom in Racket programming where all this just works 
anyway?
Is there some efficency reason for not recognising output parameters?
Do they parhaps cause new storage allocation every time they are called?

I would prefer that other Racket code that uses the old binding not have 
to be rewritten for the new.  I'd like the new binding to be both 
correct and compatible insofar as compatibility matters.

And I would very much prefer my binding to follow spec on both the 
openGL front and the Racket front.

Or maybe I should call the new binding something else, like opengl3, 
so that old code can use old bindings and new code the new.
That would be touble for those using old libraries who also want to use 
ew features.

And I've encountered a few cases where I think the old binding is just 
wrong.

I would appreciate advice on these matters from those with more Racket 
or more openGL experience.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20200731210527.lrbk4sajudjuivck%40topoi.pooq.com.

[racket-users] Re: Racket CS release plan

[wanp...@gmail.com]

I noticed that the size of the CS version is 244% compare to BS 
version. Wondering why it became so large. Does that mean Chez Scheme 
runtime/vm 100 MB larger than the original one?

Racket Mac OS X
  64-bit Intel 116.7 MB SHA1: 521b5a264afcfb3f390afacc682987268f650a25

Racket CS Mac OS X
  64-bit Intel 285.8 MB SHA1: 060f311fc6621c5797a62f98b743499fa4277793

https://pre-release.racket-lang.org/

Matthew Flatt 在 2020年7月30日 星期四下午8:46:42 [UTC+8] 的信中寫道：

> With the improvements in the upcoming v7.8 release, Racket CS provides
> all of the functionality of Racket BC (the current default
> implementation). Also, end-to-end performance measurements
> increasingly favor Racket CS. For example, Racket CS now builds a
> distribution slightly faster and in slightly less memory than Racket
> BC:
>
> https://build-plot.racket-lang.org/
>
> https://build-plot-cs.racket-lang.org/
>
> It's time to consider shifting the Racket release to use Racket CS as
> the default --- while Racket BC will remain an option for a long time
> to come.
>
> We (the release managers) propose the following rule to trigger the
> switch to Racket CS in the default distribution:
>
> Between this release and the next, if Racket CS testing and use
> uncover no bugs that are more serious than ones typically discovered
> for Racket BC, then Racket CS becomes the default for the next
> release.
>
> At the earliest, the switch would happen with the release *after* the
> soon-to-be-released v7.8. Our expectation is that the switch would
> happen with the next release (in October), but we'll see how that
> expectation lines up with reality.
>
> This rule is somewhat subjective, in that "more serious" and "typical"
> are in the eye of the beholder, but we keep a close eye on the results
> of the pkg-build service as well as Racket tests. We'll also count
> performance problems as bugs, so Racket CS must not have substantial
> known performance problems relative to Racket BC.
>
> Jay, John, Matthew, Matthias, Robby, Ryan, Sam, and Vincent
> (the release managers)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/7f6672e4-449d-4bda-b737-a45e9ee8dc97n%40googlegroups.com.

Re: [racket-users] Does Racket interpreter exist?

[zeRusski]

Thank you Arthur. Indeed Lisp in Small Pieces cites this paper in the 
chapter about fast interpreters among two others but sadly in French :)

On Thursday, 30 July 2020 15:45:01 UTC+1, Arthur Nunes-Harwitt wrote:
>
> Hi, 
>
>While you're enumerating these possibilities, I think it's worthwhile 
> to 
> mention a technique related to the FORTH implementation technique: Marc 
> Feeley style compilation (see "Using Closures For Code Generation" in 
> Computer Language Vol 12 No 1 pages 47-66). This idea is also mentioned in 
> SICP. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/569aa81d-3ba4-49a3-8d44-7d005cebcae6o%40googlegroups.com.

Re: [racket-users] namespaces + eval + reader

[Jens Axel Søgaard]

Den fre. 31. jul. 2020 kl. 04.01 skrev Shriram Krishnamurthi <
shri...@gmail.com>:

>  want to create a namespace for (say) the BSL language in DrRacket.
> Critically, I need the *reader* to be aligned with this language.
> Otherwise, small semantic discrepancies creep in.

...

> The expressions being `eval`ed are coming from a file, via `read`. I have
> the freedom to change things there.
>
I think you can use the htdp-reader directly:

https://github.com/racket/htdp/blob/master/htdp-lib/lang/htdp-reader.rkt

If not, you can at least see how the reader is configured in lines 46-48:

[read-case-sensitive (lookup 'read-case-sensitive table)]
[read-decimal-as-inexact #f]
[read-accept-dot #f] /Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CABefVgwg%3DkeRRQM2W9PDHXCvgcFneuquXuqnvyqa5BqaG0Zbpg%40mail.gmail.com.