Re: [racket-users] range with small or zero step doesn't return

[Alex Harsanyi]

On Tuesday, April 18, 2017 at 5:15:12 AM UTC+8, Jens Axel Søgaard wrote:
> 2017-04-17 22:56 GMT+02:00 Vincent St-Amour :
> (For people following along, the issue is that there exists a value `x`
> 
> such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
> 
> as its state at some point, then loops.)
> 
> 
> 
> What is the smallest y such that no x exists such that (= (+ x y) x) ?

This depends on how big X is.  Since floating point values are stored as 
doubles, at 2^54, the smallest number you need to add to get a different number 
is 4; at 2^55, the smallest number you need to add is 8.  

Putting a lower limit on the step size is not realistic.

Alex.

-- 
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] Preventing browser frame from terminating evaluation thread?

[Philip McGrath]

It's a little ugly, but you can change the exit handler:
(exit-handler
 (λ (x) (displayln "Called exit")))

-Philip

On Mon, Apr 17, 2017 at 8:57 PM, Matt Jadud  wrote:

> Hi all,
>
> I would like to spawn a browser frame, but I'd like it if the frame did
> not terminate the thread when I close it. I'm having a hard time figuring
> out what I should override/augment or catch so that I can spawn the frame
> from within a GUI application, let the user close the frame, and not have
> the whole application terminate.
>
> Cheers,
> Matt
>
> #lang racket
>
> (require browser)
>
> (define really-hyper-frame%
>   (class hyper-frame%
>
> (super-new)
>
> (define (on-close)
>   (printf "Closing!")
>   ;; But, how do I prevent the evaluation thread
>   ;; from terminating? For example, if I want to launch
>   ;; a browser frame from interactions in a GUI application?
>   )
> (augment on-close)
> ))
>
> ;; I'm aware the example is from the module level, but the same issue
> applies if
> ;; I create the frame as a result of, say, a button% click.
> (new really-hyper-frame%
>  [label "The Frame"]
>  [start-url "https://racket-lang.org/;])
>
> --
> 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] Preventing browser frame from terminating evaluation thread?

[Matt Jadud]

Hi all,

I would like to spawn a browser frame, but I'd like it if the frame did not 
terminate the thread when I close it. I'm having a hard time figuring out what 
I should override/augment or catch so that I can spawn the frame from within a 
GUI application, let the user close the frame, and not have the whole 
application terminate.

Cheers,
Matt

#lang racket

(require browser)

(define really-hyper-frame%
  (class hyper-frame%

(super-new)

(define (on-close)
  (printf "Closing!")
  ;; But, how do I prevent the evaluation thread
  ;; from terminating? For example, if I want to launch
  ;; a browser frame from interactions in a GUI application?
  )
(augment on-close)
))

;; I'm aware the example is from the module level, but the same issue applies 
if 
;; I create the frame as a result of, say, a button% click.
(new really-hyper-frame%
 [label "The Frame"]
 [start-url "https://racket-lang.org/;])

-- 
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] range with small or zero step doesn't return

[Vincent St-Amour]

I agree. I'll add a note to the docs.

Vincent


On Mon, 17 Apr 2017 16:16:49 -0500,
Tim Jervis wrote:
> 
> I like the document route; anyone who is happy with the performance tradeoff 
> would be free to implement a more conservative version.
> 
> On 17 Apr 2017, at 21:59, Ben Greenman  wrote:
> 
>  Maybe, just add a note to the docs?
> 
>  On Mon, Apr 17, 2017 at 4:56 PM, Vincent St-Amour 
>  wrote:
> 
>  The latter is easy to fix; I've submitted a pull request.
> 
>  The former is trickier. The problem is not so much due to the step size
>  itself, but rather to a combination of the step size and of a particular
>  iteration state.
> 
>  (For people following along, the issue is that there exists a value `x`
>  such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
>  as its state at some point, then loops.)
> 
>  Guarding against that would require an additional check at each
>  iteration, which may introduce overhead.
> 
>  I did some very, very crude benchmarking, and here's what I got:
> 
>  Without extra check:
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 19478 real time: 19469 gc time: 0
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 20171 real time: 20179 gc time: 0
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 20049 real time: 20043 gc time: 0
> 
>  With extra check:
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 22100 real time: 22210 gc time: 0
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 7 real time: 22265 gc time: 0
>  > (time (for ([i (in-range 100)]) i))
>  cpu time: 21934 real time: 22016 gc time: 0
> 
>  The difference is non-insignificant. Admittedly, this is the worst
>  possible case, though.
> 
>  Vincent
> 
>  On Mon, 17 Apr 2017 09:17:32 -0500,
>  Tim Jervis wrote:
>  >
>  > Dear Racket Users,
>  >
>  > I’ve noticed the following procedure calls don’t return (on my 64 bit Mac 
> hardware):
>  >
>  > 1 (range (- 1 1e-16) 1.0 1e-17)
>  > 2 (range 0 1 0)
>  >
>  > While (2) is obvious, (1) tripped me up (as I hadn’t noticed my step size 
> had fallen to effectively zero).
>  >
>  > A small tweak to for.rkt in the racket distribution could trap the 
> condition of an actually or effectively zero step. for.rkt already traps the 
> condition where step is not real.
>  >
>  > If this makes sense, could one of the authors consider adding the tweak? 
> Or is there a reason for leaving it alone?
>  >
>  > Kind regards,
>  >
>  > Tim
>  >
>  > Tim Jervis
>  >
>  > http://timjervis.com/
>  >
>  > --
>  > You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
>  > To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
>  > For more options, visit https://groups.google.com/d/optout.
> 
>  --
>  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] range with small or zero step doesn't return

[Tim Jervis]

I like the document route; anyone who is happy with the performance tradeoff 
would be free to implement a more conservative version.

> On 17 Apr 2017, at 21:59, Ben Greenman  wrote:
> 
> Maybe, just add a note to the docs?
> 
>> On Mon, Apr 17, 2017 at 4:56 PM, Vincent St-Amour 
>>  wrote:
>> The latter is easy to fix; I've submitted a pull request.
>> 
>> The former is trickier. The problem is not so much due to the step size
>> itself, but rather to a combination of the step size and of a particular
>> iteration state.
>> 
>> (For people following along, the issue is that there exists a value `x`
>> such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
>> as its state at some point, then loops.)
>> 
>> Guarding against that would require an additional check at each
>> iteration, which may introduce overhead.
>> 
>> I did some very, very crude benchmarking, and here's what I got:
>> 
>> Without extra check:
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 19478 real time: 19469 gc time: 0
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 20171 real time: 20179 gc time: 0
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 20049 real time: 20043 gc time: 0
>> 
>> With extra check:
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 22100 real time: 22210 gc time: 0
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 7 real time: 22265 gc time: 0
>> > (time (for ([i (in-range 100)]) i))
>> cpu time: 21934 real time: 22016 gc time: 0
>> 
>> The difference is non-insignificant. Admittedly, this is the worst
>> possible case, though.
>> 
>> Vincent
>> 
>> 
>> 
>> On Mon, 17 Apr 2017 09:17:32 -0500,
>> Tim Jervis wrote:
>> >
>> > Dear Racket Users,
>> >
>> > I’ve noticed the following procedure calls don’t return (on my 64 bit Mac 
>> > hardware):
>> >
>> > 1 (range (- 1 1e-16) 1.0 1e-17)
>> > 2 (range 0 1 0)
>> >
>> > While (2) is obvious, (1) tripped me up (as I hadn’t noticed my step size 
>> > had fallen to effectively zero).
>> >
>> > A small tweak to for.rkt in the racket distribution could trap the 
>> > condition of an actually or effectively zero step. for.rkt already traps 
>> > the condition where step is not real.
>> >
>> > If this makes sense, could one of the authors consider adding the tweak? 
>> > Or is there a reason for leaving it alone?
>> >
>> > Kind regards,
>> >
>> > Tim
>> >
>> > Tim Jervis
>> >
>> > http://timjervis.com/
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to racket-users+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> 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] range with small or zero step doesn't return

[Jens Axel Søgaard]

2017-04-17 22:56 GMT+02:00 Vincent St-Amour 
:

> (For people following along, the issue is that there exists a value `x`
> such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
> as its state at some point, then loops.)
>

What is the smallest y such that no x exists such that (= (+ x y) x) ?

/Jens Axel

-- 
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] range with small or zero step doesn't return

[Ben Greenman]

Maybe, just add a note to the docs?

On Mon, Apr 17, 2017 at 4:56 PM, Vincent St-Amour <
stamo...@eecs.northwestern.edu> wrote:

> The latter is easy to fix; I've submitted a pull request.
>
> The former is trickier. The problem is not so much due to the step size
> itself, but rather to a combination of the step size and of a particular
> iteration state.
>
> (For people following along, the issue is that there exists a value `x`
> such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
> as its state at some point, then loops.)
>
> Guarding against that would require an additional check at each
> iteration, which may introduce overhead.
>
> I did some very, very crude benchmarking, and here's what I got:
>
> Without extra check:
> > (time (for ([i (in-range 100)]) i))
> cpu time: 19478 real time: 19469 gc time: 0
> > (time (for ([i (in-range 100)]) i))
> cpu time: 20171 real time: 20179 gc time: 0
> > (time (for ([i (in-range 100)]) i))
> cpu time: 20049 real time: 20043 gc time: 0
>
> With extra check:
> > (time (for ([i (in-range 100)]) i))
> cpu time: 22100 real time: 22210 gc time: 0
> > (time (for ([i (in-range 100)]) i))
> cpu time: 7 real time: 22265 gc time: 0
> > (time (for ([i (in-range 100)]) i))
> cpu time: 21934 real time: 22016 gc time: 0
>
> The difference is non-insignificant. Admittedly, this is the worst
> possible case, though.
>
> Vincent
>
>
>
> On Mon, 17 Apr 2017 09:17:32 -0500,
> Tim Jervis wrote:
> >
> > Dear Racket Users,
> >
> > I’ve noticed the following procedure calls don’t return (on my 64 bit
> Mac hardware):
> >
> > 1 (range (- 1 1e-16) 1.0 1e-17)
> > 2 (range 0 1 0)
> >
> > While (2) is obvious, (1) tripped me up (as I hadn’t noticed my step
> size had fallen to effectively zero).
> >
> > A small tweak to for.rkt in the racket distribution could trap the
> condition of an actually or effectively zero step. for.rkt already traps
> the condition where step is not real.
> >
> > If this makes sense, could one of the authors consider adding the tweak?
> Or is there a reason for leaving it alone?
> >
> > Kind regards,
> >
> > Tim
> >
> > Tim Jervis
> >
> > http://timjervis.com/
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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] range with small or zero step doesn't return

[Vincent St-Amour]

The latter is easy to fix; I've submitted a pull request.

The former is trickier. The problem is not so much due to the step size
itself, but rather to a combination of the step size and of a particular
iteration state.

(For people following along, the issue is that there exists a value `x`
such that `(= (+ x 1e-17) x)`, and that the iteration reaches that `x`
as its state at some point, then loops.)

Guarding against that would require an additional check at each
iteration, which may introduce overhead.

I did some very, very crude benchmarking, and here's what I got:

Without extra check:
> (time (for ([i (in-range 100)]) i))
cpu time: 19478 real time: 19469 gc time: 0
> (time (for ([i (in-range 100)]) i))
cpu time: 20171 real time: 20179 gc time: 0
> (time (for ([i (in-range 100)]) i))
cpu time: 20049 real time: 20043 gc time: 0

With extra check:
> (time (for ([i (in-range 100)]) i))
cpu time: 22100 real time: 22210 gc time: 0
> (time (for ([i (in-range 100)]) i))
cpu time: 7 real time: 22265 gc time: 0
> (time (for ([i (in-range 100)]) i))
cpu time: 21934 real time: 22016 gc time: 0

The difference is non-insignificant. Admittedly, this is the worst
possible case, though.

Vincent



On Mon, 17 Apr 2017 09:17:32 -0500,
Tim Jervis wrote:
> 
> Dear Racket Users,
> 
> I’ve noticed the following procedure calls don’t return (on my 64 bit Mac 
> hardware):
> 
> 1 (range (- 1 1e-16) 1.0 1e-17)
> 2 (range 0 1 0)
> 
> While (2) is obvious, (1) tripped me up (as I hadn’t noticed my step size had 
> fallen to effectively zero).
> 
> A small tweak to for.rkt in the racket distribution could trap the condition 
> of an actually or effectively zero step. for.rkt already traps the condition 
> where step is not real.
> 
> If this makes sense, could one of the authors consider adding the tweak? Or 
> is there a reason for leaving it alone?
> 
> Kind regards,
> 
> Tim
> 
> Tim Jervis
> 
> http://timjervis.com/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: [Shameless self-promotion] Articles about programming-language theory for working programmers in Racket

[lfacchi2]

Hi Alexander,

Thank you for the nice words, neighbor 

-- 
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] Call for participation: PLDI 2017 and co-located events

[Tobias Grosser]

Call for participation: PLDI 2017 and co-located events

PLDI is the premier forum in the field of programming languages and
programming systems research, covering the areas of design,
implementation, theory, applications, and performance. The co-located
conferences take place in Barcelona, June 18-23, 2017.  This year, PLDI
is co-located with ECOOP, LCTES, DEBS, ISMM, Curry On and others. The
conferences will take place at the Universitat Polytècnica de Catalunya
in Barcelona, Spain.
http://conf.researchr.org/home/pldi-2017

Registration is now open, please visit:
https://regmaster4.com/2017conf/BARC17/register.php
to register. The early registration rate ends on May 26th.

The tentative program is available at:
http://pldi17.sigplan.org/program/program-pldi-2017

PLDI will also hold an ACM Student Research Competition:
http://pldi17.sigplan.org/track/pldi-2017-student-research-competition


Co-located events:

+ ECOOP: European Conference on Object-Oriented Programming
+ DEBS: annual conference on Distributed Event-Based Systems
+ Curry On: conference on programming languages and emerging challenges
in industry.
+ ISMM: International Symposium on Memory Management
+ LCTES: Languages, Compilers, and Tools for Embedded Systems

Co-located workshops include:

+ ARRAY: Workshop on Libraries, Languages and Compilers for Array
Programming
+ DSW: Deep Specifications in the Wild
+ FMS: Formal Methods for Security
+ IC: Workshop on Incremental Computing
+ MAPL: Machine Learning and Programming Languages
+ PLMW: Programming Languages Mentoring Workshop
+ SOAP: International Workshop on the State Of the Art in Java Program
Analysis
+ WCIRE: Workshop for Compiler Infrastructure for Research and Education

Additionally, there will be eight co-located tutorials:

+ Bug detection in JavaScript web apps using the SAFE framework
+ Building your own modular static analyzer with Facebook Infer
+ Engineering Static Analyzers with Soufflé
+ Graal: High Performance Compilation for Managed Languages
+ P4: Programming the Network Data Plane
+ Polyhedral Compilation
+ Refinement Types for Program Verification and Synthesis
+ Scala, LMS and Delite for High-Performance DSLs and Program Generators
+ WALA Hack-A-Thon
+ Writing Verified Programs in CakeML

See the web site for a schedule and further details and links.  For
further updates, follow PLDI on the social media:

Facebook: https://www.facebook.com/PLDIConf
Twitter: https://twitter.com/PLDI

Albert Cohen, PLDI 2017 General Chair
Tobias Grosser, PLDI 2017 Publicity Chair

-- 
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: [Shameless self-promotion] Articles about programming-language theory for working programmers in Racket

[Alexander McLin]

Leandro,

Your article comes at a good time for me because I received my copy of 
"Semantics Engineering with PLT Redex" last week and am preparing to start 
studying it. I thought your examples are a nice exposition of the complex ideas 
that go into selecting features a programming language needs to support.

I thought the bicycle trip example illustrates nicely the tension between 
balancing simplicity and convenience, and reminds me simplicity isn't 
necessarily helpful.

As a working programmer earning his daily bread, I typically deal with complex 
and messy cases where programming convenience is preferred over simplicity but 
being able to step back and seeing the abstract principles underlying tools I 
use is helpful. 

My main take away from your article is that there are important features that 
come together to make a programming language function as a system for 
supporting effective abstractions to help formulate and solve computing 
problems.

As you emphasized in the article, it is very interesting how certain formal 
systems very different from each other are equivalent in terms of computational 
power and ultimately reduce to communication and data. That reinforces the 
insight that what a typical working programmer does is essentially formulating 
communication plans as data to be read and executed by a computer.

On a final note, I noticed with a pleasant surprise that you are at JHU, as it 
happens I am staff affiliated with JHU under Krieger. It's nice to see there is 
another Racketeer on Homewood!

I look forward to reading more of your articles in the future.

- Alexander

-- 
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: inspecting a table error 'error 'query: multiple statements given'

[Alexander McLin]

The error message is unclear but I believe SQLite do not support parameters for 
PRAGMA statements.

The SQLite documentation at http://www.sqlite.org/lang_expr.html#varparam  
specifically says parameters are supported by expressions. PRAGMA statements 
are not expressions. 

If you examine the SQL syntax structure defined for expressions at 
http://www.sqlite.org/lang_expr.html, you'll see PRAGMA is not part of the 
definition.

If you execute the following: (query db "PRAGMA table_info($1)"). It generates 
the same error without any parameter arguments being passed along. It makes me 
think the error may be arising from an internal parsing error and probably 
could be improved on.

-- 
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] range with small or zero step doesn't return

[Tim Jervis]

Dear Racket Users,

I’ve noticed the following procedure calls don’t return (on my 64 bit Mac 
hardware):

(range (- 1 1e-16) 1.0 1e-17)
(range 0 1 0)

While (2) is obvious, (1) tripped me up (as I hadn’t noticed my step size had 
fallen to effectively zero).

A small tweak to for.rkt in the racket distribution could trap the condition of 
an actually or effectively zero step. for.rkt already traps the condition where 
step is not real.

If this makes sense, could one of the authors consider adding the tweak? Or is 
there a reason for leaving it alone?

Kind regards,



Tim

Tim Jervis

http://timjervis.com/ 

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