Re: [racket-users] side by side; scribble

[Marc Kaufmann]

Since you say that it requires dropping to the latex level, does it mean 
that doing a synchronization of scribble and other output (say, HTML or 
something else that doesn't require anything from outside scribble and 
racket) can be done directly? Essentially:

```
@title{Synchronize this!}

Can you synchronize this @racket[(range 5)]?
```

would update to show 

```
# Synchronize this!

Can you synchronize this '(0 1 2 3 4)?
```

and it would update it quickly when I change (range 5) to (range 4)? I may 
have misinterpreted what you said - but if I didn't, then I wasn't aware 
this was easily doable.

Cheers,
Marc

On Tuesday, January 29, 2019 at 2:01:37 PM UTC+1, Robby Findler wrote:
>
> In order to do that you'd need to drop down to the latex level and use 
> a package there to help you. There is information about how to do that 
> here: http://docs.racket-lang.org/scribble/config.html . Here is a 
> post about packages you could use: 
>
> https://tex.stackexchange.com/questions/308260/parallel-text-translation-including-the-same-double-parallel-heading-numbering
>  
>
> hth, 
> Robby 
>
> On Tue, Jan 29, 2019 at 5:09 AM > wrote: 
> > 
> > Can I do a side by side pdf using racket scribble? Imagine you have an 
> English text and want the Portuguese translation in the opposite column. If 
> yes, it brings another question, which is, can it be done with synchronized 
> paragraphs? 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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: updated Racket-on-Chez status

['Paulo Matos' via Racket Users]

On 30/01/2019 02:32, Alex Harsanyi wrote:
> I know the report explains the various cases where Racket CS is slower than
> Racket 7.1, but I would like to mention that these cases are very
> significant,
> at least in my case -- I mention this because the report recommends making
> Racket CS the default, which I am very concerned about:
> 
>> To maximize the maintenance benefits of Racket CS, it’s better to make it
>> the default Racket variant sooner rather than later
> 
> To understand the performance impact, below are the numbers for my
> application.  I mentioned this before [1] and I added some new timings
> to the
> Google Sheets Document [2].
> 
> * the total Travis build time (build + tests) is ~13 minutes using
> Racket 7.1
>   and it is 20 minutes, a 7 minute increase.
> 
> * the build time itself grows from 3.75 minutes in Racket 7.1 to 8.5 minutes
>   in Racket CS, a 5 minute increase.  My Edit-Compile-Run cycle is already
>   slow with Racket 7.1.
> 
> * even ignoring compile and load time, code sections which run after Racket
>   initialization and library loading indicate that the running time is
>   increased by 33% -- given that current execution time is several
> seconds to
>   several minutes in Racket 7.1, a 33% increase is very visible to the end
>   user.
> 
> As it stands now, the cases where RacketCS is slow have a significant impact
> on my application.  Do others see the same performance degradation in their
> applications?
> 

I am about to run some thorough tests and benchmarks on my app. Will
report back on this. Thanks for raising these issues.

-- 
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] Multipart HTTP requests

[Philip McGrath]

I've put up the code I mentioned for email-sending and a proxy server at
https://github.com/LiberalArtist/multipart-writing-examples As noted, these
are not general-purpose solutions to either of those problems—I know of a
bunch of cases I don't cover, and I basically only have to use these with
trusted input—so caveat utor! But hopefully they're useful. I'd be very
happy to contribute to this effort, as well: a proper multipart writing
library would go a long way to getting some of the little bits of code I've
produced into good enough shape to post as a package, enough so that I've
thought about tackling it myself.

On Tue, Jan 29, 2019 at 8:06 AM Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

> I see... yeah, I thought about going this route but the reason it didn't
> seem particularly "robust" to me is that I would have to read the entire
> object into memory at once before passing it in as bytes.  IMO it would
> be better to have the option to provide ports with file data so the data
> could be streamed in without reading the whole data into memory.
>

This is one of the things you'd definitely want in a library that I haven't
dealt with, because in all of my cases I already have all the data in
memory anyway.

However that would, I still think, require being able to access the
> http-conn struct accessors at the very least.


I guess I would think about the code to do the writing separately from the
specific target you would be writing to, though certainly you would want a
good story for how to use it with the existing net libraries.

Maybe you've already seen this, but most of the functions in this family
support supplying post data as a `data-procedure/c
`,
which lets you stream using chunked content transfer encoding. I think the
most explicit documentation for that is under `http-conn-send!
`.


On Tue, Jan 29, 2019 at 3:22 PM George Neuner  wrote:

> Multipart HTTP is similar but not exactly the same as MIME.
> …
> Multipart HTTP is simpler - AFAIK, it does not support recursive parts.


I believe `multipart/form-data` is a restricted subset of MIME: at least, RFC
7578  says that "The media
type multipart/form-data follows the model of multipart MIME data streams
as specified in Section 5.1 of RFC 2046; changes are noted in this
document."

I hope that a single writing library would be able to handle both
`multipart/form-data` and MIME for email, but some of the restrictions on
`multipart/form-data` have implications for the design of a writer. In
particular, in an email context, you might decide that it's up to the
library whether to use a Content-Transfer-Encoding: an implementation could
then decide to put everything in quoted-printable encoding so that it could
reliably use a boundary containing, say, "=_", which can never appear in
quoted-printable-encoded data. However, this strategy doesn't work for
`multipart/form-data`, because RFC 7578 §4.7
 says that senders "SHOULD
NOT" use Content-Transfer-Encoding (even though the RFC itself uses
quoted-printable encoding in an example in section 4.5
)—I learned this after
sending quoted-printable encoding provoked a null pointer error in a real
server I was talking to.

Of course, you can also send normal, email-style MIME over HTTP by using an
appropriate content type header (`multipart/alternative`,
`multipart/mixed`, etc.), just as you can send `application/json`.

-Philip

-- 
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] Multipart HTTP requests

[Jon Zeppieri]

On Tue, Jan 29, 2019 at 4:17 AM Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

>
> Any thoughts on how I should move forward?


I think that using a `data-procedure/c` of a particular sort should allow
you to implement this without needing access to the struct internals or
needing to read everything into memory at once.

(Though, it would be a bit nicer if the write proc allowed you to specify
an offset and length into the string/byte string.)

Something like:
===
#lang racket/base

(require net/http-client
 file/sha1
 racket/random)

(define (http-conn-send/multipart! hc uri multipart-body
   #:version [version #"1.1"]
   #:method [method #"POST"]
   #:close? [close? #f]
   #:headers [headers '()]
   #:content-decode [decodes '(gzip)]
   #:boundary [boundary (random-boundary)])
  (define content-type-header
(string-append
 "Content-Type: multipart/form-data; boundary="
 boundary))

  (http-conn-send! hc uri
   #:version version
   #:method method
   #:close? close?
   #:headers (cons content-type-header headers)
   #:content-decode decodes
   #:data (multipart-body->data-proc boundary
multipart-body)))

(define (mime-escape s)
  (regexp-replace* #rx"[\"\\]" s "\\0"))

(define (make-string-part field-name field-value)
  (λ (write-chunk boundary)
(write-chunk
 (format
  (string-append "--~a\r\n"
 "Content-Disposition: form-data; name=\"~a\"\r\n"
  "Content-Type: text/plain; charset=utf-8\r\n"
  "\r\n"
  "~a\r\n")
  boundary
  (mime-escape field-name)
  field-value


(define (make-file-part field-name file-name content-type in)
  (λ (write-chunk boundary)
(write-chunk
 (format
  (string-append "--~a\r\n"
 "Content-Disposition: form-data; name=\"~a\";
filename=\"~a\"\r\n"
  "Content-Type: ~a\r\n"
  "\r\n")
  boundary
  (mime-escape field-name)
  (mime-escape file-name)
  content-type))

(define buffer (make-bytes 4096))
(let loop ([n (read-bytes-avail! buffer in)])
  (cond
[(eof-object? n)
 n]
[else
 (write-chunk (subbytes buffer 0 n))
 (loop (read-bytes-avail! buffer in))]))

(write-chunk "\r\n")))

(define (multipart-body->data-proc boundary parts)
  (λ (write-chunk)
(for ([part parts])
  (part write-chunk boundary))
(write-chunk (format "--~a--\r\n" boundary

(define (random-boundary)
  (string-append
   "--"
   (bytes->hex-string
(crypto-random-bytes 8

-- 
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: updated Racket-on-Chez status

[Alex Harsanyi]

I know the report explains the various cases where Racket CS is slower than
Racket 7.1, but I would like to mention that these cases are very 
significant,
at least in my case -- I mention this because the report recommends making
Racket CS the default, which I am very concerned about:

> To maximize the maintenance benefits of Racket CS, it’s better to make it
> the default Racket variant sooner rather than later

To understand the performance impact, below are the numbers for my
application.  I mentioned this before [1] and I added some new timings to 
the
Google Sheets Document [2].

* the total Travis build time (build + tests) is ~13 minutes using Racket 
7.1
  and it is 20 minutes, a 7 minute increase.

* the build time itself grows from 3.75 minutes in Racket 7.1 to 8.5 minutes
  in Racket CS, a 5 minute increase.  My Edit-Compile-Run cycle is already
  slow with Racket 7.1.

* even ignoring compile and load time, code sections which run after Racket
  initialization and library loading indicate that the running time is
  increased by 33% -- given that current execution time is several seconds 
to
  several minutes in Racket 7.1, a 33% increase is very visible to the end
  user.

As it stands now, the cases where RacketCS is slow have a significant impact
on my application.  Do others see the same performance degradation in their
applications?

Best Regards,
Alex.

[1] https://groups.google.com/d/msg/racket-users/yfQvM4Rf7mA/gcJJI-XbAAAJ

[2] 
https://docs.google.com/spreadsheets/d/1r1ZKtw4lDfv5xGXCfrOuE6jlCAMm0atMic4BfAnLLLw/edit?usp=sharing


On Tuesday, January 29, 2019 at 10:49:57 PM UTC+8, Matthew Flatt wrote:
>
> Here's a new status report on Racket CS: 
>
>  http://blog.racket-lang.org/2019/01/racket-on-chez-status.html 
>
> Short version: Racket CS is done in a useful sense, but we'll wait 
> until it gets better before making it the default Racket 
> implementation. 
>
>
> Matthew 
>
>

-- 
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] Beginning of the end for googlegroups?

[James Platt]

On Jan 25, 2019, at 8:51 PM, Neil Van Dyke wrote:

> Regarding hosting of the email list server... worst case, were Google Groups 
> to shut down with no good migration offering... if we can't find a turn-key 
> email list service we like, we could always run the time-honored MailMan on 
> either one of the affiliated universities' in-house systems (if the non-owned 
> .org domain name isn't a problem for that .edu), or on Linode/AWS/etc.
 
GDPR now mandates data portability for companies serving European citizens.  
IIRC, Google, among others, just a few months ago, set up some standards for 
exchanging data among competing services to comply with the new law.  If we go 
for some other service, we should check that they have a good statement 
regarding GDPR compliance.

At the university where I worked until recently, we had a MailMan server and it 
was trivial to set up a group on just about any vaguely academic topic you 
wanted.  However, they decommissioned the server just last year and now use a 
combination of features from Microsoft cloud services.   University IT has been 
moving away from anything maintained in-house.  The idea is that it is better 
for the IT department to act as a broker for external services.  With forum 
hosting, specifically, spam is an issue.   Our servers, or even our whole 
domain, were increasingly getting blocked by external servers.  SaaS (Software 
as a Service) is now the first choice.   I don't know if other universities 
are, or will be, making similar decisions but I wouldn't be too surprised.  


-- 
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] Beginning of the end for googlegroups?

[James Platt]

On Jan 29, 2019, at 3:08 PM, 'John Clements' via Racket Users wrote:

> For what it’s worth, I’m firmly in the “let’s wait and see” camp. I’m not 
> worried about losing archives…I think I personally have just about all of the 
> messages that have been posted to the google group, and I don’t think I’m 
> alone. So: for the moment, I’m not that concerned.

I have full archives since the time I first subscribed but it may still be 
useful, from time to time, to search the older archives.  Also, I think part of 
the value of having this kind of forum is that it is searchable from the 
internet for people who are researching something or doing some kind of 
troubleshooting.   It helps to promote and support Racket.  The Racket-Money 
list has made a different choice and decided to promote more candid discussion. 
 You just have to consider what the mission of this particular list is.  

-- 
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] Multipart HTTP requests

[Neil Van Dyke]

HTTP multipart reading is pretty easy to implement.  You just want to be 
careful about space performance -- not only because you might want 
lots-and-lots of this processing going on on each server (and the costs 
add up), but because the individual parts are quite often large (for the 
purposes to which people often put multipart).


(Side note: This seems like one of the many essential library things 
that might quickly shake out of a startup with strong Racketeers who 
contribute back high-quality open source packages for their 
non-trade-secret modules.  Many of these packages *could* also be done 
by a hobbyist volunteer, but a startup figuring out real-world 
function/interface/performance requirements, and needing to do it and 
make it work, might be more likely to do produce what's actually needed 
by other practitioners.  A few Racket startups doing this, and maybe you 
get an effect like the story of the person who, to design footpaths 
through a university quad, instead planted grass, and let the 
grass-trampling by students getting between classes determine where to 
place good footpaths.)


--
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] Multipart HTTP requests

[George Neuner]

On 1/29/2019 8:11 AM, Matthew Flatt wrote:

At Tue, 29 Jan 2019 04:17:53 -0500, Christopher Lemmer Webber wrote:
> Any thoughts on how I should move forward?  Has anyone else written a
> multipart library I don't know about, for instance?

Is that the same as MIME's multipart as used in email? If so, see

   http://docs.racket-lang.org/net/mime.html


Multipart HTTP is similar but not exactly the same as MIME.

Maybe I'm missing something, but I don't see where the net library lets 
you encode a mulitpart MIME message - it seems only able to parse them.  
I had a need to send multipart email some time ago and ended up encoding 
messages manually because I couldn't find anything then either.  MIME 
certainly isn't difficult - it's just tedious (the format is recursive, 
2 level even when "simple", and parts can contain parts).


Multipart HTTP is simpler - AFAIK, it does not support recursive parts.

George

--
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] Beginning of the end for googlegroups?

['John Clements' via Racket Users]

For what it’s worth, I’m firmly in the “let’s wait and see” camp. I’m not 
worried about losing archives…I think I personally have just about all of the 
messages that have been posted to the google group, and I don’t think I’m 
alone. So: for the moment, I’m not that concerned.

John


> On Jan 29, 2019, at 11:46 AM, Sorawee Porncharoenwase 
>  wrote:
> 
> 1784 at the moment, way beyond "500-750 users"
> 
> On Tue, Jan 29, 2019 at 10:39 AM Jens Axel Søgaard  
> wrote:
> How many users are on the racket-users list?
> 
> Are we anywhere near the listed numbers?
> 
> Den lør. 26. jan. 2019 kl. 01.01 skrev 'Paulo Matos' via Racket Users 
> :
> Apologies for message unrelated to racket, but it might affect us.
> 
> Just read this:
> https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/FZEWCOSyFlk/MFUXyq1YDAAJ
> 
> Not sure of the size of the mailing list but I wonder if this is the 
> beginning of the end and we should have instead a plan B.
> 
> --
> 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.
> 
> 
> -- 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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.



-- 
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] Beginning of the end for googlegroups?

[Sorawee Porncharoenwase]

1784 at the moment, way beyond "500-750 users"

On Tue, Jan 29, 2019 at 10:39 AM Jens Axel Søgaard 
wrote:

> How many users are on the racket-users list?
>
> Are we anywhere near the listed numbers?
>
> Den lør. 26. jan. 2019 kl. 01.01 skrev 'Paulo Matos' via Racket Users <
> racket-users@googlegroups.com>:
>
>> Apologies for message unrelated to racket, but it might affect us.
>>
>> Just read this:
>>
>> https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/FZEWCOSyFlk/MFUXyq1YDAAJ
>>
>> Not sure of the size of the mailing list but I wonder if this is the
>> beginning of the end and we should have instead a plan B.
>>
>> --
>> 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.
>>
>
>
> --
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Beginning of the end for googlegroups?

[Jens Axel Søgaard]

How many users are on the racket-users list?

Are we anywhere near the listed numbers?

Den lør. 26. jan. 2019 kl. 01.01 skrev 'Paulo Matos' via Racket Users <
racket-users@googlegroups.com>:

> Apologies for message unrelated to racket, but it might affect us.
>
> Just read this:
>
> https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/FZEWCOSyFlk/MFUXyq1YDAAJ
>
> Not sure of the size of the mailing list but I wonder if this is the
> beginning of the end and we should have instead a plan B.
>
> --
> 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.
>


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

[racket-users] Re: Beginning of the end for googlegroups?

['Joel Dueck' via Racket Users]

A possible alternative to Google would be to host this group as a forum on 
a public Fossil repository. 

Fossil is a source control system similar to Git. But unlike Git, a fossil 
repo can include its own forum (as well as wiki and issue tracking), and it 
has a built-in web interface. A Fossil repo is contained in a single SQLite 
database file, so there's no separate DB engine to monitor, and 
backups/migrations are dead simple.

The Fossil project itself uses a forum-only repo to host its own forum, you 
can see it here: https://fossil-scm.org/forum/forum

Fossil can send email updates (per-message or daily digest) to users. The 
only thing we would lose by this arrangement is the ability to reply to a 
post by email.

It seems to me this would be a good, simple way to both enable and archive 
Racket discussions in a permanently usable format.

On Friday, January 25, 2019 at 6:01:21 PM UTC-6, Paulo Matos wrote:
>
> Apologies for message unrelated to racket, but it might affect us. 
>
> Just read this: 
>
> https://groups.google.com/a/isocpp.org/forum/m/#!msg/sg14/FZEWCOSyFlk/MFUXyq1YDAAJ
>  
>
> Not sure of the size of the mailing list but I wonder if this is the 
> beginning of the end and we should have instead a plan B. 
>
> -- 
> 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] Multipart HTTP requests

[Hendrik Boom]

On Tue, Jan 29, 2019 at 04:34:49AM -0500, Philip McGrath wrote:
> I don't think there's a multipart-writing library yet, and it would be a
> great thing to have.
> 
> I've written little multipart-writing functions for a small proxy server
> built on `http-sendrecv/url` and for sending email using `net/sendmail`
> with html and text/plain alternatives. I'm happy to share code if it would
> be helpful, but nothing I've written is especially robust—for example, I
> just use a boundary that I know won't appear in legitimate input in my
> cases—which is why I haven't posted it publicly yet.

You could do what a lot of revision control repositories do -- use a 
cryptographically random boundary marker.  It's a provably wrong method, 
but a long enough one is unlikely to run into much trouble.

I think it's an ugly solution, but ...

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

[racket-users] updated Racket-on-Chez status

[Matthew Flatt]

Here's a new status report on Racket CS:

 http://blog.racket-lang.org/2019/01/racket-on-chez-status.html

Short version: Racket CS is done in a useful sense, but we'll wait
until it gets better before making it the default Racket
implementation.


Matthew

-- 
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] Multipart HTTP requests

[Matthew Flatt]

At Tue, 29 Jan 2019 04:17:53 -0500, Christopher Lemmer Webber wrote:
> Any thoughts on how I should move forward?  Has anyone else written a
> multipart library I don't know about, for instance?

Is that the same as MIME's multipart as used in email? If so, see

  http://docs.racket-lang.org/net/mime.html

-- 
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] Multipart HTTP requests

[Christopher Lemmer Webber]

I see... yeah, I thought about going this route but the reason it didn't
seem particularly "robust" to me is that I would have to read the entire
object into memory at once before passing it in as bytes.  IMO it would
be better to have the option to provide ports with file data so the data
could be streamed in without reading the whole data into memory.
However that would, I still think, require being able to access the
http-conn struct accessors at the very least.

At any rate, if you don't mind, send what you have!  I'm in the middle
of a hackathon and it might help me deliver some cool things faster :)

Please do mark your work with a libre license if you upload it so I can
safely incorporate it :)

Philip McGrath writes:

> I don't think there's a multipart-writing library yet, and it would be a
> great thing to have.
>
> I've written little multipart-writing functions for a small proxy server
> built on `http-sendrecv/url` and for sending email using `net/sendmail`
> with html and text/plain alternatives. I'm happy to share code if it would
> be helpful, but nothing I've written is especially robust—for example, I
> just use a boundary that I know won't appear in legitimate input in my
> cases—which is why I haven't posted it publicly yet.
>
> One thought I've had about making a library is that it would be nice if the
> writing API corresponded in some sensible way to the API from `net/mime
> ` (which only handles parsing).
>
> -Philip
>
>
> On Tue, Jan 29, 2019 at 4:17 AM Christopher Lemmer Webber <
> cweb...@dustycloud.org> wrote:
>
>> I'm looking to do multipart HTTP requests in Racket, though it looks
>> like there's no support at the moment.
>>
>> I thought I might add a utility using the net/http-client library,
>> starting with making an adjusted http-conn-send! function.  However, the
>> http-conn-(host/port/etc) struct accessors aren't made available, so it
>> appears I can't build a utility that uses the same http-conn struct.
>>
>> Any thoughts on how I should move forward?  Has anyone else written a
>> multipart library I don't know about, for instance?
>>
>>  - cwebb
>>
>> --
>> 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.
>>

-- 
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] side by side; scribble

[Robby Findler]

In order to do that you'd need to drop down to the latex level and use
a package there to help you. There is information about how to do that
here: http://docs.racket-lang.org/scribble/config.html . Here is a
post about packages you could use:
https://tex.stackexchange.com/questions/308260/parallel-text-translation-including-the-same-double-parallel-heading-numbering

hth,
Robby

On Tue, Jan 29, 2019 at 5:09 AM  wrote:
>
> Can I do a side by side pdf using racket scribble? Imagine you have an 
> English text and want the Portuguese translation in the opposite column. If 
> yes, it brings another question, which is, can it be done with synchronized 
> paragraphs?
>
> --
> 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.

-- 
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] side by side; scribble

[mig . silva]

Can I do a side by side pdf using racket scribble? Imagine you have an 
English text and want the Portuguese translation in the opposite column. If 
yes, it brings another question, which is, can it be done with synchronized 
paragraphs?

-- 
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] Multipart HTTP requests

[Philip McGrath]

I don't think there's a multipart-writing library yet, and it would be a
great thing to have.

I've written little multipart-writing functions for a small proxy server
built on `http-sendrecv/url` and for sending email using `net/sendmail`
with html and text/plain alternatives. I'm happy to share code if it would
be helpful, but nothing I've written is especially robust—for example, I
just use a boundary that I know won't appear in legitimate input in my
cases—which is why I haven't posted it publicly yet.

One thought I've had about making a library is that it would be nice if the
writing API corresponded in some sensible way to the API from `net/mime
` (which only handles parsing).

-Philip


On Tue, Jan 29, 2019 at 4:17 AM Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

> I'm looking to do multipart HTTP requests in Racket, though it looks
> like there's no support at the moment.
>
> I thought I might add a utility using the net/http-client library,
> starting with making an adjusted http-conn-send! function.  However, the
> http-conn-(host/port/etc) struct accessors aren't made available, so it
> appears I can't build a utility that uses the same http-conn struct.
>
> Any thoughts on how I should move forward?  Has anyone else written a
> multipart library I don't know about, for instance?
>
>  - cwebb
>
> --
> 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.
>

-- 
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] Multipart HTTP requests

[Christopher Lemmer Webber]

I'm looking to do multipart HTTP requests in Racket, though it looks
like there's no support at the moment.

I thought I might add a utility using the net/http-client library,
starting with making an adjusted http-conn-send! function.  However, the
http-conn-(host/port/etc) struct accessors aren't made available, so it
appears I can't build a utility that uses the same http-conn struct.

Any thoughts on how I should move forward?  Has anyone else written a
multipart library I don't know about, for instance?

 - cwebb

-- 
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.