[racket-users] Criação dinâmica de perguntas

[dev . videira]

Boa noite, 

Necessito criar radio-boxs dinâmico, estou usando um for e um contador para 
realizar a criação de cada um dos radio-box. desta maneira:

(define que (string-append "questao_solve" (number->string count)))
(print que)
(set! que (new radio-box%
   (label "")
   (parent panel)
   (choices (list (list-ref lista_questao 2)
  (list-ref lista_questao 3)
  (list-ref lista_questao 4)
  (list-ref lista_questao 5)
  (list-ref lista_questao 6)

Está criando corretamente porem quando vou recuperar os dados dos radio-box 
*questao_solve1 
*por exemplo da o seguinte erro : 

send: target is not an object
  target: "questao_solve1"
  method name: get-value

Pelo que entendi do erro, a minha criação se por strings e não por um 
objeto. Não sei oq fazer.

Obrigado

-- 
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-Chez snapshots

[Gustavo Massaccesi]

I think that is is possible to add an unofficial CS target to
travis-racket (https://github.com/greghendershott/travis-racket) using
something similar to https://github.com/racket/racket/pull/2266 . For
now it will be slow because it will have to install a normal Racket,
ChezScheme and recompile everything. But in the future it may use the
racket-cs installer.

Gustavo


Gustavo


On Mon, Oct 1, 2018 at 12:31 PM Matthew Flatt  wrote:
>
> That's a good idea. It won't happen this week, but maybe it can happen
> in November or so.
>
> At Mon, 1 Oct 2018 10:21:46 -0500, Philip McGrath wrote:
> > Would it be feasible and useful to start building Racket-on-Chez snapshots
> > along with the other variants at https://pre.racket-lang.org? In light of
> > the promising outlook for Chez replacing the current Racket VM in the
> > relatively near future, I would be interested in starting to include it in
> > my CI tests. (I wish I 'd thought of this question yesterday.)
> >
> > If so, my vote would be for the executables in a Racket-on-Chez snapshot to
> > be named `racket ...` rather than `racketcs ...` to minimize special-casing
> > in scripts
> >
> > -Philip
> >
> > --
> > 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] Using DrRacket for MIT Scheme

[Neil Van Dyke]

Yasser Hussain wrote on 10/1/18 5:31 AM:
Unfortunately, I don't remember which DrRacket version, and which 
exact `#lang` line I was using. But I specifically remember that 
"load" worked with some earlier version of racket.


Hi, Yasser.  The reason I asked those questions offline was that, after 
checking my original SICP PLaneT package with Racket 6.12, I was no 
longer assuming that `load` ever worked with the SICP support, and 
perhaps `load` wasn't necessary for the current SICP support.  I wanted 
a rapid path to determining whether a regression happened, and where, 
and you potentially had the best information for doing that quickly and 
easily.  Then we could report back to the much broader Racket email list 
with the resolution.




Problem with using `require` is that I'll have to use "#lang racket" 
with it, which will prevent me from using standard scheme procedures 
like `set-cdr!`, etc.


The SICP support is only intended to be a convenience for using the very 
important SICP textbook, to try maximize SICP's accessibility to 
contemporary students (who might not be able to run MIT Scheme, for 
whatever reason).  Please let me try to address your goals...


If you really just want to use classics like `set-cdr!` in the Racket 
universe or just with Racket tools, you might like to try Racket's 
`#lang r5rs`.


If you want the tons of benefits of evolved Racket, but also want 
mutable pairs right now, you can have that with Racket (though, be aware 
that a mutable pair isn't a subtype of pair in Racket, so all 
pair/list-related code must be aware of this).  There aren't many other 
non-backward-compatible differences in Racket, and the change to 
mutability of pairs is the only painful one I recall, in ~18 years of 
contributing to Racket,


A third possibility that I'd like to suggest is to consider trying to 
write idiomatic Racket, as an exercise.  If, for example, Racket 
discourages mutable pairs, try to write your code without that, and see 
where it pushes you (e.g., more towards functional programming, or 
strengthening your code in some ways), and then decide what you think 
about that.  (Personally, I only had mutable pairs pain with the very 
earliest Scheme code I wrote; in later code, I was already usually 
treating pairs as immutable, and minimizing mutation in general.)


BTW, since you said "standard", I very much appreciate sentiments in 
favor of standards.  Incidentally, I'm not part of the benevolent cabal; 
just a bottom-tier contributor. :)  In this niche of innovative language 
platforms, I suspect that Racket overall would be consistent with your 
ultimate goals, even if it's in some ways not "standard" -- it's much 
more than any standard, and somewhat different.  (Personally, if you're 
thinking of it as a Scheme implementation, despite all their efforts to 
be clear that it's not Scheme... I've probably used most of the Schemes 
and descendants, and it's nice to know that I can always use other 
Scheme implementation/descendants.  Probably my favorite one other than 
Racket is Gambit by Marc Feeley.  I'm also fond of some of the others, 
each with their own strengths, and they also remain in my pocket for 
possibly using later.  I also like that I can make my own Racket `#lang` 
dialect at any time, in such a way that I maintain good interoperation 
with, and contribution to, the rest of the Racket world.)


Is it possible for me to take a look at the source code and try to 
figure out why "load" doesn't work, and possible try to get it to 
work? Could you provide some pointers? :)


Yes.  Ways include:

1. To familiarize with the Racket package catalog, if you go to that 
package catalog URL I gave, there's a "Code" button that, in this case, 
goes to a GitHub repo, where you can do go normal Git and GitHub things.


2. Racket packages themselves actually usually include the source for 
all of code+test+documentation.  (There's an even more lightweight 
source-centric thing I want to do, but haven't done yet.)  I'm not sure 
what's the best starting point for your needs, but here's two:

https://docs.racket-lang.org/pkg/cmdline.html
https://docs.racket-lang.org/pkg/git-workflow.html

--
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: editor-snip clickback not working in DrRacket interaction window

[Philippe M]

Some follow-up to my previous message (which, I guess, everyone was waiting 
for given the seemingly large interest :)

I tried using quickscript to get access to the interaction window and add 
the snip from there and it works.
I feel that this might confirm my hypothesis regarding not being in the 
right event space but I could use some help here.

The quickscript script I used:
#lang racket/gui
(require quickscript/script)

(define (show-dialog)
  (define f (new dialog% [label "Dialog"] [style '(close-button)]))
  (define m (new message% [label "Clicked"] [parent f]))
  (send f show #t))

(define (make-snip)
  (define t (new text%))
  (send t insert "Click Me!")
  (send t set-clickback
0 (send t last-position)
(lambda (t s e)
  (show-dialog)))
  (define s (new editor-snip% [editor t]))
  s)

(define-script inspector
  #:label "inspector"
  (λ (selection #:interactions i)
(send i insert (make-snip))
#f))

Regards
Philippe


On Thursday, September 27, 2018 at 9:02:29 PM UTC+2, Philippe M wrote:
>
> Hi,
>
> It seems that clickbacks are not working when a snip is displayed in 
> DrRacket interaction window.
>
> Here is a sample program:
> #lang racket/gui
>
> (define (show-dialog)
>   (define f (new dialog% [label "Dialog"] [style '(close-button)]))
>   (define m (new message% [label "Clicked"] [parent f]))
>   (send f show #t))
>
> (define f (new frame% [label "Test"] [width 300] [height 200]))
> (define e (new text%))
> (define c (new editor-canvas% [parent f] [editor e]))
> (send f show #t)
>
> (define t (new text%))
> (send t insert "Click Me!")
> (send t set-clickback
>   0 (send t last-position)
>   (lambda (t s e)
> (show-dialog)))
> (define s (new editor-snip% [editor t]))
>
>
> (send e insert s)
>
>
> If you click on the Click Me text you will get the dialog displayed.
> If I enter 's' (without the quotes) in DrRacket interaction window, I can 
> see my snip displayed but clicking on it does nothing.
>
> I looked at DrRacket code but did not find anything that makes me think it 
> should not work except, maybe, for the fact that the snip is sent using the 
> text:send-snip-to-port function which serializes the snip to the proper 
> event space using text:make-snip-special.
>
> Could someone enlighten me on why it is not working as I expect and how I 
> could make this works ?
>
> Thanks for your help
> Philippe
>
>
>
>

-- 
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-Chez snapshots

[Shu-Hung You]

Here! http://www.cs.utah.edu/~mflatt/racket-on-chez-jan-2018/
Also a few days algo there were some more updates at RacketCon and
Scheme Workshop.
On Mon, Oct 1, 2018 at 1:08 PM Brett Gilio  wrote:
>
>
> Philip McGrath writes:
> > In light of
> > the promising outlook for Chez replacing the current Racket VM
> > in the
>
> > -Philip
>
>
> Hey, could you provide a resource with more information on Chez
> possibly
> replacing the Racket VM? I haven't been keeping up to date on
> this.
>
> --
> Brett M. Gilio
> Free Software Foundation, Member
> https://gnu.org/software/guix | https://emacs.org
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [racket-users] Racket-on-Chez snapshots

[Tom Gillespie]

If by lately you mean any time in 2018 there is Matthew's report from back
in January.
https://blog.racket-lang.org/2018/01/racket-on-chez-status.html
http://www.cs.utah.edu/~mflatt/racket-on-chez-jan-2018/
If you are feeling adventurous you can also build it from source
https://github.com/racket/racket/blob/master/Makefile#L245.

On Mon, Oct 1, 2018 at 11:07 AM, Brett Gilio  wrote:

>
> Philip McGrath writes:
>
>> In light of
>> the promising outlook for Chez replacing the current Racket VM in the
>>
>
> -Philip
>>
>
>
> Hey, could you provide a resource with more information on Chez possibly
> replacing the Racket VM? I haven't been keeping up to date on this.
>
> --
> Brett M. Gilio
> Free Software Foundation, Member
> https://gnu.org/software/guix | https://emacs.org
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [racket-users] Re: Surprising slow-down of near tail-call: Potential missed optimization?

[Matthew Flatt]

I'll answer anyway, because the `begin0` difference is subtle.

At the level of `let`, the Racket optimzier goes out of its way to not
convert your second program to the first. Continuation marks make a
change from non-tail call to tail call observable, and in this case,
the compiler won't be able to prove that there are no continuation-mark
observations that could be affected by the conversion.

For `begin0`, we have defined the first subexpression of `begin0` to be
in tail position with respect to the `begin0` form if it's the only
subexpression. That choice accommodates exactly this kind of case,
although it's a little ad hoc.

At Mon, 1 Oct 2018 11:37:29 -0700 (PDT), Phil Nguyen wrote:
> Actually nvm. Whoever wrote such macro could have just used `begin0` 
> instead.
> 
> On Monday, October 1, 2018 at 2:34:23 PM UTC-4, Phil Nguyen wrote:
> >
> > (Racket 7.0) This program runs in no time:
> >
> > (define (sum n acc)
> >   (if (> n 0)
> >   (sum (- n 1) (+ acc n))
> >   acc))
> >
> > (collect-garbage) (collect-garbage) (collect-garbage)
> > (time (sum 1000 0))
> > ; cpu time: 47 real time: 57 gc time: 0
> > ; 500500
> >
> > This slightly modified program runs significantly slower:
> >
> > (define (sum n acc)
> >   (if (> n 0)
> >   (let ([ans (sum (- n 1) (+ acc n))])
> > ans)
> >   acc))
> >
> > (collect-garbage) (collect-garbage) (collect-garbage)
> > (time (sum 1000 0))
> > ; cpu time: 1719 real time: 1872 gc time: 1064
> > ; 500500
> >
> > While the call to `sum` in the second program is not in tail position, I 
> > wonder if this kind of code happens often enough from macro expansion to 
> > benefit from an optimization.
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[racket-users] Re: Surprising slow-down of near tail-call: Potential missed optimization?

[Phil Nguyen]

Actually nvm. Whoever wrote such macro could have just used `begin0` 
instead.

On Monday, October 1, 2018 at 2:34:23 PM UTC-4, Phil Nguyen wrote:
>
> (Racket 7.0) This program runs in no time:
>
> (define (sum n acc)
>   (if (> n 0)
>   (sum (- n 1) (+ acc n))
>   acc))
>
> (collect-garbage) (collect-garbage) (collect-garbage)
> (time (sum 1000 0))
> ; cpu time: 47 real time: 57 gc time: 0
> ; 500500
>
> This slightly modified program runs significantly slower:
>
> (define (sum n acc)
>   (if (> n 0)
>   (let ([ans (sum (- n 1) (+ acc n))])
> ans)
>   acc))
>
> (collect-garbage) (collect-garbage) (collect-garbage)
> (time (sum 1000 0))
> ; cpu time: 1719 real time: 1872 gc time: 1064
> ; 500500
>
> While the call to `sum` in the second program is not in tail position, I 
> wonder if this kind of code happens often enough from macro expansion to 
> benefit from an optimization.
>

-- 
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] Surprising slow-down of near tail-call: Potential missed optimization?

[Phil Nguyen]

(Racket 7.0) This program runs in no time:

(define (sum n acc)
  (if (> n 0)
  (sum (- n 1) (+ acc n))
  acc))

(collect-garbage) (collect-garbage) (collect-garbage)
(time (sum 1000 0))
; cpu time: 47 real time: 57 gc time: 0
; 500500

This slightly modified program runs significantly slower:

(define (sum n acc)
  (if (> n 0)
  (let ([ans (sum (- n 1) (+ acc n))])
ans)
  acc))

(collect-garbage) (collect-garbage) (collect-garbage)
(time (sum 1000 0))
; cpu time: 1719 real time: 1872 gc time: 1064
; 500500

While the call to `sum` in the second program is not in tail position, I 
wonder if this kind of code happens often enough from macro expansion to 
benefit from an optimization.

-- 
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-Chez snapshots

[Brett Gilio]

Philip McGrath writes:

In light of
the promising outlook for Chez replacing the current Racket VM 
in the



-Philip



Hey, could you provide a resource with more information on Chez 
possibly
replacing the Racket VM? I haven't been keeping up to date on 
this.


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/software/guix | https://emacs.org

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

Re: [racket-users] Racket-on-Chez snapshots

[Matthew Flatt]

That's a good idea. It won't happen this week, but maybe it can happen
in November or so.

At Mon, 1 Oct 2018 10:21:46 -0500, Philip McGrath wrote:
> Would it be feasible and useful to start building Racket-on-Chez snapshots
> along with the other variants at https://pre.racket-lang.org? In light of
> the promising outlook for Chez replacing the current Racket VM in the
> relatively near future, I would be interested in starting to include it in
> my CI tests. (I wish I 'd thought of this question yesterday.)
> 
> If so, my vote would be for the executables in a Racket-on-Chez snapshot to
> be named `racket ...` rather than `racketcs ...` to minimize special-casing
> in scripts
> 
> -Philip
> 
> -- 
> 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] Racket-on-Chez snapshots

[Philip McGrath]

Would it be feasible and useful to start building Racket-on-Chez snapshots
along with the other variants at https://pre.racket-lang.org? In light of
the promising outlook for Chez replacing the current Racket VM in the
relatively near future, I would be interested in starting to include it in
my CI tests. (I wish I 'd thought of this question yesterday.)

If so, my vote would be for the executables in a Racket-on-Chez snapshot to
be named `racket ...` rather than `racketcs ...` to minimize special-casing
in scripts

-Philip

-- 
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 DrRacket for MIT Scheme

[Yasser Hussain]

Unfortunately, I don't remember which DrRacket version, and which exact 
`#lang` line I was using. But I specifically remember that "load" worked 
with some earlier version of racket.

Problem with using `require` is that I'll have to use "#lang racket" with 
it, which will prevent me from using standard scheme procedures like 
`set-cdr!`, etc.
Is it possible for me to take a look at the source code and try to figure 
out why "load" doesn't work, and possible try to get it to work? Could you 
provide some pointers? :)

On Monday, October 1, 2018 at 12:53:26 AM UTC+5:30, Neil Van Dyke wrote:
>
> That's probably my fault. 
>
> First, be sure you're using the `sicp` package from current Racket 
> package system, "https://pkgs.racket-lang.org/package/sicp";, not my 
> older PLaneT one. 
>
> Then, Jens Axel Soegaard is still set up in GitHub, and he can add 
> `load` there, once he gets a chance.  But if he can't do it in time for 
> your needs, let me know, and I'll make a temporary replacement 
> "sicp/main.rkt" that you can apply to your installation of the package. 
>
> (Background: I made the original semi-polished SICP DrScheme support 
> package in PLaneT, which used the work of Mike Sperber and Jens Axel for 
> the hard parts.  While I was moving my packages from PLaneT to the 
> current package system, Jens Axel was in a much better position to lead 
> the SICP support, so we consolidated the projects, and I contributed 
> only a new, simpler `#lang`, rather than dump a lot of bitrotted and 
> no-longer-applicable stuff on the project.  Probably I neglected to add 
> `load` to this `#lang`, while I was slammed from triaging and moving way 
> too many less-important packages.  If so, I deserve any "You had ONE 
> job..." memes. :) 
>
>

-- 
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] Playing the Game with PLT Redex · Second Edition

['Paulo Matos' via Racket Users]

Leandro, obrigado por esta excelente contribuição.

Thank you for this excellent contribution. It's really good. I am
reading it a bit at a time and I really enjoy it, not only how you write
it but the subject as well.

Racket needs more of this.

Paulo Matos

On 30/09/2018 18:34, 'Leandro Facchinetti' via Racket Users wrote:
> Hi Racketeers,
> 
> I while ago I wrote a short article in which I used PLT Redex to play a
> game of Peg Solitaire. I now present you the extended version of that
> article:
> 
> https://www.leafac.com/prose/playing-the-game-with-plt-redex/
> 
> The short and to-the-point version still exists in the form of an
> introduction: 
> https://www.leafac.com/prose/playing-the-game-with-plt-redex/introduction
> 
> But now I also dive into a few PLT Redex forms in more detail. I
> consider this to be a better bridge between knowing little about
> programming-language theory and being able to follow more advanced
> material, for example, the excellent SEwPR.
> 
> I welcome feedback.
> 
> Thank you for your time.
> 
> -- 
> Leandro Facchinetti mailto:m...@leafac.com>>
> https://www.leafac.com
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Paulo Matos

-- 
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] Places code not using all the CPU

['Paulo Matos' via Racket Users]

I attach yet another example where this behaviour is much more
noticiable. This is on a 64 core dedicated machine in amazon aws.

-- 
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] Places code not using all the CPU

['Paulo Matos' via Racket Users]

Hi,

I am not sure this is an issue with places or what it could be but my
devops-fu is poor and I am not even sure how to debug something like
this so maybe someone with more knowledge than me on this might chime in
to hint on a possible debug method.

I was running some benchmarks and noticed something odd for the first
time (although it doesn't mean it was ok before, just that this is the
first time I am actually analysing this issue).

My program (the master) will create N places (the workers) and each
place will start by issuing a rosette call which will trigger a call to
the z3 smt solver. So, N instances of Z3 will run and after it is done
it will run pure racket code that implements a graph search algorithm.
This N worker places are actually in a sync call waiting for messages
from the master and the work is being done by a thread on the worker
place. The master is either waiting for the timeout to arrive or for a
solution to be sent from a worker.

The interesting thing is that when the Z3 instances are running I get
all my 16 CPUs (on a dedicated machine) working at 100%. When the racket
code is running the search, they are all holding off at around 60%-80%
with a huge portion of it in the kernel (red bars in htop).

Since the Z3 calls come before the threads inside the places are started
and we get to the sync call, is it possible something bad is happening
in the sync call that uses the kernel so much? Take a look at htop
during Z3 and during the search - screenshots attached.

Are there any suggestions on what the problem might be or how I could
start to understand why the kernel is so active?

Kind regards,


-- 
Paulo Matos

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