Re: [racket-users] backwards-incompatible change to in-vector

[Stephen Chang]

> I think you should not change this backwards compatibility unless you
> really know it isn't used (and even then it is hard to know such
> things).

Well I still think these programs would be relying on a bug, since
they are referencing a non-existent vector element.

But since there's no agreement, I'll leave it for now.

I'll just add a special case for empty vectors and 0,0.

It's probably not worth it to add yet-another new special case, as in
Matthew's email, right?




>
> Robby
>
> On Tue, Jan 19, 2016 at 1:16 PM, Stephen Chang  wrote:
>> Yes, or course it's possible, at the expense of more unreadable code.
>>
>> But the zero special case doesnt make sense. And is inconsistent with
>> other out-of-range cases, eg (in-vector (vector) 1 1) errors
>>
>> To be clear, empty traversals with valid indices would still be legal,
>> eg (in-vector (vector 1 2) 1 1)
>>
>> On Tue, Jan 19, 2016 at 2:06 PM, Vincent St-Amour
>>  wrote:
>>> Would it be possible to special-case `(in-vector (vector) 0 0)`
>>> directly, and fix the bug while keeping backwards compatibility?
>>>
>>> Vincent
>>>
>>>
>>> On Tue, 19 Jan 2016 12:19:12 -0600,
>>> Stephen Chang wrote:

 I'm fixing pr 15227 but I would like to do so in a backwards-incompatible 
 way.

 Right now an out-of-range index is sometimes allowed as an argument to
 in-vector, leading to the bug:

 $ racket
 Welcome to Racket v6.4.0.4.
 -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
 SIGSEGV MAPERR si_code 1 fault on addr 0x180
 Aborted

 From what I can tell, the out-of-range index is allowed to enable this 
 program:

 (in-vector (vector) 0 0)

 I want to change in-vector so that the starting index is always a
 valid vector-ref. The above program would become illegal.

 From what I gather, the above program is allowed so that in-vector
 mimics in-range but I don't think this makes sense either if it means
 allowing out-of-range indices for the former.

 Any objections?

 --
 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.
>
> --
> 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] Top Level Variables or List of Shared Libraries

['John Clements' via Racket Users]

> On Jan 19, 2016, at 11:14 AM, Leif Andersen  wrote:
> 
> Is it possible to either create a variable that persists until the
> Racket VM shuts down or get a list of all of the libraries that are
> shared libraries that are currently being linked against the racket
> vm?

I can’t help you. But! This reminds me of a closely related problem that occurs 
with the `rsound` library.

The rsound library contains shared libraries. Running rsound programs performs 
dynamic linking against these libraries.

When students try to upgrade the package, terrible things happen; the update 
tries to replace the file, and the OS won’t allow it, because the dynamic 
library is still linked. This leaves things in a half-installed state from 
which (IIRC) it’s difficult to recover. If there were a way to enumerate 
currently-linked shared libraries, the update could simply refuse to run, which 
would be a substantial improvement.

CAVEAT: I haven’t tested this in the last two years. Please forgive me if this 
problem has already been resolved.

Thanks!

John



-- 
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] backwards-incompatible change to in-vector

[Robby Findler]

On Tuesday, January 19, 2016, Stephen Chang  wrote:

> > I think you should not change this backwards compatibility unless you
> > really know it isn't used (and even then it is hard to know such
> > things).
>
> Well I still think these programs would be relying on a bug, since
> they are referencing a non-existent vector element.


Just to be clear, you cannot know that. And even if you did, you would be
dictating how the programmers that maintain that code spend their time. If
they have something more important to do you are not giving them the option
to do their more important thing first but instead to do what you want. And
many programmers, when faced with this choice choose not to upgrade which
is a very bad outcome for us.

You could help those programmers by finding them and pointing out the fix
to them instead?

Robby



>
> But since there's no agreement, I'll leave it for now.
>
> I'll just add a special case for empty vectors and 0,0.
>
> It's probably not worth it to add yet-another new special case, as in
> Matthew's email, right?
>
>
>
>
> >
> > Robby
> >
> > On Tue, Jan 19, 2016 at 1:16 PM, Stephen Chang  > wrote:
> >> Yes, or course it's possible, at the expense of more unreadable code.
> >>
> >> But the zero special case doesnt make sense. And is inconsistent with
> >> other out-of-range cases, eg (in-vector (vector) 1 1) errors
> >>
> >> To be clear, empty traversals with valid indices would still be legal,
> >> eg (in-vector (vector 1 2) 1 1)
> >>
> >> On Tue, Jan 19, 2016 at 2:06 PM, Vincent St-Amour
> >> > wrote:
> >>> Would it be possible to special-case `(in-vector (vector) 0 0)`
> >>> directly, and fix the bug while keeping backwards compatibility?
> >>>
> >>> Vincent
> >>>
> >>>
> >>> On Tue, 19 Jan 2016 12:19:12 -0600,
> >>> Stephen Chang wrote:
> 
>  I'm fixing pr 15227 but I would like to do so in a
> backwards-incompatible way.
> 
>  Right now an out-of-range index is sometimes allowed as an argument to
>  in-vector, leading to the bug:
> 
>  $ racket
>  Welcome to Racket v6.4.0.4.
>  -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
>  SIGSEGV MAPERR si_code 1 fault on addr 0x180
>  Aborted
> 
>  From what I can tell, the out-of-range index is allowed to enable
> this program:
> 
>  (in-vector (vector) 0 0)
> 
>  I want to change in-vector so that the starting index is always a
>  valid vector-ref. The above program would become illegal.
> 
>  From what I gather, the above program is allowed so that in-vector
>  mimics in-range but I don't think this makes sense either if it means
>  allowing out-of-range indices for the former.
> 
>  Any objections?
> 
>  --
>  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.
> >
> > --
> > 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] backwards-incompatible change to in-vector

[Stephen Chang]

I'm fixing pr 15227 but I would like to do so in a backwards-incompatible way.

Right now an out-of-range index is sometimes allowed as an argument to
in-vector, leading to the bug:

$ racket
Welcome to Racket v6.4.0.4.
-> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
SIGSEGV MAPERR si_code 1 fault on addr 0x180
Aborted

>From what I can tell, the out-of-range index is allowed to enable this program:

(in-vector (vector) 0 0)

I want to change in-vector so that the starting index is always a
valid vector-ref. The above program would become illegal.

>From what I gather, the above program is allowed so that in-vector
mimics in-range but I don't think this makes sense either if it means
allowing out-of-range indices for the former.

Any objections?

-- 
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] Top Level Variables or List of Shared Libraries

[Leif Andersen]

Is it possible to either create a variable that persists until the
Racket VM shuts down or get a list of all of the libraries that are
shared libraries that are currently being linked against the racket
vm?

The reason why I ask is because I created a `from-c` require form[1],
which takes in a C implementation of a module, compiles it, links it,
and then loads the module. So using it would look something like this:

#lang racket/base
(require zordoz
 (from-c "foo.c"))

However, it seems very unsafe to just recompile link and load the c
file every time a module is run, because if the module is changed, the
old version of the module will still remain. Worse still, it could
cause the program to crash. And it's not trivial to unload the linked
library and reload it at run time.

So, I want to test if the module has already been compiled and linked,
if so, skip the compile process and just load the module. (Or if the c
file was modified throw an error telling the user to restart the VM.)
In order to do this, I either need to use a list of all of the shared
libraries linked with the Racket VM, or make that list myself. Now, I
tried putting that list in the module, and just mutating it whenever a
file is loaded[2]. This, however, doesn't work in an environment like
DrRacket where it uses a sandbox to emulate a new racket environment,
but it is still technically running in the same vm. (It fails because
the module seems to get reloaded, and thus the list gets reset.)

Thus, is there a way I can get a list of all of the currently linked
libraries, or create a persistent variable that lasts as long as the
VM is running? The `current-standard-link-libraries`[3] parameter
doesn't work here because it only lists the standard libraries that
are linked to the VM, and thus not ones that are loaded with
`link-extension`.

As a side note, an alternative approach I took to this problem was to
compile a fresh version of the library with a new file name every
single time the require form was run. (Which would create a bunch of
extra files, but ideally those could be deleted when the VM shuts
down. Again, kind of odd, but I wouldn't use this `from-c` think in
anything besides quick tests anyway, so I don't think it matters too
much.) I made an implementation of that here[4] (there are a few bugs
in the counting code for creating new files, and it currently just
stays at 0. That's not the problem though.) Whenever I use this code,
to require something `from-c`, I get the following error:

load-extension: expected module not found
  expected: syntax-grabber-0
  found: module `syntax-grabber'
  path: /Users/leif/compiled/native/x86_64-macosx/3m/syntax-grabber-0.dylib

Which is odd, because the `names` variable is in fact
`syntax-grabber`, not `syntax-grabber-0`. And when I run this code in
a `begin-for-syntax` rather than a `make-require-transformer` it works
fine.

So is there anyway I can either:
(a) Get a list of all of the shared objects that are currently linked
against the VM (ideally without using the FFI),
(b) Keep a variable that persists until the VM terminates,
(c) or load a module who's file name differs from the module it instantiates?

Thank you.

[1]: http://pasterack.org/pastes/11082
[2]: http://pasterack.org/pastes/36865
[3]: 
http://docs.racket-lang.org/dynext/Linking.html?q=dynext%2Flink#%28def._%28%28lib._dynext%2Flink..rkt%29._current-standard-link-libraries%29%29
[4]: http://pasterack.org/pastes/63016

~Leif Andersen

-- 
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] backwards-incompatible change to in-vector

[Vincent St-Amour]

Would it be possible to special-case `(in-vector (vector) 0 0)`
directly, and fix the bug while keeping backwards compatibility?

Vincent


On Tue, 19 Jan 2016 12:19:12 -0600,
Stephen Chang wrote:
> 
> I'm fixing pr 15227 but I would like to do so in a backwards-incompatible way.
> 
> Right now an out-of-range index is sometimes allowed as an argument to
> in-vector, leading to the bug:
> 
> $ racket
> Welcome to Racket v6.4.0.4.
> -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
> SIGSEGV MAPERR si_code 1 fault on addr 0x180
> Aborted
> 
> From what I can tell, the out-of-range index is allowed to enable this 
> program:
> 
> (in-vector (vector) 0 0)
> 
> I want to change in-vector so that the starting index is always a
> valid vector-ref. The above program would become illegal.
> 
> From what I gather, the above program is allowed so that in-vector
> mimics in-range but I don't think this makes sense either if it means
> allowing out-of-range indices for the former.
> 
> Any objections?
> 
> -- 
> 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] backwards-incompatible change to in-vector

[Robby Findler]

I think you should not change this backwards compatibility unless you
really know it isn't used (and even then it is hard to know such
things).

Robby

On Tue, Jan 19, 2016 at 1:16 PM, Stephen Chang  wrote:
> Yes, or course it's possible, at the expense of more unreadable code.
>
> But the zero special case doesnt make sense. And is inconsistent with
> other out-of-range cases, eg (in-vector (vector) 1 1) errors
>
> To be clear, empty traversals with valid indices would still be legal,
> eg (in-vector (vector 1 2) 1 1)
>
> On Tue, Jan 19, 2016 at 2:06 PM, Vincent St-Amour
>  wrote:
>> Would it be possible to special-case `(in-vector (vector) 0 0)`
>> directly, and fix the bug while keeping backwards compatibility?
>>
>> Vincent
>>
>>
>> On Tue, 19 Jan 2016 12:19:12 -0600,
>> Stephen Chang wrote:
>>>
>>> I'm fixing pr 15227 but I would like to do so in a backwards-incompatible 
>>> way.
>>>
>>> Right now an out-of-range index is sometimes allowed as an argument to
>>> in-vector, leading to the bug:
>>>
>>> $ racket
>>> Welcome to Racket v6.4.0.4.
>>> -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
>>> SIGSEGV MAPERR si_code 1 fault on addr 0x180
>>> Aborted
>>>
>>> From what I can tell, the out-of-range index is allowed to enable this 
>>> program:
>>>
>>> (in-vector (vector) 0 0)
>>>
>>> I want to change in-vector so that the starting index is always a
>>> valid vector-ref. The above program would become illegal.
>>>
>>> From what I gather, the above program is allowed so that in-vector
>>> mimics in-range but I don't think this makes sense either if it means
>>> allowing out-of-range indices for the former.
>>>
>>> Any objections?
>>>
>>> --
>>> 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.

-- 
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] backwards-incompatible change to in-vector

[Stephen Chang]

Yes, or course it's possible, at the expense of more unreadable code.

But the zero special case doesnt make sense. And is inconsistent with
other out-of-range cases, eg (in-vector (vector) 1 1) errors

To be clear, empty traversals with valid indices would still be legal,
eg (in-vector (vector 1 2) 1 1)

On Tue, Jan 19, 2016 at 2:06 PM, Vincent St-Amour
 wrote:
> Would it be possible to special-case `(in-vector (vector) 0 0)`
> directly, and fix the bug while keeping backwards compatibility?
>
> Vincent
>
>
> On Tue, 19 Jan 2016 12:19:12 -0600,
> Stephen Chang wrote:
>>
>> I'm fixing pr 15227 but I would like to do so in a backwards-incompatible 
>> way.
>>
>> Right now an out-of-range index is sometimes allowed as an argument to
>> in-vector, leading to the bug:
>>
>> $ racket
>> Welcome to Racket v6.4.0.4.
>> -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
>> SIGSEGV MAPERR si_code 1 fault on addr 0x180
>> Aborted
>>
>> From what I can tell, the out-of-range index is allowed to enable this 
>> program:
>>
>> (in-vector (vector) 0 0)
>>
>> I want to change in-vector so that the starting index is always a
>> valid vector-ref. The above program would become illegal.
>>
>> From what I gather, the above program is allowed so that in-vector
>> mimics in-range but I don't think this makes sense either if it means
>> allowing out-of-range indices for the former.
>>
>> Any objections?
>>
>> --
>> 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.

[racket-users] 1st Call for Contributions for SPLASH'16: OOPSLA, Onward!, Workshops, DLS, SLE, GPCE

[Tijs van der Storm]

//
ACM Conference on Systems, Programming, Languages, and Applications:
Software for Humanity (SPLASH'16)

Amsterdam, The Netherlands
Sun 30th October - Fri 4th November , 2016

http://2016.splashcon.org

Sponsored by ACM SIGPLAN

//

FIRST COMBINED CALL FOR CONTRIBUTIONS:
OOPSLA
Onward!
Workshops
Doctoral Symposium
Posters
Dynamic Languages Symposium (DLS)
Software Language Engineering (SLE)
Generative Programming: Concepts & Experiences (GPCE)

//


# SPLASH 2016

The ACM SIGPLAN conference on Systems, Programming, Languages and
Applications: Software for Humanity (SPLASH) embraces all aspects of
software construction, to make it the premier conference at the
intersection of programming, languages, systems, and software engineering.
We invite high quality submissions describing original and unpublished work.


## OOPSLA Research Papers

Papers that address any aspect of software development are welcome,
including requirements, modeling, prototyping, design, implementation,
generation, analysis, verification, testing, evaluation, maintenance,
reuse, replacement, and retirement of software systems. Papers may address
these topics in a variety of ways, including new tools (such as languages,
program analyses, and runtime systems), new techniques (such as
methodologies, design processes, code organization approaches, and
management techniques), and new evaluations (such as formalisms and proofs,
corpora analyses, user studies, and surveys).

Submissions due: Wed 23 March, 2016
http://2016.splashcon.org/track/splash-2016-oopsla


## Onward! Research Papers

Onward! is a premier multidisciplinary conference focused on everything to
do with programming and software: including processes, methods, languages,
communities, and applications. Onward! is more radical, more visionary, and
more open than other conferences to ideas that are well-argued but not yet
proven. We welcome different ways of thinking about, approaching, and
reporting on programming language and software engineering research.

Submissions due: Fri 1 April, 2016
http://2016.splashcon.org/track/onward2016/onward-2016-papers


## Onward! Essays

Onward! Essays is looking for clear and compelling pieces of writing about
topics important to the software community. An essay can be an exploration
of a topic, its impact, or the circumstances of its creation; it can
present a personal view of what is, explore a terrain, or lead the reader
in an act of discovery; it can be a philosophical digression or a deep
analysis. It can describe a personal journey, perhaps by which the author
reached an understanding of such a topic. The subject area should be
interpreted broadly and can include the relationship of software to human
endeavors, or its philosophical, sociological, psychological, historical,
or anthropological underpinnings.

Submissions due: Fri 1 April, 2016
http://2016.splashcon.org/track/onward2016/onward2016-essays

## Workshops

The SPLASH Workshops track will host a variety of high-quality workshops,
allowing their participants to meet and discuss research questions with
peers, to mature new and exciting ideas, and to build up communities and
start new collaborations. SPLASH workshops complement the main tracks of
the conference and provide meetings in a smaller and more specialized
setting. Workshops cultivate new ideas and concepts for the future,
optionally recorded in formal proceedings.

Late Phase Submissions of Workshop Proposals due: Fri 4 Mar, 2016
http://2016.splashcon.org/track/splash2016-workshops


## Doctoral Symposium

The SPLASH Doctoral Symposium provides students with useful guidance for
completing their dissertation research and beginning their research
careers. The Symposium will provide an interactive forum for doctoral
students who have progressed far enough in their research to have a
structured proposal, but will not be defending their dissertation in the
next 12 months.

Submissions due: Thu 30 Jun, 2016
http://2016.splashcon.org/track/splash-2016-ds


## Posters

The SPLASH Poster track provides an excellent forum for authors to present
their recent or ongoing projects in an interactive setting, and receive
feedback from the community. We invite submissions covering any aspect of
programming, systems, languages and applications. The goal of the poster
session is to encourage and facilitate small groups of individuals
interested in a technical area to gather and interact.

Poster submissions due: Fri 8 Jul, 2016
http://2016.splashcon.org/track/splash-2016-posters

## Dynamic Languages Symposium (DLS)

DLS is the premier forum for researchers and practitioners to share
knowledge and research on dynamic languages, their implementation, and
applications. The influence of 

[racket-users] Using the web server without continuations?

[Alexis King]

I’ve been using the Racket web server, and I’m very pleased with how
easy it’s been to get a simple working application. However, so far, I
haven’t been using send/suspend or any of the other features that
leverage continuations.

I’ve been wondering: since I’m not using send/back (just returning
responses) or create-none-manager, am I leaking memory by capturing
continuations that never get used? Do I need to do anything to safely
“opt out” of the continuation features? Or can I safely keep using
stateful servlets without continuations and expect it to not capture
anything?

Thanks,
Alexis

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

Re: [racket-users] backwards-incompatible change to in-vector

[Gustavo Massaccesi]

I couldn't write an example that is not obvious, but this programs
looks ok to me:

;---
#lang racket
(define (display-vector v)
  (for ([x (in-vector v 0 (vector-length v))])
(display x)))

(display-vector (vector 1 2 3))
(newline)
(display-vector (vector))
(newline)
;---

And I also like (in-vector (vector) 1 1), but it's more difficult to
defend this case.

Gustavo


On Tue, Jan 19, 2016 at 5:55 PM, Robby Findler
 wrote:
>
>
> On Tuesday, January 19, 2016, Stephen Chang  wrote:
>>
>> > I think you should not change this backwards compatibility unless you
>> > really know it isn't used (and even then it is hard to know such
>> > things).
>>
>> Well I still think these programs would be relying on a bug, since
>> they are referencing a non-existent vector element.
>
>
> Just to be clear, you cannot know that. And even if you did, you would be
> dictating how the programmers that maintain that code spend their time. If
> they have something more important to do you are not giving them the option
> to do their more important thing first but instead to do what you want. And
> many programmers, when faced with this choice choose not to upgrade which is
> a very bad outcome for us.
>
> You could help those programmers by finding them and pointing out the fix to
> them instead?
>
> Robby
>
>
>>
>>
>> But since there's no agreement, I'll leave it for now.
>>
>> I'll just add a special case for empty vectors and 0,0.
>>
>> It's probably not worth it to add yet-another new special case, as in
>> Matthew's email, right?
>>
>>
>>
>>
>> >
>> > Robby
>> >
>> > On Tue, Jan 19, 2016 at 1:16 PM, Stephen Chang 
>> > wrote:
>> >> Yes, or course it's possible, at the expense of more unreadable code.
>> >>
>> >> But the zero special case doesnt make sense. And is inconsistent with
>> >> other out-of-range cases, eg (in-vector (vector) 1 1) errors
>> >>
>> >> To be clear, empty traversals with valid indices would still be legal,
>> >> eg (in-vector (vector 1 2) 1 1)
>> >>
>> >> On Tue, Jan 19, 2016 at 2:06 PM, Vincent St-Amour
>> >>  wrote:
>> >>> Would it be possible to special-case `(in-vector (vector) 0 0)`
>> >>> directly, and fix the bug while keeping backwards compatibility?
>> >>>
>> >>> Vincent
>> >>>
>> >>>
>> >>> On Tue, 19 Jan 2016 12:19:12 -0600,
>> >>> Stephen Chang wrote:
>> 
>>  I'm fixing pr 15227 but I would like to do so in a
>>  backwards-incompatible way.
>> 
>>  Right now an out-of-range index is sometimes allowed as an argument
>>  to
>>  in-vector, leading to the bug:
>> 
>>  $ racket
>>  Welcome to Racket v6.4.0.4.
>>  -> (for/sum ([x (in-vector (vector 10 20) 2 -1 -1)]) x)
>>  SIGSEGV MAPERR si_code 1 fault on addr 0x180
>>  Aborted
>> 
>>  From what I can tell, the out-of-range index is allowed to enable
>>  this program:
>> 
>>  (in-vector (vector) 0 0)
>> 
>>  I want to change in-vector so that the starting index is always a
>>  valid vector-ref. The above program would become illegal.
>> 
>>  From what I gather, the above program is allowed so that in-vector
>>  mimics in-range but I don't think this makes sense either if it means
>>  allowing out-of-range indices for the former.
>> 
>>  Any objections?
>> 
>>  --
>>  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.
>> >
>> > --
>> > 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 

Re: [racket-users] Using the web server without continuations?

[Jay McCarthy]

If you do not use send/suspend or send/suspend/dispatch, no continuations
are ever saved. You do not need to "opt out". You "opt in" to continuations.

Jay

On Tue, Jan 19, 2016 at 7:07 PM, Alexis King  wrote:

> I’ve been using the Racket web server, and I’m very pleased with how
> easy it’s been to get a simple working application. However, so far, I
> haven’t been using send/suspend or any of the other features that
> leverage continuations.
>
> I’ve been wondering: since I’m not using send/back (just returning
> responses) or create-none-manager, am I leaking memory by capturing
> continuations that never get used? Do I need to do anything to safely
> “opt out” of the continuation features? Or can I safely keep using
> stateful servlets without continuations and expect it to not capture
> anything?
>
> Thanks,
> Alexis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

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

[racket-users] Re: Code critique request: data/fetch, proc for walking hashes/lists

[David K. Storrs]

I apologize for the long ping time on this -- for whatever reason I didn't get 
any of the replies sent to my email and I thought no one had responded. 

JCG, Jack, thank you very much for taking the time. 

Jack: I had to stare at your code for a while before I got it, but thank you 
for it. That's really elegant, which is exactly the sort of thing I was looking 
for. Much appreciated. 

Dave

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

Re: [racket-users] Store value with unsupported type in Postgres?

[Ryan Culpepper]

On 01/17/2016 06:35 PM, Alexis King wrote:

The DB docs for SQL type conversions[1] note that not all Postgres types
are supported by Racket, and it recommends using a cast to work around
this. It even uses the inet type as an example right at the start of the
page. However, I want to store an inet value in my database, not query
an inet value out, and I can’t figure out what set of casts I need for
the right coercion to take place.

My query looks like this:

   (query-exec conn "INSERT INTO some_table (ip) VALUES ($1)" client-ip)

Attempting to execute that query gives me the following error:

   query-exec: unsupported type
 type: inet
 typeid: 869

Is there any way to annotate this so that I can insert into that table?


Try something like

  INSERT INTO some_table (ip) VALUES ($1::text::inet)

or the corresponding CAST syntax. The first cast, ::text, determines the 
type of the parameter. The second, ::inet, converts the text to the inet 
type.


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] Using the web server without continuations?

[Alexis King]

Perfect! That was my hope. One more question: if I did want to opt-in to
continuations for just a single portion of my application, could I? The
way I’ve been structuring my application is to have a module that serves
as an entry point that calls serve/servlet and passes a dispatch
function defined via dispatch-rules. The various handler functions are
separated into multiple modules.

Right now, all those handler functions just use #lang racket/base, but
if I wanted a certain route to use continuations, could I change one of
those modules to use #lang web-server and then call send/suspend within
it? Or would I have to have a multi-servlet application?

> On Jan 19, 2016, at 16:29, Jay McCarthy  wrote:
> 
> If you do not use send/suspend or send/suspend/dispatch, no continuations are 
> ever saved. You do not need to "opt out". You "opt in" to continuations.
> 
> Jay

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