Re: [racket-users] Multiple namespaces in Racket

[Alex Knauth]

> On Oct 12, 2017, at 6:31 PM, Alexis King  wrote:
> 
>> On Oct 12, 2017, at 1:46 PM, Matthew Flatt  wrote:
>> 
>> You could put all the type exports in a submodule. Then, you do need
>> your own variant of `require`, but that variant can mostly just check
>> for the presence of a type submodule, much the way that TR or
>> `plai-typed` do. If the submodule is available, you can import it with
>> the extra scope for types.
> 
> This makes a lot of sense to me, but I’m not completely sure how to
> implement the providing side. I imagine that users may very well want
> to use Racket’s namespace management features with types, leading to
> pathological declarations like this:
> 
>(provide (except-out (all-from-out foo/bar)
> (type-out ExcludedType)))
> 
> If type-out is a provide transformer that doesn’t actually provide
> anything, it merely expands to a submodule (perhaps using
> `syntax-local-lift-module-end-declaration`), then it can’t possibly
> understand that it should be doing something different when used in
> “excluding” position. Is the unfortunate answer here that I can’t get
> around needing to reimplement my own version of `provide` as well?

I just implemented this, and this is a problem, but the `all-from-out` form in 
general is an ever bigger problem, it's completely broken. 

The first strategy is to just lift the provide form into a submodule, but 
`all-from-out` expects there to be a require in the *same* module, 
`all-from-out` always yells at you with the error, all-from-out: no 
corresponding require.

The second strategy is to try to resolve the `all-from-out` references in the 
pre-transformer using `expand-export`. However this is still broken for 
`all-from-out` because `syntax-local-module-required-identifiers` complains 
about "not currently transforming module provides." 
(syntax-local-transforming-module-provides? is false). All-from-out uses 
syntax-local-module-required-identifiers to determine what identifiers should 
be in it, and that needs to be called within a provide-transformer, not a 
provide pre-transformer.

To create a new lifted module I need to use a provide-pre-transformer, but to 
resolve all-from-out's properly I need to use a provide-transformer. Is there 
any way around this?

What I have so far:
https://gist.github.com/AlexKnauth/b7d9f2e0af1c5b8e2186d6581b1f7e4d 


Alex Knauth

-- 
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] Intro and projects inquiry

[James]

I think a prominent cross platform GUI application which demonstrates the 
quality of interface you can get with relatively little effort in Racket would 
go a long way.  I find JAVA GUI s to be painful.  There is also a Python cross 
platform GUI but, judging by PgAdmin 4, I'm not impressed.  

A related idea would be Racket for rapid development of database clients.  This 
could be especially good if some easy database connection elements were added 
to MrEd Designer.  This is a crowded field but it's such a common need that a 
better tool would be welcome.  

James

-- 
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] Multiple namespaces in Racket

[Alexis King]

> On Oct 12, 2017, at 1:46 PM, Matthew Flatt  wrote:
> 
> You could put all the type exports in a submodule. Then, you do need
> your own variant of `require`, but that variant can mostly just check
> for the presence of a type submodule, much the way that TR or
> `plai-typed` do. If the submodule is available, you can import it with
> the extra scope for types.

This makes a lot of sense to me, but I’m not completely sure how to
implement the providing side. I imagine that users may very well want
to use Racket’s namespace management features with types, leading to
pathological declarations like this:

(provide (except-out (all-from-out foo/bar)
 (type-out ExcludedType)))

If type-out is a provide transformer that doesn’t actually provide
anything, it merely expands to a submodule (perhaps using
`syntax-local-lift-module-end-declaration`), then it can’t possibly
understand that it should be doing something different when used in
“excluding” position. Is the unfortunate answer here that I can’t get
around needing to reimplement my own version of `provide` as well?

-- 
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] Intro and projects inquiry

[Andrew Gwozdziewycz]

On Thu, Oct 12, 2017 at 10:02 PM, David Storrs  wrote:
> On Thu, Oct 12, 2017 at 5:27 PM, Andrew Gwozdziewycz  wrote:
>> We need people building tools and blogging about why using Racket made
> I agree that talking about how great Racket is will be an important
> part of increasing uptake.  That said, I contend that it is not
> enough.  People have been talking about how awesome LISP is for
> literally decades, and many of those people are influencers.  Example:
>  Paul Graham, who is essentially the god of Silicon Valley startups,
> has blogged extensively about how amazing LISP is and how it vastly
> increased the speed of his startup.  Despite that, I know of exactly
> zero SV startups that are using LISP -- I've been out of the valley
> for a couple years now, so maybe it's changed, but I was there for
> quite a while and never heard of any.

To be fair, despite Mr. Graham's talk, he didn't exactly put a lot of
code out that *showed* anyone anything. But take Clojure as an
example. It's got an advantage in that there's an immediate avenue for
getting it integrated with an existing codebase -- It's written in
Java. Adopting it to try it out isn't a big thing if you're already a
JVM shop.

But what if you *aren't* a JVM shop? Why would you adopt Clojure? It's
really not because of the libraries, or frameworks around it. Most of
that, at least early on, was really surface level stuff, except for
maybe Ring for web apps. But, Ring really isn't all that special...
either. Still, Clojure was successful *outside* of the world of the
JVM. ClojureScript maybe even more so!

Racket doesn't play well with existing code bases (except C things)
and so my hypothesis is simply that to gain adoption of Racket, you
need to solve problems that aren't in the "production path." Good
thing there are *lots* of those! All those Python scripts you have?
All of those Perl scripts that no one understands anymore? Those are,
in my opinion, the way in.

-- 
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] Intro and projects inquiry

[David Storrs]

On Thu, Oct 12, 2017 at 5:27 PM, Andrew Gwozdziewycz  wrote:
> I love seeing all of these project ideas, but I really don't think
> Racket needs a "killer app." I think what it needs is the people
> passionate about it building tools in it, and *using* those tools in
> the work place, and sharing the experiences of using those tools more
> vocally.
>
> We need people building tools and blogging about why using Racket made
> the job easier. Why would it be harder to do in Python, or Ruby? We
> need straight up advocacy, and that starts with everyone in this
> thread who *hasn't* done that yet.
>
> I started the thread about a "graphviz" like because I'd like to write
> documentation without pointing and clicking--including the figures I
> need to illustrate a point. That's not a killer app, but that's
> something that I can *share* inside the work place to make the lives
> of developers (who'd rather declare a drawing, than fight to point and
> click with it), to have an integrated documentation system they can
> use from their editor. It makes sense to me, and I'm sure it'd make
> sense to them, too.
>
> You might get some push back on the parentheses! You might get some
> push back on the fact that Racket has it's roots in "LISP"
> (intentionally capped). But, that's an opportunity. Show your
> coworkers the *why*. Explain to them why it's powerful. Explain to
> them that they can set up an editor to do parentheses matching.
> Explain to them contracts, or Typed Racket, or how powerful the
> language extension model is.
>
> Anyway. I don't think it makes sense to solve problems that you don't
> have. Solve your own problems, but do it in Racket. Then spread the
> word that Racket made it easy, fun, and elegant! Be sure to somehow
> include that the community is extremely welcoming, helpful, and
> growing!

I agree that talking about how great Racket is will be an important
part of increasing uptake.  That said, I contend that it is not
enough.  People have been talking about how awesome LISP is for
literally decades, and many of those people are influencers.  Example:
 Paul Graham, who is essentially the god of Silicon Valley startups,
has blogged extensively about how amazing LISP is and how it vastly
increased the speed of his startup.  Despite that, I know of exactly
zero SV startups that are using LISP -- I've been out of the valley
for a couple years now, so maybe it's changed, but I was there for
quite a while and never heard of any.

So, yes.  Talking Racket up is necessary, but it's not enough.
There's a chicken and egg problem -- there's no one in the private
sector who lists Racket on their resume, so there's no jobs to be had
in Racket.  There's no jobs to be had in Racket, so there's no reason
to learn Racket for your resume.  Everyone is constantly busy and
staying on the SOTA curve in order to maintain employability is
difficult.  If I'm a working programmer I have N hours of study time
in a week.  There are lots of interesting things to study, so would I
devote those precious hours to Racket (something that doesn't make me
more employable and which no one I know is using) as opposed to
learning a more popular tool (e.g. a web framework, or a job-viable
programming language) or a popular field of study (e.g. machine
learning, data science) that opens up entire new career tracks for me?

The key rule of sales is "find the pain, fix it".  Simply saying "use
Racket because it's awesome" does not fix anyone's pain; they are
perfectly happy with the languages they're using, so there is no pain
there.  On the other hand, show them a tool that solves a problem they
have (a source of pain) and they will happily learn this weird,
unemployable, thing-I-never-heard-of language in order to use it.



>
> On Thu, Oct 12, 2017 at 9:09 PM, James  wrote:
>>
>>> Does a killer app or library sorely need a Racket alternative?
>>
>> Let me throw out a few things which we would use in our business even if 
>> they are not the most pressing needs in general.  We have ways to work 
>> around these things but It would be much nicer to have a Racket native 
>> solution.  I have numbered the list but they are really in no particular 
>> order.
>>
>> 1. Libsodium - We need to do some sophisticated encryption and web of trust 
>> stuff.  See earlier comments on this list by Tony Garnock-Jones.
>>
>> 2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
>> working on using FFI to either PJNATH or libnice.  A pure Racket 
>> implementation would be great.  It should probably be combined with Tony G's 
>> efforts on UPnP and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal. 
>>  This is an area which has suffered greatly from a lack of the right people 
>> coming together and agreeing on a good standard.  ICE is a method for 
>> prioritizing and selecting from multiple competing standards which may each 
>> be the best choice in different 

[racket-users] (seventh RacketCon) Survey

[Vincent St-Amour]

Racketeers,

(seventh RacketCon) was held last weekend. I hope you were able to join
us, be it in person, or via the live stream.

As we're always trying to make RacketCon better, we're interested in
hearing what you thought of this one. If you did not attend, we're also
interested in hearing from you, in the hopes of better reaching you in
the future.

If you're willing to share your thoughts with us, please fill in this
brief survey:


https://docs.google.com/forms/d/e/1FAIpQLScfpVDpXMAtoH_-XmnPpqrhQ_-NVW8fuyGCLQ4CMQAt_67qFg/viewform?c=0w=1usp=mail_form_link

Thanks again to all of you who made this RacketCon possible: speakers,
sponsors, and audience!

Vincent

-- 
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] Intro and projects inquiry

[Andrew Gwozdziewycz]

I love seeing all of these project ideas, but I really don't think
Racket needs a "killer app." I think what it needs is the people
passionate about it building tools in it, and *using* those tools in
the work place, and sharing the experiences of using those tools more
vocally.

We need people building tools and blogging about why using Racket made
the job easier. Why would it be harder to do in Python, or Ruby? We
need straight up advocacy, and that starts with everyone in this
thread who *hasn't* done that yet.

I started the thread about a "graphviz" like because I'd like to write
documentation without pointing and clicking--including the figures I
need to illustrate a point. That's not a killer app, but that's
something that I can *share* inside the work place to make the lives
of developers (who'd rather declare a drawing, than fight to point and
click with it), to have an integrated documentation system they can
use from their editor. It makes sense to me, and I'm sure it'd make
sense to them, too.

You might get some push back on the parentheses! You might get some
push back on the fact that Racket has it's roots in "LISP"
(intentionally capped). But, that's an opportunity. Show your
coworkers the *why*. Explain to them why it's powerful. Explain to
them that they can set up an editor to do parentheses matching.
Explain to them contracts, or Typed Racket, or how powerful the
language extension model is.

Anyway. I don't think it makes sense to solve problems that you don't
have. Solve your own problems, but do it in Racket. Then spread the
word that Racket made it easy, fun, and elegant! Be sure to somehow
include that the community is extremely welcoming, helpful, and
growing!

On Thu, Oct 12, 2017 at 9:09 PM, James  wrote:
>
>> Does a killer app or library sorely need a Racket alternative?
>
> Let me throw out a few things which we would use in our business even if they 
> are not the most pressing needs in general.  We have ways to work around 
> these things but It would be much nicer to have a Racket native solution.  I 
> have numbered the list but they are really in no particular order.
>
> 1. Libsodium - We need to do some sophisticated encryption and web of trust 
> stuff.  See earlier comments on this list by Tony Garnock-Jones.
>
> 2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
> working on using FFI to either PJNATH or libnice.  A pure Racket 
> implementation would be great.  It should probably be combined with Tony G's 
> efforts on UPnP and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal.  
> This is an area which has suffered greatly from a lack of the right people 
> coming together and agreeing on a good standard.  ICE is a method for 
> prioritizing and selecting from multiple competing standards which may each 
> be the best choice in different circumstances.  UPnP and NAT-PMP are only 
> partial solutions for us and we really need STUN and TURN as well.
>
> 3. Advanced fountain codes - For example, https://arxiv.org/abs/1605.09125.  
> I haven't seen a Racket native library for basic Reed-Solomon erasure codes 
> either.
>
> 4. A DSL alternative to GraphViz - see my other message.
>
> 5. #lang R or some other method to combine Racket and R - We need to go to R 
> for computational work because that's what is trusted in the field.
>
> James
>
> --
> 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.



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

Re: [racket-users] Intro and projects inquiry

[Philip McGrath]

On Thu, Oct 12, 2017 at 4:09 PM, James  wrote:
>
> 5. #lang R or some other method to combine Racket and R - We need to go to
> R for computational work because that's what is trusted in the field.


I published a package called opencpu (
http://docs.racket-lang.org/opencpu/index.html) that provides a little bit
of abstraction on the Racket side over the OpenCPU HTTP API for R (
https://www.opencpu.org/). I haven't used it in production (because I
persuaded my colleagues in the project for which I wrote it to just
implement the functionality in pure Racket), but it may be a useful
starting point for others. I welcome suggestions, forks, and pull requests!
https://github.com/liberalartist/opencpu

-- 
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] Intro and projects inquiry

[James]

> Does a killer app or library sorely need a Racket alternative?

Let me throw out a few things which we would use in our business even if they 
are not the most pressing needs in general.  We have ways to work around these 
things but It would be much nicer to have a Racket native solution.  I have 
numbered the list but they are really in no particular order.  

1. Libsodium - We need to do some sophisticated encryption and web of trust 
stuff.  See earlier comments on this list by Tony Garnock-Jones.

2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
working on using FFI to either PJNATH or libnice.  A pure Racket implementation 
would be great.  It should probably be combined with Tony G's efforts on UPnP 
and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal.  This is an area 
which has suffered greatly from a lack of the right people coming together and 
agreeing on a good standard.  ICE is a method for prioritizing and selecting 
from multiple competing standards which may each be the best choice in 
different circumstances.  UPnP and NAT-PMP are only partial solutions for us 
and we really need STUN and TURN as well.

3. Advanced fountain codes - For example, https://arxiv.org/abs/1605.09125.  I 
haven't seen a Racket native library for basic Reed-Solomon erasure codes 
either.

4. A DSL alternative to GraphViz - see my other message.

5. #lang R or some other method to combine Racket and R - We need to go to R 
for computational work because that's what is trusted in the field.  

James

-- 
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] Multiple namespaces in Racket

[Matthew Flatt]

At Thu, 12 Oct 2017 12:59:17 -0700, Alexis King wrote:
> An alternative approach that
> I have considered (and discussed briefly with some people) is to
> introduce a “value” scope using make-syntax-introducer in
> #%module-begin, then use a separate “type” scope when parsing types to
> keep the two bindings completely separate.

That sounds right to me.

> Specifically, the main question occurs when considering code that spans
> more than a single module. What do require and provide do? For the
> provide case, it doesn’t seem too hard to have a (type-out ) provide
> transformer, but what happens when a user requires the module? Since my
> understanding is that modules essentially only provide a set of
> *symbols* per phase, not identifiers, would I need to mangle names in
> order to allow a module to export a type with the same name as a value?
> Would I need to write my own version of require to handle this without
> wrapping all imports in a require transformer? What about interop with
> other Racket languages?

You could put all the type exports in a submodule. Then, you do need
your own variant of `require`, but that variant can mostly just check
for the presence of a type submodule, much the way that TR or
`plai-typed` do. If the submodule is available, you can import it with
the extra scope for types.

-- 
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] Multiple namespaces in Racket

[Alexis King]

In discussions with some people at (seventh RacketCon), I managed to
solve a few open problems I had in my implementation of Hackett. One
thing I didn’t get a good answer for, however, is implementing a
language with multiple namespaces. Hackett is not dependently-typed, so
it is pointless and inconvenient for types and values to share the same
namespace; indeed, it is often useful and idiomatic in Haskell to reuse
names for both type variables and runtime variables.

Racket is, of course, a staunch Lisp-1, and it has a single namespace.
I generally think this is the right default, but for Hackett, I’ve
already run into situations in which I would strongly prefer the types
and value namespaces remain separate. Fortunately, Racket often makes
it possible to build these things as derived concepts, so I am hopeful
I will be able to implement this without too much pain.

I currently have an understanding of two possible approaches for
implementing multiple namespaces. The first appears to be the usual
technique of maintaining a separate binding table (using free id tables
from syntax/id-table). This is often good enough, but it isn’t good
enough for Hackett, since Hackett needs to support arbitrary local
bindings and bindings that can be tracked and renamed separately from
the Racket binding they are “attached” to. An alternative approach that
I have considered (and discussed briefly with some people) is to
introduce a “value” scope using make-syntax-introducer in
#%module-begin, then use a separate “type” scope when parsing types to
keep the two bindings completely separate. This seems more promising,
but it has problems of its own.

Specifically, the main question occurs when considering code that spans
more than a single module. What do require and provide do? For the
provide case, it doesn’t seem too hard to have a (type-out ) provide
transformer, but what happens when a user requires the module? Since my
understanding is that modules essentially only provide a set of
*symbols* per phase, not identifiers, would I need to mangle names in
order to allow a module to export a type with the same name as a value?
Would I need to write my own version of require to handle this without
wrapping all imports in a require transformer? What about interop with
other Racket languages?

This seems like a significant burden to put on me as the author of a
language, but I don’t know of a better way. Is there prior art here? Is
there a simpler solution? And are there any pitfalls I haven’t yet
considered?

Thanks,
Alexis

-- 
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] Intro and projects inquiry

[James]

> I enjoyed following the graph drawing thread a few weeks ago. A serious 
> attempt at "better than graphviz" could be fun and worthwhile.

I was going to reply to that thread as well but didn't get to it.  There is a 
great need for something like this in bioinformatics.  Down the road a bit, we 
will want something like it for the startup business which I am in.  We are 
developing bioinformatics software and one of the things on our to do list is a 
module for graphing protein-protein interactions.

Have a look at this paper:
http://bit.ly/2yfXTip

I painstakingly created figure 1C in Cytoscape.  I was unable to make similar 
graphs, much less the more sophisticated ones I would like to create, for 
subsequent publications because it just took too much time.  Of course I wanted 
to automate the process.  I tried scripting Cytoscape but found that to be too 
tedious and unreliable.  I looked into creating a Cytoscape plugin but it was 
too much work and I would have had to learn Java.  Most of my programming 
experience, so far, has been Perl and R.  I researched a bunch of different 
options and then turned to a GraphViz library for R but found that it was too 
limited.  Finally, I wrote some custom R code to create GraphViz code.  This 
got me the farthest but I would really like to have something nicer than 
GraphViz to work with.

Figure 1C is combining raw gene expression profiling data with Gene Set 
Enrichment Analysis (GSEA) to indicate the activity of various transcription 
factors.  The raw data and GSEA scores are then graphed in the context of the 
most significant transcription factors and their known target genes.  This can 
be a very powerful way of looking at the data under the right circumstances.  
The more common situation is looking at a combination of expression profiling 
data with mutation calls from sequencing in the context of known 
protein-protein interactions.  There are some commercial options which do some 
of this but they are not very good and not really open enough to allow for 
accessible and reproducible research.  Our model is to charge for participation 
in our network and for what will eventually become our platform software.  The 
analytical tools and community contributed analytical modules will be open 
source so you can see exactly what they are doing.  

Moving forward, something which has been an idea for a long time but not yet 
done satisfactorily, as far as I know, is to show proteins as either logic 
gates or analog circuits.  Proteins are viewed, in many cases, as forming 
signal networks.  It would be good to be able to show an animation of how the 
signal flow over the network changes with different environmental signals.  
Alternatively, hold the environmental signals constant and show what happens to 
the signal flow if you add/remove a mutation in one of the proteins.  So that's 
a step or two beyond what GraphViz does but I think it's a logical direction to 
go for further development.  

James

-- 
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] emission filesystem-change-evt when directory is changing fast

[David Storrs]

I see.  Thanks, Matthew, that helps.

On Thu, Oct 12, 2017 at 3:06 PM, Matthew Flatt  wrote:
> A filesystem-change event becomes ready if there's a change between the
> time that you create the event and the time that you poll it. After the
> change event becomes ready, it stays ready, so you'd need create a new
> filesystem-change event to watch for further changes.
>
> With that interface, these questions of granularity don't apply,
> because your program is in charge of how often it creates and checks
> filesystem-change evts. Then again, it also means that the
> filesystem-change API doesn't tell you what has changed.
>
> At Thu, 12 Oct 2017 14:58:09 -0400, David Storrs wrote:
>> Suppose I'm watching a directory such that I will receive
>> filesystem-change-evts when things are added/deleted/renamed.  Someone
>> drag-n-drops 4,000 files into the directory.  How will the system
>> handle this?
>>
>> 1) Will I receive an event every time the OS starts copying the next
>> file, will it batch them up, or what?
>>
>> 2) If it batches them, what is the granularity?
>>
>> 3) How does this vary across OSes?
>>
>> --
>> 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] emission filesystem-change-evt when directory is changing fast

[Matthew Flatt]

A filesystem-change event becomes ready if there's a change between the
time that you create the event and the time that you poll it. After the
change event becomes ready, it stays ready, so you'd need create a new
filesystem-change event to watch for further changes.

With that interface, these questions of granularity don't apply,
because your program is in charge of how often it creates and checks
filesystem-change evts. Then again, it also means that the
filesystem-change API doesn't tell you what has changed.

At Thu, 12 Oct 2017 14:58:09 -0400, David Storrs wrote:
> Suppose I'm watching a directory such that I will receive
> filesystem-change-evts when things are added/deleted/renamed.  Someone
> drag-n-drops 4,000 files into the directory.  How will the system
> handle this?
> 
> 1) Will I receive an event every time the OS starts copying the next
> file, will it batch them up, or what?
> 
> 2) If it batches them, what is the granularity?
> 
> 3) How does this vary across OSes?
> 
> -- 
> 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] emission filesystem-change-evt when directory is changing fast

[David Storrs]

Suppose I'm watching a directory such that I will receive
filesystem-change-evts when things are added/deleted/renamed.  Someone
drag-n-drops 4,000 files into the directory.  How will the system
handle this?

1) Will I receive an event every time the OS starts copying the next
file, will it batch them up, or what?

2) If it batches them, what is the granularity?

3) How does this vary across OSes?

-- 
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] Intro and projects inquiry

[Matthias Felleisen]

David’s reference is to Vishesh’s RacketScript. Please see (seventh RacketCon). 
Contributions welcome. 




> On Oct 12, 2017, at 1:00 PM, 'Royall Spence' via Racket Users 
>  wrote:
> 
> Unfortunately, Whalesong's current fork requires an old version of Racket and 
> hasn't seen a commit to master in several months. Racketscript is under 
> active development, though, and provides a mostly-complete implementation of 
> Racket for Javascript. Seems comparable to Clojurescript in its vision.
> 
> https://github.com/vishesh/racketscript
> 
> 
> On Thu, Oct 12, 2017, at 12:43 PM, Thomas Lynch wrote:
>> Apparently Whalesong is such an alterntiave. 
>> https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
>>A Lisp dialect, Clojure, has caused a lot of young folks to ask 
>> questions/to think about Lisp 
>> (https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e).
>> 
>> On Thu, Oct 12, 2017 at 4:31 PM, David Storrs  wrote:
>> My suggestion would be that the single largest thing that would make
>> Racket take off is if it could become a replacement for Javascript.
>> The browser is the default GUI for most work these days, and doing
>> real-time interfaces in the browser requires Javascript.  If Racket
>> could run inside the browser and was more convenient to work with than
>> Javascript then it would start climbing the hockey stick.  That would
>> be an enormous project and I don't even know how you would get the
>> popular browsers to adopt it; forking the browsers won't work and nor
>> will making a plugin / addon -- it's got to run out of the box so that
>> developers can rely on the fact that visitors to their site will be
>> able to use it.
>> 
>> For now, something that made it trivial to compile Racket to
>> Javascript is probably the best option.  As it happens, I believe
>> there is some effort in that direction. :>
>> 
>> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke  wrote:
>> > Eric Griffis wrote on 10/11/2017 07:44 PM:
>> >>
>> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke > >> > wrote:
>> >>
>> >>
>> >> * Being there soon with a Web Assembly and HTML5 plus server
>> >> full-stack
>> >> story, in case developers respond favorably to that.
>> >>
>> >>
>> >> Web back-ends are my wheelhouse. It sure would make my professional life
>> >> easier... Not gonna lie, this isn't something I'd look forward to banging
>> >> out alone.
>> >
>> >
>> > There are some scalable HTTP protocol handling things I'd like to try,
>> > including some hardcore systems-ish programming, and then multiple parties
>> > (including me) could layer independent framework-y things over that
>> > (server-side-only, and client-side-too).
>> >
>> > The WebAssembly part is what might be an emerging opportunity, but am
>> > guessing the best way involves working with the tentative new Chez backend
>> > for Racket.  (Also, WebAssembly didn't look very simple nor yet as
>> > well-documented as you'd want, and looks still being hammered out.  So,
>> > knowing how adopted Web standards tend to happen... you might have to put 
>> > in
>> > considerable effort to catch up with and track it, buy a gorilla suit, 
>> > munch
>> > some beetle grubs[1], and hopefully become accepted by the pack, to be
>> > confident that Racket will be a first-class citizen in WebAssembly.)
>> >
>> >> * Push DSL-based programming, for which Racket might already have the
>> >> best technology.  (The other day, I saw someone looking to hire
>> >> developers to use some DSL-based speculative methodology thing...
>> >> in Ruby.)
>> >>
>> >>
>> >> This might also be interesting. Any concrete demand out there to drive the
>> >> process?
>> >
>> >
>> > Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
>> > methodologists are always clamoring to invent and brand approaches, now
>> > including applications of DSLs. :)
>> >
>> > (DSLs can be little mini-languages used by programmers as part of any kind
>> > of programming, they can be used by programmers mix traditional language
>> > paradigms in a code base, they can be used to support domain
>> > experts/specialists capturing and maintaining knowledge/behavior separate
>> > from programmers.)
>> >
>> >>
>> >> The Godot game engine is kinda like this, but for Python. It has a lot of
>> >> rough edges, which could help design a good Racket alternative. There may 
>> >> be
>> >> a ton of reusable functionality in a project like that.
>> >
>> >
>> > Over a decade ago, someone was actually doing game engine-ish stuff using
>> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
>> > simulator for first-responders in emergency scenarios.  It might've used 
>> > the
>> > open-sourced Quake engine, or just built atop OpenGL; I forget whether I
>> > heard.  At the time, I guess 

Re: [racket-users] Intro and projects inquiry

['Royall Spence' via Racket Users]

Unfortunately, Whalesong's current fork requires an old version of
Racket and hasn't seen a commit to master in several months.
Racketscript is under active development, though, and provides a mostly-
complete implementation of Racket for Javascript. Seems comparable to
Clojurescript in its vision.
https://github.com/vishesh/racketscript


On Thu, Oct 12, 2017, at 12:43 PM, Thomas Lynch wrote:
> Apparently Whalesong is such an alterntiave.
> https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
> A Lisp dialect, Clojure, has caused a lot of young folks to ask
> questions/to think about Lisp
> (https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e)
> .> 
> On Thu, Oct 12, 2017 at 4:31 PM, David Storrs
>  wrote:>> My suggestion would be that the single 
> largest thing that would make>> Racket take off is if it could become a 
> replacement for Javascript.
>> The browser is the default GUI for most work these days, and doing
>> real-time interfaces in the browser requires Javascript.  If Racket
>> could run inside the browser and was more convenient to work
>> with than>> Javascript then it would start climbing the hockey stick.  That 
>> would>> be an enormous project and I don't even know how you would get the
>> popular browsers to adopt it; forking the browsers won't work and nor>> will 
>> making a plugin / addon -- it's got to run out of the box
>> so that>> developers can rely on the fact that visitors to their site will be
>> able to use it.
>> 
>> For now, something that made it trivial to compile Racket to
>> Javascript is probably the best option.  As it happens, I believe
>> there is some effort in that direction. :>
>> 
>> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke
>>  wrote:>> > Eric Griffis wrote on 10/11/2017 07:44 PM:
>> >>
>> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke
>> >> > >> > wrote:
>> >>
>> >>
>> >> * Being there soon with a Web Assembly and HTML5 plus server
>> >> full-stack
>> >> story, in case developers respond favorably to that.
>> >>
>> >>
>> >> Web back-ends are my wheelhouse. It sure would make my
>> >> professional life>> >> easier... Not gonna lie, this isn't something I'd 
>> >> look forward to
>> >> banging>> >> out alone.
>> >
>> >
>> > There are some scalable HTTP protocol handling things I'd like
>> > to try,>> > including some hardcore systems-ish programming, and then 
>> > multiple
>> > parties>> > (including me) could layer independent framework-y things over 
>> > that>> > (server-side-only, and client-side-too).
>> >
>> > The WebAssembly part is what might be an emerging opportunity,
>> > but am>> > guessing the best way involves working with the tentative new 
>> > Chez
>> > backend>> > for Racket.  (Also, WebAssembly didn't look very simple nor 
>> > yet as>> > well-documented as you'd want, and looks still being hammered
>> > out.  So,>> > knowing how adopted Web standards tend to happen... you 
>> > might have
>> > to put in>> > considerable effort to catch up with and track it, buy a 
>> > gorilla
>> > suit, munch>> > some beetle grubs[1], and hopefully become accepted by the 
>> > pack,
>> > to be>> > confident that Racket will be a first-class citizen in
>> > WebAssembly.)>> >
>> >> * Push DSL-based programming, for which Racket might already
>> >>   have the>> >> best technology.  (The other day, I saw someone 
>> >> looking to
>> >> hire>> >> developers to use some DSL-based speculative methodology
>> >> thing...>> >> in Ruby.)
>> >>
>> >>
>> >> This might also be interesting. Any concrete demand out there to
>> >> drive the>> >> process?
>> >
>> >
>> > Chattering about DSLs now seems mainstream.  Also, Agile-esque
>> > upstart>> > methodologists are always clamoring to invent and brand
>> > approaches, now>> > including applications of DSLs. :)
>> >
>> > (DSLs can be little mini-languages used by programmers as part of
>> > any kind>> > of programming, they can be used by programmers mix 
>> > traditional
>> > language>> > paradigms in a code base, they can be used to support domain
>> > experts/specialists capturing and maintaining knowledge/behavior
>> > separate>> > from programmers.)
>> >
>> >>
>> >> The Godot game engine is kinda like this, but for Python. It has a
>> >> lot of>> >> rough edges, which could help design a good Racket 
>> >> alternative.
>> >> There may be>> >> a ton of reusable functionality in a project like that.
>> >
>> >
>> > Over a decade ago, someone was actually doing game engine-ish stuff
>> > using>> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D
>> > training>> > simulator for first-responders in emergency scenarios.  It 
>> > might've
>> > used the>> > open-sourced Quake engine, or just built atop OpenGL; I forget
>> > whether I>> > heard.  At the time, I guess a Lisp was a big enough win for 
>> > that,
>> > and 

Re: [racket-users] Intro and projects inquiry

[Thomas Lynch]

Apparently Whalesong is such an alterntiave.
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
A Lisp dialect, Clojure, has caused a lot of young folks to ask
questions/to think about Lisp (
https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e).

On Thu, Oct 12, 2017 at 4:31 PM, David Storrs 
wrote:

> My suggestion would be that the single largest thing that would make
> Racket take off is if it could become a replacement for Javascript.
> The browser is the default GUI for most work these days, and doing
> real-time interfaces in the browser requires Javascript.  If Racket
> could run inside the browser and was more convenient to work with than
> Javascript then it would start climbing the hockey stick.  That would
> be an enormous project and I don't even know how you would get the
> popular browsers to adopt it; forking the browsers won't work and nor
> will making a plugin / addon -- it's got to run out of the box so that
> developers can rely on the fact that visitors to their site will be
> able to use it.
>
> For now, something that made it trivial to compile Racket to
> Javascript is probably the best option.  As it happens, I believe
> there is some effort in that direction. :>
>
> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke 
> wrote:
> > Eric Griffis wrote on 10/11/2017 07:44 PM:
> >>
> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke  >> > wrote:
> >>
> >>
> >> * Being there soon with a Web Assembly and HTML5 plus server
> >> full-stack
> >> story, in case developers respond favorably to that.
> >>
> >>
> >> Web back-ends are my wheelhouse. It sure would make my professional life
> >> easier... Not gonna lie, this isn't something I'd look forward to
> banging
> >> out alone.
> >
> >
> > There are some scalable HTTP protocol handling things I'd like to try,
> > including some hardcore systems-ish programming, and then multiple
> parties
> > (including me) could layer independent framework-y things over that
> > (server-side-only, and client-side-too).
> >
> > The WebAssembly part is what might be an emerging opportunity, but am
> > guessing the best way involves working with the tentative new Chez
> backend
> > for Racket.  (Also, WebAssembly didn't look very simple nor yet as
> > well-documented as you'd want, and looks still being hammered out.  So,
> > knowing how adopted Web standards tend to happen... you might have to
> put in
> > considerable effort to catch up with and track it, buy a gorilla suit,
> munch
> > some beetle grubs[1], and hopefully become accepted by the pack, to be
> > confident that Racket will be a first-class citizen in WebAssembly.)
> >
> >> * Push DSL-based programming, for which Racket might already have
> the
> >> best technology.  (The other day, I saw someone looking to hire
> >> developers to use some DSL-based speculative methodology thing...
> >> in Ruby.)
> >>
> >>
> >> This might also be interesting. Any concrete demand out there to drive
> the
> >> process?
> >
> >
> > Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
> > methodologists are always clamoring to invent and brand approaches, now
> > including applications of DSLs. :)
> >
> > (DSLs can be little mini-languages used by programmers as part of any
> kind
> > of programming, they can be used by programmers mix traditional language
> > paradigms in a code base, they can be used to support domain
> > experts/specialists capturing and maintaining knowledge/behavior separate
> > from programmers.)
> >
> >>
> >> The Godot game engine is kinda like this, but for Python. It has a lot
> of
> >> rough edges, which could help design a good Racket alternative. There
> may be
> >> a ton of reusable functionality in a project like that.
> >
> >
> > Over a decade ago, someone was actually doing game engine-ish stuff using
> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
> > simulator for first-responders in emergency scenarios.  It might've used
> the
> > open-sourced Quake engine, or just built atop OpenGL; I forget whether I
> > heard.  At the time, I guess a Lisp was a big enough win for that, and
> there
> > were a lot fewer and more primitive 3D game engines, that it made sense.
> > Today, whenever there is again a win to using Racket, I'd probably end up
> > taking an off-the-shelf (preferably libre-licensed) 3D game engine that
> met
> > all the other requirements, and make it work well with Racket.
> >
> > [1] Gary Larson, The Far Side, "So you're a *real* gorilla, are you?
> ...".
> > https://i.pinimg.com/736x/da/ed/ed/daeded47decfd2a200aca58b00a9d0e5.jpg
> >
> >
> > --
> > 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 

Re: [racket-users] Intro and projects inquiry

[David Storrs]

My suggestion would be that the single largest thing that would make
Racket take off is if it could become a replacement for Javascript.
The browser is the default GUI for most work these days, and doing
real-time interfaces in the browser requires Javascript.  If Racket
could run inside the browser and was more convenient to work with than
Javascript then it would start climbing the hockey stick.  That would
be an enormous project and I don't even know how you would get the
popular browsers to adopt it; forking the browsers won't work and nor
will making a plugin / addon -- it's got to run out of the box so that
developers can rely on the fact that visitors to their site will be
able to use it.

For now, something that made it trivial to compile Racket to
Javascript is probably the best option.  As it happens, I believe
there is some effort in that direction. :>

On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke  wrote:
> Eric Griffis wrote on 10/11/2017 07:44 PM:
>>
>> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke > > wrote:
>>
>>
>> * Being there soon with a Web Assembly and HTML5 plus server
>> full-stack
>> story, in case developers respond favorably to that.
>>
>>
>> Web back-ends are my wheelhouse. It sure would make my professional life
>> easier... Not gonna lie, this isn't something I'd look forward to banging
>> out alone.
>
>
> There are some scalable HTTP protocol handling things I'd like to try,
> including some hardcore systems-ish programming, and then multiple parties
> (including me) could layer independent framework-y things over that
> (server-side-only, and client-side-too).
>
> The WebAssembly part is what might be an emerging opportunity, but am
> guessing the best way involves working with the tentative new Chez backend
> for Racket.  (Also, WebAssembly didn't look very simple nor yet as
> well-documented as you'd want, and looks still being hammered out.  So,
> knowing how adopted Web standards tend to happen... you might have to put in
> considerable effort to catch up with and track it, buy a gorilla suit, munch
> some beetle grubs[1], and hopefully become accepted by the pack, to be
> confident that Racket will be a first-class citizen in WebAssembly.)
>
>> * Push DSL-based programming, for which Racket might already have the
>> best technology.  (The other day, I saw someone looking to hire
>> developers to use some DSL-based speculative methodology thing...
>> in Ruby.)
>>
>>
>> This might also be interesting. Any concrete demand out there to drive the
>> process?
>
>
> Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
> methodologists are always clamoring to invent and brand approaches, now
> including applications of DSLs. :)
>
> (DSLs can be little mini-languages used by programmers as part of any kind
> of programming, they can be used by programmers mix traditional language
> paradigms in a code base, they can be used to support domain
> experts/specialists capturing and maintaining knowledge/behavior separate
> from programmers.)
>
>>
>> The Godot game engine is kinda like this, but for Python. It has a lot of
>> rough edges, which could help design a good Racket alternative. There may be
>> a ton of reusable functionality in a project like that.
>
>
> Over a decade ago, someone was actually doing game engine-ish stuff using
> PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
> simulator for first-responders in emergency scenarios.  It might've used the
> open-sourced Quake engine, or just built atop OpenGL; I forget whether I
> heard.  At the time, I guess a Lisp was a big enough win for that, and there
> were a lot fewer and more primitive 3D game engines, that it made sense.
> Today, whenever there is again a win to using Racket, I'd probably end up
> taking an off-the-shelf (preferably libre-licensed) 3D game engine that met
> all the other requirements, and make it work well with Racket.
>
> [1] Gary Larson, The Far Side, "So you're a *real* gorilla, are you? ...".
> https://i.pinimg.com/736x/da/ed/ed/daeded47decfd2a200aca58b00a9d0e5.jpg
>
>
> --
> 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] Re: Thank you all for letting me speak

[David Storrs]

On Thu, Oct 12, 2017 at 6:04 AM, Geoffrey Knauth  wrote:
> I enjoyed your talk as well.

Thanks, Geoffrey.

>
> In my adopted family (cousins), I lost a sister and a brother to cancer.
> The sister was a cancer researcher.  The topic of your talk is from a
> personal point of view very compelling, and it is compelling for many people
> I know.

I'm sorry for your loss.  I hope we'll be able to make a difference in
cancer research, although I'm not arrogant enough to think it will be
a huge one.

> From a scientific point of view, the vision of what you're doing fills a
> void.
> What you are doing sounds very hard.  You are doing things that big storage
> companies say they don't want to do.  I can't tell if that is brave or
> foolish of you, but you didn't seem terribly worried, and that too is
> interesting.

I think it's less that they don't want to do it because it's
technically difficult, but because it's more difficult to monetize.
Google could do peer-to-peer networking with local storage if they
wanted to, but it's not in their interest.  It's much better for them
to control your data so that (a) you can't easily move away from them
and (b) they can data mine it in order to better target ads at you.
We (Biomantica) are not concerned with being a billion dollar company;
our goal is to contribute something to the world and make a good
living doing it.  Eventually James and I will probably exit and use
the resulting money to start something else; if you have $5M in the
bank then you can live on interest indefinitely, anywhere in the
country, meaning that you have infinite runway to work on your next
effort without having to take investment or scramble for grants.



> Given how much gene sequencing work has been done in Perl in the past, and
> given the speed advantage of almost anything besides Perl for very large
> data (I have some first-hand experience with large data and Perl from the
> 1990s), I think it's great you're using Racket for anything even remotely
> related to gene sequencing.

Thanks!  Perl gets used so much because it's a great language and
extremely practical, as well as having excellent and extensive modules
in everything including bioinformatics.  The people who object to it
typically do so on three grounds: (1) it's old, (2) they dislike its
use of punctuation, and (3) it's slower than some of the competition.
Personally, I think the first two are ridiculous calumnies, but you're
right about the third.  That's a problem that Racket shares, but it's
fast *enough* even if it's not fast overall.  Racket is also more
powerful than any other language I've worked in, fully staffed in
terms of modules, and a pleasure to write.

Dave


>
> --
> 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] indentation under for for/list for/vector for/hash ...

[Geoffrey Knauth]

Thanks!  In my case that turned out to be:

  > (find-system-path 'pref-file)
  #https://groups.google.com/d/optout.

Re: [racket-users] indentation under for for/list for/vector for/hash ...

[Robby Findler]

It is in the file that this expression evaluates to:

  (find-system-path 'pref-file)

Look in there for a sequence whose first position is
plt:framework-pref:framework:tabify and then delete that entire
sequence (close DrRacket before you edit the file so DrRacket doesn't
write to it while you're doing that -- not strictly necessary, but
simpler).

Robby


On Thu, Oct 12, 2017 at 7:29 AM, Geoffrey Knauth  wrote:
> Where is that possibly old preferences file?  I looked under ${HOME} (on a
> MBP) and didn't see anything obvious.  Otherwise I'm running a very recent
> nightly build.
>
> Thanks,
> Geoff
>
> --
> 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] indentation under for for/list for/vector for/hash ...

[Geoffrey Knauth]

Where is that possibly old preferences file?  I looked under ${HOME} (on a 
MBP) and didn't see anything obvious.  Otherwise I'm running a very recent 
nightly build.

Thanks,
Geoff

-- 
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] indentation under for for/list for/vector for/hash ...

[Robby Findler]

I guess that you probably have (had?) a default version of the preferences
that has an old, less helpful regexp in it. You might not see any changes
now, but you could also delete that line from the preferences file (and
closing drr) and then open it again to get a good setting.

Sorry we changed that in a way that your (and other's) drr don't pick it
up.

Robby

On Thu, Oct 12, 2017 at 6:04 AM Geoffrey Knauth  wrote:

> Philip, thanks, that did it!  I'll make a note of this in my hints file,
> in case I have to do this again.
>
> Geoff
>
> --
> 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] indentation under for for/list for/vector for/hash ...

[Geoffrey Knauth]

Philip, thanks, that did it!  I'll make a note of this in my hints file, in 
case I have to do this again.

Geoff

-- 
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] indentation under for for/list for/vector for/hash ...

[Philip McGrath]

In the DrRacket Preferences window, under the Editing > Indenting tab, you
want these forms to be recognized as "Lambda-like Keywords", either by
explicitly including them on the list or by having them match the "Extra
regexp". I believe the default settings recognize the Racket-provided
`for`-like macros.

I know I've made some customizations, but I see that I have some forms
(importantly `for` and `for*`) explicitly listed, and my "Extra regexp" is
`for\*?/|lambda`, which matches the others. Having this regexp doesn't
interfere with the forms that are explicitly included on the "For/fold-like
keywords" list being indented properly.

-Philip

On Thu, Oct 12, 2017 at 5:19 AM, Geoffrey Knauth  wrote:

> When I use for, for/list, for/vector or for/hash, I get this indentation:
>
> (for ([(i j) #hash(("a" . 1) ("b" . 20))])
>  (display (list i j)))
>
> instead of this:
>
> (for ([(i j) #hash(("a" . 1) ("b" . 20))])
>   (display (list i j)))
>
> If I want the latter, is there a setting I can use to get the two-spaces
> indentation under a for/thing that I want, as I do under a let?
>
> Geoff
>
> --
> 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] indentation under for for/list for/vector for/hash ...

[Geoffrey Knauth]

When I use for, for/list, for/vector or for/hash, I get this indentation:

(for ([(i j) #hash(("a" . 1) ("b" . 20))])
 (display (list i j)))

instead of this:

(for ([(i j) #hash(("a" . 1) ("b" . 20))])
  (display (list i j)))

If I want the latter, is there a setting I can use to get the two-spaces 
indentation under a for/thing that I want, as I do under a let?

Geoff

-- 
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: Thank you all for letting me speak

[Geoffrey Knauth]

I enjoyed your talk as well.

   1. In my adopted family (cousins), I lost a sister and a brother to 
   cancer.  The sister was a cancer researcher.  The topic of your talk is 
   from a personal point of view very compelling, and it is compelling for 
   many people I know.
   2. From a scientific point of view, the vision of what you're doing 
   fills a void.
   3. What you are doing sounds very hard.  You are doing things that big 
   storage companies say they don't want to do.  I can't tell if that is brave 
   or foolish of you, but you didn't seem terribly worried, and that too is 
   interesting.
   4. Given how much gene sequencing work has been done in Perl in the 
   past, and given the speed advantage of almost anything besides Perl for 
   very large data (I have some first-hand experience with large data and Perl 
   from the 1990s), I think it's great you're using Racket for anything even 
   remotely related to gene sequencing.

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