Re: [racket-users] iso-recursive types not allowed in TR?

['John Clements' via users-redirect]

> On Jun 12, 2015, at 6:07 PM, Asumu Takikawa  wrote:
> 
> On 2015-06-12 17:30:42 -0700, 'John Clements' via users-redirect wrote:
>> (define-type (HuffJsexpr T)
>>  (U T (HashTable Symbol HuffJsexpr)))
> 
> The variant that Alex mentioned should work.

Interesting… there *is* a problem, though; If I try to write a function with 
the type, say,

(All (T) ((HuffJsexpr T) -> number))

I get into trouble quickly trying to distinguish between the two variants, 
because of course the type T might be something confusing like (HashTable 
Symbol Symbol), so no test can distinguish between the two variants. 

Anyhow, no big deal, I can just make them dynamic checks.

Okay, I shouldn’t change topics, but while I’ve got you (guys): it looks like 
(module+ test …) now works in TR, but not when there are imported bindings… 
suppose I have foo.rkt:

#lang typed/racket

(provide [struct-out Z])

(define-struct Z ([a : Number]))

… and then try to import it in a test+:

#lang typed/racket

(require "foo.rkt")

(Z 3)

(module+ test
  (Z 3))

this leads to this error message:

Type Checker: missing type for identifier;
 consider using `require/typed' to import it
  identifier: make-Z
  from module: (submod foo.rkt #%contract-defs-reference .. #%contract-defs) 
in: make-Z

I tried various require/typed combinations, but only managed to get an error on 
`make-Z1`, which doesn’t sound like forward progress.

John

> 
> I think the only restrictions on recursive types that TR enforces are that it
> has to be (A) productive, in that there's a real type constructor in the
> recursive body, and (B) it can't be polymorphic recursive.
> 
> (A) implies something like (Rec X (U Integer X)) isn't allowed. U doesn't
> count as a type constructor for this purpose.
> 
> (B) implies you can't have a type definition like:
> 
>  (define-type (MyType T) (U Integer (MyType (Listof T
> 
> where the instantiated type changes.
> 
> Cheers,
> Asumu

-- 
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] Break-before-run

[Robby Findler]

Oh, I see. I've pushed that change.

Thanks,
Robby

On Fri, Jun 12, 2015 at 8:08 PM, Neil Van Dyke  wrote:
> Robby Findler wrote on 06/12/2015 09:01 PM:
>>
>> I think DrRacket will kill the old execution when you hit run. Are you not
>> seeing that?
>
>
> I just tested with 6.1.1 on Linux, and (with a `sleep` running) neither the
> button click nor Ctrl-R responds until you manually break the execution with
> button or key combination.
>
> +1 on John's question; this need to manually break still occasionally
> results in pilot error for me, and I've been using this UI since DrScheme
> v103.
>
> Neil V.
>
>
> --
> 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] Break-before-run

[Neil Van Dyke]

Robby Findler wrote on 06/12/2015 09:01 PM:
I think DrRacket will kill the old execution when you hit run. Are you 
not seeing that?


I just tested with 6.1.1 on Linux, and (with a `sleep` running) neither 
the button click nor Ctrl-R responds until you manually break the 
execution with button or key combination.


+1 on John's question; this need to manually break still occasionally 
results in pilot error for me, and I've been using this UI since 
DrScheme v103.


Neil V.

--
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] iso-recursive types not allowed in TR?

[Asumu Takikawa]

On 2015-06-12 17:30:42 -0700, 'John Clements' via users-redirect wrote:
> (define-type (HuffJsexpr T)
>   (U T (HashTable Symbol HuffJsexpr)))

The variant that Alex mentioned should work.

I think the only restrictions on recursive types that TR enforces are that it
has to be (A) productive, in that there's a real type constructor in the
recursive body, and (B) it can't be polymorphic recursive.

(A) implies something like (Rec X (U Integer X)) isn't allowed. U doesn't
count as a type constructor for this purpose.

(B) implies you can't have a type definition like:

  (define-type (MyType T) (U Integer (MyType (Listof T

where the instantiated type changes.

Cheers,
Asumu

-- 
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] iso-recursive types not allowed in TR?

['John Clements' via users-redirect]

> On Jun 12, 2015, at 5:52 PM, Alexander D. Knauth  wrote:
> 
> 
> On Jun 12, 2015, at 8:30 PM, 'John Clements' via users-redirect 
>  wrote:
> 
>> Here’s the type I want to write:
>> 
>> (define-type (HuffJsexpr T)
>> (U T (HashTable Symbol HuffJsexpr)))
> 
> 
> Do you mean this?
> (define-type (HuffJsexpr T)
>  (U T (HashTable Symbol (HuffJsexpr T

D’oh! Can’t believe I missed that.

Actually, I also can’t believe that TR allowed me to use a type constructor 
without an argument like that.

Thanks!


John

> 
> #lang typed/racket
> (define-type (HuffJsexpr T)
>  (U T (HashTable Symbol (HuffJsexpr T
> (: x : (HuffJsexpr String))
> (define x
>  #hash([a . "a string"]
>[b . #hash([c . #hash()]
>   [d . "another string"])]
>[e . #hash([f . "and another"])]))
> 

-- 
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] Break-before-run

[Robby Findler]

I think DrRacket will kill the old execution when you hit run. Are you
not seeing
that?

Robby

On Friday, June 12, 2015, John Carmack  wrote:

>  Would it be reasonable to have DrRacket leave the Run option available
> at all times, and force a break if the program is already running?
>
>
>
> I find myself doing the ctrl-B ctrl-R sequence very often, or sometimes
> wondering why nothing is happening after my ctrl-R because I didn’t notice
> the program was still running.
>
>
>
> --
> 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] iso-recursive types not allowed in TR?

[Alexander D. Knauth]

On Jun 12, 2015, at 8:30 PM, 'John Clements' via users-redirect 
 wrote:

> Here’s the type I want to write:
> 
> (define-type (HuffJsexpr T)
>  (U T (HashTable Symbol HuffJsexpr)))


Do you mean this?
(define-type (HuffJsexpr T)
  (U T (HashTable Symbol (HuffJsexpr T

#lang typed/racket
(define-type (HuffJsexpr T)
  (U T (HashTable Symbol (HuffJsexpr T
(: x : (HuffJsexpr String))
(define x
  #hash([a . "a string"]
[b . #hash([c . #hash()]
   [d . "another string"])]
[e . #hash([f . "and another"])]))

-- 
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] Break-before-run

[John Carmack]

Would it be reasonable to have DrRacket leave the Run option available at all 
times, and force a break if the program is already running?

I find myself doing the ctrl-B ctrl-R sequence very often, or sometimes 
wondering why nothing is happening after my ctrl-R because I didn't notice the 
program was still running.

-- 
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] iso-recursive types not allowed in TR?

['John Clements' via users-redirect]

Here’s the type I want to write:

(define-type (HuffJsexpr T)
  (U T (HashTable Symbol HuffJsexpr)))

… for use in converting a tree to a jsexpr. My memory was that this wasn’t 
possible in TR because TR would get caught in a loop trying to figure out how 
many times to “unfold” the type in order to make type-checking work. IIUC the 
best solution is just … not to try to do this in TR.  Is that right?

Many 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] System Scheme (RnRS): Shared Secret Generator

[Tony Garnock-Jones]

On 06/12/2015 03:15 AM, Michael Titke wrote:
> In my understanding the pseudo random number generator is deterministic.
> That means for the same input seed /random/ will always return the same
> value. This is why one usually has to set a new state for each call of
> random.

If you're generating randomness for cryptographic purposes, e.g.
generation of passwords, you should ABSOLUTELY NOT use Racket's (random).

The built-in random number generator is not a cryptographically strong PRNG.

Instead, simply read the desired number of bits from /dev/urandom. Do
not use (random) at all.

>  In the current implementation I get a one byte value from the entropy
> pool via the device "/dev/urandom". One byte has 256 possibilities. Now
> that already is true randomness but I have to map it onto a character
> set of 65 possible output characters.

The correct way to choose at random from 65 distinct possibilities using
/dev/urandom is:

 1 read one byte
 2 mask it with #b111, the smallest one-less-than-power-of-two
   larger than the range. (This optimization step is optional.)
 3 if the result is greater than or equal to 65, then loop back to
   step 1.
 4 otherwise, the result will have been drawn uniformly at random from
   the range 0-64 inclusive.

> But to be able to use true randomness with Racket's random

Racket's (random) will *never* produce randomness usable in a
cryptographic application.

Cheers,
  Tony

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

Re: [racket-users] System Scheme (RnRS): Shared Secret Generator

[Konrad Hinsen]

On 12/06/2015 15:35, Michael Titke wrote:


That does not explain the bias, I guess. I repeat: But IMHO a function
(random n state/generator) should guarantee a common saturation of the
destination space when the current state is filled with real randomness.


I have never seen such a criterion for the seeding procedure of any 
random generator. It's not an unreasonable expectation, but I don't 
think any implementation actually makes such a promise.



Do you really think that seeding with numbers from an entropy pool would
create such a strong bias. I don't think so.


I have no opinion about this. But I do remember Knuth's warning never to 
choose a random number generator at random. It's very hard to predict 
the impact of any change.


Konrad.

--
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] System Scheme (RnRS): Shared Secret Generator

[Alexander D. Knauth]

On Jun 12, 2015, at 9:35 AM, Michael Titke  wrote:

> On 12/06/2015 13:21, Konrad Hinsen wrote:

>> Seeding is provided for two use cases: 1) Reproducibility, ... 2) "Real" 
>> randomization, by setting the seed from some unpredictable source, such as 
>> the system time. In both cases, the idea is to set the seed once at the 
>> beginning of a program run.

> With your idea in #2 I would reliably produce known sequences depending on 
> only 256 original states. 

>> The statistical properties of the pseudo-random sequence hold only for an 
>> unperturbed sequence, i.e. without changing the seed. If you set the seed 
>> every time you ask for a random number, your random sequence becomes simply 
>> some complicated function of your input seed, whose statistical properties 
>> are hard to predict and most probably not what you want.

> If you want to look at the system and do a black box test then the result 
> would be:

> true randomness / noise -> Racket's randomness implementation with one 
> initial state -> one of 256 known sequences

If you want one of 65536 known sequences, you can get 2 bytes of initial 
randomness to start though, right?
And if you want one of 16777216 known sequences, you can use 3 bytes, and so on?
Increase the seed space?

> true randomness / noise -> GNU-Guile's randomness implementation -> noise
> 
> BTW the basic formula of cryptography is: Message |+| Randomness -> Randomness
> Now replace Randomness with Racket and try to ...

-- 
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] System Scheme (RnRS): Shared Secret Generator

[Michael Titke]

On 12/06/2015 13:21, Konrad Hinsen wrote:

On 12/06/15 09:15, Michael Titke wrote:


In my understanding the pseudo random number generator is deterministic.
That means for the same input seed /random/ will always return the same
value. This is why one usually has to set a new state for each call of
random.


No, quite on the contrary.

Before going on, please note that I never looked at the specific 
random generator used by Racket. I assume it's one of the popular 
random number generator algorithms. For what follows, it doesn't even 
matter which one.


All pseudorandom generators produce a sequence of numbers. The 
intention is that the sequence should have as little detectable 
correlation as possible. The algorithms differ in how they define this 
goal exactly, and how well they reach it.
Right, it should not be the same number on every call to random but the 
same sequence of numbers for each and every seed. Whenever I use the 
same seed I will get the same sequence of random numbers for the 
sequence of calls to random.





The principle behind all these generators is a chaotic dynamic process 
that transforms the current state of the generator (some finite number 
of bits) into a new state, which is used for the next call. The 
returned value is some function of the state. Setting a new seed 
changes to state to some function of the seed value.


Seeding is provided for two use cases: 1) Reproducibility, mainly for 
software testing. If you set the seed to some constant at the start of 
your program, it will behave exactly the same way whenever it is run. 
2) "Real" randomization, by setting the seed from some unpredictable 
source, such as the system time. In both cases, the idea is to set the 
seed once at the beginning of a program run.


With your idea in #2 I would reliably produce known sequences depending 
on only 256 original states. Using as much entropy from the pool as my 
current implementation is uncommon but it definitely does not create the 
bias. I "abuse" the pseudo random number generator only to map these 256 
possibilities onto the list (mathematical vector) of 65 characters. 
Racket's implementation somehow introduces that bias. But IMHO a 
function random (n state/generator) should guarantee a common saturation 
of the destination space.


From the Guile reference:

Note that the initial value of `*random-state*' is the same every
time Guile starts up.  Therefore, if you don't pass a STATE parameter
to the above procedures, and you don't set `*random-state*' to
`(seed->random-state your-seed)', where `your-seed' is something that
_isn't_ the same every time, you'll get the same sequence of "random"
numbers on every run.

The current system time is highly predictable.




The statistical properties of the pseudo-random sequence hold only for 
an unperturbed sequence, i.e. without changing the seed. If you set 
the seed every time you ask for a random number, your random sequence 
becomes simply some complicated function of your input seed, whose 
statistical properties are hard to predict and most probably not what 
you want.


That does not explain the bias, I guess. I repeat: But IMHO a function 
(random n state/generator) should guarantee a common saturation of the 
destination space when the current state is filled with real randomness. 
Do you really think that seeding with numbers from an entropy pool would 
create such a strong bias. I don't think so. On the contrary it does 
away with the predictable sequences of the 256 original states won by 
using the pure result of reading the randomness device.


If you want to look at the system and do a black box test then the 
result would be:


true randomness / noise -> Racket's randomness implementation with a new 
state each time -> strongly biased noise


true randomness / noise -> Racket's randomness implementation with one 
initial state -> one of 256 known sequences


true randomness / noise -> GNU-Guile's randomness implementation -> noise

BTW the basic formula of cryptography is: Message |+| Randomness -> 
Randomness

Now replace Randomness with Racket and try to ...

--
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] System Scheme (RnRS): Shared Secret Generator

[Konrad Hinsen]

On 12/06/15 09:15, Michael Titke wrote:


In my understanding the pseudo random number generator is deterministic.
That means for the same input seed /random/ will always return the same
value. This is why one usually has to set a new state for each call of
random.


No, quite on the contrary.

Before going on, please note that I never looked at the specific random 
generator used by Racket. I assume it's one of the popular random number 
generator algorithms. For what follows, it doesn't even matter which one.


All pseudorandom generators produce a sequence of numbers. The intention 
is that the sequence should have as little detectable correlation as 
possible. The algorithms differ in how they define this goal exactly, 
and how well they reach it.


The principle behind all these generators is a chaotic dynamic process 
that transforms the current state of the generator (some finite number 
of bits) into a new state, which is used for the next call. The returned 
value is some function of the state. Setting a new seed changes to state 
to some function of the seed value.


Seeding is provided for two use cases: 1) Reproducibility, mainly for 
software testing. If you set the seed to some constant at the start of 
your program, it will behave exactly the same way whenever it is run. 2) 
"Real" randomization, by setting the seed from some unpredictable 
source, such as the system time. In both cases, the idea is to set the 
seed once at the beginning of a program run.


The statistical properties of the pseudo-random sequence hold only for 
an unperturbed sequence, i.e. without changing the seed. If you set the 
seed every time you ask for a random number, your random sequence 
becomes simply some complicated function of your input seed, whose 
statistical properties are hard to predict and most probably not what 
you want.


Konrad.

--
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] racket on android (Was: Racket modules in R6RS?)

[Lehi Toskin]

On Thursday, June 11, 2015 at 7:12:48 PM UTC-7, neil wrote:
> Matthew Flatt wrote on 06/11/2015 10:00 PM:
> > Android via NDK is a supported platform.
> 
> Matthew, that's great.  Thank you.
> 
> Anyone implemented `racket/gui` for Android with this, or otherwise 
> hooked up things so that the Racket program can drive a UI on Android?
> 
> Neil V.

Racket GUI programming on Android? This must be(come) a thing!

-- 
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] System Scheme (RnRS): Shared Secret Generator

[Michael Titke]

On 12/06/2015 00:38, Matthew Flatt wrote:

At Wed, 10 Jun 2015 18:44:15 +0200, Michael Titke wrote:

On 10/06/2015 12:33, Michael Titke wrote:

I changed from one OS to another and I was missing a simple feature:
automatic password generation. To fill the gap with a Scheme I
implemented such a generator as a command line tool respectively
/crypto sweet/.

After having read /SRFI 27: Sources of Random Bits/ I decided to
implement my algorithm natively with /Guile 1.8/ and /Racket 6.1/.
There is some portability of simple RnRS System Scheme programs: right
now it seems that the "heritage" of the Scheme Shell (/scsh/) grants
portability across UNIX/POSIX/SUS systems.

Even when it comes to true randomness as perhaps generated by the
noise in the low order magnitudes/bits of hardware sensors which is
enhanced and accessible with the file system device entry
"/dev/urandom" this simple System Scheme Script remains portable.
Accessing entropy pools on other systems should be as easy - perhaps
with the foreign function interface.

With real entropy pools the need for the interface described by SRFI
27 vanishes almost completely. It's still a good idea to seed some
randomizing function with real entropy before using it but randomizing
functions do IMHO not constitute a domain of their own whereas SRFI 27
declares them to be.



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

The expressions used in this text might diverge significantly from usual
mathematical terminology.
But I didn't study maths at university ...

There seems to be a strong bias in the /Racket/ version (three examples:
"G3GpGGGCuG3u", "GGIGYGGGI9GG", "mGCnF3G,") with a lot of capital
letter Gs so please don't use it in production environments.
   This bias is that obvious because there neither is a further
permutation of the initial character sets nor an obfuscation of the
result. But this bias might mean that the procedure /random/ is not
(what I call) /holomorphic/: the procedure /random /does not "spread or
distribute the seed" across the destination space (one dimension with a
magnitude denoted by n). Filling all the 31 bits of the seed might
produce visually more appealing results but it could as well be as
strongly biased as the examples given. In my understanding of /random/
as an /unstable function/ *the current behavior is **wrong* or I missed
some point about Racket's randomness. Right now it seems to have the
opposite effect of an unstable function: it seems to reduce the entropy
in the given example like a stabilizer where it should act as a
randomizer ...

The other version does not have such an obvious bias but I have not yet
analyzed the "saturation / distribution" and other properties of the
resulting shared secrets. Right now I do not have the time to check this
and I don't want to file a bug report as long as I'm not sure about the
source of the bias.

I'm not sure I follow, but I think you're right to suggest an issue
with `random-seed`. The space of inputs for `random-seed` is much
smaller than the state of the random-number generator, and by
repeatedly setting the seed that way, you're reducing the space of
generated numbers; it makes sense that it would also bias the generated
numbers in various.


In my understanding the pseudo random number generator is deterministic. 
That means for the same input seed /random/ will always return the same 
value. This is why one usually has to set a new state for each call of 
random.
 In the current implementation I get a one byte value from the entropy 
pool via the device "/dev/urandom". One byte has 256 possibilities. Now 
that already is true randomness but I have to map it onto a character 
set of 65 possible output characters. This is why I put the true 
randomness byte into the seed and then I call random to do the mapping 
correctly. There is almost four times the entropy of the output 
possibilities but random still creates that bias in the range from 0 to 255.


A decade ago or more I had a short look at chaos functions or unstable 
functions. The only I was able to understand at that time started to 
become unstable or chaotic only after some distance away from the 
origin. For small numbers it was - well, I can't remember exactly - 
almost linear or sine like ...


Racket's /random/ seems to work well with the current values of the 
system clock in microseconds and the seed input space is 0 to (expt 2 
31) which is the same as positive signed integers on 32 bit systems 
which is the range of current-exact-milliseconds or however it was called.


But to be able to use true randomness with Racket's random and to avoid 
the capital letter G bias I would have to do the bit fiddling of the