Re: [racket-users] Re: Question about Racket design philosophy: returning (void)

[Gustavo Massaccesi]

For debuging I like

  (define (show x)
(display x)
x)

  (define (noshow x)
x)

For example in

  (define (average x)
(/ (+ (car x) (show (cdr x))) 2))

noshow is useful to turn on/off them fast.

But this is different from the convension of << in the streams of C, that
return the stream instead of the value, something like

  (<< (<< cout "Hello ") "Word!")

Gustavo

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] deprecating a package (and redirecting users to new version)

[Stephen De Gabrielle]

Hi,

What is the best way to deprecate a package on pkgs.racket-lang.org ?

Is there a way to redirect users to a new package (with a different name)?

Kind regards,

Stephen

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] not worth shrinking language to ../base?

['John Clements' via Racket Users]

I did a mini-experiment today, and was surprised.

Specifically, my guess was that changing the language of a file from 

#lang typed/racket

to

#lang typed/racket/base

and adding the newly-necessary requires:

(require racket/match
 racket/list
 racket/math)

… would result in faster compile times and smaller .zo files. Neither of these 
was true; compilation time rose slightly, from about 3.35 seconds to about 3.45 
seconds, and the .zo file went from about 58K up to about 59K. 

I also tried to trim the imports by using ‘only-in’ and a local definition for 
‘natural’, leading to this replacement for the require:

(require racket/match
 (only-in racket/list first rest second third fourth group-by)
 ;racket/math
 )

(define natural? exact-nonnegative-integer?)

… but the compilation time stayed about the same, and the generated .zo was 
about the same size.

I then checked on startup times for the compiled file, and they were apparently 
the same (0.57 seconds) for both versions. 

So, my question is this: does it actually make sense to spend time stripping 
down files from typed/racket to typed/racket/base? 

A related question with a possibly totally different answer: what about time 
spent stripping files down from racket to racket/base? Is this also not worth 
it?

Thanks!

John



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Experience with REST APIs in Racket

['Paulo Matos' via Racket Users]

Peter,

Thank you very much for the reference to the vignette and simple-http
package. simple-http seems to make it quite straightforward, therefore I
will be giving it a go.

Paulo Matos

On 12/04/18 17:28, Peter Schmiedeskamp wrote:
> Darren Newton's simple-http library
> (https://github.com/DarrenN/simple-http) vastly eases working with REST
> APIs and is very much modeled off of the http client libraries you'd
> expect to see in other language ecosystems.
> 
> For some quick, useful, and opinionated perspective on REST services, I
> like to point people to this vignette from the R
> community: 
> https://cran.r-project.org/web/packages/httr/vignettes/api-packages.html
> The httr package works similarly to the simple-http package in R.
> 
> As an aside, if any members of the academic Racket community are out
> there, I'd humbly submit that the R community would be an ideal place to
> start plundering if the goal were ever to grow the Racket ecosystem.
> While the R language itself can be a little idiosyncratic (it originally
> started as a bunch of Scheme macros I believe), the community is
> addressing longstanding challenges in creative, researched ways. When
> watching the Python and R data science communities, I find myself
> feeling that the Python community's comparative advantage is in being
> able to write code, while the R community's comparative advantage is in
> having the disposition to read about prior art before writing code.
> Occasionally both of those skills are manifest in the same place,
> producing truly great contributions like ggplot and dplyr (the httr
> package mentioned above was similarly well-researched and executed, but
> there's is much prior art). I can't help but look at the ggplot data
> visualization DSL and the dplyr data manipulation / RDBMS interaction
> DSL and think that Racket's facilities couldn't enable something even
> more powerful. If I had more time and computer science know-how, this
> would surely be my dream task.
> 
> Cheers,
> Peter
> 
> On Wednesday, April 11, 2018 at 11:36:50 AM UTC-7, Paulo Matos wrote:
> 
> Hi,
> 
> I am interested in developing a Racket wrapper for hetzner cloud rest
> api. This is a REST API defined in:
> https://docs.hetzner.cloud/
> 
> I however, have no experience with accessing REST APIs in racket much
> less developing one.
> 
> 1. Are there any examples out there of wrapping rest apis in racket?
> 2. If you look at how this is done in Python[1] as expected everything
> is an object. However, from what I generally see, libraries seem to
> rarely touch the racket object system (although I think it's great).
> So,
> I guess instead of having an object 'Client' to which you would do
> (send
> client login "username" "password"), is it generally preferable to have
> a (make-client ...), which you would follow with (client-login
> "username" "password")?
> 
> Any thoughts would be appreciated before I commit myself, only to find
> it goes against the racket way once I publish it. :)
> 
> [1] https://github.com/elsyms/hetznercloud-py/
> 
> -- 
> Paulo Matos
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Paulo Matos

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Experience with REST APIs in Racket

[Peter Schmiedeskamp]

Darren Newton's simple-http library 
(https://github.com/DarrenN/simple-http) vastly eases working with REST 
APIs and is very much modeled off of the http client libraries you'd expect 
to see in other language ecosystems.

For some quick, useful, and opinionated perspective on REST services, I 
like to point people to this vignette from the R 
community: 
https://cran.r-project.org/web/packages/httr/vignettes/api-packages.html 
The httr package works similarly to the simple-http package in R.

As an aside, if any members of the academic Racket community are out there, 
I'd humbly submit that the R community would be an ideal place to start 
plundering if the goal were ever to grow the Racket ecosystem. While the R 
language itself can be a little idiosyncratic (it originally started as a 
bunch of Scheme macros I believe), the community is addressing longstanding 
challenges in creative, researched ways. When watching the Python and R 
data science communities, I find myself feeling that the Python community's 
comparative advantage is in being able to write code, while the R 
community's comparative advantage is in having the disposition to read 
about prior art before writing code. Occasionally both of those skills are 
manifest in the same place, producing truly great contributions like ggplot 
and dplyr (the httr package mentioned above was similarly well-researched 
and executed, but there's is much prior art). I can't help but look at the 
ggplot data visualization DSL and the dplyr data manipulation / RDBMS 
interaction DSL and think that Racket's facilities couldn't enable 
something even more powerful. If I had more time and computer science 
know-how, this would surely be my dream task.

Cheers,
Peter

On Wednesday, April 11, 2018 at 11:36:50 AM UTC-7, Paulo Matos wrote:
>
> Hi, 
>
> I am interested in developing a Racket wrapper for hetzner cloud rest 
> api. This is a REST API defined in: 
> https://docs.hetzner.cloud/ 
>
> I however, have no experience with accessing REST APIs in racket much 
> less developing one. 
>
> 1. Are there any examples out there of wrapping rest apis in racket? 
> 2. If you look at how this is done in Python[1] as expected everything 
> is an object. However, from what I generally see, libraries seem to 
> rarely touch the racket object system (although I think it's great). So, 
> I guess instead of having an object 'Client' to which you would do (send 
> client login "username" "password"), is it generally preferable to have 
> a (make-client ...), which you would follow with (client-login 
> "username" "password")? 
>
> Any thoughts would be appreciated before I commit myself, only to find 
> it goes against the racket way once I publish it. :) 
>
> [1] https://github.com/elsyms/hetznercloud-py/ 
> -- 
> Paulo Matos 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Experience with REST APIs in Racket

['Paulo Matos' via Racket Users]

On 12/04/18 11:45, Jack Firth wrote:
> I think this is an area where Racket's ecosystem could be significantly
> improved. However, this would probably only be worth the investment for
> those developing on both the client and server side of multiple
> services. Do you have plans to develop your own HTTP service APIs in
> Racket as well?
> 

Maybe, I am still deciding what to do. I have in the past developed my
own HTTP service APIs with Flask in Python. Racket would have the
upper-hand here if it's relatively easy to learn and if the tools are
already there. I have looked yesterday at Jesse Alama's Server Racket
and he has a chapter on it so I might end up giving Racket a try.

> On Wednesday, April 11, 2018 at 11:36:50 AM UTC-7, Paulo Matos wrote:
> 
> Hi,
> 
> I am interested in developing a Racket wrapper for hetzner cloud rest
> api. This is a REST API defined in:
> https://docs.hetzner.cloud/
> 
> I however, have no experience with accessing REST APIs in racket much
> less developing one.
> 
> 1. Are there any examples out there of wrapping rest apis in racket?
> 2. If you look at how this is done in Python[1] as expected everything
> is an object. However, from what I generally see, libraries seem to
> rarely touch the racket object system (although I think it's great).
> So,
> I guess instead of having an object 'Client' to which you would do
> (send
> client login "username" "password"), is it generally preferable to have
> a (make-client ...), which you would follow with (client-login
> "username" "password")?
> 
> Any thoughts would be appreciated before I commit myself, only to find
> it goes against the racket way once I publish it. :)
> 
> [1] https://github.com/elsyms/hetznercloud-py/
> 
> -- 
> Paulo Matos
> 
> -- 
> 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
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Paulo Matos

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] IEEE 754 single precision float support

[George Neuner]

On 4/11/2018 7:03 PM, Philip McGrath wrote:
From one following along who knows fairly little about floating-point 
math (the Toronto/McCarthy paper looks very informative!):


On Tue, Apr 10, 2018 at 12:13 AM, George Neuner > wrote:


As Philip McGrath mentioned already, you can specify single
precision at least for input values ... but I think inexact (i.e.
floating point) math in Racket all is done at maximum hardware
precision and the result coerced back to the input precision if
possible.  For purposes of numerical analysis, that is not the
same as performing all operations at the input precision.


Is this confirmed to be what Racket does?


Yes and no.  I did not intend to attribute the issue to Racket - it's 
really a hardware issue.



Racket follows the modern convention of using the CPU's SIMD hardware to 
do FP math.  SIMD hardware (typically) does not widen results, so you 
get back the same precision you put in ... but internally there was an 
intermediate double-wide mantissa computed that maybe didn't fit into 
the output.


   You see:
  single X single -> single
  double X double -> double

   The hardware does:
  single X single -> double -> single
  double X double -> quad -> double

If the result overflows or underflows, you get INF or zero rather than a 
correct but wider answer.



If you are trying to check your FPU using software emulations:  i.e. 
bigint-rationals or bigfloats, then you need to know exactly how the 
computations are being done.  More on that below.




Modern x86 have both SIMD and x87 co-processor.  The SIMD unit was 
introduced on the Pentium III with single precision and was expanded to 
double precision on the Pentium IV and later.   The modern convention to 
use the SIMD unit exclusively leaves the x87 idle all the time.  There's 
a good reason for it - the SIMD unit is faster because it is more 
tightly integrated ... the x87 originally was a separate chip and even 
though it now is integrated, there still is a performance penalty for 
having to use the co-processor interface protocol.  And the SIMD unit 
produces more consistent results [see below].


The x87 and the SIMD unit do not work the same way, and they may produce 
different results from the same calculation.  The SIMD unit offers 
single or double precision.  The x87 offers a 3rd choice: extended 
precision - an 80 bit format that has 64 bits of mantissa [vs 53 bits in 
an IEEE double].  Extended precision is the default mode of the x87.


The x87 always computes a full (64-bit mantissa) extended precision 
result before rounding AT the selected precision and then truncating TO 
the selected precision [which clears any trailing bits in the 
register].   In the SIMD unit, precision is specified by the 
instruction: the registers are (virtually) subdivided into slots which 
are sized appropriately for the specified precision [no trailing bits], 
and all slots are computed in parallel TO the specified precision.


Very different.  And potentially confusing if you are expecting to get 
bit-identical results.



GPU or DSP calculations can be even more challenging to check with a CPU 
because their FPU hardware often is very different - not just not IEEE 
compliant, but sometimes not even close.




Aside for Dale:
If you're on x86, and you find that rationals or bigfloats are too slow, 
the x87 may offer a faster way to your more precise calculations.
see: 
https://docs.racket-lang.org/reference/extflonums.html?q=math%2Fextflonum#%28tech._extflonum%29




If so, are the observable differences vs. the operations working at 
the input precision because of error and error propagation


Yes.  Consider what happens at the limits of the selected precision.  
Switching to C for a moment, consider:


   float X = FLT_MAX;
   float Y = FLT_MAX - 4;

   float Z = (X + Y) / 2;
   float W = (float) (((double) X + Y) / 2);

Z gets compiled something like:
   float t1 = X + Y
   float t2 = t1 / 2
   Z = t2

W get compiled something like:
    double t1 = (double) X
    double t2 = (double) Y
    double t3 = t1 + t2
    double t4 = t3 / 2
    W = (float) t4

In the case of Z  the temporaries are single precision, so (X + Y) 
overflows to INF and that carries forward through the rest of the 
calculation.  In the case of W, the temporaries are double precision, so 
the calculation of (X + Y) succeeds and W gets the right answer.


Now you don't see these temporaries [except maybe by compiling in debug 
mode and specifying "consistent" floating point], but they exist in the 
FPU registers.   The actual answers you would get depend on the FPU 
hardware and how the code was compiled.


E.g., on x87, keeping the temporaries in registers, both Z and W would 
get the same (right) answer if the FPU were in double or extended 
precision mode even though the compiler thinks the temporaries are 
single precision values.   But if the 

[racket-users] Re: Experience with REST APIs in Racket

[Jack Firth]

I think this is an area where Racket's ecosystem could be significantly 
improved. However, this would probably only be worth the investment for 
those developing on both the client and server side of multiple services. 
Do you have plans to develop your own HTTP service APIs in Racket as well?

On Wednesday, April 11, 2018 at 11:36:50 AM UTC-7, Paulo Matos wrote:
>
> Hi, 
>
> I am interested in developing a Racket wrapper for hetzner cloud rest 
> api. This is a REST API defined in: 
> https://docs.hetzner.cloud/ 
>
> I however, have no experience with accessing REST APIs in racket much 
> less developing one. 
>
> 1. Are there any examples out there of wrapping rest apis in racket? 
> 2. If you look at how this is done in Python[1] as expected everything 
> is an object. However, from what I generally see, libraries seem to 
> rarely touch the racket object system (although I think it's great). So, 
> I guess instead of having an object 'Client' to which you would do (send 
> client login "username" "password"), is it generally preferable to have 
> a (make-client ...), which you would follow with (client-login 
> "username" "password")? 
>
> Any thoughts would be appreciated before I commit myself, only to find 
> it goes against the racket way once I publish it. :) 
>
> [1] https://github.com/elsyms/hetznercloud-py/ 
> -- 
> Paulo Matos 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.