Re: [racket-users] "Unbound Identifier" (Lists)

[David Storrs]

On Thu, Feb 25, 2021 at 12:43 PM IF Karona  wrote:

> Your solution is so elegant. Thank you!
>
> >> PS  Do I have the salutation right?  Is it 'Hello, IF' or 'Hello,
> Karona'? <<
>
> You may call me Karona. Thank you for asking. :)
>
> Karona
>
>
Cool, good to know and I'm glad you liked the solution.

Thinking more about it, it would be better to pull the match out in order
to have clearer code, and add a way to end the loop. Something like this:

#lang racket
(struct message (str sender recipient) #:transparent)
; This returns a list consisting of the message that we are sending

; out followed by the message that the participant posted. It will

; be appended to the history.

(define (say m str)
  (displayln str)
  (list (message str "me" "participant") m))

(define (find-response input history)
  (match (message-str input)
[(regexp #rx"(?i:Hello,* world!)")
 (say input "I would not know about the rest of the world, but I can
hear \
you just fine.")]
[(regexp #px"(?i:I( am|'m) learning how to program in Racket,* world!)")
 (say input "Racket is a great language, and it is lovely that you are
\
learning it, but does literally everyone need to know?")]
[(regexp #px".*,+\\s*world!")
 (say input "Did the whole world really need to hear that?")]
["DEBUG" (pretty-print history) '()]
[else (say input "I didn't understand that")]))

(let loop ([history '()])
  (display "Input: ")
  (define input  (message (read-line (current-input-port) 'any)
"participant" "me"))
  (display "Chatbot: ")
  (if (equal? (message-str input) "DONE")
  (begin (displayln "Bye!") (pretty-print history))
  (loop (append (find-response input history) history


> On Wed, Feb 24, 2021 at 11:14 PM David Storrs 
> wrote:
>
>> Hi IF,
>>
>> I think this is what you want.  You were right about the issue -- you
>> were consing onto the history list but then immediately throwing away the
>> result because it wasn't modifying the original history value.
>>
>> #lang racket
>>
>> (struct message (str sender recipient) #:transparent)
>> ; This returns a list consisting of the message that we are sending
>>
>> ; out; followed by the message that the participant posted. It will
>>
>> ; be appended; to the history.
>>
>> (define (say m str)
>>   (displayln str)
>>   (list (message str "me" "participant") m))
>>
>> ; start off with an empty history
>> (let loop ([history '()])
>>   (display "Input: ")
>>   (define input  (message (read-line (current-input-port) 'any)
>> "participant" "me"))
>>   (display "Chatbot: ")
>>   (loop
>>(append
>> (match (message-str input)
>>   [(regexp #rx"(?i:Hello,* world!)")
>>(say input "I would not know about the rest of the world, but I
>> can hear \
>> you just fine.")]
>>   [(regexp #px"(?i:I( am|'m) learning how to program in Racket,*
>> world!)")
>>(say input "Racket is a great language, and it is lovely that you
>> are \
>> learning it, but does literally everyone need to know?")]
>>   [(regexp #px".*,+\\s*world!")
>>(say input "Did the whole world really need to hear that?")]
>> ; if your input is DEBUG then it will print out the history but not add
>> to it
>>   ["DEBUG" (pretty-print history) '()]
>> ; if you type something unrecognized it will say so
>>   [else (say input "I didn't understand that")])
>> history))
>>   (loop))
>>
>>
>> PS  Do I have the salutation right?  Is it 'Hello, IF' or 'Hello, Karona'?
>>
>>
>>
>> On Wed, Feb 24, 2021 at 6:21 PM IF Karona  wrote:
>>
>>> Thank you!
>>>
>>> I can get the code that follows to run, but the chatbot never replies. I
>>> surmise this is because lists are not mutable.
>>>
>>> With the background I have the most obvious way forward would be to use
>>> an array instead of a list, but that does not strike me as the best
>>> approach to take while trying to learn functional programming.
>>>
>>> Is there a better way through this?
>>>
>>> ;example.rkt
>>>
>>> #lang racket
>>>
>>> (require racket/match)
>>>
>>> (struct message (str sender recipient))
>>>
>>> (define chat-history (list (message "" "" "")))
>>>
>>> (define (say m)
>>>   (cons m chat-history))
>>>
>>> (define (log m)
>>>   (cons m chat-history))
>>>
>>> (let loop ()
>>>   (display "Input: ")
>>>   (define input (message (read-line (current-input-port) 'any)
>>> "participant" "me"))
>>>   (define str (message-str input))
>>>   (log input)
>>>
>>>   (cond
>>>
>>> [(regexp-match #px"(?i:Hello,* world!)" str)
>>>  (say (message "I would not know about the rest of the world, but I
>>> can hear \
>>> you just fine." "me" "participant"))]
>>>
>>> [(regexp-match #px"(?i:I( am|'m) learning how to program in Racket,*
>>> world!)" str)
>>>  (say (message "Racket is a great language, and it is lovely that
>>> you are \
>>> learning it, but does literally everyone need to know?" "me"
>>> "participant"))]
>>>
>>> [(regexp-match #px".*,+\\s*world!" str)
>>>  (say (message "Did the whole world 

Re: [racket-users] [racket users] list question

[Kevin Forchione]

> On Feb 25, 2021, at 10:12 AM, Norman Gray  wrote:
> 
> 
> I think this is called 'zip', or a convolution [1].  The variant you describe 
> is (effectively) with circular lists, but seems to be the same principle.
> 
> ...and I see that, with that name in hand, SRFI/1 does indeed have a zip 
> procedure, which works with circular lists.

Thanks, Norman! Looks like “zip” is the right name for the general process, and 
now that I can browse the docs for it there seems to be several flavors in 
various library modules, depending on creator intention.  I’ve generalized mine 
a bit to fit intention and some of theirs. 

(define/contract (zip #:length (len max) . lsts)
  (->* () (#:length (or/c procedure? natural?)) #:rest (listof list?) (listof 
list?))
  (define (loop cnt (acc empty))
(cond
  [(zero? cnt) acc]
  [else
   (define n (sub1 cnt))
   (loop n (cons (map (λ (lst) (list-ref lst (modulo n (length lst 
lsts) acc))]))
  (loop (cond
  [(procedure? len)
   (apply len (map length lsts))]
[else len])))

Kevin

-- 
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/650A2841-B8F8-4802-9116-7AB9876EA901%40gmail.com.

Re: [racket-users] "Unbound Identifier" (Lists)

[IF Karona]

Your solution is so elegant. Thank you!

>> PS  Do I have the salutation right?  Is it 'Hello, IF' or 'Hello,
Karona'? <<

You may call me Karona. Thank you for asking. :)

Karona

On Wed, Feb 24, 2021 at 11:14 PM David Storrs 
wrote:

> Hi IF,
>
> I think this is what you want.  You were right about the issue -- you were
> consing onto the history list but then immediately throwing away the result
> because it wasn't modifying the original history value.
>
> #lang racket
>
> (struct message (str sender recipient) #:transparent)
> ; This returns a list consisting of the message that we are sending
>
> ; out; followed by the message that the participant posted. It will
>
> ; be appended; to the history.
>
> (define (say m str)
>   (displayln str)
>   (list (message str "me" "participant") m))
>
> ; start off with an empty history
> (let loop ([history '()])
>   (display "Input: ")
>   (define input  (message (read-line (current-input-port) 'any)
> "participant" "me"))
>   (display "Chatbot: ")
>   (loop
>(append
> (match (message-str input)
>   [(regexp #rx"(?i:Hello,* world!)")
>(say input "I would not know about the rest of the world, but I can
> hear \
> you just fine.")]
>   [(regexp #px"(?i:I( am|'m) learning how to program in Racket,*
> world!)")
>(say input "Racket is a great language, and it is lovely that you
> are \
> learning it, but does literally everyone need to know?")]
>   [(regexp #px".*,+\\s*world!")
>(say input "Did the whole world really need to hear that?")]
> ; if your input is DEBUG then it will print out the history but not add to
> it
>   ["DEBUG" (pretty-print history) '()]
> ; if you type something unrecognized it will say so
>   [else (say input "I didn't understand that")])
> history))
>   (loop))
>
>
> PS  Do I have the salutation right?  Is it 'Hello, IF' or 'Hello, Karona'?
>
>
>
> On Wed, Feb 24, 2021 at 6:21 PM IF Karona  wrote:
>
>> Thank you!
>>
>> I can get the code that follows to run, but the chatbot never replies. I
>> surmise this is because lists are not mutable.
>>
>> With the background I have the most obvious way forward would be to use
>> an array instead of a list, but that does not strike me as the best
>> approach to take while trying to learn functional programming.
>>
>> Is there a better way through this?
>>
>> ;example.rkt
>>
>> #lang racket
>>
>> (require racket/match)
>>
>> (struct message (str sender recipient))
>>
>> (define chat-history (list (message "" "" "")))
>>
>> (define (say m)
>>   (cons m chat-history))
>>
>> (define (log m)
>>   (cons m chat-history))
>>
>> (let loop ()
>>   (display "Input: ")
>>   (define input (message (read-line (current-input-port) 'any)
>> "participant" "me"))
>>   (define str (message-str input))
>>   (log input)
>>
>>   (cond
>>
>> [(regexp-match #px"(?i:Hello,* world!)" str)
>>  (say (message "I would not know about the rest of the world, but I
>> can hear \
>> you just fine." "me" "participant"))]
>>
>> [(regexp-match #px"(?i:I( am|'m) learning how to program in Racket,*
>> world!)" str)
>>  (say (message "Racket is a great language, and it is lovely that you
>> are \
>> learning it, but does literally everyone need to know?" "me"
>> "participant"))]
>>
>> [(regexp-match #px".*,+\\s*world!" str)
>>  (say (message "Did the whole world really need to hear that?" "me"
>> "participant"))]
>>
>> [else (say (message "Did you really just say something without
>> addressing the \
>> world? I am so proud of you! :,)" "me" "participant"))])
>>
>>   (define head (first chat-history))
>>   (define response (message-str head))
>>   (printf "Chatbot: ~a\n" response)
>>   (loop))
>>
>> On Wed, Feb 24, 2021 at 3:11 PM George Neuner 
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> Presumably you are using 'head' to get the first element of a list.
>>> However, there is no function 'head' for lists.
>>> see:  https://docs.racket-lang.org/reference/pairs.html
>>>
>>> Try using 'first' and 'rest' instead of 'head' and 'tail'.
>>>
>>> George
>>>
>>>
>>> On 2/24/2021 3:55 PM, IF Karona wrote:
>>>
>>> Hi everyone,
>>>
>>> After trying to implement some changes Sage suggested (all errors are my
>>> own), I am now encountering the following message (courtesy of DrRacket):
>>>
>>> "head: unbound identifier in: head"
>>>
>>> Could someone help me find a fix?
>>>
>>> As before, I welcome suggestions on how to better do this the functional
>>> programming way.
>>>
>>> Karona
>>>
>>> ;example.rkt
>>>
>>> #lang racket
>>>
>>> (require racket/match)
>>>
>>> (struct message (str sender recipient))
>>>
>>> (define (say chat-history m)
>>>   (cons m
>>> chat-history))
>>>
>>> (define (log chat-history m)
>>>   (cons m
>>> chat-history))
>>>
>>> (let loop ()
>>>   (display "Input: ")
>>>   (define input (message (read-line (current-input-port) 'any)
>>> "participant" "me"))
>>>   (define str (message-str input))
>>>   (log chat-history input)
>>>
>>>   (cond
>>>

Re: [racket-users] [racket users] list question

[Norman Gray]

Kevin, hello.

On 25 Feb 2021, at 17:07, Kevin Forchione wrote:

As you can see each element of the sublist corresponds to the list-ref 
of the modulo n (length sublist) as n proceeds from 0 to  some maximum 
value. I’ve created a function that does exactly this, but … 
I’ve no idea what this process might be called. As they say, the 
naming of cats, and all that.Does this sort of mapping have a formal 
name?


I think this is called 'zip', or a convolution [1].  The variant you 
describe is (effectively) with circular lists, but seems to be the same 
principle.


...and I see that, with that name in hand, SRFI/1 does indeed have a zip 
procedure, which works with circular lists.


[1] https://en.wikipedia.org/wiki/Convolution_(computer_science)

Best wishes,

Norman


--
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

--
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/7F1C9263-EA6A-4B5F-A0CF-15A5725E1EAE%40glasgow.ac.uk.

[racket-users] [racket users] list question

[Kevin Forchione]

Hi guys,
I’m trying to find out what this process may be called. Suppose you have lists 
of various lengths:

‘(A B C D E F)
‘(1 2)
‘(3 4 5)

And you want tho produce the following:

'((A 1 3) (B 2 4) (C 1 5) (D 2 3) (E 1 4) (F 2 5) (A 1 3) (B 2 4) (C 1 5) (D 2 
3) ...)

As you can see each element of the sublist corresponds to the list-ref of the 
modulo n (length sublist) as n proceeds from 0 to  some maximum value. I’ve 
created a function that does exactly this, but … I’ve no idea what this process 
might be called. As they say, the naming of cats, and all that.Does this sort 
of mapping have a formal name?

Thanks!
Kevin

-- 
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/C34265FD-5370-47BD-B5AE-9FC75BEEFA8D%40gmail.com.

Re: [racket-users] the future of #lang web-server

[Jay McCarthy]

That's a cute idea. We do something like that already when sharing the
serialized continuation with the world, but Racket could conceivably do
that when it `read`/`write`s things, although it would be very odd.

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.


On Thu, Feb 25, 2021 at 3:28 AM jackh...@gmail.com 
wrote:

> Could you cryptographically sign the serialized form or something like
> that?
>
> On Monday, February 22, 2021 at 8:59:29 AM UTC-8 jay.mc...@gmail.com
> wrote:
>
>> On Sun, Feb 21, 2021 at 2:35 PM je...@lisp.sh  wrote:
>> >
>> > #lang web-server is brilliant. This #lang is, in my view, a really
>> excellent example of Racket's take on language-oriented programming. I find
>> that the performance of continuations is just fine, given my limited use of
>> them, and after a while you get used to the limitations and just program
>> around them.
>>
>> Thanks, a lot of people contributed a ton to it, specifically: Greg
>> Pettyjohn, John Clements, Joe Marshall, Shriram Krishnamurthi,
>> Matthias Felleisen.
>>
>> >
>> > One thing that always bothers me about #lang web-server, though, is
>> that there are a lot of provisos in the documentation. I'm talking about
>> section 3.2, "Usage Considerations", of
>> https://docs.racket-lang.org/web-server/stateless.html, in the part
>> after "However, there are some considerations you must make." Here a couple
>> of questions:
>> >
>> > + " [#lang web-server] will create an immense number of lambdas and
>> structures your program did not normally contain. The performance
>> implication of this has not been studied with Racket."
>> >
>> > This seems to me like an interesting research question. Has this
>> question been taken up? I've tried taking a look on Google Scholar for any
>> follow-up. I looked at citations of Jay's "Automatically RESTful web
>> applications" and "The two-state solution: native and serializable
>> continuations accord", but nothing stuck out to me (...which is not to say
>> that there may have missed something).
>>
>>
>> I never did any more research about this. I think you could take the
>> traditional Scheme benchmarks ---
>>
>> https://github.com/racket/racket/tree/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common
>> --- and add `#lang web-server` to the top and see what happens.
>>
>> >
>> > + Some limitations of #lang web-server seem don't seem obviously
>> necessary, at least to someone who's not very familiar with the precise
>> details of the underlying program transformations. You get used to them,
>> but you wonder if there's some accessible world in which they work. For
>> example: "You may not use parameterize, because parameterizations are not
>> serializable." Is that inherently so (that is, there's no way around that,
>> no matter how clever you tweak the program transformations on which #lang
>> web-server rests), or is that just a conequence of the particular approach
>> taken (maybe it's possible, but no one has done it yet). Has there been any
>> fresh thinking about these limitations?
>>
>> In some sense, everything is possible, because we can just change the
>> way the VM works... the existing `#lang web-server` is designed to
>> never require modifications down there. In the case of `parameterize`,
>> the problem is a matter of security. Consider the following program:
>>
>> ```
>> #lang racket
>> (define p (make-parameter #t))
>> (define (launch-the-missiles!)
>> (when (p) .))
>> (define (run-code-downloaded-from-youtube f)
>> (parameterize ([p #f]) (f)))
>> ```
>>
>> We don't want the code from YouTube to be able to launch the missiles.
>> Suppose that parameterizations were serializeable, then the YouTube
>> code could be something like:
>>
>> ```
>> (lambda ()
>> (call-with-parameterization
>> (read (with-input-string (hack-the-planet (with-output-to-string
>> (lambda () (write (current-parameterization)
>> launch-the-missiles!))
>> ```
>>
>> where `hack-the-planet` changes the `#f` to `#t`. That's why you can't
>> inspect parameterizations or enumerate the keys in a continuation mark
>> set.
>>
>> In general, all of the limitations of `#lang web-server` are because
>> of things like this.
>>
>> Jay
>>
>> --
>> Jay McCarthy
>> Associate Professor @ CS @ UMass Lowell
>> http://jeapostrophe.github.io
>> Vincit qui se vincit.
>>
> --
> 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/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [racket-users] Bit Scan Reverse in Racket

[Dominik Pantůček]

On 25. 02. 21 10:01, Jens Axel Søgaard wrote:
> Try integer-length.
> 
> https://docs.racket-lang.org/reference/generic-numbers.html?q=integer-length#%28def._%28%28quote._~23~25kernel%29._integer-length%29%29

Oh, I completely missed this one. Thank you!!!

> 
> I don't know how it is implemented.

And now I do. On CS it is implemented in terms of fxlength, which is a
SW implementation, but still an order of magnitude faster than pure
Racket implementation.

So for my project, integer-length is an improvement I wanted. But the
general question remains. Instead of almost 100 instructions, it could
be just one or two. I'll look into it later on if no-one else finds it
interesting enough to fiddle with cpnanopass.ss and x86_64.ss ;-)


Cheers,
Dominik

-- 
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/ff8da3ed-3fee-5c4c-11f2-eecb086fd60e%40trustica.cz.

[racket-users] ACM Workshop on Functional Art, Music, Modelling and Design - Call for Papers, Demos, and Performances

[Michael Sperber]

===
  7th ACM SIGPLAN International Workshop on
 Functional Art, Music, Modelling and Design
(FARM)
   Call for Papers, Demos, and Performance
   Virtual, 27th August 2021
  Deadlines:
   May 15 (Papers & Demos)
June 13 (Performances
   https://functional-art.org/2021
===

Key Dates
=

Papers and Demos:
Paper submission deadline   May 15
Author notification June 5
Camera readyJune 26
WorkshopAugust 27

Performances:
Performance submission deadline  June 13
Performance notification June 26

Call for Papers
===

After an 2020 online edition restricted to the performance session,
the ACM SIGPLAN International Workshop on Functional Art, Music,
Modelling and Design (FARM) will also be held online in 2021 but open
to all tracks (paper, demo and performance). Pursuing its mission,
this 9th workshop aims to bring together people who are harnessing
functional techniques in the pursuit of creativity and artistic
expression.

FARM encourages submissions from across art, craft, and design,
including textiles, visual art, music, 3D sculpture, animation, GUIs,
video games, 3D printing and architectural models, choreography,
poetry, and even VLSI layouts, GPU configurations, or mechanical
engineering designs. Theoretical foundations, language design,
implementation issues, and applications in industry or the arts are
all within the scope of the workshop.

In addition to the main workshop, FARM hosts a traditional evening of
performances. Thus, this call encompasses both papers/demos for the
workshop (and its published proceedings) as well as performance
proposals for the evening’s event. Authors are invited to make a
single submission for each. Authors may submit both a paper/demo and
performance proposal, but the submissions will be considered
independently.

Submission
==

We welcome submissions from academic, professional, and independent
programmers and artists. Submissions are accepted via the Submission
page on Easychair:

https://easychair.org/conferences/?conf=farm2021

Paper proposals
===

Paper submissions are invited in three categories:

- Original research
- Overview / state of the art
- Technology tutorial (especially tools and environments for distributed 
artistic workflow)

All submissions must propose an original contribution to the FARM
theme. FARM is an interdisciplinary conference, so a wide range of
approaches are encouraged. An original paper should have 5 to 12
pages, be in portable document format (PDF), and use the ACM SIGPLAN
style guides and ACM SIGPLAN template (using the SIGPLAN
sub-format). Accepted papers will be published in the ACM Digital
Library as part of the FARM 2021 proceedings.

Authors are encouraged to submit auxiliary material for publication
along with their paper (source code, data, videos, images, etc.);
authors retain all rights to the auxiliary material.

Demo proposals
==

Demo proposals should describe a demonstration to be given at the FARM
workshop and its context, connecting it with the themes of FARM. A
demo could be in the form of a short (1020 minute) tutorial,
presentation of work-in-progress, an exhibition of some work, or even
a performance. Demo proposals should be in the form of an extended
abstract (500 to 2000 words). A demo proposal should be clearly marked
as such, by prepending “Demo Proposal:” to the title and proposed to
the ‘paper’ track. Demo proposals will be published on the FARM
website.

Performance proposals
==

FARM seeks proposals for performances which employ functional
programming techniques, in whole or in part. We invite a diverse range
of functionally-themed submissions including music, video, dance, and
performance art. Both live performances and fixed-media submissions
are welcome. We encourage both risk-taking proposals that push forward
the state of the art and refined presentations of highly developed
practice. Performances will be held online.

Performance proposals should be emailed to
performa...@functional-art.org, and must include: a description of the
performance (please be as specific as possible), an explanation of the
use of functional programming in the work, and a list of technical
requirements. All proposals should be supported by a link to an audio
or video example (YouTube, Vimeo, Bandcamp, etc.).

Important dates/deadlines
=

Submission Deadline: May, 15th
Author Notification: June, 5th
Performance Submission Deadlione: June 13th
Camera Ready: June 26th
Performance Notification: June 26
Workshop: August 27th

Authors take note
=

For 

Re: [racket-users] Bit Scan Reverse in Racket

[Jens Axel Søgaard]

Try integer-length.

https://docs.racket-lang.org/reference/generic-numbers.html?q=integer-length#%28def._%28%28quote._~23~25kernel%29._integer-length%29%29

I don't know how it is implemented.

/Jens Axel

Den tor. 25. feb. 2021 kl. 09.52 skrev Dominik Pantůček <
dominik.pantu...@trustica.cz>:

> Hello Racketeers,
>
> I'm slightly stuck with speeding up some calculations and the reason is
> that I need to compute the index of highest set bit in a number. So for
> 1 it is 0, for 2 it is 1, for 8 3, 1023 9 and 1024 10 ...
>
> The fastest Racket code I can come up with is as follows:
>
> (begin-encourage-inline
>   (define (highest-bit num)
> (let loop ((num num)
>(bit 0))
>   (if (unsafe-fx> num 0)
>   (loop (unsafe-fxrshift num 1)
> (unsafe-fx+ bit 1))
>   bit
>
> (Yes, it returns incorrect result for 0, but that must be checked
> elsewhere as the result cannot be defined for 0 anyway).
>
> However this is a single instruction operation on x86 (bsr) or two
> instruction operation (rbit and clz if I am not mistaken) on ARM. Dunno
> about PPC yet.
>
> I looked at CS internals a bit and although there is a "name collision"
> as the bsr mnemonics is used for ret (branch subroutine return?), it
> should be fairly easy to add something like fxbsr (-> fixnum? fixnum?)
> to Racket core.
>
> I also experimented with x64asm package but the results were even worse
> than the aforementioned tight loop (there is a lot of overhead in
> define-λ! generated functions).
>
> As the routine is typically called 40k-60k times per frame in my code
> (real-time rendering) it could really make a difference.
>
> Should I try to add it? How should it be named? What about BC?
>
> And more generic question - aren't there more similar operations that
> can be implemented efficiently on all supported CPUs that might be
> useful in general? Yes, I am aiming at SIMD as many of you know :)
> Especially with the expanded number of available FP registers to 8 on
> 64-bit x86 CS there surely is quite some potential to it.
>
>
> Cheers,
> Dominik
>
> --
> 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/a2a4fe83-877d-d7ed-4812-bd628c128659%40trustica.cz
> .
>


-- 
-- 
Jens Axel Søgaard

-- 
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/CABefVgwvxcsy1EN_W04fYUfp%2BGm2nbBdoeTEnD3UbKfCHcHyKw%40mail.gmail.com.

[racket-users] Bit Scan Reverse in Racket

[Dominik Pantůček]

Hello Racketeers,

I'm slightly stuck with speeding up some calculations and the reason is
that I need to compute the index of highest set bit in a number. So for
1 it is 0, for 2 it is 1, for 8 3, 1023 9 and 1024 10 ...

The fastest Racket code I can come up with is as follows:

(begin-encourage-inline
  (define (highest-bit num)
(let loop ((num num)
   (bit 0))
  (if (unsafe-fx> num 0)
  (loop (unsafe-fxrshift num 1)
(unsafe-fx+ bit 1))
  bit

(Yes, it returns incorrect result for 0, but that must be checked
elsewhere as the result cannot be defined for 0 anyway).

However this is a single instruction operation on x86 (bsr) or two
instruction operation (rbit and clz if I am not mistaken) on ARM. Dunno
about PPC yet.

I looked at CS internals a bit and although there is a "name collision"
as the bsr mnemonics is used for ret (branch subroutine return?), it
should be fairly easy to add something like fxbsr (-> fixnum? fixnum?)
to Racket core.

I also experimented with x64asm package but the results were even worse
than the aforementioned tight loop (there is a lot of overhead in
define-λ! generated functions).

As the routine is typically called 40k-60k times per frame in my code
(real-time rendering) it could really make a difference.

Should I try to add it? How should it be named? What about BC?

And more generic question - aren't there more similar operations that
can be implemented efficiently on all supported CPUs that might be
useful in general? Yes, I am aiming at SIMD as many of you know :)
Especially with the expanded number of available FP registers to 8 on
64-bit x86 CS there surely is quite some potential to it.


Cheers,
Dominik

-- 
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/a2a4fe83-877d-d7ed-4812-bd628c128659%40trustica.cz.

[racket-users] Re: When are rackunit tests delayed? (different between 7.8 and 8)

[jackh...@gmail.com]

The test-suite semantics in rackunit are complex, under-specified, and 
quite brittle. I recommend avoiding them entirely and sticking entirely to 
test cases and test-begin.

On Monday, February 22, 2021 at 10:19:04 PM UTC-8 William J. Bowman wrote:

> Below is an example that behaves "correctly", as in all tests run and are
> counted as failured or errors correctly, in Racket 7.8, but which crashes 
> in
> Racket 8.
>
> > #lang racket
> > 
> > (require
> > rackunit
> > rackunit/log)
> > 
> > (define (suite1)
> > (test-suite
> > ""
> > (test-begin
> > (check-not-equal? (error "actual") (error "expected")
> > 
> > (define (suite2)
> > (test-suite
> > ""
> > (check-not-equal? (error "actual") (error "expected"
> > 
> > (module+ test
> > (require rackunit/text-ui)
> > 
> > ;; Correctly counts the tests as errors in 7.8 and 8.0
> > (check-pred
> > integer?
> > (run-tests (suite1)))
> > 
> > ;; Counts the tests as errors in 7.8, but crashes in 8.0
> > (check-pred
> > integer?
> > (run-tests (suite2)))
> >
> > ;; Gets run in 7.8, but not in 8.0
> > (check-equal? 0 0))
>
> This has something to do with when test-suite delays a test, which seems
> inconsistent across the Racket versions.
> I'm not sure whether the problem was some undefined behaviour in 
> test-suite or
> not.
>
> I'm a bit confused about the semantics of test-suites and tests, since the
> documentation claims a test (unlike a check) is delayed, yet test-case and
> test-begin do not delay tests, while test-suite does produce a delayed 
> suite of
> tests.
> However, test-begin DOES seem to delay a test in the context of a 
> test-suite.
>
> I'd appreciate any insight.
>
> --
> William J. Bowman
>
>

-- 
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/73510d26-7405-4c0a-a0e3-1b06f77f3576n%40googlegroups.com.

Re: [racket-users] the future of #lang web-server

[jackh...@gmail.com]

Could you cryptographically sign the serialized form or something like that?

On Monday, February 22, 2021 at 8:59:29 AM UTC-8 jay.mc...@gmail.com wrote:

> On Sun, Feb 21, 2021 at 2:35 PM je...@lisp.sh  wrote:
> >
> > #lang web-server is brilliant. This #lang is, in my view, a really 
> excellent example of Racket's take on language-oriented programming. I find 
> that the performance of continuations is just fine, given my limited use of 
> them, and after a while you get used to the limitations and just program 
> around them.
>
> Thanks, a lot of people contributed a ton to it, specifically: Greg
> Pettyjohn, John Clements, Joe Marshall, Shriram Krishnamurthi,
> Matthias Felleisen.
>
> >
> > One thing that always bothers me about #lang web-server, though, is that 
> there are a lot of provisos in the documentation. I'm talking about section 
> 3.2, "Usage Considerations", of 
> https://docs.racket-lang.org/web-server/stateless.html, in the part after 
> "However, there are some considerations you must make." Here a couple of 
> questions:
> >
> > + " [#lang web-server] will create an immense number of lambdas and 
> structures your program did not normally contain. The performance 
> implication of this has not been studied with Racket."
> >
> > This seems to me like an interesting research question. Has this 
> question been taken up? I've tried taking a look on Google Scholar for any 
> follow-up. I looked at citations of Jay's "Automatically RESTful web 
> applications" and "The two-state solution: native and serializable 
> continuations accord", but nothing stuck out to me (...which is not to say 
> that there may have missed something).
>
>
> I never did any more research about this. I think you could take the
> traditional Scheme benchmarks ---
>
> https://github.com/racket/racket/tree/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common
> --- and add `#lang web-server` to the top and see what happens.
>
> >
> > + Some limitations of #lang web-server seem don't seem obviously 
> necessary, at least to someone who's not very familiar with the precise 
> details of the underlying program transformations. You get used to them, 
> but you wonder if there's some accessible world in which they work. For 
> example: "You may not use parameterize, because parameterizations are not 
> serializable." Is that inherently so (that is, there's no way around that, 
> no matter how clever you tweak the program transformations on which #lang 
> web-server rests), or is that just a conequence of the particular approach 
> taken (maybe it's possible, but no one has done it yet). Has there been any 
> fresh thinking about these limitations?
>
> In some sense, everything is possible, because we can just change the
> way the VM works... the existing `#lang web-server` is designed to
> never require modifications down there. In the case of `parameterize`,
> the problem is a matter of security. Consider the following program:
>
> ```
> #lang racket
> (define p (make-parameter #t))
> (define (launch-the-missiles!)
> (when (p) .))
> (define (run-code-downloaded-from-youtube f)
> (parameterize ([p #f]) (f)))
> ```
>
> We don't want the code from YouTube to be able to launch the missiles.
> Suppose that parameterizations were serializeable, then the YouTube
> code could be something like:
>
> ```
> (lambda ()
> (call-with-parameterization
> (read (with-input-string (hack-the-planet (with-output-to-string
> (lambda () (write (current-parameterization)
> launch-the-missiles!))
> ```
>
> where `hack-the-planet` changes the `#f` to `#t`. That's why you can't
> inspect parameterizations or enumerate the keys in a continuation mark
> set.
>
> In general, all of the limitations of `#lang web-server` are because
> of things like this.
>
> Jay
>
> --
> Jay McCarthy
> Associate Professor @ CS @ UMass Lowell
> http://jeapostrophe.github.io
> Vincit qui se vincit.
>

-- 
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/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com.