[racket-users] `apply`ing polymorphic functions in typed/racket

2017-01-04 Thread Matthew Eric Bassett 
Hi everyone,

I have a strange example for you.  The following code throws an error in
typed/racket 6.7:

> (define (list1) : (Listof (Setof  Positive-Byte))
(list (set 2) (set 3 2)))
  (apply set-union (list1))
Type Checker: Bad arguments to function in `apply':
Domain: (Setof e) (Setof e) *
Arguments: (Listof (Setof Positive-Byte)) *
in: (apply set-union (list1))

At first I thought "doh! There's a note in the docs about polymorphic
function, just use inst".  But on the other hand,

> (define list0 
(list (set 2) (set 3 2)))
  (apply set-union list0)

Happily compiles and evaluates to the expected result.  For the record,
(inst set-union Positive-Byte) does not help.

What is weirder is that if I open a fresh repl and try:

> (define list0 : (Listof (Setof Positive-Byte)) 
(list (set 2) (set 3 2)))
  (apply set-union list0)

It then throws the same error.

I wasn't able to get the same error with other polymorphic functions as
much as I tried. It turns out this is limited to set-union and
set-subtract.  the type signatures of this functions are:
(-> (Setof e) (Setof e) * (Setof e))

Therein lies our problem.  we need to curry set-union, et al, to get rid
of that leading argument!  But to curry we run into polymorphic type
problems.  so we do:

> (apply (curry (inst set-union Positive-Byte) (ann (set) (Setof 
> Positive-Byte))) (list1))

That's a bit of a mouthful, but racket is as happy as a clam.  Might I
hope for a cleaner way to write this in a later version?
Somewhat related, I have one parting question: Out of the two:

> (define list0 
(list (set 2) (set 3 2)))
  (apply set-union list0)

> (define list2 : (Listof (Setof Positive-Byte)) 
(list (set 2) (set 3 2)))
  (apply set-union list2)

Why does the former work and the latter fail ?

Thanks,

Matthew Eric

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


signature.asc
Description: OpenPGP digital signature

Re: [racket-users] Well typed classes do go wrong

2017-01-04 Thread Asumu Takikawa 
On 2017-01-04 20:23:14 -0500, Leif Andersen wrote:
>If you run it, racket will segfault. Because typed racket thinks that the
>output of `foo` is safe (as it does typecheck), but the `require/typed` is
>incorrect, and apparently doesn't get the correct contract.

The problem is likely that the generated `class/c` contract in this code:

  
https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/static-contracts/combinators/object.rkt#L152

needs to install `inherit-field` contracts in addition to ordinary `field`
contracts. Thanks for the example.

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] Re: hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread WarGrey Gyoudmon Ju 
Hello, is this normal?
I found my released package still does not work.
This is the bug I mentioned above that shown in 6.7(and also in 6.6).

http://pkg-build.racket-lang.org/server/built/fail/digimon.txt

If the distribution is built from source, that bug does not exist.

I am sure it used to be okay 2 weeks ago.
Then I made a pull request for typed/setup/getinfo, and it was merged
within one day.
But the pkg-build.racket-lang.org does not update, so I made my source self
contained again,
Then it fails...


On Wed, Jan 4, 2017 at 11:39 PM, Andrew Kent  wrote:

> At a glance, I believe the bug you're noticing on the snapshot is one we
> also recently observed -- it is fixed in a PR that should be pushed in the
> next couple of days (https://github.com/racket/typed-racket/pull/481).
>
> Sorry for the trouble.
>
> Best,
> Andrew
>
> On Wednesday, January 4, 2017 at 3:51:15 AM UTC-5, WarGrey Gyoudmon Ju
> wrote:
> > I cannot deploy my typed desktop application on Windows.
> >
> >
> > In the download home page, 6.7 does not work, and that bug seemed to be
> solved (I started 6.7 from 6.7.0.3, do not know whether it was okay on
> macOS).
> >
> >
> > The latest snapshot has a new bug shown both on macOS and Windows:
> >
> >
> >
> > in-list: contract violation
> >   expected: list?
> >   given: (hash (Object) #t b #t)
> >   compilation context...:
> > context...:
> >C:\Program Files\Racket-6.7.0.4\collects\racket\private\for.rkt:633:2:
> in-list
> >f184
> >C:\Program 
> > Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:656:4:
> for-loop
> >C:\Program 
> > Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:653:0:
> Union-map
> >f152
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\rep\rep-utils.rkt:191:8: Rep-fmap
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:98:0: subst-tc-result
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:35:0: values->tc-results5
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-funapp.rkt:45:0: tc/funapp
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:329:0: core914
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-if.rkt:13:0: core16
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:326:0: tc-expr
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:79:0: tc-expr/check
> >...
> >
> >
> > Would you please take me to the download page of 6.7.0.3? or one commit
> before this bug? (I don't want to build it from source because real users
> of this application have no knowledge on programming. Also I am working
> remotely, we should have an agile feedback and update process). Thank you.
>
> --
> 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] Well typed classes do go wrong

2017-01-04 Thread Matthias Felleisen 

Funny. I just used an example like this in Snapl ’17 to say “oh well, you will 
get an error from the run-time system eventually and the guy who added types 
gained nothing” . Dang optimizers. 



> On Jan 4, 2017, at 8:23 PM, Leif Andersen  wrote:
> 
> Specifically, if you use a field inside of a require/typed. Consider the 
> following code:
> #lang racket
> 
> (module mod-a racket
>   (provide A%)
>   (define A%
> (class object%
>   (super-new)
>   (field [state 0]
> 
> (module mod-b typed/racket
>   (require/typed (submod ".." mod-a)
>  [A% (Class (field [state (Vectorof String)]))])
>   (define B%
> (class A%
>   (super-new)
>   (inherit-field state)
>   (: foo (-> (Vectorof String)))
>   (define/public (foo)
> state)))
> 
>   (define b (new B%))
>   (vector-ref (send b foo) 0))
> 
> (require 'mod-b)
> If you run it, racket will segfault. Because typed racket thinks that the 
> output of `foo` is safe (as it does typecheck), but the `require/typed` is 
> incorrect, and apparently doesn't get the correct contract.
> 
> You can also see a similar issue in this code:
> #lang racket
> 
> (module mod-a racket
>   (provide A%)
>   (define A%
> (class object%
>   (super-new)
>   (define/public (foo)
> "hello")
>   (define/public (bar)
> ;; TRY REPLACING WITH `(send this foo)`!!!
> (foo)
> 
> (module mod-b typed/racket
>   (require/typed (submod ".." mod-a)
>  [A% (Class [foo (-> Integer)]
> [bar (-> String)])])
>   (define B%
> (class A%
>   (super-new)
>   ;; TRY COMMENTING OUT THIS METHOD!!!
>   (define/override (foo)
> 42)))
> 
>   (define b (new B%))
>   (send b bar))
> 
> 
> (require 'mod-b)
> The code here fails, as expected, because foo returns an integer.
> But, if you comment out the
> 
> (define/override (foo)
>   42)
> 
> It actually works because (foo) now returns a string: `"hello"`.
> 
> This would make sense if the call to `foo` was static, but its dynamic. This 
> can be seen by replacing bar's implementation (in mod-a) with:
> 
> (define/public (bar)
>   (send this foo)
> 
> Then `foo` now throws a contract error because, as expected, it returned a 
> String rather than the Integer require/typed expected.
> 
> In both cases, even though we are using dynamic dispatch, one case gets a 
> contract wrapper and the other doesn't. At best, this seems inconsistent.  
> And at worst, this seems very unsound and can lead to unpredictable behavior 
> (like the segfault above).
> 
> Thoughts?
> 
> Thank you
> 
> ~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 
> .

-- 
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] Well typed classes do go wrong

2017-01-04 Thread Leif Andersen 
Specifically, if you use a field inside of a require/typed. Consider the
following code:

#lang racket

(module mod-a racket
  (provide A%)
  (define A%
(class object%
  (super-new)
  (field [state 0]

(module mod-b typed/racket
  (require/typed (submod ".." mod-a)
 [A% (Class (field [state (Vectorof String)]))])
  (define B%
(class A%
  (super-new)
  (inherit-field state)
  (: foo (-> (Vectorof String)))
  (define/public (foo)
state)))

  (define b (new B%))
  (vector-ref (send b foo) 0))

(require 'mod-b)

If you run it, racket will segfault. Because typed racket thinks that the
output of `foo` is safe (as it does typecheck), but the `require/typed` is
incorrect, and apparently doesn't get the correct contract.

You can also see a similar issue in this code:

#lang racket

(module mod-a racket
  (provide A%)
  (define A%
(class object%
  (super-new)
  (define/public (foo)
"hello")
  (define/public (bar)
;; TRY REPLACING WITH `(send this foo)`!!!
(foo)

(module mod-b typed/racket
  (require/typed (submod ".." mod-a)
 [A% (Class [foo (-> Integer)]
[bar (-> String)])])
  (define B%
(class A%
  (super-new)
  ;; TRY COMMENTING OUT THIS METHOD!!!
  (define/override (foo)
42)))

  (define b (new B%))
  (send b bar))


(require 'mod-b)

The code here fails, as expected, because foo returns an integer.
But, if you comment out the

(define/override (foo)
  42)

It actually works because (foo) now returns a string: `"hello"`.

This would make sense if the call to `foo` was static, but its dynamic.
This can be seen by replacing bar's implementation (in mod-a) with:

(define/public (bar)
  (send this foo)

Then `foo` now throws a contract error because, as expected, it returned a
String rather than the Integer require/typed expected.

In both cases, even though we are using dynamic dispatch, one case gets a
contract wrapper and the other doesn't. At best, this seems inconsistent.
And at worst, this seems very unsound and can lead to unpredictable
behavior (like the segfault above).

Thoughts?

Thank you

~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] list-box% Gtk-WARNING

2017-01-04 Thread Matthew Flatt 
I've pushed a change to avoid this warning.

At Wed, 4 Jan 2017 01:22:41 -0800 (PST), Lehi Toskin wrote:
> I've been encountering Gtk-WARNING's on some simple GUI code and it's not 
> really making any sense to me. Here's the code:
> 
> ;;;
> #lang racket/gui
> 
> (define frame
>   (new frame%
>[label "foo"]
>[width 500]
>[height 500]))
> 
> (define lbox
>   (new list-box%
>[parent frame]
>[label "lbox"]
>[style '(single vertical-label)]
>[choices '(""
>   ""
>   ""
>   "")]))
> 
> (send frame show #t)
> ;;;
> 
> 
> Here's the error:
> 
> (foo.rkt:23484): Gtk-WARNING **: Allocating size to GtkFixed 0x2023270 
> without 
> calling gtk_widget_get_preferred_width/height(). How does the code know the 
> size to allocate?
> 
> 
> Now, a workaround I've found that works is to set lbox's style to include 
> 'deleted and then *after* I show the frame, I tell the frame to add lbox as a 
> child. I think I understand why this is happening, but IMHO the above code 
> should Just Work™.
> 
> -- 
> 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] Narrow radix of string->number.

2017-01-04 Thread Alex Knauth 

> On Jan 4, 2017, at 1:49 PM, Robby Findler  wrote:
> 
> Is changing the alphabet something that can be done post-facto with
> string replacements?

Could there be a more general list-of-digits->number that could work with any 
base?

(list-of-digits->number (list 50 73) 90) ;=> 4573

Then using an arbitrary alphabet could work by replacing numbers within a list 
instead of finding sequences within a string, which sounds much more hacky.

Alex Knauth

> Robby
> 
> On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda  wrote:
>> Some food for thought on this topic, I use base conversion for all sorts of
>> silly things. To this end I require a great deal of flexibility in
>> representation. When I wrote my continued-fractions package I included this
>> as a separate module. Here's an example:
>> 
>> Welcome to DrRacket, version 6.7 [3m].
>> Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
>>> (require continued-fractions/bases)
>> 
>> (define rep (make-representation #:radix #\!
>> #:negate #\+
>> #:terms
>> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
>> 
>> (parameterize ((representation rep)
>>   (digits 10))
>>  (let ((n (/ -125382661425156036913657 101559956668416)))
>>(let ((s (->string n)))
>>  (displayln s)
>>  (let ((n* (->number s)))
>>(= n n*)
>> +KF12OI!4FZZZXRSP
>> #t
>>> 
>> 
>> This may be pointlessly more flexible than a normal user of number->string
>> would want but an arbitrary alphabet is something I'd request people
>> consider for a few moments if changing number->string is open for debate.
>> Maybe it is too much flexibility for racket/base, though, which is where
>> number->string lives.
>> 
>> Deren
>> 
>> On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
>> wrote:
>>> 
>>> I'm still worried about bignums. So I borrowed the idea of Mathew of
>>> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
>>> For each fixnum chunk I calculate the string representation as usual,
>>> but as most of the calculations involve only fixnum, then It's x4
>>> faster for bignums.
>>> 
>>> It's slightly slower for the DrRacket distribution and fixnums and
>>> (5%-10%).
>>> 
>>> The code assumes that a 9 is a fixnum, this is true for 32 and
>>> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
>>> platform, the code is still correct but slower.)
>>> 
>>> DrRacket distribution of numbers
>>> number->string cpu time: 4907 real time: 4898 gc time: 77
>>> number->string* cpu time: 3703 real time: 3701 gc time: 0
>>> number->string** cpu time: 6782 real time: 6777 gc time: 16
>>> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>>> 
>>> Always N=123 (10 times less calls)
>>> number->string cpu time: 859 real time: 846 gc time: 0
>>> number->string* cpu time: 1688 real time: 1676 gc time: 31
>>> number->string** cpu time: 672 real time: 673 gc time: 0
>>> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>>> 
>>> Always N=1234567890123456789012345678901234567890 (10 times less calls)
>>> number->string cpu time: 5625 real time: 5623 gc time: 0
>>> number->string* cpu time: 102125 real time: 102100 gc time: 403
>>> number->string** cpu time: 750 real time: 748 gc time: 15
>>> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>>> 
>>> Gustavo
>>> 
>>> ;Here is ony the code of the new function and benchmarks
>>> ;I'm not happy with the names of the auxiliary functions.
>>> 
>>> (define (number->string***/fixed N short-size trim)
>>>  (define str (make-string short-size #\0))
>>>  (let loop ([N N] [i short-size])
>>>(cond
>>>  [(zero? N)
>>>   (if trim
>>>   (substring str i short-size)
>>>   str)]
>>>  [else
>>>   (define q (quotient N 10))
>>>   (define r (remainder N 10))
>>>   (define d (integer->char (+ r (char->integer #\0
>>>   (string-set! str (- i 1) d)
>>>   (loop q (- i 1))])))
>>> 
>>> (define (number->string***/bignum/list N tail)
>>>  (define-values (q r) (quotient/remainder N (expt 10 9)))
>>>  (cond
>>>[(zero? q)
>>> (cons (number->string***/fixed r 9 #t) tail)]
>>>[else
>>> (number->string***/bignum/list q (cons (number->string***/fixed r
>>> 9 #f) tail))]))
>>> 
>>> (define (number->string*** N)
>>>  (cond
>>>[(fixnum? N)
>>> (cond
>>>   [(< N 10)
>>>(string (integer->char (+ (char->integer #\0) N)))]
>>>   [(< N (expt 10 9))
>>>(number->string***/fixed N 9 #t)]
>>>   [else
>>>(apply string-append (number->string***/bignum/list N '()))])]
>>>[else
>>> (apply string-append (number->string***/bignum/list N '()))]))
>>> 
>>> ;(define-syntax-rule (test-it id ...) ...)
>>> 
>>> (define iterations 5)
>>> 
>>> (define-syntax-rule (time-it id ...)
>>>  (begin
>>>(define numbers (for/list ([i (in-range 1000)])

Re: [racket-users] Narrow radix of string->number.

2017-01-04 Thread Deren Dohoda 
Yes, Robby, if the new base fits within the range allowed by number->string.

On Wed, Jan 4, 2017 at 1:49 PM, Robby Findler 
wrote:

> Is changing the alphabet something that can be done post-facto with
> string replacements?
>
> Robby
>
>
> On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda 
> wrote:
> > Some food for thought on this topic, I use base conversion for all sorts
> of
> > silly things. To this end I require a great deal of flexibility in
> > representation. When I wrote my continued-fractions package I included
> this
> > as a separate module. Here's an example:
> >
> > Welcome to DrRacket, version 6.7 [3m].
> > Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
> >> (require continued-fractions/bases)
> >
> > (define rep (make-representation #:radix #\!
> >  #:negate #\+
> >  #:terms
> > "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
> >
> > (parameterize ((representation rep)
> >(digits 10))
> >   (let ((n (/ -125382661425156036913657 101559956668416)))
> > (let ((s (->string n)))
> >   (displayln s)
> >   (let ((n* (->number s)))
> > (= n n*)
> > +KF12OI!4FZZZXRSP
> > #t
> >>
> >
> > This may be pointlessly more flexible than a normal user of
> number->string
> > would want but an arbitrary alphabet is something I'd request people
> > consider for a few moments if changing number->string is open for debate.
> > Maybe it is too much flexibility for racket/base, though, which is where
> > number->string lives.
> >
> > Deren
> >
> > On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
> > wrote:
> >>
> >> I'm still worried about bignums. So I borrowed the idea of Mathew of
> >> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
> >> For each fixnum chunk I calculate the string representation as usual,
> >> but as most of the calculations involve only fixnum, then It's x4
> >> faster for bignums.
> >>
> >> It's slightly slower for the DrRacket distribution and fixnums and
> >> (5%-10%).
> >>
> >> The code assumes that a 9 is a fixnum, this is true for 32 and
> >> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
> >> platform, the code is still correct but slower.)
> >>
> >> DrRacket distribution of numbers
> >> number->string cpu time: 4907 real time: 4898 gc time: 77
> >> number->string* cpu time: 3703 real time: 3701 gc time: 0
> >> number->string** cpu time: 6782 real time: 6777 gc time: 16
> >> number->string*** cpu time: 3797 real time: 3796 gc time: 16
> >>
> >> Always N=123 (10 times less calls)
> >> number->string cpu time: 859 real time: 846 gc time: 0
> >> number->string* cpu time: 1688 real time: 1676 gc time: 31
> >> number->string** cpu time: 672 real time: 673 gc time: 0
> >> number->string*** cpu time: 1796 real time: 1800 gc time: 0
> >>
> >> Always N=1234567890123456789012345678901234567890 (10 times less calls)
> >> number->string cpu time: 5625 real time: 5623 gc time: 0
> >> number->string* cpu time: 102125 real time: 102100 gc time: 403
> >> number->string** cpu time: 750 real time: 748 gc time: 15
> >> number->string*** cpu time: 26343 real time: 26337 gc time: 95
> >>
> >> Gustavo
> >>
> >> ;Here is ony the code of the new function and benchmarks
> >> ;I'm not happy with the names of the auxiliary functions.
> >>
> >> (define (number->string***/fixed N short-size trim)
> >>   (define str (make-string short-size #\0))
> >>   (let loop ([N N] [i short-size])
> >> (cond
> >>   [(zero? N)
> >>(if trim
> >>(substring str i short-size)
> >>str)]
> >>   [else
> >>(define q (quotient N 10))
> >>(define r (remainder N 10))
> >>(define d (integer->char (+ r (char->integer #\0
> >>(string-set! str (- i 1) d)
> >>(loop q (- i 1))])))
> >>
> >> (define (number->string***/bignum/list N tail)
> >>   (define-values (q r) (quotient/remainder N (expt 10 9)))
> >>   (cond
> >> [(zero? q)
> >>  (cons (number->string***/fixed r 9 #t) tail)]
> >> [else
> >>  (number->string***/bignum/list q (cons (number->string***/fixed r
> >> 9 #f) tail))]))
> >>
> >> (define (number->string*** N)
> >>   (cond
> >> [(fixnum? N)
> >>  (cond
> >>[(< N 10)
> >> (string (integer->char (+ (char->integer #\0) N)))]
> >>[(< N (expt 10 9))
> >> (number->string***/fixed N 9 #t)]
> >>[else
> >> (apply string-append (number->string***/bignum/list N '()))])]
> >> [else
> >>  (apply string-append (number->string***/bignum/list N '()))]))
> >>
> >> ;(define-syntax-rule (test-it id ...) ...)
> >>
> >> (define iterations 5)
> >>
> >> (define-syntax-rule (time-it id ...)
> >>   (begin
> >> (define numbers (for/list ([i (in-range 1000)])
> >>   (sample/drr)))
> >> (begin
> >>

Re: [racket-users] Narrow radix of string->number.

2017-01-04 Thread Robby Findler 
Is changing the alphabet something that can be done post-facto with
string replacements?

Robby


On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda  wrote:
> Some food for thought on this topic, I use base conversion for all sorts of
> silly things. To this end I require a great deal of flexibility in
> representation. When I wrote my continued-fractions package I included this
> as a separate module. Here's an example:
>
> Welcome to DrRacket, version 6.7 [3m].
> Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
>> (require continued-fractions/bases)
>
> (define rep (make-representation #:radix #\!
>  #:negate #\+
>  #:terms
> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
>
> (parameterize ((representation rep)
>(digits 10))
>   (let ((n (/ -125382661425156036913657 101559956668416)))
> (let ((s (->string n)))
>   (displayln s)
>   (let ((n* (->number s)))
> (= n n*)
> +KF12OI!4FZZZXRSP
> #t
>>
>
> This may be pointlessly more flexible than a normal user of number->string
> would want but an arbitrary alphabet is something I'd request people
> consider for a few moments if changing number->string is open for debate.
> Maybe it is too much flexibility for racket/base, though, which is where
> number->string lives.
>
> Deren
>
> On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
> wrote:
>>
>> I'm still worried about bignums. So I borrowed the idea of Mathew of
>> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
>> For each fixnum chunk I calculate the string representation as usual,
>> but as most of the calculations involve only fixnum, then It's x4
>> faster for bignums.
>>
>> It's slightly slower for the DrRacket distribution and fixnums and
>> (5%-10%).
>>
>> The code assumes that a 9 is a fixnum, this is true for 32 and
>> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
>> platform, the code is still correct but slower.)
>>
>> DrRacket distribution of numbers
>> number->string cpu time: 4907 real time: 4898 gc time: 77
>> number->string* cpu time: 3703 real time: 3701 gc time: 0
>> number->string** cpu time: 6782 real time: 6777 gc time: 16
>> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>>
>> Always N=123 (10 times less calls)
>> number->string cpu time: 859 real time: 846 gc time: 0
>> number->string* cpu time: 1688 real time: 1676 gc time: 31
>> number->string** cpu time: 672 real time: 673 gc time: 0
>> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>>
>> Always N=1234567890123456789012345678901234567890 (10 times less calls)
>> number->string cpu time: 5625 real time: 5623 gc time: 0
>> number->string* cpu time: 102125 real time: 102100 gc time: 403
>> number->string** cpu time: 750 real time: 748 gc time: 15
>> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>>
>> Gustavo
>>
>> ;Here is ony the code of the new function and benchmarks
>> ;I'm not happy with the names of the auxiliary functions.
>>
>> (define (number->string***/fixed N short-size trim)
>>   (define str (make-string short-size #\0))
>>   (let loop ([N N] [i short-size])
>> (cond
>>   [(zero? N)
>>(if trim
>>(substring str i short-size)
>>str)]
>>   [else
>>(define q (quotient N 10))
>>(define r (remainder N 10))
>>(define d (integer->char (+ r (char->integer #\0
>>(string-set! str (- i 1) d)
>>(loop q (- i 1))])))
>>
>> (define (number->string***/bignum/list N tail)
>>   (define-values (q r) (quotient/remainder N (expt 10 9)))
>>   (cond
>> [(zero? q)
>>  (cons (number->string***/fixed r 9 #t) tail)]
>> [else
>>  (number->string***/bignum/list q (cons (number->string***/fixed r
>> 9 #f) tail))]))
>>
>> (define (number->string*** N)
>>   (cond
>> [(fixnum? N)
>>  (cond
>>[(< N 10)
>> (string (integer->char (+ (char->integer #\0) N)))]
>>[(< N (expt 10 9))
>> (number->string***/fixed N 9 #t)]
>>[else
>> (apply string-append (number->string***/bignum/list N '()))])]
>> [else
>>  (apply string-append (number->string***/bignum/list N '()))]))
>>
>> ;(define-syntax-rule (test-it id ...) ...)
>>
>> (define iterations 5)
>>
>> (define-syntax-rule (time-it id ...)
>>   (begin
>> (define numbers (for/list ([i (in-range 1000)])
>>   (sample/drr)))
>> (begin
>>   (collect-garbage)
>>   (time
>>(for* ([x (in-range iterations)]
>>   [n (in-list numbers)])
>>  (id n))
>>(printf "~a " 'id))) ...))
>>
>> (time-it number->string number->string* number->string**
>> number->string***)
>>
>> (define-syntax-rule (time-it-N N id ...)
>>   (begin
>> (begin
>>   (collect-garbage)
>>   (time
>>(for* ([x (in-range (* 100 iterations))])
>>

Re: [racket-users] Narrow radix of string->number.

2017-01-04 Thread Deren Dohoda 
Some food for thought on this topic, I use base conversion for all sorts of
silly things. To this end I require a great deal of flexibility in
representation. When I wrote my continued-fractions package I included this
as a separate module. Here's an example:

Welcome to DrRacket, version 6.7 [3m].
Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
> (require continued-fractions/bases)

(define rep (make-representation #:radix #\!
 #:negate #\+
 #:terms
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))

(parameterize ((representation rep)
   (digits 10))
  (let ((n (/ -125382661425156036913657 101559956668416)))
(let ((s (->string n)))
  (displayln s)
  (let ((n* (->number s)))
(= n n*)
+KF12OI!4FZZZXRSP
#t
>

This may be pointlessly more flexible than a normal user of number->string
would want but an arbitrary alphabet is something I'd request people
consider for a few moments if changing number->string is open for debate.
Maybe it is too much flexibility for racket/base, though, which is where
number->string lives.

Deren

On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
wrote:

> I'm still worried about bignums. So I borrowed the idea of Mathew of
> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
> For each fixnum chunk I calculate the string representation as usual,
> but as most of the calculations involve only fixnum, then It's x4
> faster for bignums.
>
> It's slightly slower for the DrRacket distribution and fixnums and
> (5%-10%).
>
> The code assumes that a 9 is a fixnum, this is true for 32 and
> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
> platform, the code is still correct but slower.)
>
> DrRacket distribution of numbers
> number->string cpu time: 4907 real time: 4898 gc time: 77
> number->string* cpu time: 3703 real time: 3701 gc time: 0
> number->string** cpu time: 6782 real time: 6777 gc time: 16
> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>
> Always N=123 (10 times less calls)
> number->string cpu time: 859 real time: 846 gc time: 0
> number->string* cpu time: 1688 real time: 1676 gc time: 31
> number->string** cpu time: 672 real time: 673 gc time: 0
> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>
> Always N=1234567890123456789012345678901234567890 (10 times less calls)
> number->string cpu time: 5625 real time: 5623 gc time: 0
> number->string* cpu time: 102125 real time: 102100 gc time: 403
> number->string** cpu time: 750 real time: 748 gc time: 15
> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>
> Gustavo
>
> ;Here is ony the code of the new function and benchmarks
> ;I'm not happy with the names of the auxiliary functions.
>
> (define (number->string***/fixed N short-size trim)
>   (define str (make-string short-size #\0))
>   (let loop ([N N] [i short-size])
> (cond
>   [(zero? N)
>(if trim
>(substring str i short-size)
>str)]
>   [else
>(define q (quotient N 10))
>(define r (remainder N 10))
>(define d (integer->char (+ r (char->integer #\0
>(string-set! str (- i 1) d)
>(loop q (- i 1))])))
>
> (define (number->string***/bignum/list N tail)
>   (define-values (q r) (quotient/remainder N (expt 10 9)))
>   (cond
> [(zero? q)
>  (cons (number->string***/fixed r 9 #t) tail)]
> [else
>  (number->string***/bignum/list q (cons (number->string***/fixed r
> 9 #f) tail))]))
>
> (define (number->string*** N)
>   (cond
> [(fixnum? N)
>  (cond
>[(< N 10)
> (string (integer->char (+ (char->integer #\0) N)))]
>[(< N (expt 10 9))
> (number->string***/fixed N 9 #t)]
>[else
> (apply string-append (number->string***/bignum/list N '()))])]
> [else
>  (apply string-append (number->string***/bignum/list N '()))]))
>
> ;(define-syntax-rule (test-it id ...) ...)
>
> (define iterations 5)
>
> (define-syntax-rule (time-it id ...)
>   (begin
> (define numbers (for/list ([i (in-range 1000)])
>   (sample/drr)))
> (begin
>   (collect-garbage)
>   (time
>(for* ([x (in-range iterations)]
>   [n (in-list numbers)])
>  (id n))
>(printf "~a " 'id))) ...))
>
> (time-it number->string number->string* number->string** number->string***)
>
> (define-syntax-rule (time-it-N N id ...)
>   (begin
> (begin
>   (collect-garbage)
>   (time
>(for* ([x (in-range (* 100 iterations))])
>  (id N))
>(printf "~a " 'id))) ...))
>
> (time-it-N 123 number->string number->string* number->string**
> number->string***)
> (time-it-N 1234567890123456789012345678901234567890 number->string
> number->string* number->string** number->string***)
> ;---
>
>
> On Sun, Jan 1, 2017 at 8:01 PM, Robby Findler
>

Re: [racket-users] Re: hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread WarGrey Gyoudmon Ju 
Oh, thank you Andrew, you are making a great improvements.
Couple of days are not too long to wait.

On Wed, Jan 4, 2017 at 11:39 PM, Andrew Kent  wrote:

> At a glance, I believe the bug you're noticing on the snapshot is one we
> also recently observed -- it is fixed in a PR that should be pushed in the
> next couple of days (https://github.com/racket/typed-racket/pull/481).
>
> Sorry for the trouble.
>
> Best,
> Andrew
>
> On Wednesday, January 4, 2017 at 3:51:15 AM UTC-5, WarGrey Gyoudmon Ju
> wrote:
> > I cannot deploy my typed desktop application on Windows.
> >
> >
> > In the download home page, 6.7 does not work, and that bug seemed to be
> solved (I started 6.7 from 6.7.0.3, do not know whether it was okay on
> macOS).
> >
> >
> > The latest snapshot has a new bug shown both on macOS and Windows:
> >
> >
> >
> > in-list: contract violation
> >   expected: list?
> >   given: (hash (Object) #t b #t)
> >   compilation context...:
> > context...:
> >C:\Program Files\Racket-6.7.0.4\collects\racket\private\for.rkt:633:2:
> in-list
> >f184
> >C:\Program 
> > Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:656:4:
> for-loop
> >C:\Program 
> > Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:653:0:
> Union-map
> >f152
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\rep\rep-utils.rkt:191:8: Rep-fmap
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:98:0: subst-tc-result
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:35:0: values->tc-results5
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-funapp.rkt:45:0: tc/funapp
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:329:0: core914
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-if.rkt:13:0: core16
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:326:0: tc-expr
> >temp101
> >C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:79:0: tc-expr/check
> >...
> >
> >
> > Would you please take me to the download page of 6.7.0.3? or one commit
> before this bug? (I don't want to build it from source because real users
> of this application have no knowledge on programming. Also I am working
> remotely, we should have an agile feedback and update process). Thank you.
>
> --
> 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] Narrow radix of string->number.

2017-01-04 Thread Gustavo Massaccesi 
I'm still worried about bignums. So I borrowed the idea of Mathew of
splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
For each fixnum chunk I calculate the string representation as usual,
but as most of the calculations involve only fixnum, then It's x4
faster for bignums.

It's slightly slower for the DrRacket distribution and fixnums and (5%-10%).

The code assumes that a 9 is a fixnum, this is true for 32 and
64 bit's racket. (In case Racket is ported in the future to a 16 bits
platform, the code is still correct but slower.)

DrRacket distribution of numbers
number->string cpu time: 4907 real time: 4898 gc time: 77
number->string* cpu time: 3703 real time: 3701 gc time: 0
number->string** cpu time: 6782 real time: 6777 gc time: 16
number->string*** cpu time: 3797 real time: 3796 gc time: 16

Always N=123 (10 times less calls)
number->string cpu time: 859 real time: 846 gc time: 0
number->string* cpu time: 1688 real time: 1676 gc time: 31
number->string** cpu time: 672 real time: 673 gc time: 0
number->string*** cpu time: 1796 real time: 1800 gc time: 0

Always N=1234567890123456789012345678901234567890 (10 times less calls)
number->string cpu time: 5625 real time: 5623 gc time: 0
number->string* cpu time: 102125 real time: 102100 gc time: 403
number->string** cpu time: 750 real time: 748 gc time: 15
number->string*** cpu time: 26343 real time: 26337 gc time: 95

Gustavo

;Here is ony the code of the new function and benchmarks
;I'm not happy with the names of the auxiliary functions.

(define (number->string***/fixed N short-size trim)
  (define str (make-string short-size #\0))
  (let loop ([N N] [i short-size])
(cond
  [(zero? N)
   (if trim
   (substring str i short-size)
   str)]
  [else
   (define q (quotient N 10))
   (define r (remainder N 10))
   (define d (integer->char (+ r (char->integer #\0
   (string-set! str (- i 1) d)
   (loop q (- i 1))])))

(define (number->string***/bignum/list N tail)
  (define-values (q r) (quotient/remainder N (expt 10 9)))
  (cond
[(zero? q)
 (cons (number->string***/fixed r 9 #t) tail)]
[else
 (number->string***/bignum/list q (cons (number->string***/fixed r
9 #f) tail))]))

(define (number->string*** N)
  (cond
[(fixnum? N)
 (cond
   [(< N 10)
(string (integer->char (+ (char->integer #\0) N)))]
   [(< N (expt 10 9))
(number->string***/fixed N 9 #t)]
   [else
(apply string-append (number->string***/bignum/list N '()))])]
[else
 (apply string-append (number->string***/bignum/list N '()))]))

;(define-syntax-rule (test-it id ...) ...)

(define iterations 5)

(define-syntax-rule (time-it id ...)
  (begin
(define numbers (for/list ([i (in-range 1000)])
  (sample/drr)))
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range iterations)]
  [n (in-list numbers)])
 (id n))
   (printf "~a " 'id))) ...))

(time-it number->string number->string* number->string** number->string***)

(define-syntax-rule (time-it-N N id ...)
  (begin
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range (* 100 iterations))])
 (id N))
   (printf "~a " 'id))) ...))

(time-it-N 123 number->string number->string* number->string**
number->string***)
(time-it-N 1234567890123456789012345678901234567890 number->string
number->string* number->string** number->string***)
;---


On Sun, Jan 1, 2017 at 8:01 PM, Robby Findler
 wrote:
> I'm skeptical of an unbounded cache.
>
> If we go by the sample from DrRacket's start up, then we don't really
> need a cache to do better than the built-in number->string. Below is
> some code that takes the version I had earlier with what I understood
> to be Gustavo's suggestions and then just does better on the fixnums
> between 0 and 9. I then changed the random inputs to sample from the
> distribution that DrRacket demonstrated and you won't be surprised to
> learn that this does better than having a cache. Below is the code.
>
> I also tried to collect the arguments to number->string during
> rebuilding all of the .zo files. Of the first 2.3 million calls about
> 99.5% of them were exact integers between 0 and 9 so probably this is
> the only optimization we need to do. (My sampling method turned out to
> be noisy, tho, but I don't think it affects the results.)
>
> ... unless someone comes up with some other benchmark or app we care about?
>
> Robby
>
> #lang racket
> (require (for-syntax syntax/parse))
>
> (define-syntax (mk-sample stx)
>   (syntax-parse stx
> [(_ (value:exact-nonnegative-integer
> occurrences:exact-nonnegative-integer) ...)
>  (define-values (cond-clauses count)
>(for/fold ([other-cases '()]
>   [so-far 0])
>  ([value (in-list (syntax->list #'(value ...)))]
>   [occurrences (in-list (syntax->list

[racket-users] Re: hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread Andrew Kent 
At a glance, I believe the bug you're noticing on the snapshot is one we also 
recently observed -- it is fixed in a PR that should be pushed in the next 
couple of days (https://github.com/racket/typed-racket/pull/481).

Sorry for the trouble.

Best,
Andrew

On Wednesday, January 4, 2017 at 3:51:15 AM UTC-5, WarGrey Gyoudmon Ju wrote:
> I cannot deploy my typed desktop application on Windows.
> 
> 
> In the download home page, 6.7 does not work, and that bug seemed to be 
> solved (I started 6.7 from 6.7.0.3, do not know whether it was okay on macOS).
> 
> 
> The latest snapshot has a new bug shown both on macOS and Windows:
> 
> 
> 
> in-list: contract violation
>   expected: list?
>   given: (hash (Object) #t b #t)
>   compilation context...:
> context...:
>    C:\Program Files\Racket-6.7.0.4\collects\racket\private\for.rkt:633:2: 
> in-list
>    f184
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:656:4:
>  for-loop
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:653:0:
>  Union-map
>    f152
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\rep-utils.rkt:191:8:
>  Rep-fmap
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-subst.rkt:98:0:
>  subst-tc-result
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-subst.rkt:35:0:
>  values->tc-results5
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-funapp.rkt:45:0:
>  tc/funapp
>    temp101
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:329:0:
>  core914
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-if.rkt:13:0:
>  core16
>    temp101
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:326:0:
>  tc-expr
>    temp101
>    C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:79:0:
>  tc-expr/check
>    ...
> 
> 
> Would you please take me to the download page of 6.7.0.3? or one commit 
> before this bug? (I don't want to build it from source because real users of 
> this application have no knowledge on programming. Also I am working 
> remotely, we should have an agile feedback and update process). Thank you.

-- 
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] hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread WarGrey Gyoudmon Ju 
Hi, Stephen, I've already tried 12.28 and no luck. And at this time, that
link is dead. So, all snapshots are temporary testers.

hi Dupéron, For me on my computer I always build it from source, but I
never trace the date and commit.
Actually this is one of the major reason I gave up Haskell, Racket can be
built in OpenIndiana without painful.
And, the same, I do not use Windows at all.

On Wed, Jan 4, 2017 at 6:09 PM, Dupéron Georges  wrote:

> I don't think the old "minor" versions are kept, only the last few as
> Stephen pointed out.
>
> As can be checked in the git log for https://github.com/racket/
> racket/blame/master/pkgs/base/info.rkt, the version number was bumped
> away from 6.7.0.3 in commit d7b18e7, so you could try checking out the
> previous commit (5e94a90) and compiling that. Racket isn't very difficult
> to compile under Linux, never tried on Windows, so good luck :) !
>
> PS: Don't forget to report that new bug if you haven't already, sometimes
> they are fixed within hours.

-- 
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] hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread Dupéron Georges 
I don't think the old "minor" versions are kept, only the last few as Stephen 
pointed out.

As can be checked in the git log for 
https://github.com/racket/racket/blame/master/pkgs/base/info.rkt, the version 
number was bumped away from 6.7.0.3 in commit d7b18e7, so you could try 
checking out the previous commit (5e94a90) and compiling that. Racket isn't 
very difficult to compile under Linux, never tried on Windows, so good luck :) !

PS: Don't forget to report that new bug if you haven't already, sometimes they 
are fixed within hours.

-- 
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] hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread Stephen De Gabrielle 
there is an 'other available snapshots' at the bottom of the snapshots
screen

e.g.

https://www.cs.utah.edu/plt/snapshots/20161228-f039a4c/index.html

they have dates but I don't know what snapshot version numbers they
correspond to.
HTH

Stephen




On Wed, Jan 4, 2017 at 8:51 AM, WarGrey Gyoudmon Ju 
wrote:

> I cannot deploy my typed desktop application on Windows.
>
> In the download home page, 6.7 does not work, and that bug seemed to be
> solved (I started 6.7 from 6.7.0.3, do not know whether it was okay on
> macOS).
>
> The latest snapshot has a new bug shown both on macOS and Windows:
>
> in-list: contract violation
>   expected: list?
>   given: (hash (Object) #t b #t)
>   compilation context...:
> context...:
>C:\Program Files\Racket-6.7.0.4\collects\racket\private\for.rkt:633:2:
> in-list
>f184
>C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:656:4:
> for-loop
>C:\Program 
> Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:653:0:
> Union-map
>f152
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\rep\rep-utils.rkt:191:8: Rep-fmap
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:98:0: subst-tc-result
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-subst.rkt:35:0: values->tc-results5
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-funapp.rkt:45:0: tc/funapp
>temp101
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:329:0: core914
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-if.rkt:13:0: core16
>temp101
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:326:0: tc-expr
>temp101
>C:\Program Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-
> racket\typecheck\tc-expr-unit.rkt:79:0: tc-expr/check
>...
>
> Would you please take me to the download page of 6.7.0.3? or one commit
> before this bug? (I don't want to build it from source because real users
> of this application have no knowledge on programming. Also I am working
> remotely, we should have an agile feedback and update process). Thank you.
>
> --
> 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] list-box% Gtk-WARNING

2017-01-04 Thread Lehi Toskin 
I've been encountering Gtk-WARNING's on some simple GUI code and it's not 
really making any sense to me. Here's the code:

;;;
#lang racket/gui

(define frame
  (new frame%
   [label "foo"]
   [width 500]
   [height 500]))

(define lbox
  (new list-box%
   [parent frame]
   [label "lbox"]
   [style '(single vertical-label)]
   [choices '(""
  ""
  ""
  "")]))

(send frame show #t)
;;;


Here's the error:

(foo.rkt:23484): Gtk-WARNING **: Allocating size to GtkFixed 0x2023270 without 
calling gtk_widget_get_preferred_width/height(). How does the code know the 
size to allocate?


Now, a workaround I've found that works is to set lbox's style to include 
'deleted and then *after* I show the frame, I tell the frame to add lbox as a 
child. I think I understand why this is happening, but IMHO the above code 
should Just Work™.

-- 
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] hello, where can I find the distribution 6.7.0.3.

2017-01-04 Thread WarGrey Gyoudmon Ju 
I cannot deploy my typed desktop application on Windows.

In the download home page, 6.7 does not work, and that bug seemed to be
solved (I started 6.7 from 6.7.0.3, do not know whether it was okay on
macOS).

The latest snapshot has a new bug shown both on macOS and Windows:

in-list: contract violation
  expected: list?
  given: (hash (Object) #t b #t)
  compilation context...:
context...:
   C:\Program Files\Racket-6.7.0.4\collects\racket\private\for.rkt:633:2:
in-list
   f184
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:656:4:
for-loop
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\type-rep.rkt:653:0:
Union-map
   f152
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\rep\rep-utils.rkt:191:8:
Rep-fmap
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-subst.rkt:98:0:
subst-tc-result
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-subst.rkt:35:0:
values->tc-results5
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-funapp.rkt:45:0:
tc/funapp
   temp101
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:329:0:
core914
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-if.rkt:13:0:
core16
   temp101
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:326:0:
tc-expr
   temp101
   C:\Program
Files\Racket-6.7.0.4\share\pkgs\typed-racket-lib\typed-racket\typecheck\tc-expr-unit.rkt:79:0:
tc-expr/check
   ...

Would you please take me to the download page of 6.7.0.3? or one commit
before this bug? (I don't want to build it from source because real users
of this application have no knowledge on programming. Also I am working
remotely, we should have an agile feedback and update process). Thank you.

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