[racket-users] Re: Building full racket 6.10 and up fails on Nix/MacOS

[Claes Wallin]

On Friday, February 23, 2018 at 11:57:55 AM UTC+8, Claes Wallin wrote:
>
> On Friday, February 23, 2018 at 11:55:17 AM UTC+8, Claes Wallin wrote:
>>
>> I'm currently testing whether 6.9 still builds and if it doesn't, I'll 
>> git bisect through nixpkgs to see what broke it. So let's hope it breaks. 
>> :-)
>>
>
> Nope, 6.9 worked. So it's not as simple as something I can pin down to a 
> nixpkgs commit.
>
> > raco setup: 0 making: /racket-doc/scribblings/reference
>

Correction: The above line was no indicator, it did break finally! On to 
git-bisect nixpkgs.

-- 
   /c 

-- 
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: Building full racket 6.10 and up fails on Nix/MacOS

[Claes Wallin]

On Friday, February 23, 2018 at 11:55:17 AM UTC+8, Claes Wallin wrote:
>
> I'm currently testing whether 6.9 still builds and if it doesn't, I'll git 
> bisect through nixpkgs to see what broke it. So let's hope it breaks. :-)
>

Nope, 6.9 worked. So it's not as simple as something I can pin down to a 
nixpkgs commit.

> raco setup: 0 making: /racket-doc/scribblings/reference

-- 
   /c

-- 
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] Building full racket 6.10 and up fails on Nix/MacOS

[Claes Wallin]

I have got racket-minimal 6.12 into Nix, and it builds properly on 
aarch64-linux and on x86_64-darwin (MacOS). AArch64 probably hasn't had a 
racket before (I haven't checked), and Nix/MacOS has been without a working 
racket since it was bumped to 6.10 last August (which broke it because 6.10 
needed some previously unnecessary MacOS frameworks and nobody fixed that).

However, I can't get the full racket to build, because I'm getting errors 
when it's parsing a scribble file:

raco setup: --- summary of errors ---
raco setup: error: during building docs for 
/racket-doc/scribblings/reference/reference.scrbl
raco setup:   examples: exception raised in example
raco setup: error: "bytes-convert: contract violation\n  expected: 
bytes-converter?\n  given: #f\n  argument position: 1st\n  other 
arguments...:\n   #\"ABCD\""


I haven't checked whether this file is special or if it's simply the first 
file in line to break things.

Any idea what might be causing this? The lack of a stack trace makes this 
feel like a tricky thing to track down without prior knowledge of the code 
base. The racket community has obviously been able to build native DrRacket 
for MacOS (the Nix build is --enable-xonx), so we know it's possible as far 
as racket is concerned.

I'm currently testing whether 6.9 still builds and if it doesn't, I'll git 
bisect through nixpkgs to see what broke it. So let's hope it breaks. :-)

For more discussion and details, see 
https://github.com/NixOS/nixpkgs/issues/34576 .

-- 
   /c

-- 
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] #lang rust

[Claes Wallin]

On Wednesday, February 21, 2018 at 11:20:23 PM UTC+8, stewart mackenzie 
wrote:
>
> On Wed, 21 Feb 2018, 14:44 Hendrik Boom,  > wrote:
>
>> The interesting parrt would the integrating of Rust's garbage
>> collector (yes, it has a concept of garbage collection for data declared
>> to need it) with Racket's.
>>
>
> I understand you'd need the Custom Allocator which is (currently) only 
> available on rust nightly which is a relatively fast moving target. 
>
>>
Unless you use Racket with the conservative gc and let it figure things out?

-- 
   /c 

-- 
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: Non-blocking place get

[Robby Findler]

I've pushed some edits to that guide section (and noted place channels
as evt?s). Hopefully those code examples there are useful to someone!

Robby

On Thu, Feb 22, 2018 at 5:11 PM, Philip McGrath
 wrote:
> I've found the paper "Kill-Safe Synchronization Abstractions"
> (https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf) useful for getting
> a sense of how to work with events and sync. (Note that a few things have
> slightly different names than in the paper, like "thread" instead of
> "spawn".)
>
> More extensive coverage in the guide would be great, though! (For the
> record, there is "Synchronizable Events and sync":
> http://docs.racket-lang.org/guide/concurrency.html#(part._.Synchronizable_.Events_and_sync))
> Unfortunately, I don't feel like nearly enough of an expert to write such a
> chapter.
>
> -Philip
>
> On Thu, Feb 22, 2018 at 4:55 PM, Zelphir Kaltstahl
>  wrote:
>>
>> (Lets try this answering to a topic via e-mail thing. Here goes …)
>>
>> With a lot of help from people in the Racket user group the following
>> was recently created: https://github.com/ZelphirKaltstahl/work-distributor
>> Maybe its code can also be helpful to 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.

-- 
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: Non-blocking place get

[Philip McGrath]

I've found the paper "Kill-Safe Synchronization Abstractions" (
https://www.cs.utah.edu/plt/publications/pldi04-ff.pdf) useful for getting
a sense of how to work with events and sync. (Note that a few things have
slightly different names than in the paper, like "thread" instead of
"spawn".)

More extensive coverage in the guide would be great, though! (For the
record, there is "Synchronizable Events and sync":
http://docs.racket-lang.org/guide/concurrency.html#(part._.Synchronizable_.Events_and_sync))
Unfortunately, I don't feel like nearly enough of an expert to write such a
chapter.

-Philip

On Thu, Feb 22, 2018 at 4:55 PM, Zelphir Kaltstahl <
zelphirkaltst...@gmail.com> wrote:

> (Lets try this answering to a topic via e-mail thing. Here goes …)
>
> With a lot of help from people in the Racket user group the following
> was recently created: https://github.com/ZelphirKaltstahl/work-distributor
> Maybe its code can also be helpful to 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] Re: Non-blocking place get

[Zelphir Kaltstahl]

(Lets try this answering to a topic via e-mail thing. Here goes …)

With a lot of help from people in the Racket user group the following
was recently created: https://github.com/ZelphirKaltstahl/work-distributor
Maybe its code can also be helpful to 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.

[racket-users] Fwd: Us congress hearing of maan alsaan Money laundry قضية الكونغجرس لغسيل الأموال للمليادير معن الصانع

[كاجو محمص]

*موقع اليوتيوب الذي عرض فيديوهات جلسة استماع الكونجرس الأمريكي *

* لمتابعة نشاطات غسل الأموال ونشاطات*



*السعودي معن عبدالواحد الصانع*

*مالك مستشفى  وشركة سعد  ومدارس سعد بالمنطقة الشرقية** بالسعودية * * ورئيس
مجلس ادارة بنك اوال البحريني*



 *وتعليق محطة سي ان بي سي التلفزيونية*



*مترجم باللغة العربية*



US Congressional Hearing of

 Saudi billionaire" maan  Al Sanea "

 and Money Laundering

with bank of America



With Arabic Subtitles





http://www.youtube.com/watch?v=mIBNnQvhU8s

-- 
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 (7) on a new arch

[Alexander McLin]

As one of those who have been following RISC-V progress for several years 
and also interested in seeing Racket being ported to that architecture I 
want to drop a note to let you know you have my support!

-- 
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] Non-blocking place get

[Robby Findler]

These are great points! Thank you.

Robby

On Thu, Feb 22, 2018 at 1:59 AM 'Paulo Matos' via Racket Users <
racket-users@googlegroups.com> wrote:

>
>
> On 22/02/18 01:02, Robby Findler wrote:
> > You can create a thread and wait simultaneously on the place channel
> > value and also on some channel that the various workers use to check
> > in and see if a value is available. Here's a very simple instantiation
> > of this idea.
> >
>
> Thanks. That looks like it could work with my current architecture.
>
> > More generally, I think that one of the underappreciated parts of
> > Racket's built in features are `evt`s.  Do check out what they can do.
> > You can do much more sophisticated protocols that are tailored to
> > exactly what you need.
> >
>
> Just finished reading the reference manual on evt's. A feature I had not
> used before. Looks great.
>
> While doing so I noticed two things:
> 1. There's no guide chapter on evts with guide-like explanations and
> examples; although the ref is not bad either;
> 2. It doesn't say place channels were evts. Actually when I looked at
> your example I thought you missed the fact I was talking about place
> channels and not normal channels. Also because the reference mentions:
>
> "Racket values that act as synchronizable events include semaphores,
> channels, asynchronous channels, ports, TCP listeners, log receivers,
> threads, subprocesses, will executors, and custodian boxes. Libraries
> can define new synchronizable events, especially though prop:evt."
>
> There's no mention of place channels. I was happy to find out that your
> example would work with place channels as well because:
>
> > (define-values (p1 p2) (place-channel))
> > (evt? p1)
> #t
>
> Thanks,
>
> --
> 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.
>

-- 
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: Is it possible to get the size of a panel%

[Robby Findler]

If you need the size before it is shown, you can use reflow-container.

Robby

On Thu, Feb 22, 2018 at 6:22 AM David Alkire  wrote:

> Thanks. It was the tricky bit that tricked me. I was trying to get the
> size of the panel before it was painted. I guess I should default to the
> mins and update afterward based on the available calculated size.
>
> --
> 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: Is it possible to get the size of a panel%

[David Alkire]

Thanks. It was the tricky bit that tricked me. I was trying to get the size of 
the panel before it was painted. I guess I should default to the mins and 
update afterward based on the available calculated size.

-- 
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: Typing lag with DrRacket on Linux

[evdubs]

My apologies for the continued spam, but it feels like I am close to having 
buttery-smooth text editing in DrRacket on large resolution windows. I just 
need some help :)

When I set the interactions-canvas% and definitions-canvas% in unit.rkt to 
have the 'transparent style (after hacking the background handling to not 
throw an exception when 'transparent is set while backgrounds are being 
set), I can get smooth text entry in DrRacket until it starts getting 
really buggy due to my hack (like when inserting an end-parenthesis or when 
resizing the window). So, it seems like what is desired here is something 
like 'transparent in editor-canvas% that isn't forcing flushes or refreshes 
while respecting the background setting. It looks like canvas% provides 
'no-autoclear, but editor-canvas% does not. I am not sure where to start to 
see if implementing that in editor-canvas% makes sense. Also, I tried to 
set lazy-refresh for the interactions-canvas% and definitions-canvas% but 
this does not seem to have the same performance impact as 'transparent.

Anyway, if someone still happens to be following along with this and has 
any ideas for what to do here, please let me know.

Evan

On Wednesday, February 21, 2018 at 10:42:22 AM UTC-10, evdubs wrote:
>
> I played around with is a bit more and noticed that setting 
> editor-canvas%'s style to (list 'transparent) greatly increases the 
> performance of the simple editor to where it performs just like any other 
> text editor. However, I tried applying this to DrRacket in 
> drracket/drracket/private/app.rkt and this did not seem to make much of a 
> difference. Anyway, I think the key to improving performance here is still 
> the removal of the call to gdk_window_process_all_updates. The "improved" 
> editor looks like:
>
> #lang racket
>
> (require racket/gui)
> (define frame (new frame% [label "Simple Edit"]
>[width 1800]
>[height 1800]))
> (define canvas (new editor-canvas% [parent frame]
>   [style (list 'transparent)]))
> (define text (new text%))
> (send canvas set-editor text)
> (send frame show #t)
>
>
>
> Evan
>
> On Sunday, February 11, 2018 at 11:41:53 AM UTC-10, evdubs wrote:
>>
>> I created PR 95  to remove the 
>> call to gdk_window_process_all_updates. I am still unsure if there are 
>> legacy or compatibility reasons for having this call.
>>
>> Evan
>>
>> On Saturday, February 10, 2018 at 12:39:58 PM UTC-10, evdubs wrote:
>>>
>>> I made the following change to window.rkt 
>>> 's
>>>  
>>> flush-display
>>>
>>> (define (flush-display)
>>>   (try-to-sync-refresh)
>>>   ;; (gdk_window_process_all_updates)
>>>   (gdk_display_flush (gdk_display_get_default)))
>>>
>>>
>>> I made this change after finding the following note for the 
>>> gdk_window_process_all_updates 
>>> documentation 
>>> 
>>>
>>> gdk_window_process_all_updates has been deprecated since version 3.22 
 and should not be used in newly-written code.
>>>
>>>
>>> Things run much better now in DrRacket (and in the little editor 
>>> example), but still the performance isn't great.
>>>
>>> I would create a pull request with the removal of 
>>> gdk_window_process_all_updates but I don't know if there are other 
>>> Racket instances out there relying on older GTK versions that need this 
>>> call. Is there a way to check for that?
>>>
>>> Evan
>>>
>>> On Saturday, February 10, 2018 at 11:08:16 AM UTC-10, evdubs wrote:

 I had to add a sampler to that code so what I really had was this:

 #lang racket/gui

 (require profile)
 (require profile/analyzer)
 (require profile/render-text)
 (require profile/sampler)

 (define s (create-sampler (current-thread) 0.0))

 (s 'get-snapshots)

 (define ec%
   (class editor-canvas%
 (define/override (on-paint)
   (profile (super on-paint) #:threads #t #:order 'self))
 (define/override (on-char e)
   (profile (super on-char e) #:threads #t #:order 'self))
 (super-new)))
 (define frame (new frame% [label "Simple Edit"]
[width 1800]
[height 1800]))

 (define canvas (new ec% [parent frame]))
 (define text (new text%))
 (send canvas set-editor text)
 (send frame show #t)

 Then, I could use the following in the interactions window to get 
 results after typing in some text to the text editor.

 (render (analyze-samples (s 'get-snapshots)))

 Here are my results for the rows that had significant values for "self"


 
 Caller
 

Re: [racket-users] Non-blocking place get

['Paulo Matos' via Racket Users]

On 22/02/18 01:02, Robby Findler wrote:
> You can create a thread and wait simultaneously on the place channel
> value and also on some channel that the various workers use to check
> in and see if a value is available. Here's a very simple instantiation
> of this idea.
> 

Thanks. That looks like it could work with my current architecture.

> More generally, I think that one of the underappreciated parts of
> Racket's built in features are `evt`s.  Do check out what they can do.
> You can do much more sophisticated protocols that are tailored to
> exactly what you need.
> 

Just finished reading the reference manual on evt's. A feature I had not
used before. Looks great.

While doing so I noticed two things:
1. There's no guide chapter on evts with guide-like explanations and
examples; although the ref is not bad either;
2. It doesn't say place channels were evts. Actually when I looked at
your example I thought you missed the fact I was talking about place
channels and not normal channels. Also because the reference mentions:

"Racket values that act as synchronizable events include semaphores,
channels, asynchronous channels, ports, TCP listeners, log receivers,
threads, subprocesses, will executors, and custodian boxes. Libraries
can define new synchronizable events, especially though prop:evt."

There's no mention of place channels. I was happy to find out that your
example would work with place channels as well because:

> (define-values (p1 p2) (place-channel))
> (evt? p1)
#t

Thanks,

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