[racket-users] Can’t get `raco setup --mode errortrace` to work

[Alexis King]

I’m working on a project where having errortrace would be nice, but it’s
a little too big to want to run without compiling anything at all. From
the errortrace documentation, it seemed like `raco setup --mode
errortrace` was just what I wanted, so I gave it a shot with a simple
program. Here are the steps I took:

$ cd /tmp/test-pkg

$ cat main.rkt
#lang racket/base
(define (foo) (values (bar)))
(define (bar) (values (baz)))
(define (baz) (values (qux)))
(define (qux) (error 'qux "kaboom!"))
(foo)

$ raco pkg install --no-setup
Linking current directory as a package

$ racket -l errortrace -l test-pkg
qux: kaboom!
  errortrace...:
   /tmp/test-pkg/main.rkt:5:14: (error (quote qux) "kaboom!")
   /tmp/test-pkg/main.rkt:4:14: (values (qux))
   /tmp/test-pkg/main.rkt:3:14: (values (baz))
   /tmp/test-pkg/main.rkt:2:14: (values (bar))

$ raco setup --mode errortrace --pkgs test-pkg


$ racket -l errortrace -l test-pkg
qux: kaboom!
  errortrace...:

As you can see, when running main.rkt before compiling, I got a lot of
nice errortrace output, but after running `raco setup`, I didn’t get a
stack trace, even though I used `--mode errortrace`.

Did I do something wrong? If not, is this a bug or a missing feature? If
either of the latter, is it an issue with Racket or with errortrace?

-- 
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] Beginners question: implementing existing generics for existing structs

[Andrew Kent]

In this case, Alexis designed data/collection to work well with some of the
pre-existing Racket generic interfaces.

For example, since ddicts implement the gen:dict interface, you can use
them with data/collection already:

```
#lang racket

(require data/collection
 data/ddict)

(define dd (ddict 1 2 3 4 5 6))


(extend dd '((7 . 8) (9 . 10)))

#|
produces:
#
|#
```


On Tue, Jan 31, 2017 at 4:49 PM, Ronie Uliana 
wrote:

> Let's assume I have a struct that is not mine (like ddict [
> https://pkgn.racket-lang.org/package/ddict], or some of pfds [
> https://pkgn.racket-lang.org/package/pfds]). I'd like to implement
> generics for them that also are not mine :p (like data/collection from
> Alexis King).
>
> 1 - Is it possible?
> 2 - How do I do that?
>
> I searched through generics documentation, but I think I completely missed
> that part =/
>
> []s an thx!
> Ronie
>
> --
> 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] Beginners question: implementing existing generics for existing structs

[Jon Zeppieri]

On Tue, Jan 31, 2017 at 4:49 PM, Ronie Uliana  wrote:
> Let's assume I have a struct that is not mine (like ddict 
> [https://pkgn.racket-lang.org/package/ddict], or some of pfds 
> [https://pkgn.racket-lang.org/package/pfds]). I'd like to implement generics 
> for them that also are not mine :p (like data/collection from Alexis King).
>
> 1 - Is it possible?
> 2 - How do I do that?
>

Short of sending a pull request to the package maintainer, I don't
think it's possible, and it seems like any attempt to make that work
would invite modularity problems similar to the instance coherence
problem for type classes. Consider two modules that implement
gen:serializable for the same struct type in incompatible ways. -J

-- 
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] Second Call for Papers: ICFP 2017

['Lindsey Kuper' via users-redirect]

  ICFP 2017
The 22nd ACM SIGPLAN International Conference on Functional Programming
 Oxford, United Kingdom
   http://icfp17.sigplan.org/
 Second Call for Papers
 
### Important dates

Submissions due:Monday, February 27, Anywhere on Earth
https://icfp17.hotcrp.com
Author response:Monday, April 17, 2017, 15:00 (UTC) -
Thursday, April 20, 2017, 15:00 (UTC)
Notification:   Monday, 1 May, 2017
Final copy due: Monday, 5 June 2017
Early registration: TBA
Conference: Monday, 4 September -
Wednesday, 6 September, 2017

### Updates for Second Call for Papers

This revision, published January 31, 2017, includes the following updates:
 
  * A link to the list of frequently asked questions about the
double-blind review process.

  * A new requirement for citations in author-year format. This follows
a decision for PACMPL that was made after the original version of
this call was distributed. As such, author-year format will be
required for final (accepted) versions of papers in ICFP 2017, but
not for submissions.

  * Additional guidance for authors using LaTeX.

  * A clarification about the expectations for author attendance in the
event of visa-related problems.

### New this year

Those familiar with previous ICFP conferences should be aware of two
significant changes that are being introduced in 2017:

1. Papers selected for ICFP 2017 will be published as the ICFP 2017
issue of a new journal, Proceedings of the ACM on Programming Languages
(PACMPL), which replaces the previous ICFP conference proceedings. The
move to PACMPL will have two noticeable impacts on authors:

* A new, two-phase selection and reviewing process that conforms to
  ACM’s journal reviewing guidelines.

* A new, single-column format for submissions.

2. Authors of papers that are conditionally accepted in the first phase
of the reviewing process will have the option to submit materials for
Artifact Evaluation.

Further details on each of these changes are included in the following
text.

### Scope

ICFP 2017 seeks original papers on the art and science of functional
programming. Submissions are invited on all topics from principles to
practice, from foundations to features, and from abstraction to
application. The scope includes all languages that encourage functional
programming, including both purely applicative and imperative languages,
as well as languages with objects, concurrency, or parallelism. Topics
of interest include (but are not limited to):

  * *Language Design*: concurrency, parallelism, and distribution;
modules; components and composition; metaprogramming; type systems;
interoperability; domain-specific languages; and relations to
imperative, object-oriented, or logic programming.

  * *Implementation*: abstract machines; virtual machines;
interpretation; compilation; compile-time and run-time optimization;
garbage collection and memory management; multi-threading;
exploiting parallel hardware; interfaces to foreign functions,
services, components, or low-level machine resources.

  * *Software-Development Techniques*: algorithms and data structures;
design patterns; specification; verification; validation; proof
assistants; debugging; testing; tracing; profiling.

  * *Foundations*: formal semantics; lambda calculus; rewriting; type
theory; monads; continuations; control; state; effects; program
verification; dependent types.

  * *Analysis and Transformation*: control-flow; data-flow; abstract
interpretation; partial evaluation; program calculation.

  * *Applications*: symbolic computing; formal-methods tools; artificial
intelligence; systems programming; distributed-systems and web
programming; hardware design; databases; XML processing; scientific
and numerical computing; graphical user interfaces; multimedia and
3D graphics programming; scripting; system administration; security.

  * *Education*: teaching introductory programming; parallel
programming; mathematical proof; algebra.

Submissions will be evaluated according to their relevance, correctness,
significance, originality, and clarity. Each submission should explain
its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical content
should be accessible to a broad audience.

ICFP 2017 also welcomes submissions in two separate categories ---
Functional Pearls and Experience Reports --- that must be marked as
such at the time of submission and that need not report original
research results.  Detailed guidelines on both categories are given at
the end of this call.

Please contact the program chair if you have questions or are concerned

Re: [racket-users] DrRacket debugger

[Dan Liebgold]

On Monday, January 30, 2017 at 1:43:06 PM UTC-8, Robby Findler wrote:

The simple program seems to work ok.

It appears my problem is related to bytecode compilation (this occurs on a 
smallish program that pulls in a large library)... it takes awhile for the 
buttons to respond, and it seems like I'm able to more easily get it into a bad 
state?


> It isn't an issue I know about.
> 
> I don't see that with this simple program:
> 
> #lang racket
> (let loop () (loop))
> 
> Do you?
> 
> Robby
> 

-- 
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] Beginners question: implementing existing generics for existing structs

[Ronie Uliana]

Let's assume I have a struct that is not mine (like ddict 
[https://pkgn.racket-lang.org/package/ddict], or some of pfds 
[https://pkgn.racket-lang.org/package/pfds]). I'd like to implement generics 
for them that also are not mine :p (like data/collection from Alexis King).

1 - Is it possible?
2 - How do I do that?

I searched through generics documentation, but I think I completely missed that 
part =/

[]s an thx!
Ronie

-- 
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: Package layout in docs

[Ethan Estrada]

On Mon, Jan 30, 2017 at 6:17 PM, Hendrik Boom  wrote:
> While we were talking about "core" and non-"core"packages, there was
> controversy.  Now that we have changed words, and are talking about
> "rings", we seem to be happier.  What a difference a word makes!  Or
> is there a technical distinction I am missing?

On Jan 31, 2017 06:28, "Jay McCarthy"  wrote:
> I think most people read "core" as "made by people who are in Matthias
> Felleisen's academic family tree", but the idea of "ring" is that
> there's some quasi-objective standard that anyone can meet and get
> blessed by the community as a great package.

The "ring" approach sounds like a good direction to me. I think the
problem of "What do I already have and what do I need to go out and
fetch" still isn't fully resolved by rings, but I think it easily can
be addressed. One way could be by adding an extra option to 'raco pkg
install' that would simply install all ring0 packages. As I'm writing
this though, I realize that the one issue is that as the package index
gets bigger, this puts serious strain on both the package server(s)
and the user's network bandwidth.

Possibly the best may me to be clear on the docs about it. It is very
different from any other software ecosystem, which isn't necessarily a
bad thing; in fact, I would say it is a good thing. However, this
means that it probably should have an explanation available to
newcomers. I would add something like the following to the main docs
page or in a docs FAQ or wherever it is obvious and accessible. In FAQ
style:

- "Hey, where's the standard library?

Although Racket ships with some module code maintained by the core
team, it isn't a standard library. Instead the Racket ecosystem
utilizes a package "ring" system; you can learn more about it here:
(some link). If you aren't certain a frequently mentioned package is
already available, simply attempt to install it with 'raco pkg install
--skip-installed --ring0-only '."

--
Ethan Estrada

-- 
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: Package layout in docs

[Neil Van Dyke]

Jack Firth wrote on 01/31/2017 03:11 PM:
If the package build server and catalog hosted built packages for 
multiple Racket versions, I think we could go a long ways towards 
removing the need to split packages completely.


If there's important requirements driving that, and if that's a good 
solution.


I've seen a lot of effort put into infrastructure size bloat 
(e.g., creating several separate implementation variations for 
essentially the same thing, in case anyone ever wants to do it one of 
those many ways) that looks like it will likely encumber solving actual 
very important ongoing problems.


Sometimes size/complexity bloat is worthwhile or at least benign, 
sometimes closer to malignant.


--
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: Package layout in docs

[Jack Firth]

On Tuesday, January 31, 2017 at 11:25:31 AM UTC-8, Neil Van Dyke wrote:
> For the benefit of the tightwad people, packages could optionally 
> include metadata about any docs and tests that can be stripped -- 
> anything nonessential to "run-only" the package.  This metadata could be 
> used by either the installation tools or by a package file transformer 
> tool that people can run themselves.  (And, eventually, these tests and 
> documentation might normally be linguistic constructs anyway, embedded 
> within the code, not something in their own files that can be maintained 
> in a separate package from the implementation.)  The package catalog 
> still only lists the one canonical package, though.

This currently exists. All dependencies used in test and doc submodules and 
scribblings/ modules are build dependencies (defined in `build-deps` in 
info.rkt) and when installing a pre-built package, you can optionally omit 
build dependencies by installing the package with the `--binary` and 
`--binary-lib` flags. The package build server also creates a separate "built 
packages" catalog that hosts pre-built versions of packages. Unfortunately, 
pre-built packages are specific to a Racket version so this catalog is only 
usable if you're using the latest Racket version.

If the package build server and catalog hosted built packages for multiple 
Racket versions, I think we could go a long ways towards removing the need to 
split packages completely.

-- 
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: Package layout in docs

[Neil Van Dyke]

Greg Trzeciak wrote on 01/31/2017 01:24 PM:

Speaking of packages - there seems to be a trend recently in racket packages to create 
separate packages for main, lib, doc, test, etc. This causes an artificial inflation in 
available packages and IMHO may cause some confusion for newcomers as instead of finding 
eg. "PackageX" we now get the following instead:


I agree with Greg that this looks like people are going out of their way 
to make clutter.  I don't think that ever should have been encouraged.


I think the "lightweight languages" way to do this is to do this in most 
cases is to distribute a single package that includes the 
implementation+tests+scribble, not split up the package.  The normal 
case should be to include everything in a package as a developer or 
library user, including modifying it.  Packages only rarely are big, and 
hardly anyone is working on tiny microcontrollers or other tight 
deployments.


For the benefit of the tightwad people, packages could optionally 
include metadata about any docs and tests that can be stripped -- 
anything nonessential to "run-only" the package.  This metadata could be 
used by either the installation tools or by a package file transformer 
tool that people can run themselves.  (And, eventually, these tests and 
documentation might normally be linguistic constructs anyway, embedded 
within the code, not something in their own files that can be maintained 
in a separate package from the implementation.)  The package catalog 
still only lists the one canonical package, though.


A rare special case would be things like demos that pull in big 
dependencies that are often not wanted (e.g., neural nets library that 
has a GUI demo).  That demo you might put in a separate package, for the 
same reasons you might put a big neural nets GUI visualizer tool in a 
separate package from your neural nets library, even if it wasn't a demo 
-- because it has big different dependencies, and the main functionality 
of the package is very often used without it.  (Of course, not all demos 
have to be in a separate package.  The `charterm` demo has a small 
implementation, and doesn't pull in big additional dependencies, so I 
just threw it into the main package, and documented it that way: 
"http://www.neilvandyke.org/racket/charterm/#%28part._.Demo%29;.)


Another rare special case is when you have big "test data" that you 
can't trim down and you really think should be distributed with the 
package.  Offhand, I can think of only one example I'm aware of this in 
Racket, though I assume there are some situations I don't know about, 
and it does occur with real-world research data.  When it's research 
data, this might also involve open scientific data archiving/sharing 
efforts, and you might want to look at those efforts in your field.  Of 
course, big real-world data might not be that good as software 
engineering regression tests anyway, even if you ran the data through 
"as a test" or as a practical application of your code for your thesis, 
so maybe that data doesn't belong in the package anyway.


Again, I think the normal case is one package that includes all 
implementation+tests+scribbles.


--
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] How to determine that an image file is valid and working in image-snip%

[Erich Rast]

Hi!

Is there a correct/"best practice" cross-platform way to determine
whether a given pathname obtained from on-drop-file of an
editor-canvas% leads to a valid image file that can be displayed by an
image-snip% in a text%? Is there an official function that checks an
image file? (It may load the image but should avoid crashing the
application when the image file is corrupt or very huge.)

I ask because I'd like to avoid making assumptions based on file
suffixes if possible.

Best,

Erich

-- 
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: Package layout in docs

[Greg Trzeciak]

On Tuesday, January 31, 2017 at 7:29:44 PM UTC+1, Jay McCarthy wrote:
> I think it would be nice to change the frontend to collapse them
> together in some meaningful way to help read the catalog.
> 
> Jay

+1
That would solve the issue.

-- 
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: Package layout in docs

[Jay McCarthy]

I think it would be nice to change the frontend to collapse them
together in some meaningful way to help read the catalog.

Jay

On Tue, Jan 31, 2017 at 1:29 PM, Jay McCarthy  wrote:
> On Tue, Jan 31, 2017 at 1:24 PM, Greg Trzeciak  wrote:
>> Other than package creator's convenience - is their any rationale for this 
>> trend I don't see?
>
> Actually, it is INCONVENIENT for the creator. It provides to the users
> the ability to install the library without docs (good for deployment)
> or without tests (good for users), etc.
>
> Jay
>
> --
> Jay McCarthy
> Associate Professor
> PLT @ CS @ UMass Lowell
> http://jeapostrophe.github.io
>
>"Wherefore, be not weary in well-doing,
>   for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
>   - D 64:33



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
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: Package layout in docs

[Jay McCarthy]

On Tue, Jan 31, 2017 at 1:24 PM, Greg Trzeciak  wrote:
> Other than package creator's convenience - is their any rationale for this 
> trend I don't see?

Actually, it is INCONVENIENT for the creator. It provides to the users
the ability to install the library without docs (good for deployment)
or without tests (good for users), etc.

Jay

-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
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: Package layout in docs

[Greg Trzeciak]

Speaking of packages - there seems to be a trend recently in racket packages to 
create separate packages for main, lib, doc, test, etc. This causes an 
artificial inflation in available packages and IMHO may cause some confusion 
for newcomers as instead of finding eg. "PackageX" we now get the following 
instead:
PackageX
PackageX-doc
PackageX-lib
PackageX-demo
PackageX-test

Most likely the only package out of these installed by anyone other than the 
package author will be "PackageX"

Other than package creator's convenience - is their any rationale for this 
trend I don't see? 

Regards

Greg

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

Capturing Unix signals (was Re: [racket-users] Best way to ensure threads finish in GUI application?)

[Tony Garnock-Jones]

Hi Erich,

On 01/31/2017 08:23 AM, Erich Rast wrote:
> Related to that, does application-quit-handler capture signals on
> Linux, and if so, which ones, and/or is there a way to install signal
> handlers in Racket?

There's a package, https://pkgn.racket-lang.org/package/unix-signals,
that includes a small C extension that allows capturing signals.

Here is the documentation for the package:
http://docs.racket-lang.org/unix-signals/index.html

Cheers,
  Tony

-- 
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] Package layout in docs

[WarGrey Gyoudmon Ju]

On Tue, Jan 31, 2017 at 9:12 PM, Matthias Felleisen 
wrote:

>
> > On Jan 31, 2017, at 12:37 AM, WarGrey Gyoudmon Ju 
> wrote:
> >
> > Hello.
> >
> > This is one of the culture shocks that a new Racketeer would face, and
> so was I.
> > But this statement makes it clear to me: Racket is an operating system
> that pretend to a programming language;
> >
> > Yes, it may totally be a kind of over reading here.
>
>
> No, you’re not. See third principle of the Racket Manifesto
> (internalization) and the Revenge of the Son of the Lisp Machine.


Oh, I just forgot the Manifesto[1].
So why not give it an entry in the index page? just like "How to Program
Racket: a Style Guard";
or make a margin-note that links to it in the section "Naming and Designing
Packages"[2].

[1] http://www.ccs.neu.edu/home/matthias/manifesto/
[2]
https://docs.racket-lang.org/pkg/getting-started.html#%28part._.Naming_and_.Designing_.Packages%29

-- 
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] Best way to ensure threads finish in GUI application?

[Erich Rast]

Fantastic! I didn't know about "plumbers" at all.

Thanks a lot!

Best,

Erich

On Tue, 31 Jan 2017 06:33:03 -0700
Matthew Flatt  wrote:

> I think you probably want `plumber-add-flush-handle!`:
> 
>   http://docs.racket-lang.org/reference/plumbers.html
> 
> At Tue, 31 Jan 2017 13:23:03 +, Erich Rast wrote:
> > Hi,
> > 
> > I was wondering what's the best way to ensure that threads end
> > when a gui application is shut down, which synchronization
> > mechanism I should use and which kind of program terminations would
> > be handled gracefully  by this.
> > 
> > I'm planning on delaying certain sqlite transactions in threads,
> > since doing them immediately when the user interacts with the GUI
> > does not work well. AFAIK, sqlite is ACID-compliant, so db
> > consistency should not be a concern, but I still need to figure out
> > which mechanism to use for ensuring that the main thread waits for
> > the remaining threads to finish, and under which conditions it will
> > fail. I've read about custodians and application-quit-handler.
> > Should I use the latter? Which timeout is "safe" on which platform?
> > (E.g. Windows waits for applications to finish before it shuts
> > down, but not indefinitely, and how about Linux and OSX?)
> > 
> > Related to that, does application-quit-handler capture signals on
> > Linux, and if so, which ones, and/or is there a way to install
> > signal handlers in Racket?
> > 
> > Sorry for posing so many questions at once. I just wonder what the
> > practice is for this common scenario. Thanks in advance for any
> > replies!
> > 
> > Best,
> > 
> > Erich
> > 
> > -- 
> > 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] Best way to ensure threads finish in GUI application?

[Matthew Flatt]

I think you probably want `plumber-add-flush-handle!`:

  http://docs.racket-lang.org/reference/plumbers.html

At Tue, 31 Jan 2017 13:23:03 +, Erich Rast wrote:
> Hi,
> 
> I was wondering what's the best way to ensure that threads end
> when a gui application is shut down, which synchronization mechanism I
> should use and which kind of program terminations would be handled
> gracefully  by this.
> 
> I'm planning on delaying certain sqlite transactions in threads,
> since doing them immediately when the user interacts with the GUI does
> not work well. AFAIK, sqlite is ACID-compliant, so db consistency
> should not be a concern, but I still need to figure out which mechanism
> to use for ensuring that the main thread waits for the remaining
> threads to finish, and under which conditions it will fail. I've read
> about custodians and application-quit-handler. Should I use the latter?
> Which timeout is "safe" on which platform? (E.g. Windows waits for
> applications to finish before it shuts down, but not indefinitely, and
> how about Linux and OSX?)
> 
> Related to that, does application-quit-handler capture signals on
> Linux, and if so, which ones, and/or is there a way to install signal
> handlers in Racket?
> 
> Sorry for posing so many questions at once. I just wonder what the
> practice is for this common scenario. Thanks in advance for any replies!
> 
> Best,
> 
> Erich
> 
> -- 
> 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: Package layout in docs

[Jay McCarthy]

On Mon, Jan 30, 2017 at 6:17 PM, Hendrik Boom  wrote:
> While we were talking about "core" and non-"core"packages, there was
> controversy.  Now that we have changed words, and are talking about
> "rings", we seem to be happier.  What a difference a word makes!  Or
> is there a technical distinction I am missing?

I think most people read "core" as "made by people who are in Matthias
Felleisen's academic family tree", but the idea of "ring" is that
there's some quasi-objective standard that anyone can meet and get
blessed by the community as a great package.

Jay

-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
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] Best way to ensure threads finish in GUI application?

[Erich Rast]

Hi,

I was wondering what's the best way to ensure that threads end
when a gui application is shut down, which synchronization mechanism I
should use and which kind of program terminations would be handled
gracefully  by this.

I'm planning on delaying certain sqlite transactions in threads,
since doing them immediately when the user interacts with the GUI does
not work well. AFAIK, sqlite is ACID-compliant, so db consistency
should not be a concern, but I still need to figure out which mechanism
to use for ensuring that the main thread waits for the remaining
threads to finish, and under which conditions it will fail. I've read
about custodians and application-quit-handler. Should I use the latter?
Which timeout is "safe" on which platform? (E.g. Windows waits for
applications to finish before it shuts down, but not indefinitely, and
how about Linux and OSX?)

Related to that, does application-quit-handler capture signals on
Linux, and if so, which ones, and/or is there a way to install signal
handlers in Racket?

Sorry for posing so many questions at once. I just wonder what the
practice is for this common scenario. Thanks in advance for any replies!

Best,

Erich

-- 
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: Package layout in docs

[Hendrik Boom]

On Tue, Jan 31, 2017 at 01:37:41PM +0800, WarGrey Gyoudmon Ju wrote:
> Hello.
> 
> This is one of the culture shocks that a new Racketeer would face, and so
> was I.
> But this statement makes it clear to me: Racket is an operating system that
> pretend to a programming language;

Much like emacs, also based on Lisp.  It's a wonderful operating 
system and user-interface for machines with just an old-style 
characters-only CRT.

And it too is based on Lisp.

> 
> Yes, it may totally be a kind of over reading here.
> 
> Say, I do not care if a manual page is the one shipped with unix
> distribution or installed by user, same to shell commands and shared
> objects, all entries should globally unique.

The important distinctions are the level of maturity of the API, its
long-term stablity and the availability of maintainers to fix problems 
if they should arise.

-- hendrik

> 
> Okay, the documentation system is a little different here, it can be
> provided with a different front page, and obviously there is no way to
> satisfy all.
> Actually I am afraid of where to insert the entry of my package as well.
> 
> Of my preference, I would suggest putting status icons (or even emojis) in
> front of every entry in the index page based on the ring system.
> 
> On Tue, Jan 31, 2017 at 11:57 AM, Philip McGrath 
> wrote:
> 
> > I was also going to suggest the ring system as a way of giving more
> > information without imposing an unnecessary artificial distinction. In
> > general I'm enthusiastic about the benefits of not having a sharp dividing
> > line, but it would be useful to show more clearly in the documentation
> > which packages have been vetted to "ring zero" standards.
> >
> >
> >
> >
> > On Mon, Jan 30, 2017 at 8:46 PM, Jack Firth  wrote:
> >
> >> Rather than splitting "core packages" from "community packages", what if
> >> we used the package ring system? [1] We could establish a way for the
> >> Racket community to bless packages with "ring zero" status, then provide a
> >> --catalog argument to Scribble to lookup ring information in when deciding
> >> how to style package documentation. The docs would remain unified, we'd
> >> have a centralized place to curate packages, and there's no artificial
> >> barrier that prevents user-contributed packages from living alongside
> >> main-distribution packages.

While we were talking about "core" and non-"core"packages, there was 
controversy.  Now that we have changed words, and are talking about 
"rings", we seem to be happier.  What a difference a word makes!  Or 
is there a technical distinction I am missing?

> >>
> >> [1] http://docs.racket-lang.org/pkg/Future_Plans.html?q=ring
> >>

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

Re: [racket-users] Package layout in docs

[Matthias Felleisen]

> On Jan 31, 2017, at 12:37 AM, WarGrey Gyoudmon Ju  
> wrote:
> 
> Hello.
> 
> This is one of the culture shocks that a new Racketeer would face, and so was 
> I.
> But this statement makes it clear to me: Racket is an operating system that 
> pretend to a programming language;
> 
> Yes, it may totally be a kind of over reading here.


No, you’re not. See third principle of the Racket Manifesto (internalization) 
and the Revenge of the Son of the Lisp Machine. 



> 
> Say, I do not care if a manual page is the one shipped with unix distribution 
> or installed by user, same to shell commands and shared objects, all entries 
> should globally unique.
> 
> Okay, the documentation system is a little different here, it can be provided 
> with a different front page, and obviously there is no way to satisfy all.
> Actually I am afraid of where to insert the entry of my package as well.
> 
> Of my preference, I would suggest putting status icons (or even emojis) in 
> front of every entry in the index page based on the ring system.


Everyone, 

I really like your brain storming here. This issue is something that definitely 
deserves discussion, and it would be terrific  if the community can come up 
with a near-consensus idea. In any case, I have put this topic on the agenda 
for our next coordination meeting where we will consider your ideas and discuss 
them. 

— Matthias

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