[racket-users] SUBJECT: ACM/SPEC ICPE'17 - Call for Participation

[Andrea Rosà]

ICPE 2017
8th ACM/SPEC International Conference on Performance Engineering

    Sponsored by ACM SIGMETRICS, SIGSOFT, and SPEC RG

L'Aquila, Italy
   April 22-27, 2017

      https://icpe2017.spec.org/



---

The goal of the International Conference on Performance Engineering (ICPE) is 
to integrate theory and practice in the field of performance engineering by 
providing a forum for sharing ideas and experiences between industry and 
academia. Nowadays, complex systems of all types, like Web-based systems, data 
centers and cloud infrastructures, social networks, peer-to-peer, mobile and 
wireless systems, cyber-physical systems, the Internet of Things, real-time and 
embedded systems, have increasingly distributed and dynamic system 
architectures that provide high flexibility, however, also increase the 
complexity of managing end-to-end application performance.

ICPE brings together researchers and industry practitioners to share and 
present their experiences, discuss challenges, and report state-of-the-art and 
in-progress research on performance engineering of software and systems, 
including performance measurement, modeling, benchmark design, and run-time 
performance management. The focus is both on classical metrics such as response 
time, throughput, resource utilization, and (energy) efficiency, as well as on 
the relationship of such metrics to other system properties including but not 
limited to scalability, elasticity, availability, reliability, and security. 

---

PROGRAM

ICPE'17 takes place from April 22 to 27, 2017. 
The main conference runs from April 24 to 26, with a welcome reception on April 
24 and a banquet on April 25. 
Tutorials are held on April 22 and 23, while workshops take place on April 22, 
23, and 27. 

The preliminary program is available at 
https://icpe2017.spec.org/conference-program.html

The following eight workshops will be held in conjunction with the main 
conference:

- Saturday, April 22:
-- ACPROSS: Autonomous Control for Performance and Reliability Trade-offs in 
Internet of Services
-- PABS: Third International Workshop on Performance Analysis of Big Data 
Systems
-- WOSP-C: Workshop on Challenges in Performance Methods for Software 
Development

- Sunday, April 23:
-- ENERGY-SIM: Third International Workshop on Energy-aware Simulation
-- LTB: Sixth International Workshop on Load Testing and Benchmarking of 
Software Systems
-- MoLS: First International Workshop on Monitoring in Large-Scale Software 
Systems
-- WEPPE: Workshop on Education and Practice of Performance Engineering

- Thursday, April 27:
-- QUDOS: Third International Workshop on Quality-aware DevOps

More information on the workshops can be found at 
https://icpe2017.spec.org/conference-program/conference-workshops.html


---

REGISTRATION

Registration is open! To register to ICPE'17 or to the co-located workshops and 
tutorials, please follow the instruction at the following link: 
https://icpe2017.spec.org/registration.html. 

Early registration deadline: March 24, 2017


---

KEYNOTE

We are proud to announce our keynote speakers for ICPE'17:

--

Arif Merchant
(Google)
 
Title: Autonomic storage management at scale
 
Abstract:
Cloud data centers use enormous amounts of storage, and it is critical to 
monitor, manage, and optimize the storage autonomically. Optimally configuring 
storage is difficult because storage workloads are very diverse and change over 
time. Data centers measure running workloads, but this measurement data stream 
is itself quite large. We present some real world case studies in the use of 
big data techniques, sampling, and optimization to manage storage in data 
centers.
 
Short bio:
Arif Merchant is a Research Scientist at Google and leads the Storage Analytics 
group, which studies interactions between components of the storage stack. His 
interests include distributed storage systems, storage management, and 
stochastic modeling. He holds the B.Tech. degree from IIT Bombay and the Ph.D. 
in Computer Science from Stanford University. He is an ACM Distinguished 
Scientist.

--

Francesco Quaglia
(University of Rome "La Sapienza")

Title: Performance is Also a Matter of Where You Live

Abstract:
Nowadays, a plethora of techniques and methods are available to optimize the 
runtime behavior of complex applications, ranging from modeling/prediction 
tools to the 

[racket-users] Re: prepared queries

[Ryan Culpepper]

On 03/13/2017 06:30 PM, George Neuner wrote:

Hi Ryan,

On 3/13/2017 5:43 PM, Ryan Culpepper wrote:


Racket's db library always prepares a statement before executing it,
even if there are no query parameters. When allowed, instead of
closing the prepared statement immediately after executing it, the
connection stores it in a (Racket-side, per-connection) cache. The
cache key is just the SQL string. If you use the same query string
with different parameters, you'll still get the cached prepared
statement.

To extend my previous example:

  > (query c "select $1::integer" 1)
  
  ** caching statement
  
  > (query c "select $1::integer" 2)
  ** using cached statement
  

On the other hand, if the query string is not identical, it misses the
cache.


Hmm.   Then what is the purpose of having separate (prepare ...)?


Explicit control, history (the statement cache is much newer), and 
reflection (eg prepared-statement-result-types).



And what happens if the unknowing user issues a PREPARE statement for the
query directly to the DBMS?


You mean like PostgreSQL's PREPARE/EXECUTE commands? Those should work 
fine too, as long as the statements are given names distinct from the 
obscure names chosen by the db library.



Then there is the issue that deliberately prepared queries are not
optimized as heavily as normal queries - which is the case in pretty
much every DBMS that exists.  Heavyweight queries that require maximum
performance are harmed by preparation.


In general, performing a query consists of three steps: Prepare, Bind, 
and Execute. When there's a "one-step" approach, it's just a convenience 
wrapper around those three steps. So I'd be very surprised if Prepare 
intrinsically slowed down a query.


Maybe you mean that *parameterization* inhibits the query planner, 
because query planning doesn't take the values of query parameters into 
account. That seems to depend on the backend. PostgreSQL did planning at 
Prepare time before version 9.2 and does it at Bind time since 9.2 
("typically", the docs say). I don't know about other systems. But in 
any case, parameterization is under the control of the user.


If that's not what you meant, can you elaborate?


Moreover, prepared queries are not cached in the normal sense ... they
persist until explicitly dropped, or until the connection is closed.
There are both per connection and global limits on the number of
prepared queries, and bad things can happen if these limits are
exceeded  [e.g., I've seen versions of Postgresql freeze and Sybase
crash in such circumstances].   A long running application using pool
connections could get into trouble.


The statement cache is limited to 20 statements by default, and the 
statement cache is only enabled within transactions and flushed on 
commit/rollback. Also, connections returned to a connection pool with an 
open transaction are disconnected rather than reused.


Ryan

--
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] refactoring help/tools?

[Daniel Feltey]

I've started working on adding this refactoring to DrRacket[1], it's not
quite as full-featured(and is definitely still a bit buggy) as what
racket-mode in emacs seems to allow, but it's a first step and I'd
appreciate suggestions or requests on how DrRacket can better support
developers editing and refactoring code.

[1] https://github.com/racket/drracket/pull/97

Dan

On Mon, Mar 13, 2017 at 7:30 PM, Greg Hendershott  wrote:

> The `racket-trim-requires` and `racket-base-requires` commands use
> `raco check-requires` behind the scenes (then format/sort as does
> `racket-tidy-requires`).
>
> Today I tried to use `racket-trim-requires` on a Typed Racket file
> containing `define-type`; and got the error you mention. This turned
> out to be an issue with `raco check-requires`; thanks to a hint from
> Sam on Slack, I pushed a a PR that Ryan merged:
>
>   https://github.com/racket/macro-debugger/pull/22
>
> I just now saw this thread, which is weird timing!
>
> I'd welcome hearing any other examples where racket-{tidy
> base}-requires doesn't work -- and `raco check-requires` on that same
> file works or not. (Of course I'd also understand if folks are too
> busy to detour to report them.)
>
>
> On Mon, Mar 13, 2017 at 1:50 PM, Dan Liebgold
>  wrote:
> > raco check-requires does the job.
> >
> > I use emacs racket-mode, but it's hobbled in ways I haven't investigated
> -- e.g. when I try to use tidy or trim requires it gives me a "Can't do,
> source file has error" when it doesn't, or at least not in a way I can see.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Why does 1 count as numeric in xexpr, but 0 does not?

[Philip McGrath]

Numbers in x-expressions are interpreted as XML entities, not as the string
representation of the number. The value of (xexpr->string '(html 1)), to
use your example, is "". The 1 represents the character
that Racket would represent as #\u0001, i.e. the value of (integer->char
1). In contrast, (char->integer #\1) produces 49.

-Philip

On Mon, Mar 13, 2017 at 8:38 PM, Marc Kaufmann 
wrote:

> Hi,
>
> I am creating matrices of 0s and 1s that I display in HTML-tables and
> somewhat surprisingly I found out that 0s are not permissible in
> X-expressions, while 1s are:
>
> (require web-server/http)
>
> (response/xexpr '(html 1)) ; Fine, no trouble.
> (response/xexpr '(html 0)) ; Blow-up.
>
> The specific violation is the following:
>
> "response/xexpr: contract violation;
>  Not an Xexpr. Expected a string, symbol, valid numeric entity, comment,
> processing instruction, or list, given 0"
>
> After some digging around, it turns out that only numbers that satisfy
> valid-char? are acceptable, which means "exact-nonnegative-integer whose
> character interpretation under UTF-8 is from the set ([#x1-#xD7FF] |
> [#xE000-#xFFFD] | [#x1-#x10]), in accordance with section 2.2 of
> the XML 1.1 spec."
>
> First, should 0 really not be accepted? (I am not going to try and figure
> out the UTF-8 interpretation...) And second, is the reason that negative
> numbers are not acceptable that they are not under the XML spec above? This
> took me by surprise and means I have to put number->string in a bunch of
> places.
>
> Cheers,
> Marc
>
> --
> 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] Require the same file repeatedly for debugging on command line

[Marc Kaufmann]

Hi all,

while trying to debug, I often change the code in the text file and then want 
to do a (require "file-with-code.rkt") on the command line to test the new 
code. This never works, because I cannot redefine imported modules. Thus I 
always use Dr Racket for this, where I can hit the "Run" button, which reruns 
everything and all is good. Since I prefer to use Vim for editing, I was 
wondering if there is an equivalent of the "Run" button for the command line 
(well, for the require at least)?

Thanks,
Marc

-- 
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] Why does 1 count as numeric in xexpr, but 0 does not?

[Marc Kaufmann]

Hi,

I am creating matrices of 0s and 1s that I display in HTML-tables and somewhat 
surprisingly I found out that 0s are not permissible in X-expressions, while 1s 
are:

(require web-server/http)

(response/xexpr '(html 1)) ; Fine, no trouble.
(response/xexpr '(html 0)) ; Blow-up.

The specific violation is the following:

"response/xexpr: contract violation;
 Not an Xexpr. Expected a string, symbol, valid numeric entity, comment, 
processing instruction, or list, given 0"

After some digging around, it turns out that only numbers that satisfy 
valid-char? are acceptable, which means "exact-nonnegative-integer whose 
character interpretation under UTF-8 is from the set ([#x1-#xD7FF] | 
[#xE000-#xFFFD] | [#x1-#x10]), in accordance with section 2.2 of the 
XML 1.1 spec." 

First, should 0 really not be accepted? (I am not going to try and figure out 
the UTF-8 interpretation...) And second, is the reason that negative numbers 
are not acceptable that they are not under the XML spec above? This took me by 
surprise and means I have to put number->string in a bunch of places.

Cheers,
Marc

-- 
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] refactoring help/tools?

[Greg Hendershott]

The `racket-trim-requires` and `racket-base-requires` commands use
`raco check-requires` behind the scenes (then format/sort as does
`racket-tidy-requires`).

Today I tried to use `racket-trim-requires` on a Typed Racket file
containing `define-type`; and got the error you mention. This turned
out to be an issue with `raco check-requires`; thanks to a hint from
Sam on Slack, I pushed a a PR that Ryan merged:

  https://github.com/racket/macro-debugger/pull/22

I just now saw this thread, which is weird timing!

I'd welcome hearing any other examples where racket-{tidy
base}-requires doesn't work -- and `raco check-requires` on that same
file works or not. (Of course I'd also understand if folks are too
busy to detour to report them.)


On Mon, Mar 13, 2017 at 1:50 PM, Dan Liebgold
 wrote:
> raco check-requires does the job.
>
> I use emacs racket-mode, but it's hobbled in ways I haven't investigated -- 
> e.g. when I try to use tidy or trim requires it gives me a "Can't do, source 
> file has error" when it doesn't, or at least not in a way I can see.
>
> --
> 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] refactoring help/tools?

[Matthias Felleisen]

> On Mar 13, 2017, at 5:26 PM, Stephen De Gabrielle  
> wrote:
> 
> Do you mean a drracket plugin that
> i. Expands #lang racket into racket/base and requires, 
> ii. removes the unneeded requires


I am sure that one day soon someone will write a dissertation that 

 (1) collects a catalogue of common and Racket-specific refactorings 
 (2) comes with a new language for stating the pre-conditions for these 
refactorings 
 (3) and uses the syntax system to implement these refactorings. 

All 3 bullets contribute new knowledge and possibly portable knowledge, so it 
must be in the makings, somewhere. 

-- 
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] Virtual connections, threads, and DSN extraction, oh my!

[George Neuner]

On 3/13/2017 5:16 PM, Ryan Culpepper wrote:


When a thread uses a VC, it gets an underlying connection assigned 
exclusively to it for the lifetime of the thread[*]. When the thread 
dies, the VC releases the underlying connection; if it came from a 
pool, it returns to the pool and it can be obtained by another thread.


[*] or until the thread calls disconnect


Ah.  My mistake.   This was not clear [to me] from the documentation.

Thanks,
George


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] prepared queries

[George Neuner]

Hi Ryan,

On 3/13/2017 5:43 PM, Ryan Culpepper wrote:


Racket's db library always prepares a statement before executing it, 
even if there are no query parameters. When allowed, instead of 
closing the prepared statement immediately after executing it, the 
connection stores it in a (Racket-side, per-connection) cache. The 
cache key is just the SQL string. If you use the same query string 
with different parameters, you'll still get the cached prepared 
statement.


To extend my previous example:

  > (query c "select $1::integer" 1)
  
  ** caching statement
  
  > (query c "select $1::integer" 2)
  ** using cached statement
  

On the other hand, if the query string is not identical, it misses the 
cache.


Hmm.   Then what is the purpose of having separate (prepare ...)? And 
what happens if the unknowing user issues a PREPARE statement for the 
query directly to the DBMS?


Then there is the issue that deliberately prepared queries are not 
optimized as heavily as normal queries - which is the case in pretty 
much every DBMS that exists.  Heavyweight queries that require maximum 
performance are harmed by preparation.


Moreover, prepared queries are not cached in the normal sense ... they 
persist until explicitly dropped, or until the connection is closed.  
There are both per connection and global limits on the number of 
prepared queries, and bad things can happen if these limits are 
exceeded  [e.g., I've seen versions of Postgresql freeze and Sybase 
crash in such circumstances].   A long running application using pool 
connections could get into trouble.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

[George Neuner]

On 3/13/2017 3:16 PM, David Storrs wrote:


... you talk about the "real connection", singular -- aren't there 
multiple real connections underlying the pool?


Yes, a pool maintains some number of real connections to the DBMS.

Note, however, that a pool can be configured to maintain just a single 
connection:

(connection-pool ... #:max-connections 1 #:max-idle-connections 1)


- The pool will maintain some number (hopefully >0) of real 
connections.  Every time the virtual connection receives a request, 
that request will be forwarded to a real connections, creating the 
connection if necessary. (Presumably either the pool or the VC will 
take responsibility for verifying that the connection in question has 
not been disconnected by the RDBMS and generating a new one if it has.)


Is that right?


Yes.  In either case, new DBMS connections will be created on demand if 
needed.


However, a virtual connection effectively opens and closes  a real 
connection for EVERY query.   This will be the actual behavior if the VC 
is created using a connect function.  You really need to use a pool if 
actual DBMS connections are slow to establish.


The default open/close behavior generally is OK for a local database 
solution - e.g., Sqlite, or a DBMS server co-resident with your program 
on the same host.  But even with a co-resident DBMS server, it will work 
better if you can use Unix sockets rather than [loopback] TCP.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

[Ryan Culpepper]

On 03/13/2017 04:56 PM, George Neuner wrote:


On 3/13/2017 3:41 PM, David Storrs wrote:

On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper > wrote:

If you are using `prepare` just for speed, it might help to know that
most base connections have an internal statement cache that maps SQL
strings to prepared statement objects. The cache is only used inside
of transactions, though, to avoid issues with concurrent schema changes.

You can check on statement caching by setting the #:debug? argument
when connecting. Aside from lots of other noise, queries will print
out whether they are using the statement cache. Here's an example:

  > (define c (dsn-connect 'pg #:debug? #t))
  
  > (start-transaction c)
  
  ** in managed transaction
  > (query c "select 1")
  
  ** caching statement
  
  > (query c "select 1")
  ** using cached statement
  

Could that replace your use of `prepare`?



Looks like inside a transaction all statements are prepared.  Cool.
If so, that's very nearly perfect -- it adds and removes all the
concerns that transactions always add/remove, but offhand I can't
think of a case where doing it in a transaction would be a problem.


[...]

I'm not sure exactly what  #:debug?  is showing you.   Ryan knows better
than I do, but if you haven't explicitly called "prepare", then I
suspect it is only the specific syntax of the cached query that can be
reused, and that if you change the query in any way - e.g., by passing
different arguments - then the cached version will not be used.


Racket's db library always prepares a statement before executing it, 
even if there are no query parameters. When allowed, instead of closing 
the prepared statement immediately after executing it, the connection 
stores it in a (Racket-side, per-connection) cache. The cache key is 
just the SQL string. If you use the same query string with different 
parameters, you'll still get the cached prepared statement.


To extend my previous example:

  > (query c "select $1::integer" 1)
  
  ** caching statement
  
  > (query c "select $1::integer" 2)
  ** using cached statement
  

On the other hand, if the query string is not identical, it misses the 
cache.


Ryan

--
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] refactoring help/tools?

[Stephen De Gabrielle]

Sorry  - I meant to reply all. My questions weren't directed at anyone
specific.
S.

On Mon, 13 Mar 2017 at 21:24, Stephen De Gabrielle 
wrote:

> Do you mean a drracket plugin that
> i. Expands #lang racket into racket/base and requires,
> ii. removes the unneeded requires
>
> Should there be a complimentary function that suggests and adds requires
> if an error triggers for an undefined function?
>
> Are there any other gaps between DrRacket and Emacs? (specifically for
> Racket dev/languages - I'm not suggesting org-mode or anything like that)
>
> Is it easier to develop extensions to Emacs than plugins for DrRacket?
>
> Kind regards
>
> Stephen
>
> On Mon, 13 Mar 2017 at 18:20, Matthias Felleisen 
> wrote:
>
>
> I know that one. I want the refactoring.
>
>
> > On Mar 13, 2017, at 1:40 PM, Robby Findler 
> wrote:
> >
> > Not the same thing, but if you mouse over the requires in DrRacket, it
> > will put a red background on the ones that have no apparent use (of
> > course, requires may have an effect too; neither tool picks that up,
> > IIUC).
> >
> > Robby
> >
> >
> > On Mon, Mar 13, 2017 at 12:38 PM, Jay McCarthy 
> wrote:
> >> Actually it is the trim option. I prefer racket-base-requires though
> >>
> >> Jay
> >>
> >> On Mon, Mar 13, 2017 at 1:37 PM Jay McCarthy 
> wrote:
> >>>
> >>> M-x racket-tidy-requires
> >>>
> >>> Jay
> >>>
> >>> On Mon, Mar 13, 2017 at 1:29 PM Matthias Felleisen <
> matth...@ccs.neu.edu>
> >>> wrote:
> 
> 
>  Does Emacs really give you this refactoring? If so, I may have to
>  reconsider DrRacket.
> 
> 
> > On Mar 13, 2017, at 1:18 PM, Jay McCarthy 
> > wrote:
> >
> > racket-mode in Emacs does this
> >
> > Jay
> >
> > On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold
> >  wrote:
> > Hi -
> >
> > In refactoring a some Racket code I'd love to have a "require and
> > provide only what you need" tool to help trim down the require and
> provide
> > lists. Is there such a thing? Or at least a better approach for this
> than
> > inspection or trial and error?
> >
> > Thanks,
> > Dna
> >
> > --
> > 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.
> > --
> > -=[ Jay McCarthy   http://jeapostrophe.github.io
> ]=-
> > -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> > -=[ Moses 1:33: And worlds without number have I created; ]=-
> >
> > --
> > 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.
> 
> >>> --
> >>> -=[ Jay McCarthy   http://jeapostrophe.github.io
> ]=-
> >>> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> >>> -=[ Moses 1:33: And worlds without number have I created; ]=-
> >>
> >> --
> >> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> >> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> >> -=[ Moses 1:33: And worlds without number have I created; ]=-
> >>
> >> --
> >> 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.
>
> --
> Kind regards,
> Stephen
> --
>
-- 
Kind regards,
Stephen
--

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

[David Storrs]

Thank you, everyone.  I really appreciate the detailed answers.

On Mon, Mar 13, 2017 at 5:16 PM, Ryan Culpepper  wrote:

> On 03/13/2017 03:16 PM, David Storrs wrote:
>
>> [...]
>> On Mon, Mar 13, 2017 at 2:49 PM, George Neuner > > wrote:
>>
>>> - It's also fine to pass the VC into other threads.  It will be
>>> shared state between the threads, but the CP will keep their
>>> connections isolated and when the threads terminate it won't
>>> interfere.  (Ignore pathological cases -- obviously if I give it
>>> to enough threads and they all use it at once then we might exceed
>>> the DB limits on number of handles, speed, bandwidth, etc.)
>>>
>>
>> No.  A VC is not tied to any particular real connection, so it's not
>> possible to guarantee that 2 threads sharing a VC do not share an
>> RC.   It's actually quite likely in a lightly loaded system.
>>
>> If you need connection isolation, you have to use real connections.
>>
>> Gotcha.  Thanks.
>>
>
> Two threads that share a VC will not have the same real connection *at the
> same time*. When a thread uses a VC, it gets an underlying connection
> assigned exclusively to it for the lifetime of the thread[*]. When the
> thread dies, the VC releases the underlying connection; if it came from a
> pool, it returns to the pool and it can be obtained by another thread.
>
> [*] or until the thread calls disconnect
>
> [...]
>>
>> There is no way in the current implementation to get at the real
>> connection underlying the virtual one.  Because the system
>> multiplexes connections, I think it probably would break badly if
>> you were able to somehow get hold of the underlying real connection.
>>
>> I know this isn't what you want to hear.
>> George
>>
>> Hey, I'd rather hear uncomfortable truth than comforting lies.  Still,
>> in the above you talk about the "real connection", singular -- aren't
>> there multiple real connections underlying the pool?
>>
>> My mental model for how this works is:
>>
>> - User creates a function F that creates real connections
>>
>> - User hands F to a pool via: (virtual-connection (connection-pool F))
>> and gets back a VC.
>>
>> - The pool will maintain some number (hopefully >0) of real
>> connections.  Every time the virtual connection receives a request, that
>> request will be forwarded to a real connections, creating the connection
>> if necessary.  (Presumably either the pool or the VC will take
>> responsibility for verifying that the connection in question has not
>> been disconnected by the RDBMS and generating a new one if it has.)
>>
>> Is that right?
>>
>
> Yes, but the VC keeps a mapping of threads to connections as I mentioned
> above, so it doesn't choose a new real connection per query.
>
> The connection pool does check that a real connection is still connected
> before it hands it out, but there's a race: the server could disconnect
> between the check and when the connection actually gets used for the first
> time.
>
> Ryan
>
>

-- 
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] Virtual connections, threads, and DSN extraction, oh my!

[Ryan Culpepper]

On 03/13/2017 03:16 PM, David Storrs wrote:

[...]
On Mon, Mar 13, 2017 at 2:49 PM, George Neuner > wrote:

- It's also fine to pass the VC into other threads.  It will be
shared state between the threads, but the CP will keep their
connections isolated and when the threads terminate it won't
interfere.  (Ignore pathological cases -- obviously if I give it
to enough threads and they all use it at once then we might exceed
the DB limits on number of handles, speed, bandwidth, etc.)


No.  A VC is not tied to any particular real connection, so it's not
possible to guarantee that 2 threads sharing a VC do not share an
RC.   It's actually quite likely in a lightly loaded system.

If you need connection isolation, you have to use real connections.

Gotcha.  Thanks.


Two threads that share a VC will not have the same real connection *at 
the same time*. When a thread uses a VC, it gets an underlying 
connection assigned exclusively to it for the lifetime of the thread[*]. 
When the thread dies, the VC releases the underlying connection; if it 
came from a pool, it returns to the pool and it can be obtained by 
another thread.


[*] or until the thread calls disconnect


[...]

There is no way in the current implementation to get at the real
connection underlying the virtual one.  Because the system
multiplexes connections, I think it probably would break badly if
you were able to somehow get hold of the underlying real connection.

I know this isn't what you want to hear.
George

Hey, I'd rather hear uncomfortable truth than comforting lies.  Still,
in the above you talk about the "real connection", singular -- aren't
there multiple real connections underlying the pool?

My mental model for how this works is:

- User creates a function F that creates real connections

- User hands F to a pool via: (virtual-connection (connection-pool F))
and gets back a VC.

- The pool will maintain some number (hopefully >0) of real
connections.  Every time the virtual connection receives a request, that
request will be forwarded to a real connections, creating the connection
if necessary.  (Presumably either the pool or the VC will take
responsibility for verifying that the connection in question has not
been disconnected by the RDBMS and generating a new one if it has.)

Is that right?


Yes, but the VC keeps a mapping of threads to connections as I mentioned 
above, so it doesn't choose a new real connection per query.


The connection pool does check that a real connection is still connected 
before it hands it out, but there's a race: the server could disconnect 
between the check and when the connection actually gets used for the 
first time.


Ryan

--
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] Virtual connections, threads, and DSN extraction, oh my!

[George Neuner]

On 3/13/2017 3:41 PM, David Storrs wrote:
On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper > wrote:
If you are using `prepare` just for speed, it might help to know that 
most base connections have an internal statement cache that maps SQL 
strings to prepared statement objects. The cache is only used inside 
of transactions, though, to avoid issues with concurrent schema changes.


You can check on statement caching by setting the #:debug? argument 
when connecting. Aside from lots of other noise, queries will print 
out whether they are using the statement cache. Here's an example:


  > (define c (dsn-connect 'pg #:debug? #t))
  
  > (start-transaction c)
  
  ** in managed transaction
  > (query c "select 1")
  
  ** caching statement
  
  > (query c "select 1")
  ** using cached statement
  

Could that replace your use of `prepare`?



Looks like inside a transaction all statements are prepared.  Cool.  
If so, that's very nearly perfect -- it adds and removes all the 
concerns that transactions always add/remove, but offhand I can't 
think of a case where doing it in a transaction would be a problem.


There's a difference between "prepared" and "compiled".

Every query is compiled.  The compiled version can be - and typically is 
in most DBMS - cached for reuse if the same *identical* query string is 
presented again.  With a normal query, the compiled version is optimized 
based on the specific values contained in the statement.


Prepare is different.  The idea of "preparation" is to be able to reuse 
a generic query with different arguments.  A prepared query is compiled 
to use variables rather than inline values, so it is not as well 
optimized as compilation of a normal query.  The savings in preparation 
comes mainly from avoiding compiles on subsequent reuse.


The compiled version of a prepared query persists until explicitly 
dropped or the connection is closed.  It is not cached in the same way 
as are normal queries.



I'm not sure exactly what  #:debug?  is showing you.   Ryan knows better 
than I do, but if you haven't explicitly called "prepare", then I 
suspect it is only the specific syntax of the cached query that can be 
reused, and that if you change the query in any way - e.g., by passing 
different arguments - then the cached version will not be used.



George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Virtual connections, threads, and DSN extraction, oh my!

[David Storrs]

On Mon, Mar 13, 2017 at 2:04 PM, Ryan Culpepper  wrote:

> On 03/13/2017 12:49 PM, David Storrs wrote:
>
>> [...]
>>
>>
>> Assuming I've understood all that correctly, my last question would be
>> how to get around the 'can't do prepare with a virtual connection' issue
>> for situations where I've been passed a connection (perhaps from third
>> party code) and it might or might not be virtual. First, to dispose of
>> some quibbles:
>>
>> - One answer is "well, don't do that."  Write a contract on the function
>> that mandates the connection being non-virtual.
>>
>> - Another is "well, don't do that."  Test if the connection is virtual
>> and, if so, don't use prepare.
>>
>> - Another is "well, don't do that."  Pass around a dsn instead of a VC
>> and generate connections as needed.
>>
>> None of these is terribly satisfying.  The first violates the principle
>> of "be generous in what you accept and strict in what you emit", the
>> second gives up a lot of speed if we were in a situation where we wanted
>> to use 'prepare' in the first place, and the third isn't feasible since
>> I won't always have control over what a third-party library emits.
>>
>>
>> My ideal solution would be something like this:
>>
>> (define (myfunc a-handle)
>> (define dbh
>> (if (virtual-connection? a-handle)
>> (my-function-to-do-connect-with-dsn (get-dsn-from a-handle))
>> a-handle))
>> (define sth (prepare dbh "select foo from bar where baz = $1"))
>> ...stuff...
>> )
>>
>> In other words, check if the connection is virtual and, if so, extract
>> the dsn from it and use that to create a non-virtual connection.
>>
>> Is there a way to do that?  I've been through the db module docs and
>> Google but not found a way.  Did I miss something?
>>
>
> There's no way to do that at the moment.
>
> If you are using `prepare` just for speed, it might help to know that most
> base connections have an internal statement cache that maps SQL strings to
> prepared statement objects. The cache is only used inside of transactions,
> though, to avoid issues with concurrent schema changes.
>
> You can check on statement caching by setting the #:debug? argument when
> connecting. Aside from lots of other noise, queries will print out whether
> they are using the statement cache. Here's an example:
>
>   > (define c (dsn-connect 'pg #:debug? #t))
>   
>   > (start-transaction c)
>   
>   ** in managed transaction
>   > (query c "select 1")
>   
>   ** caching statement
>   
>   > (query c "select 1")
>   ** using cached statement
>   
>
> Could that replace your use of `prepare`?
>



Looks like inside a transaction all statements are prepared.  Cool.  If so,
that's very nearly perfect -- it adds and removes all the concerns that
transactions always add/remove, but offhand I can't think of a case where
doing it in a transaction would be a problem.

Thanks, Ryan.




>
> Ryan
>
> --
> 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] Virtual connections, threads, and DSN extraction, oh my!

[David Storrs]

On Mon, Mar 13, 2017 at 2:49 PM, George Neuner  wrote:

>
> This is why you can't use prepared queries with virtual connections -
> because there is no guarantee that the connection that prepared the query
> will be the same one that tries to execute it.
>

*nod*  Good, that's what I thought.  Nice to have it confirmed.


>
>
> - The connection pool (CP) inside the VC will maintain a (small?)
> collection of persistent connections to hand out upon request, so I'm not
> paying the connection-setup-time penalty every time I use it.
>
>
> Yes and no.  The pool will try to keep idle connections, but the DBMS
> eventually will close them  (subject to the keep-alive settings in
> postgresql.conf).
>

Ah, makes sense.  Still, the point is that in the normal case events I
shouldn't need to pay the setup cost each time.



>
> - It's also fine to pass the VC into other threads.  It will be shared
> state between the threads, but the CP will keep their connections isolated
> and when the threads terminate it won't interfere.  (Ignore pathological
> cases -- obviously if I give it to enough threads and they all use it at
> once then we might exceed the DB limits on number of handles, speed,
> bandwidth, etc.)
>
>
> No.  A VC is not tied to any particular real connection, so it's not
> possible to guarantee that 2 threads sharing a VC do not share an RC.
> It's actually quite likely in a lightly loaded system.
>
> If you need connection isolation, you have to use real connections.
>

Gotcha.  Thanks.



> Real connections will persist until closed.  Virtual connections can come
> and go like dreams.
>

If this were a forum I would sig that.  :>


> There is no way in the current implementation to get at the real
> connection underlying the virtual one.  Because the system multiplexes
> connections, I think it probably would break badly if you were able to
> somehow get hold of the underlying real connection.
>
>
> I know this isn't what you want to hear.
> George
>

Hey, I'd rather hear uncomfortable truth than comforting lies.  Still, in
the above you talk about the "real connection", singular -- aren't there
multiple real connections underlying the pool?

My mental model for how this works is:

- User creates a function F that creates real connections

- User hands F to a pool via: (virtual-connection (connection-pool F)) and
gets back a VC.

- The pool will maintain some number (hopefully >0) of real connections.
Every time the virtual connection receives a request, that request will be
forwarded to a real connections, creating the connection if necessary.
(Presumably either the pool or the VC will take responsibility for
verifying that the connection in question has not been disconnected by the
RDBMS and generating a new one if it has.)

Is that right?




> --
> 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] Virtual connections, threads, and DSN extraction, oh my!

[George Neuner]

Hi David,

On 3/13/2017 12:49 PM, David Storrs wrote:

I've got a centralized database connector:

(define dbh
 (virtual-connection
(connection-pool
 (thunk (postgresl-connect ...)

This gets passed around from handle to handle and into various 
temporary or ongoing worker threads.  Thinking about it, I'd like to 
check that I've understood it properly:


- The virtual connection (VC) itself is very lightweight and it's fine 
for it to persist throughout the run of the program.


Yes.  However, virtual connections are multiplexed over real 
connections.  The underlying real connection  can be stolen (given to 
another virtual connection) any time it is idle - such as when it is 
between queries.  If you have a thread that performs a sequence of queries:


  :
do_query_1
  :
do_query_2
  :

then it's possible for the real connection to be snatched away between 
the queries.  Of course, when the thread goes to use the VC again, it 
will get *some* real connection, but there's no guarantee that it will 
be the *same* one each time.


This is why you can't use prepared queries with virtual connections - 
because there is no guarantee that the connection that prepared the 
query will be the same one that tries to execute it.



- The connection pool (CP) inside the VC will maintain a (small?) 
collection of persistent connections to hand out upon request, so I'm 
not paying the connection-setup-time penalty every time I use it.


Yes and no.  The pool will try to keep idle connections, but the DBMS 
eventually will close them  (subject to the keep-alive settings in 
postgresql.conf).



- It's also fine to pass the VC into other threads.  It will be shared 
state between the threads, but the CP will keep their connections 
isolated and when the threads terminate it won't interfere.  (Ignore 
pathological cases -- obviously if I give it to enough threads and 
they all use it at once then we might exceed the DB limits on number 
of handles, speed, bandwidth, etc.)


No.  A VC is not tied to any particular real connection, so it's not 
possible to guarantee that 2 threads sharing a VC do not share an RC.   
It's actually quite likely in a lightly loaded system.


If you need connection isolation, you have to use real connections.


- The CP will create more connections as needed, so there's no need to 
worry about running out (barring pathological cases).


Subject to limitations.  You can't open more real connections than the 
DBMS permits.  However, you can have many more virtual connections than 
real connections.



- db connections will get garbage collected normally, at the marked 
points:


I have to defer this to someone who knows for sure.  Real connections 
will persist until closed.  Virtual connections can come and go like dreams.



Assuming I've understood all that correctly, my last question would be 
how to get around the 'can't do prepare with a virtual connection' 
issue for situations where I've been passed a connection (perhaps from 
third party code) and it might or might not be virtual. First, to 
dispose of some quibbles:


- One answer is "well, don't do that."  Write a contract on the 
function that mandates the connection being non-virtual.


- Another is "well, don't do that."  Test if the connection is virtual 
and, if so, don't use prepare.


- Another is "well, don't do that."  Pass around a dsn instead of a VC 
and generate connections as needed.


None of these is terribly satisfying.  The first violates the 
principle of "be generous in what you accept and strict in what you 
emit", the second gives up a lot of speed if we were in a situation 
where we wanted to use 'prepare' in the first place, and the third 
isn't feasible since I won't always have control over what a 
third-party library emits.



My ideal solution would be something like this:

(define (myfunc a-handle)
(define dbh
(if (virtual-connection? a-handle)
(my-function-to-do-connect-with-dsn (get-dsn-from a-handle))
a-handle))
(define sth (prepare dbh "select foo from bar where baz = $1"))
...stuff...
)

In other words, check if the connection is virtual and, if so, extract 
the dsn from it and use that to create a non-virtual connection.


Is there a way to do that?  I've been through the db module docs and 
Google but not found a way.  Did I miss something?




Even if you could discover the DSN, it would not help if the DBMS 
connection limit is reached,  or equivalently some user limit imposed by 
a proxy server that you don't know about.


There is no way in the current implementation to get at the real 
connection underlying the virtual one.  Because the system multiplexes 
connections, I think it probably would break badly if you were able to 
somehow get hold of the underlying real connection.



I know this isn't what you want to hear.
George

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

Re: [racket-users] refactoring help/tools?

[Matthias Felleisen]

I know that one. I want the refactoring. 


> On Mar 13, 2017, at 1:40 PM, Robby Findler  
> wrote:
> 
> Not the same thing, but if you mouse over the requires in DrRacket, it
> will put a red background on the ones that have no apparent use (of
> course, requires may have an effect too; neither tool picks that up,
> IIUC).
> 
> Robby
> 
> 
> On Mon, Mar 13, 2017 at 12:38 PM, Jay McCarthy  wrote:
>> Actually it is the trim option. I prefer racket-base-requires though
>> 
>> Jay
>> 
>> On Mon, Mar 13, 2017 at 1:37 PM Jay McCarthy  wrote:
>>> 
>>> M-x racket-tidy-requires
>>> 
>>> Jay
>>> 
>>> On Mon, Mar 13, 2017 at 1:29 PM Matthias Felleisen 
>>> wrote:
 
 
 Does Emacs really give you this refactoring? If so, I may have to
 reconsider DrRacket.
 
 
> On Mar 13, 2017, at 1:18 PM, Jay McCarthy 
> wrote:
> 
> racket-mode in Emacs does this
> 
> Jay
> 
> On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold
>  wrote:
> Hi -
> 
> In refactoring a some Racket code I'd love to have a "require and
> provide only what you need" tool to help trim down the require and provide
> lists. Is there such a thing? Or at least a better approach for this than
> inspection or trial and error?
> 
> Thanks,
> Dna
> 
> --
> 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.
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
> 
> --
> 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.
 
>>> --
>>> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
>>> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
>>> -=[ Moses 1:33: And worlds without number have I created; ]=-
>> 
>> --
>> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
>> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
>> -=[ Moses 1:33: And worlds without number have I created; ]=-
>> 
>> --
>> 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] Virtual connections, threads, and DSN extraction, oh my!

[Ryan Culpepper]

On 03/13/2017 12:49 PM, David Storrs wrote:

[...]

Assuming I've understood all that correctly, my last question would be
how to get around the 'can't do prepare with a virtual connection' issue
for situations where I've been passed a connection (perhaps from third
party code) and it might or might not be virtual. First, to dispose of
some quibbles:

- One answer is "well, don't do that."  Write a contract on the function
that mandates the connection being non-virtual.

- Another is "well, don't do that."  Test if the connection is virtual
and, if so, don't use prepare.

- Another is "well, don't do that."  Pass around a dsn instead of a VC
and generate connections as needed.

None of these is terribly satisfying.  The first violates the principle
of "be generous in what you accept and strict in what you emit", the
second gives up a lot of speed if we were in a situation where we wanted
to use 'prepare' in the first place, and the third isn't feasible since
I won't always have control over what a third-party library emits.


My ideal solution would be something like this:

(define (myfunc a-handle)
(define dbh
(if (virtual-connection? a-handle)
(my-function-to-do-connect-with-dsn (get-dsn-from a-handle))
a-handle))
(define sth (prepare dbh "select foo from bar where baz = $1"))
...stuff...
)

In other words, check if the connection is virtual and, if so, extract
the dsn from it and use that to create a non-virtual connection.

Is there a way to do that?  I've been through the db module docs and
Google but not found a way.  Did I miss something?


There's no way to do that at the moment.

If you are using `prepare` just for speed, it might help to know that 
most base connections have an internal statement cache that maps SQL 
strings to prepared statement objects. The cache is only used inside of 
transactions, though, to avoid issues with concurrent schema changes.


You can check on statement caching by setting the #:debug? argument when 
connecting. Aside from lots of other noise, queries will print out 
whether they are using the statement cache. Here's an example:


  > (define c (dsn-connect 'pg #:debug? #t))
  
  > (start-transaction c)
  
  ** in managed transaction
  > (query c "select 1")
  
  ** caching statement
  
  > (query c "select 1")
  ** using cached statement
  

Could that replace your use of `prepare`?

Ryan

--
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] refactoring help/tools?

[Robby Findler]

The bubble in the bottom right corner turns green when it is done (or
red, if it found an error).

Robby


On Mon, Mar 13, 2017 at 12:52 PM, Dan Liebgold
 wrote:
> On Monday, March 13, 2017 at 10:40:15 AM UTC-7, Robby Findler wrote:
>> Not the same thing, but if you mouse over the requires in DrRacket, it
>> will put a red background on the ones that have no apparent use (of
>> course, requires may have an effect too; neither tool picks that up,
>> IIUC).
>>
>
> That is useful... I hadn't realized that.  It would be nice if there were 
> some indication that DrRacket is still background compiling, because I tend 
> to not get arrows for awhile and usually chalk it up to my files being in a 
> bad state.
>
> --
> 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] refactoring help/tools?

[Dan Liebgold]

On Monday, March 13, 2017 at 10:40:15 AM UTC-7, Robby Findler wrote:
> Not the same thing, but if you mouse over the requires in DrRacket, it
> will put a red background on the ones that have no apparent use (of
> course, requires may have an effect too; neither tool picks that up,
> IIUC).
> 

That is useful... I hadn't realized that.  It would be nice if there were some 
indication that DrRacket is still background compiling, because I tend to not 
get arrows for awhile and usually chalk it up to my files being in a bad state.

-- 
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] refactoring help/tools?

[Dan Liebgold]

raco check-requires does the job.

I use emacs racket-mode, but it's hobbled in ways I haven't investigated -- 
e.g. when I try to use tidy or trim requires it gives me a "Can't do, source 
file has error" when it doesn't, or at least not in a way I can see.

-- 
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] refactoring help/tools?

[Robby Findler]

Not the same thing, but if you mouse over the requires in DrRacket, it
will put a red background on the ones that have no apparent use (of
course, requires may have an effect too; neither tool picks that up,
IIUC).

Robby


On Mon, Mar 13, 2017 at 12:38 PM, Jay McCarthy  wrote:
> Actually it is the trim option. I prefer racket-base-requires though
>
> Jay
>
> On Mon, Mar 13, 2017 at 1:37 PM Jay McCarthy  wrote:
>>
>> M-x racket-tidy-requires
>>
>> Jay
>>
>> On Mon, Mar 13, 2017 at 1:29 PM Matthias Felleisen 
>> wrote:
>>>
>>>
>>> Does Emacs really give you this refactoring? If so, I may have to
>>> reconsider DrRacket.
>>>
>>>
>>> > On Mar 13, 2017, at 1:18 PM, Jay McCarthy 
>>> > wrote:
>>> >
>>> > racket-mode in Emacs does this
>>> >
>>> > Jay
>>> >
>>> > On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold
>>> >  wrote:
>>> > Hi -
>>> >
>>> > In refactoring a some Racket code I'd love to have a "require and
>>> > provide only what you need" tool to help trim down the require and provide
>>> > lists. Is there such a thing? Or at least a better approach for this than
>>> > inspection or trial and error?
>>> >
>>> > Thanks,
>>> > Dna
>>> >
>>> > --
>>> > 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.
>>> > --
>>> > -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
>>> > -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
>>> > -=[ Moses 1:33: And worlds without number have I created; ]=-
>>> >
>>> > --
>>> > 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.
>>>
>> --
>> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
>> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
>> -=[ Moses 1:33: And worlds without number have I created; ]=-
>
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
>
> --
> 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] refactoring help/tools?

[Jay McCarthy]

Actually it is the trim option. I prefer racket-base-requires though

Jay

On Mon, Mar 13, 2017 at 1:37 PM Jay McCarthy  wrote:

> M-x racket-tidy-requires
>
> Jay
>
> On Mon, Mar 13, 2017 at 1:29 PM Matthias Felleisen 
> wrote:
>
>
> Does Emacs really give you this refactoring? If so, I may have to
> reconsider DrRacket.
>
>
> > On Mar 13, 2017, at 1:18 PM, Jay McCarthy 
> wrote:
> >
> > racket-mode in Emacs does this
> >
> > Jay
> >
> > On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold <
> dan_liebg...@naughtydog.com> wrote:
> > Hi -
> >
> > In refactoring a some Racket code I'd love to have a "require and
> provide only what you need" tool to help trim down the require and provide
> lists. Is there such a thing? Or at least a better approach for this than
> inspection or trial and error?
> >
> > Thanks,
> > Dna
> >
> > --
> > 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.
> > --
> > -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> > -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> > -=[ Moses 1:33: And worlds without number have I created; ]=-
> >
> > --
> > 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.
>
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
>
-- 
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
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] refactoring help/tools?

[Jay McCarthy]

M-x racket-tidy-requires

Jay

On Mon, Mar 13, 2017 at 1:29 PM Matthias Felleisen 
wrote:

>
> Does Emacs really give you this refactoring? If so, I may have to
> reconsider DrRacket.
>
>
> > On Mar 13, 2017, at 1:18 PM, Jay McCarthy 
> wrote:
> >
> > racket-mode in Emacs does this
> >
> > Jay
> >
> > On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold <
> dan_liebg...@naughtydog.com> wrote:
> > Hi -
> >
> > In refactoring a some Racket code I'd love to have a "require and
> provide only what you need" tool to help trim down the require and provide
> lists. Is there such a thing? Or at least a better approach for this than
> inspection or trial and error?
> >
> > Thanks,
> > Dna
> >
> > --
> > 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.
> > --
> > -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> > -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> > -=[ Moses 1:33: And worlds without number have I created; ]=-
> >
> > --
> > 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.
>
> --
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
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] refactoring help/tools?

[Philip McGrath]

raco check-requires might do some of what you want.

-Philip

On Mon, Mar 13, 2017 at 12:18 PM, Jay McCarthy 
wrote:

> racket-mode in Emacs does this
>
> Jay
>
> On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold 
> wrote:
>
>> Hi -
>>
>> In refactoring a some Racket code I'd love to have a "require and provide
>> only what you need" tool to help trim down the require and provide lists.
>> Is there such a thing? Or at least a better approach for this than
>> inspection or trial and error?
>>
>> Thanks,
>> Dna
>>
>> --
>> 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.
>>
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
>
> --
> 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] refactoring help/tools?

[Matthias Felleisen]

Does Emacs really give you this refactoring? If so, I may have to reconsider 
DrRacket. 


> On Mar 13, 2017, at 1:18 PM, Jay McCarthy  wrote:
> 
> racket-mode in Emacs does this
> 
> Jay
> 
> On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold  
> wrote:
> Hi -
> 
> In refactoring a some Racket code I'd love to have a "require and provide 
> only what you need" tool to help trim down the require and provide lists. Is 
> there such a thing? Or at least a better approach for this than inspection or 
> trial and error?
> 
> Thanks,
> Dna
> 
> --
> 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.
> -- 
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
> 
> -- 
> 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] refactoring help/tools?

[Jay McCarthy]

racket-mode in Emacs does this

Jay

On Mon, Mar 13, 2017 at 1:17 PM Dan Liebgold 
wrote:

> Hi -
>
> In refactoring a some Racket code I'd love to have a "require and provide
> only what you need" tool to help trim down the require and provide lists.
> Is there such a thing? Or at least a better approach for this than
> inspection or trial and error?
>
> Thanks,
> Dna
>
> --
> 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.
>
-- 
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
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] refactoring help/tools?

[Dan Liebgold]

Hi -

In refactoring a some Racket code I'd love to have a "require and provide only 
what you need" tool to help trim down the require and provide lists. Is there 
such a thing? Or at least a better approach for this than inspection or trial 
and error?

Thanks,
Dna

-- 
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] Virtual connections, threads, and DSN extraction, oh my!

[David Storrs]

I've got a centralized database connector:

(define dbh
 (virtual-connection
 (connection-pool
 (thunk (postgresl-connect ...)

This gets passed around from handle to handle and into various temporary or
ongoing worker threads.  Thinking about it, I'd like to check that I've
understood it properly:

- The virtual connection (VC) itself is very lightweight and it's fine for
it to persist throughout the run of the program.

- The connection pool (CP) inside the VC will maintain a (small?)
collection of persistent connections to hand out upon request, so I'm not
paying the connection-setup-time penalty every time I use it.

- It's also fine to pass the VC into other threads.  It will be shared
state between the threads, but the CP will keep their connections isolated
and when the threads terminate it won't interfere.  (Ignore pathological
cases -- obviously if I give it to enough threads and they all use it at
once then we might exceed the DB limits on number of handles, speed,
bandwidth, etc.)

- The CP will create more connections as needed, so there's no need to
worry about running out (barring pathological cases).

- db connections will get garbage collected normally, at the marked points:

#lang racket

(require db)

(begin ; outer begin
  (define dbh
(virtual-connection
 (connection-pool
  (thunk (postgresql-connect #:user "x"
 #:database "x"
 #:password "x"
 #:port 5432
   ) ; closes 'define dbh'

  (define (foo dbh-A)  ; dbh will be passed in
(begin ; inner begin
  (define dbh-B dbh) ; (eq? dbh-A dbh-B) => #t
  (for ((i 10))
(thread
 (thunk
  (sleep (floor (* 10 (random
  (query-value dbh-A "select 7")
  (disconnect dbh-A) ; this is a no-op since dbh-A is a virtual
connection, not an actual connection
  (with-handlers ((exn:fail? (lambda (e) (displayln e
(prepare dbh "select * from users where username = $1") ;
raises "cannot prepare statement with virtual connection" exception
);with-handlers
  (sleep (floor (* 10 (random
); closes foo
  (foo dbh)
  ); closes outer begin

(sleep 20) ; without this all the other threads would be closed when the
main thread ended

By the time we get to 'sleep 20' dbh is out of scope but still visible to
the various worker threads.  dbh will not be GC'd until all those threads
have ended, even after all those threads have executed the 'disconnect'
line and thrown the exception.


Assuming I've understood all that correctly, my last question would be how
to get around the 'can't do prepare with a virtual connection' issue for
situations where I've been passed a connection (perhaps from third party
code) and it might or might not be virtual. First, to dispose of some
quibbles:

- One answer is "well, don't do that."  Write a contract on the function
that mandates the connection being non-virtual.

- Another is "well, don't do that."  Test if the connection is virtual and,
if so, don't use prepare.

- Another is "well, don't do that."  Pass around a dsn instead of a VC and
generate connections as needed.

None of these is terribly satisfying.  The first violates the principle of
"be generous in what you accept and strict in what you emit", the second
gives up a lot of speed if we were in a situation where we wanted to use
'prepare' in the first place, and the third isn't feasible since I won't
always have control over what a third-party library emits.


My ideal solution would be something like this:

(define (myfunc a-handle)
(define dbh
(if (virtual-connection? a-handle)
(my-function-to-do-connect-with-dsn (get-dsn-from a-handle))
a-handle))
(define sth (prepare dbh "select foo from bar where baz = $1"))
...stuff...
)

In other words, check if the connection is virtual and, if so, extract the
dsn from it and use that to create a non-virtual connection.

Is there a way to do that?  I've been through the db module docs and Google
but not found a way.  Did I miss something?

-- 
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] linking with raco ctool : unable to find libracket3mxxxxxxx.lib

[Carlos Lopez]

Hi,

I'm compiling portaudio's callbacks.dll to have it with debug symbols but I'm 
running into a configuration issue.

when running raco ctool --ld ... I get the message that libracket3mxxx.lib 
is not found.

I tried running racket -l setup/winvers but did not see any change.

what would be the right steps to configure raco?

thanks,
carlos

-- 
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] define-syntax question

[NeverTooOldToCode]

On Monday, March 13, 2017 at 1:35:12 PM UTC+1, Matthias Felleisen wrote:
> > On Mar 13, 2017, at 7:06 AM, NeverTooOldToCode wrote:
> > 
> > From Greg Hendershott's Fear of Macros, section 3.3:
> > 
> >> (define-syntax (show-me stx)
> >(print stx)
> >#'(void))
> >> (show-me '(+ 1 2))
> > 
> > #
> > 
> > Why does the syntax object stx include "show-me"? Intuitively I would 
> > expect just the syntax object representing '(+ 1 2)
> 
> 
> By convention, dating back to the 1960s.

Thank you! Now my mind is clear to tackle the rest of it!

-- 
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] define-syntax question

[Matthias Felleisen]

 

> On Mar 13, 2017, at 7:06 AM, NeverTooOldToCode  wrote:
> 
> From Greg Hendershott's Fear of Macros, section 3.3:
> 
>> (define-syntax (show-me stx)
>(print stx)
>#'(void))
>> (show-me '(+ 1 2))
> 
> #
> 
> Why does the syntax object stx include "show-me"? Intuitively I would expect 
> just the syntax object representing '(+ 1 2)


By convention, dating back to the 1960s. 

-- 
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] define-syntax question

[NeverTooOldToCode]

>From Greg Hendershott's Fear of Macros, section 3.3:

> (define-syntax (show-me stx)
(print stx)
#'(void))
> (show-me '(+ 1 2))

#

Why does the syntax object stx include "show-me"? Intuitively I would expect 
just the syntax object representing '(+ 1 2)

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