Re: [racket-users] Ubuntu PPA also updated to v7.9

2020-11-09 Thread evdubs
$ ls ~/.racket
6.11  6.12  7.0  7.1  7.2  7.3  7.4  7.5  7.6  7.7  7.8  7.9  
download-cache  racket-prefs.rktd  snapshot

The above looks like the location where my user packages are installed (as 
in, the packages from raco pkg install).

$ ls ~/.config/racket
ls: cannot access '/home/evdubs/.config/racket': No such file or directory

Evan
On Monday, November 9, 2020 at 4:14:28 PM UTC-10 Matthew Flatt wrote:

> At Mon, 9 Nov 2020 18:08:51 -0800 (PST), evdubs wrote:
> > So I ran:
> > $ raco pkg config --set catalogs https://pkgs.racket-lang.org 
> > and now I am able to migrate packages. Thank you, Matthew. Maybe this is 
> > related to my installation being from the PPA.
>
> Maybe, but I wonder whether it might have something to do with the
> switch to XDG paths. Do you have "~/.racket" and/or "~/.config/racket"
> directories?
>
>
> Matthew
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/293c82e6-38ae-43d8-aa3e-df79d046bfefn%40googlegroups.com.


Re: [racket-users] Ubuntu PPA also updated to v7.9

2020-11-09 Thread evdubs
$ raco pkg config
name:
  7.9
catalogs:
  https://download.racket-lang.org/releases/7.9/catalog/
default-scope:
  user
download-cache-dir:
  /home/evdubs/.racket/download-cache
download-cache-max-files:
  1024
download-cache-max-bytes:
  67108864
git-checkout-credentials:
trash-max-packages:
  512
trash-max-seconds:
  172800
network-retries:
  5

So I ran:
$ raco pkg config --set catalogs https://pkgs.racket-lang.org 
and now I am able to migrate packages. Thank you, Matthew. Maybe this is 
related to my installation being from the PPA.

Evan

On Monday, November 9, 2020 at 3:57:05 PM UTC-10 Matthew Flatt wrote:

> What does `raco pkg config` say? The resolution search doesn't seem to
> be trying
>
> https://pkgs.racket-lang.org
>
> which is where those packages would be found.
>
> At Mon, 9 Nov 2020 17:43:22 -0800 (PST), evdubs wrote:
> > Sorry, I should have just included the full error the first time. I get:
> > 
> > $ raco pkg migrate 7.8
> > Packages to install:
> > binaryio
> > feature-profile
> > gregor
> > html-parsing
> > interactive-brokers-api
> > sxml
> > tasks
> > threading
> > webscraperhelper
> > 00: Resolving "binaryio" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 01: Resolving "feature-profile" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 02: Resolving "gregor" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 03: Resolving "html-parsing" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 05: Resolving "sxml" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 06: Resolving "tasks" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 04: Resolving "interactive-brokers-api" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > 07: Resolving "threading" via 
> > https://download.racket-lang.org/releases/7.9/catalog/
> > raco pkg migrate: cannot find package on catalogs
> > package: threading
> > raco pkg migrate: cannot find package on catalogs
> > package: html-parsing
> > raco pkg migrate: cannot find package on catalogs
> > package: interactive-brokers-api
> > raco pkg migrate: cannot find package on catalogs
> > package: sxml
> > raco pkg migrate: cannot find package on catalogs
> > package: tasks
> > raco pkg migrate: cannot find package on catalogs
> > package: gregor
> > raco pkg migrate: cannot find package on catalogs
> > package: binaryio
> > raco pkg migrate: cannot find package on catalogs
> > package: binaryio
> > 
> > Evan
> > On Monday, November 9, 2020 at 3:32:04 PM UTC-10 Matthew Flatt wrote:
> > 
> > > At Mon, 9 Nov 2020 16:28:32 -0800 (PST), evdubs wrote:
> > > > Looking at https://download.racket-lang.org/releases/7.9/catalog/, 
> an 
> > > > uncaught exception is being thrown. This error is being returned by 
> > > other 
> > > > versions, too (7.8 and 7.7 at least).
> > >
> > > When that URL is used as a catalog by `raco pkg`, it doesn't look for
> > > HTML files or "index.html" --- and there's currently no "index.html"
> > > installed at that path, so that's why you get an address when using the
> > > address directly in a browser.
> > >
> > > But that catalog works for me. For example,
> > >
> > > raco pkg catalog-show \
> > > --catalog https://download.racket-lang.org/releases/7.9/catalog/ \
> > > racket-lib
> > >
> > > shows information for "racket-lib", and
> > >
> > > raco pkg catalog-copy \
> > > https://download.racket-lang.org/releases/7.9/catalog/ \
> > > pkgs-copy/
> > >
> > > creates a local catalog listing many packages.
> > >
> > >
> > > What package couldn't be migrated?
> > >
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/racket-users/a84f5372-8d83-4186-b998-5f9dd7e2
> > 5e86n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/55cfeece-82d4-4586-8e21-8197900b7923n%40googlegroups.com.


Re: [racket-users] Ubuntu PPA also updated to v7.9

2020-11-09 Thread evdubs
Sorry, I should have just included the full error the first time. I get:

$ raco pkg migrate 7.8
Packages to install:
  binaryio
  feature-profile
  gregor
  html-parsing
  interactive-brokers-api
  sxml
  tasks
  threading
  webscraperhelper
00: Resolving "binaryio" via 
https://download.racket-lang.org/releases/7.9/catalog/
01: Resolving "feature-profile" via 
https://download.racket-lang.org/releases/7.9/catalog/
02: Resolving "gregor" via 
https://download.racket-lang.org/releases/7.9/catalog/
03: Resolving "html-parsing" via 
https://download.racket-lang.org/releases/7.9/catalog/
05: Resolving "sxml" via 
https://download.racket-lang.org/releases/7.9/catalog/
06: Resolving "tasks" via 
https://download.racket-lang.org/releases/7.9/catalog/
04: Resolving "interactive-brokers-api" via 
https://download.racket-lang.org/releases/7.9/catalog/
07: Resolving "threading" via 
https://download.racket-lang.org/releases/7.9/catalog/
raco pkg migrate: cannot find package on catalogs
  package: threading
raco pkg migrate: cannot find package on catalogs
  package: html-parsing
raco pkg migrate: cannot find package on catalogs
  package: interactive-brokers-api
raco pkg migrate: cannot find package on catalogs
  package: sxml
raco pkg migrate: cannot find package on catalogs
  package: tasks
raco pkg migrate: cannot find package on catalogs
  package: gregor
raco pkg migrate: cannot find package on catalogs
  package: binaryio
raco pkg migrate: cannot find package on catalogs
  package: binaryio

Evan
On Monday, November 9, 2020 at 3:32:04 PM UTC-10 Matthew Flatt wrote:

> At Mon, 9 Nov 2020 16:28:32 -0800 (PST), evdubs wrote:
> > Looking at https://download.racket-lang.org/releases/7.9/catalog/, an 
> > uncaught exception is being thrown. This error is being returned by 
> other 
> > versions, too (7.8 and 7.7 at least).
>
> When that URL is used as a catalog by `raco pkg`, it doesn't look for
> HTML files or "index.html" --- and there's currently no "index.html"
> installed at that path, so that's why you get an address when using the
> address directly in a browser.
>
> But that catalog works for me. For example,
>
> raco pkg catalog-show \
> --catalog https://download.racket-lang.org/releases/7.9/catalog/ \
> racket-lib
>
> shows information for "racket-lib", and
>
> raco pkg catalog-copy \
> https://download.racket-lang.org/releases/7.9/catalog/ \
> pkgs-copy/
>
> creates a local catalog listing many packages.
>
>
> What package couldn't be migrated?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a84f5372-8d83-4186-b998-5f9dd7e25e86n%40googlegroups.com.


Re: [racket-users] Ubuntu PPA also updated to v7.9

2020-11-09 Thread evdubs
I just upgraded my Racket installation to 7.9. I tried to run raco pkg 
migrate 7.8

I got the following error:

raco pkg migrate: cannot find package on catalogs

Looking at https://download.racket-lang.org/releases/7.9/catalog/, an 
uncaught exception is being thrown. This error is being returned by other 
versions, too (7.8 and 7.7 at least).

Another user in IRC has confirmed this behavior.

Evan
On Monday, November 9, 2020 at 9:37:58 AM UTC-10 Stephen De Gabrielle wrote:

> Thanks Asumu
>
> I've posted on r/racket - there are a lot of linux users there so I'm sure 
> this is much appreciated.
>
> Kind regards
>
> Stephen
>
>
> On Mon, Nov 9, 2020 at 6:35 PM Asumu Takikawa  
> wrote:
>
>> On 2020-11-02 19:10:33 -0500, 'John Clements' via Racket Users wrote:
>> > Racket version 7.9 is now available from
>> > 
>> > https://racket-lang.org/
>>
>> The Ubuntu PPA is now updated for version 7.9 as well, and available on
>> current Ubuntu versions (see https://wiki.ubuntu.com/Releases):
>>
>>   https://launchpad.net/~plt/+archive/ubuntu/racket
>>
>> As usual please report any issues on github:
>>
>>   https://github.com/takikawa/racket-ppa
>>
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/20201109183545.t5gc34k7guhdvxvc%40nixos
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/1e0283d2-bca4-44e5-803e-ea17c007fdbbn%40googlegroups.com.


Re: [racket-users] in-directory sorted results

2020-08-06 Thread evdubs
I created a PR <https://github.com/racket/racket/pull/3343> for a possible 
fix for this. I am unsure if the (directory-list) implementation in 
kw-file.rkt needs to be calling sort.

Evan

On Monday, August 3, 2020 at 3:05:55 AM UTC-10 evdubs wrote:

> Sorry, I cherry-picked the doc example as an "easy" example that others 
> might be able to easily observe.
>
> However, please imagine the following filesystem:
>
> /var/tmp/test/1.txt
> /var/tmp/test/2.txt
> /var/tmp/test/3.txt
> /var/tmp/test/4.txt
>
> The following shows these files in order:
>
> > (for/list ([f (in-directory "/var/tmp/test")]) (displayln f))
>
> However, the following does not have the same order:
>
> > (current-directory "/var/tmp/test")
> > (for/list ([f (in-directory)]) (displayln f))
>
> Does this help? What is interesting to me is that in-directory can call 
> directory-list (which seems to call sort) or dir-list, which also calls 
> sort and directory-list.
>
> Perhaps I just need to wait for your fix.
>
> Evan
> On Monday, August 3, 2020 at 2:28:33 AM UTC-10 Matthew Flatt wrote:
>
>> At Sun, 2 Aug 2020 18:38:18 -0700 (PDT), evdubs wrote: 
>> > However, the docs also show: 
>> > 
>> > > (current-directory (collection-path "info")) 
>> > > (for/list ([f (in-directory)]) 
>> > f) 
>> > '(# 
>> > # 
>> > # 
>> > #) 
>> > 
>> > Isn't this not getting sorted correctly? I am seeing that calls to 
>> > (in-directory) do not have sorted results, but calls to (in-directory 
>> > "path") do have sorted results. 
>>
>> You're right that the documentation's example is incorrect, and I'll 
>> fix that. 
>>
>> Most examples in the documentation are rendered by running them, so the 
>> results can't get out-of-sync like this. Since the `in-directory` 
>> example involves the filesystem, though, the example result is written 
>> out in the documentation source, and it wasn't updated when the sorting 
>> guarantee was added to `in-directory`. 
>>
>> Matthew 
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b28550c2-e4b5-4d4c-afe3-350d605e2409n%40googlegroups.com.


Re: [racket-users] in-directory sorted results

2020-08-03 Thread evdubs
Sorry, I cherry-picked the doc example as an "easy" example that others 
might be able to easily observe.

However, please imagine the following filesystem:

/var/tmp/test/1.txt
/var/tmp/test/2.txt
/var/tmp/test/3.txt
/var/tmp/test/4.txt

The following shows these files in order:

> (for/list ([f (in-directory "/var/tmp/test")]) (displayln f))

However, the following does not have the same order:

> (current-directory "/var/tmp/test")
> (for/list ([f (in-directory)]) (displayln f))

Does this help? What is interesting to me is that in-directory can call 
directory-list (which seems to call sort) or dir-list, which also calls sort 
and directory-list.

Perhaps I just need to wait for your fix.

Evan
On Monday, August 3, 2020 at 2:28:33 AM UTC-10 Matthew Flatt wrote:

> At Sun, 2 Aug 2020 18:38:18 -0700 (PDT), evdubs wrote:
> > However, the docs also show:
> > 
> > > (current-directory (collection-path "info"))
> > > (for/list ([f (in-directory)])
> > f)
> > '(#
> > #
> > #
> > #)
> > 
> > Isn't this not getting sorted correctly? I am seeing that calls to 
> > (in-directory) do not have sorted results, but calls to (in-directory 
> > "path") do have sorted results.
>
> You're right that the documentation's example is incorrect, and I'll
> fix that.
>
> Most examples in the documentation are rendered by running them, so the
> results can't get out-of-sync like this. Since the `in-directory`
> example involves the filesystem, though, the example result is written
> out in the documentation source, and it wasn't updated when the sorting
> guarantee was added to `in-directory`.
>
> Matthew
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b6b9bf5e-6ea9-46c1-b486-d57b33f80f0bn%40googlegroups.com.


[racket-users] in-directory sorted results

2020-08-02 Thread evdubs
Hello,

The docs for in-directory 

 
state:

> The immediate content of each directory is reported as sorted by path (current-directory (collection-path "info"))
> (for/list ([f (in-directory)])
 f)
'(#
  #
  #
  #)

Isn't this not getting sorted correctly? I am seeing that calls to 
(in-directory) do not have sorted results, but calls to (in-directory 
"path") do have sorted results.

Evan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ce5d4e2e-9954-4ec5-a343-072a822383d5n%40googlegroups.com.


[racket-users] Re: Best data structure for ordered data set with insertion and reordering?

2020-07-16 Thread evdubs
Do you think you'll need to try to identify the order that the events were 
created in?

What if user A does:

$ touch file.txt
$ rm file.txt

And what if user A had separately done:

$ rm file.txt
Error: file not found
$ touch file.txt

Would those operations both potentially create File-Create P H1 ; 
File-Delete P H1 events when things are allowed to be out of order? Don't 
they result in different states for the filesystem? If you also sent along 
the time of the operation (or maybe some sequence number), won't that let 
you keep things ordered and not make decisions that might be ambiguous?
On Wednesday, July 15, 2020 at 10:29:36 PM UTC-10 david@gmail.com wrote:

> tl;dr
> Can anyone recommend a data structure that is ordered and supports 
> efficient reordering, insertion at arbitrary location, and deletion?
>
> Long form:
>
> I'm working on an operation-log reconciliation problem, where each 
> operation is one of:
>
>   File-CreateP H
>   File-Update   P H
>   File-DeleteP H
>   Folder-Create P
>   Folder-Delete P
>
> P = path
> H = hash of the file (e.g. md5)
>
> Operation messages travel over the network, meaning that they could arrive 
> out of order.  (They could also be missed entirely, but that's a separate 
> problem that I'm not working on yet.)
>
> Specifically, I want to be able to take a series of messages and collapse 
> them where appropriate.  For example:
>
>   File-Update P H1 -> H2
>   File-Create P1 H1
> Result after collapse:  
>   '(File-Create P1 H2)
>
>   File-Create P H1
>   File-Delete P H1
> Result after collapse:
>   '()
>
>   File-Delete P X
>   File-Create P X
> Result after collapse:
>   '()
>   
>   File-Delete P1 H1
>   File-Create P2 H2
>   File-Create P1 H1
> Result after collapse:
>   '(File-Create P2 H2)
>
> I've been mulling over various ways to handle all of this and digging 
> around to find examples of other people doing it, but I'm wondering if 
> there's a data structure or existing algorithm that will handle it 
> cleanly.  Does anyone know of such a thing?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f03b33d8-e286-4cc2-afa5-4aefd0050bd5n%40googlegroups.com.


Re: [racket-users] Re: Typing lag with DrRacket on Linux

2020-05-28 Thread evdubs
I suppose that may be helpful, but this performance issue extends to any 
other Racket GUI application on Linux, including the simple editor example 
from earlier in this thread. Maybe printing something to a console could 
help, but it would be better if there was some fix to improve fractional 
scaling performance :)

Evan

On Thursday, May 28, 2020 at 2:37:49 AM UTC-10, Jens Axel Søgaard wrote:
>
> Slack users confirm the problem when the backing scale is 1.5.
>
> Should DrRacket give a warning dialog on Linux, when started with a 
> non-integer backing scale?
>
> /Jens Axel
>
>
> Den ons. 13. maj 2020 kl. 05.48 skrev evdubs  >:
>
>> I did some more digging and found locations in racket/draw that control 
>> antialiasing. I tried changing them around, and saw no impact on 
>> performance.
>>
>> However, I eventually stumbled upon the environment variable 
>> PLT_DISPLAY_BACKING_SCALE. By using an integer value for this variable, 
>> performance is nice and smooth (I tried 1 and 2; trying 1.25 and 1.5 hurt 
>> performance). In Ubuntu, I do not have my display set to a fractional 
>> scaling value, but I do have "Large Text" enabled. I am unsure if this 
>> setting interferes with whatever PLT_DISPLAY_BACKING_SCALE defaults to.
>>
>> If you're having typing lag issues on Linux within Dr Racket or other 
>> Racket GUI applications, you may want to try PLT_DISPLAY_BACKING_SCALE=1 to 
>> see if that affects performance.
>>
>> Evan
>>
>> On Monday, May 11, 2020 at 2:05:06 PM UTC-10, evdubs wrote:
>>>
>>> I think what I have seen previously with setting the canvas style to 
>>> 'transparent ultimately is turning off antialiasing in Cairo.
>>>
>>> Using the sample text editor from this thread, I ran the following:
>>>
>>> $ cairo-trace racket text-editor.rkt
>>> $ cairo-trace racket text-editor-transparent.rkt
>>>
>>> In the non-transparent version, we see these two lines:
>>>
>>> 16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /antialias 
>>> //ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style 
>>> //HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf0 
>>> exch def
>>> f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /antialias 
>>> //ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style 
>>> //HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf1 
>>> exch def
>>>
>>> These lines look like this in the transparent version:
>>>
>>> 16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics 
>>> //HINT_METRICS_ON >> scaled-font /sf0 exch def
>>> f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics 
>>> //HINT_METRICS_ON >> scaled-font /sf1 exch def
>>>
>>> I am not really sure how this initialization is happening. Can someone 
>>> help me poke through the code to see how I might disable antialiasing? 
>>> Should I try to make changes to gui-lib/mred/private/wx/gtk/gcwin.rkt?
>>>
>>> Evan
>>>
>>> On Friday, March 29, 2019 at 12:29:11 AM UTC-10, Bryan Lee wrote:
>>>>
>>>> I’m facing the same issues, and I came across an interesting 
>>>> observation. 
>>>>
>>>> It seems that DrRacket mimics scrolling behaviour by literally 
>>>> replacing each line of code with the line above or below, and uses a 
>>>> really 
>>>> inefficient method of tracking which lines should go where, thereby 
>>>> limiting how fast you can “scroll”. 
>>>>
>>>> I realised that resizing the window horizontally does nothing to 
>>>> improve performance, but shrinking the window height significantly 
>>>> improved 
>>>> performance, even if the canvas area is adjusted to remain the same. 
>>>>
>>>> In addition to some function definitions in unit.rkt describing the 
>>>> transposing of lines, that leads me to my conclusion. 
>>>>
>>>> Thoughts? 
>>>>
>>>>
>>>>
>>>> On Friday, 2 November 2018 10:46:29 UTC+8, evdubs  wrote: 
>>>> > Resurrecting an old thread. 
>>>> > 
>>>> > 
>>>> > I recently tried to see what would happen if I changed the 
>>>> interactions-canvas% and definitions-canvas% to be the following: 
>>>> > 
>>>> > 
>>>> >   (define interactions-canvas% 
>>>> > (class 

[racket-users] Re: Practical HTTP requests?

2020-05-17 Thread evdubs
Have you taken a look at net/url 
? From there, I see:

   - make-http-connection 
   
,
 
   which can allow calls to get-pure-port/headers to stay connected if the 
   server allows it.
   - current-proxy-servers 
   

 
   and current-no-proxy-servers, which show they respect http_proxy, 
   https_proxy, and no_proxy.

There are also get-pure-port 

 
related functions that allow setting headers, which I think should let you 
set your cookies? For JSON, you can take look at the json 
 docs if you're 
interested in converting the HTTP response bodies into a JSON expression. 
These expressions can then be treated like any other expression where you 
can map/filter/fold over lists and access map elements with hash table 
functions.

To find this stuff, I just searched for "http" and "json" using the ". . . 
search manuals . . ." box at the top right of the docs. The search looks 
through all of the Racket API as well as many user-contributed packages. It 
makes it very easy to find whatever you might be interested in.

Evan

On Saturday, May 16, 2020 at 7:45:08 AM UTC-10, fixpoint wrote:
>
> I'm on the search for a new programming language to learn, so I thought 
> I'd check out Racket, but I'm having a hard time trying to do a very common 
> task that would make Racket practical for my use at work:
>
>- Make a series of HTTP requests to an API that returns JSON responses
>- Reuse the HTTP connection to avoid creating new TCP connections for 
>each request
>- Honors the `http_proxy`, `https_proxy`, and `no_proxy` environment 
>variables
>- Maintains a "session" where cookies set by the server are sent back 
>in subsequent requests
>
> My daily driver is Python, so I'm used to its `requests` library. Go and 
> Rust have similar libraries. While I don't mind piecing some of this 
> together, I'm struggling as a new user to figure out what libraries are 
> recommended and, more importantly, how to put them together to accomplish 
> the above points.
>
> Thank you.
>
> p.s. The Racket documentation is by far the best looking documentation 
> I've read in any language. It's quite amazing!
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a5923caf-d735-4e3f-af5b-1fd7c81bc65b%40googlegroups.com.


[racket-users] Re: raco pkg migrate previous versions

2020-05-15 Thread evdubs
If you're running Linux or (I assume) OS X, I think you might be able to 
just do the following:

$ ls ~/.racket

For me, that shows folders for Racket versions that include raco pkg install 
packages. Maybe that's sufficient?

Evan

On Friday, May 15, 2020 at 6:55:34 AM UTC-10, Curtis Dutton wrote:
>
> Is there a way to view the previous versions that were installed from raco 
> using raco pkg migrate?
>
> I always find myself trying to guess the previous version number after an 
> upgrade to migrate from. Does raco pkg have the ability to list previously 
> instlalled versions like drracket does?
>
>
> Thanks,
>Curt
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/e89f3dd8-3da7-4ae8-b229-a70353825c3a%40googlegroups.com.


Re: [racket-users] Re: Typing lag with DrRacket on Linux

2020-05-12 Thread evdubs
I did some more digging and found locations in racket/draw that control 
antialiasing. I tried changing them around, and saw no impact on 
performance.

However, I eventually stumbled upon the environment variable 
PLT_DISPLAY_BACKING_SCALE. By using an integer value for this variable, 
performance is nice and smooth (I tried 1 and 2; trying 1.25 and 1.5 hurt 
performance). In Ubuntu, I do not have my display set to a fractional 
scaling value, but I do have "Large Text" enabled. I am unsure if this 
setting interferes with whatever PLT_DISPLAY_BACKING_SCALE defaults to.

If you're having typing lag issues on Linux within Dr Racket or other 
Racket GUI applications, you may want to try PLT_DISPLAY_BACKING_SCALE=1 to 
see if that affects performance.

Evan

On Monday, May 11, 2020 at 2:05:06 PM UTC-10, evdubs wrote:
>
> I think what I have seen previously with setting the canvas style to 
> 'transparent ultimately is turning off antialiasing in Cairo.
>
> Using the sample text editor from this thread, I ran the following:
>
> $ cairo-trace racket text-editor.rkt
> $ cairo-trace racket text-editor-transparent.rkt
>
> In the non-transparent version, we see these two lines:
>
> 16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /antialias //ANTIALIAS_SUBPIXEL 
> /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style //HINT_STYLE_SLIGHT 
> /hint-metrics //HINT_METRICS_ON >> scaled-font /sf0 exch def
> f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /antialias 
> //ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style 
> //HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf1 
> exch def
>
> These lines look like this in the transparent version:
>
> 16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics //HINT_METRICS_ON 
> >> scaled-font /sf0 exch def
> f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics 
> //HINT_METRICS_ON >> scaled-font /sf1 exch def
>
> I am not really sure how this initialization is happening. Can someone 
> help me poke through the code to see how I might disable antialiasing? 
> Should I try to make changes to gui-lib/mred/private/wx/gtk/gcwin.rkt?
>
> Evan
>
> On Friday, March 29, 2019 at 12:29:11 AM UTC-10, Bryan Lee wrote:
>>
>> I’m facing the same issues, and I came across an interesting observation. 
>>
>> It seems that DrRacket mimics scrolling behaviour by literally replacing 
>> each line of code with the line above or below, and uses a really 
>> inefficient method of tracking which lines should go where, thereby 
>> limiting how fast you can “scroll”. 
>>
>> I realised that resizing the window horizontally does nothing to improve 
>> performance, but shrinking the window height significantly improved 
>> performance, even if the canvas area is adjusted to remain the same. 
>>
>> In addition to some function definitions in unit.rkt describing the 
>> transposing of lines, that leads me to my conclusion. 
>>
>> Thoughts? 
>>
>>
>>
>> On Friday, 2 November 2018 10:46:29 UTC+8, evdubs  wrote: 
>> > Resurrecting an old thread. 
>> > 
>> > 
>> > I recently tried to see what would happen if I changed the 
>> interactions-canvas% and definitions-canvas% to be the following: 
>> > 
>> > 
>> >   (define interactions-canvas% 
>> > (class editor-canvas% 
>> >   (init [style '(transparent)]) 
>> >   (super-new (style (cons 'auto-hscroll style))) 
>> >   (inherit set-scroll-via-copy) 
>> >   (set-scroll-via-copy #t))) 
>> > 
>> > 
>> > 
>> >   (define definitions-canvas% 
>> > (class editor-canvas% 
>> >   (init [style '(transparent)]) 
>> >   (super-new (style (cons 'auto-hscroll style))) 
>> >   (inherit set-scroll-via-copy) 
>> >   (set-scroll-via-copy #t))) 
>> > 
>> > 
>> > This seemed to work well for entering text into a blank file, but 
>> opening another file still showed the same lag. I was able to remove this 
>> last bit of lag by unchecking Edit / Preferences / Editing / General 
>> Editing / Color syntax interactively. I can now enter text into Dr Racket 
>> as smoothly as I can in most other text editors and even the example 
>> 'transparent editor-canvas% text editor. Background expansion can even be 
>> enabled without incurring a per-character-entered performance hit. 
>> > 
>> > 
>> > 
>> > I do not know why setting 'transparent helps the performance of 
>> editor-canvas%. Likewise, I do not know why interactive syntax coloring 
>> also 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2020-05-11 Thread evdubs
I think what I have seen previously with setting the canvas style to 
'transparent ultimately is turning off antialiasing in Cairo.

Using the sample text editor from this thread, I ran the following:

$ cairo-trace racket text-editor.rkt
$ cairo-trace racket text-editor-transparent.rkt

In the non-transparent version, we see these two lines:

16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /antialias //ANTIALIAS_SUBPIXEL 
/subpixel-order //SUBPIXEL_ORDER_RGB /hint-style //HINT_STYLE_SLIGHT 
/hint-metrics //HINT_METRICS_ON >> scaled-font /sf0 exch def
f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /antialias 
//ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style 
//HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf1 
exch def

These lines look like this in the transparent version:

16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics //HINT_METRICS_ON 
>> scaled-font /sf0 exch def
f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics 
//HINT_METRICS_ON >> scaled-font /sf1 exch def

I am not really sure how this initialization is happening. Can someone help 
me poke through the code to see how I might disable antialiasing? Should I 
try to make changes to gui-lib/mred/private/wx/gtk/gcwin.rkt?

Evan

On Friday, March 29, 2019 at 12:29:11 AM UTC-10, Bryan Lee wrote:
>
> I’m facing the same issues, and I came across an interesting observation. 
>
> It seems that DrRacket mimics scrolling behaviour by literally replacing 
> each line of code with the line above or below, and uses a really 
> inefficient method of tracking which lines should go where, thereby 
> limiting how fast you can “scroll”. 
>
> I realised that resizing the window horizontally does nothing to improve 
> performance, but shrinking the window height significantly improved 
> performance, even if the canvas area is adjusted to remain the same. 
>
> In addition to some function definitions in unit.rkt describing the 
> transposing of lines, that leads me to my conclusion. 
>
> Thoughts? 
>
>
>
> On Friday, 2 November 2018 10:46:29 UTC+8, evdubs  wrote: 
> > Resurrecting an old thread. 
> > 
> > 
> > I recently tried to see what would happen if I changed the 
> interactions-canvas% and definitions-canvas% to be the following: 
> > 
> > 
> >   (define interactions-canvas% 
> > (class editor-canvas% 
> >   (init [style '(transparent)]) 
> >   (super-new (style (cons 'auto-hscroll style))) 
> >   (inherit set-scroll-via-copy) 
> >   (set-scroll-via-copy #t))) 
> > 
> > 
> > 
> >   (define definitions-canvas% 
> > (class editor-canvas% 
> >   (init [style '(transparent)]) 
> >   (super-new (style (cons 'auto-hscroll style))) 
> >   (inherit set-scroll-via-copy) 
> >   (set-scroll-via-copy #t))) 
> > 
> > 
> > This seemed to work well for entering text into a blank file, but 
> opening another file still showed the same lag. I was able to remove this 
> last bit of lag by unchecking Edit / Preferences / Editing / General 
> Editing / Color syntax interactively. I can now enter text into Dr Racket 
> as smoothly as I can in most other text editors and even the example 
> 'transparent editor-canvas% text editor. Background expansion can even be 
> enabled without incurring a per-character-entered performance hit. 
> > 
> > 
> > 
> > I do not know why setting 'transparent helps the performance of 
> editor-canvas%. Likewise, I do not know why interactive syntax coloring 
> also incurs a noticeable performance hit. As a reminder, this is mostly a 
> problem for large resolution displays. Shrinking the DrRacket window will 
> improve performance at the cost of not being able to see as much of the 
> text. 
> > 
> > 
> > 
> > If anyone has advice for why this might be so, or how to better profile 
> this code to determine what can be improved, please share. I do not think 
> my current modifications merit a PR to the DrRacket repository. 
> > 
> > 
> > Evan 
> > 
> > 
> > On Wednesday, February 21, 2018 at 10:50:58 PM UTC-10, evdubs wrote: 
> > 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 inser

[racket-users] Re: Do you have Racket programs whose performance you care about?

2020-03-01 Thread evdubs
Is this perhaps something that will help improve the available profiling 
tools? Something like VisualVM  would be 
amazing for Racket!

On Friday, February 28, 2020 at 8:31:18 AM UTC-10, Lukas Lazarek wrote:
>
> PLT @ Northwestern is seeking out programs to help us understand the 
> performance of Racket "in the wild".
> If you have any Racket applications that you use and care about how it 
> performs, please let us know about them in the following survey:  
>
> https://forms.gle/b2eKMZdvXjpRHKL38
>
> Thank you!
> PLT @ Northwestern
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/58f17a44-af16-4a57-8ca4-1beaf9829b8c%40googlegroups.com.


Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-10-02 Thread evdubs
If anyone is following along here, I recently installed the Racket 7.4 
(non-Chez Scheme) version from the Ubuntu PPA and this performance has been 
acceptable. It is slightly noticeably slower but much better than what I 
had seen in 7.3. This works for me, but I am still clueless in 
understanding what may have caused the performance drop as well as how to 
better profile/uncover what is happening in Racket programs in general.

On Friday, June 7, 2019 at 4:14:08 PM UTC-10, evdubs wrote:
>
>  The paint times for 7.2 seem inconsistent with your previous tests...
>
>
> Correct. That run was a bit of an outlier. The 7.2 runs are mostly in line 
> with 7.3 with respect to paint.
>
> Here's what I get for mouse callback stats with this code 
> <http://pasterack.org/pastes/88406> when I use different thresholds for 
> delta:
>
> Version Min Max Mean StdDev 
> 7.2; delta < 2 0 22 3.398 3.968 
> 7.3; delta < 2 0 210 4.795 18.214 
> 7.2; delta < 20 0 22 2.332 3.64 
> 7.3; delta < 20 0 206 9.728 19.46 
> 7.2; delta < 200 0 106 2.961 7.802 
> 7.3; delta < 200 0 239 29.579 34.369 
>
> With a smaller delta, more overlays are able to be shown in 7.3, but it is 
> still noticeably laggy compared to 7.2 (looks like about a third of the 
> frequency of updates). I suppose I can try this approach with my plot code 
> if I upgrade to 7.3, but it's kind of upsetting.
>
> Evan
>
> On Friday, June 7, 2019 at 2:07:26 PM UTC-10, Alex Harsanyi wrote:
>>
>> The paint times for 7.2 seem inconsistent with your previous tests...
>>
>> In any case, it seems mouse event handling takes longer in 7.3 based your 
>> results.  What happens if you update the callback to discard any mouse 
>> events older than, say 50 milliseconds?
>>
>> Alex.
>>
>> On Friday, June 7, 2019 at 7:27:32 PM UTC+8, evdubs wrote:
>>>
>>> I changed the Linux line of code to:
>>>
>>> [time-stamp (current-milliseconds)]
>>>
>>> Is there a reason why you did not want to do that?
>>>
>>> Any way, when I do that, here are the results I get:
>>>
>>> $ ~/racket-7.2/bin/racket chart-lag-test.rkt
>>> Mouse
>>> Min: 0.132080078125
>>> Max: 23.10107421875
>>> Mean: 3.257062241367008
>>> StdDev: 4.589805152078677
>>>
>>> Paint
>>> Min: 0.178955078125
>>> Max: 102.94091796875
>>> Mean: 28.86041259765625
>>> StdDev: 42.84071031974706
>>>
>>> $ ~/racket-7.3.0.4/bin/racket chart-lag-test.rkt
>>> Mouse
>>> Min: 0.126953125
>>> Max: 202.34912109375
>>> Mean: 25.70277455891149
>>> StdDev: 38.4063903237421
>>>
>>> Paint
>>> Min: 0.175048828125
>>> Max: 21.754150390625
>>> Mean: 7.548767089843749
>>> StdDev: 8.728339324923978
>>>
>>> If this modification is okay, I guess this is getting somewhere?
>>>
>>> Evan
>>>
>>> On Wednesday, June 5, 2019 at 5:43:40 PM UTC-10, Alex Harsanyi wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, June 5, 2019 at 9:23:26 PM UTC+8, Alex Harsanyi wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, June 5, 2019 at 8:51:48 PM UTC+8, evdubs wrote:
>>>>>>
>>>>>> I ran the program with your modifications, but counter to the 
>>>>>> documentation 
>>>>>> <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>,
>>>>>>  
>>>>>> the values I get from get-time-stamp don't seem at all similar to 
>>>>>> current-milliseconds or current-inexact-milliseconds. I ended up 
>>>>>> defining 
>>>>>> delta as follows (with 1559695139340 being a guess):
>>>>>>
>>>>>> (define delta (- (current-inexact-milliseconds) 1559695139340 (send 
>>>>>> event get-time-stamp)))
>>>>>>
>>>>>>
>>>>> On my machine, `get-time-stamp` always returns 0 -- this indicates 
>>>>> that the event% object itself is copied somewhere along the way but the 
>>>>> timestamp is not copied, The 1559695139340 is just the unix timestamp 
>>>>> from 
>>>>> when you ran the code first time.  I don't think the mouse test is 
>>>>> relevant 
>>>>> as is...  unfortunately I don't have any more suggestions for now...
>>>>>
>>>>
>>>> It looks like the `get-time-stamp` returns a value that is not what the 
>>>> documentation specifies and it is also platform specific, I created an 
>>>> issue with the relevant details here: 
>>>> https://github.com/racket/gui/issues/132
>>>>
>>>> For now, I cannot think of a way to determine how old a mouse event is 
>>>> when the callback is invoked.
>>>>  
>>>>
>>>>>
>>>>> Alex.
>>>>>
>>>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/d0170bd1-47a7-4de2-a54b-d79936508720%40googlegroups.com.


Re: [racket-users] Would it help to call racket2 something else?

2019-08-31 Thread evdubs
If "racket" is related to "scheme" by being an illegitimate scheme, I think 
"cartel" could be a good choice for "an even more illegitimate scheme". Plus, 
it's almost an anagram of racket.

#lang cartel

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/2d72c920-fbad-4916-a5a0-8d513c7623ef%40googlegroups.com.


Re: [racket-users] Advice for porting Interactive Brokers API to Racket

2019-07-14 Thread evdubs
Thanks for the feedback. I will check to see if there's some way to query 
for capabilities, but I doubt it, given the client code. 

The client code does most of this version checking in one class, so that 
seems localized enough and I think it will be straight forward. Maybe if I 
stumble on a better way to do this, I'll share.

Evan

On Thursday, July 11, 2019 at 3:09:09 AM UTC-10, Greg Hendershott wrote:
>
> Some systems provide a way to query for a capability: COM has 
> QueryInterface, Racket dynamic-require, Emacs fboundp, and so on. When 
> such a query method is available, you can simply ask for the thing you 
> need or prefer. If it's available, great. If not, act appropriately: 
> Fail, or use your own "back fill" that does something similar or is just 
> a no-op, or whatever is appropriate. 
>
> [IMHO this is more sensible than using version numbers as proxies for 
> the thing you really care about. Especially lawyerly systems like 
> so-called semantic versioning. But I digress. :)] 
>
> The Racket flavor is something like the following. Let's say 
> some/module/path maybe has a new fribble function. If that's not 
> present, or if indeed that whole module isn't even installed, we want to 
> use our own our-fribble function as a default: 
>
> (define (our-fribble _x) 
>   'some-default-value) 
>
> (define fribble 
>   (with-handlers ([exn:fail? (λ _ our-fribble)]) 
> (dynamic-require 'some/module/path 
>  'fribble))) 
>
> For example, I use this and also Emacs' fboundp in Racket Mode, to 
> support various versions of Racket and Emacs, both. 
>
>
> I don't know if/how this would help your case. Their API uses the 
> futzing-with-version-numbers approach. Even so, _maybe_ you'd want to 
> localize the version number checks in one module, which provides the 
> functions for your other code to use? The functions will end up being 
> either the real broker thing, or your own default. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/54fdaf8b-2233-475e-b6ed-78c8fdeeeabf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Advice for porting Interactive Brokers API to Racket

2019-07-10 Thread evdubs
Hi,

I am currently investigating the effort required to port the Interactive 
Brokers Client API  
to Racket. In general, there is not much complexity in the client; it 
establishes an open socket, builds byte buffers to send to the server, and 
receives byte buffer responses. Some of the code declares classes that can 
be used by the client that can serialize to and deserialize from the byte 
buffers being sent.

There are some warts in the implementation. For example, there are sections 
like the following:

private static final int MIN_SERVER_VER_REAL_TIME_BARS = 34;
private static final int MIN_SERVER_VER_SCALE_ORDERS = 35;
private static final int MIN_SERVER_VER_SNAPSHOT_MKT_DATA = 35;
private static final int MIN_SERVER_VER_SSHORT_COMBO_LEGS = 35;
private static final int MIN_SERVER_VER_WHAT_IF_ORDERS = 36;

These values represent new feature releases that introduce things like 
receiving real time bars, submitting scale orders (a way to break up a 
large order into smaller orders that can scale as prices move favorably), 
receiving a snapshot of bids and asks for a financial instrument (market 
data), and submitting orders with conditions. These server version 
declarations are paired with code like:

public synchronized void placeOrder(int id, Contract contract, Order order) 
{
  ...
  if (m_serverVersion < MIN_SERVER_VER_SCALE_ORDERS) {
if (order.scaleInitLevelSize() != Integer.MAX_VALUE ||
order.scalePriceIncrement() != Double.MAX_VALUE) {
  error(id, EClientErrors.UPDATE_TWS,
"  It does not support Scale orders.");
  return;
}
  }
  ...
  if (m_serverVersion >= MIN_SERVER_VER_SCALE_ORDERS) {
if (m_serverVersion >= MIN_SERVER_VER_SCALE_ORDERS2) {
  buffer.sendMax(order.scaleInitLevelSize());
  buffer.sendMax(order.scaleSubsLevelSize());
}
else {
  buffer.send("");
  buffer.sendMax(order.scaleInitLevelSize());
}
buffer.sendMax(order.scalePriceIncrement());
  }
  ...
}

In the above, buffer is a byte buffer that is prepared to be sent along to 
the server. In this example, there are maybe 20 different buffers that can 
be built that just represent an order to send, and they all depend on the 
server version. It may have been a nicer design to have a small set of 
fields that every order shares and a map of extra fields for special 
orders, but we can't redesign the server-side of things.

I am wondering if there is a better way in Racket to port this code than to 
just have a "straight port" of code like:

(cond [(>= server-version 'scale-orders-version)
   (vector-append buffer (vector (order-scale-init-level-size order) 
(order-scale-subs-level-size order)))])

Is there a clearer way of representing capabilities of a server and have 
that be responsible for object serialization in Racket? Has anyone ported 
code to Racket with implementations like the above and found better ways of 
structuring the code in Racket?

Curiously,

Evan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/e9507c6b-aa74-4605-a1ff-44dc1bef6d23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-06-07 Thread evdubs

>
>  The paint times for 7.2 seem inconsistent with your previous tests...


Correct. That run was a bit of an outlier. The 7.2 runs are mostly in line 
with 7.3 with respect to paint.

Here's what I get for mouse callback stats with this code 
<http://pasterack.org/pastes/88406> when I use different thresholds for 
delta:

Version Min Max Mean StdDev 
7.2; delta < 2 0 22 3.398 3.968 
7.3; delta < 2 0 210 4.795 18.214 
7.2; delta < 20 0 22 2.332 3.64 
7.3; delta < 20 0 206 9.728 19.46 
7.2; delta < 200 0 106 2.961 7.802 
7.3; delta < 200 0 239 29.579 34.369 

With a smaller delta, more overlays are able to be shown in 7.3, but it is 
still noticeably laggy compared to 7.2 (looks like about a third of the 
frequency of updates). I suppose I can try this approach with my plot code 
if I upgrade to 7.3, but it's kind of upsetting.

Evan

On Friday, June 7, 2019 at 2:07:26 PM UTC-10, Alex Harsanyi wrote:
>
> The paint times for 7.2 seem inconsistent with your previous tests...
>
> In any case, it seems mouse event handling takes longer in 7.3 based your 
> results.  What happens if you update the callback to discard any mouse 
> events older than, say 50 milliseconds?
>
> Alex.
>
> On Friday, June 7, 2019 at 7:27:32 PM UTC+8, evdubs wrote:
>>
>> I changed the Linux line of code to:
>>
>> [time-stamp (current-milliseconds)]
>>
>> Is there a reason why you did not want to do that?
>>
>> Any way, when I do that, here are the results I get:
>>
>> $ ~/racket-7.2/bin/racket chart-lag-test.rkt
>> Mouse
>> Min: 0.132080078125
>> Max: 23.10107421875
>> Mean: 3.257062241367008
>> StdDev: 4.589805152078677
>>
>> Paint
>> Min: 0.178955078125
>> Max: 102.94091796875
>> Mean: 28.86041259765625
>> StdDev: 42.84071031974706
>>
>> $ ~/racket-7.3.0.4/bin/racket chart-lag-test.rkt
>> Mouse
>> Min: 0.126953125
>> Max: 202.34912109375
>> Mean: 25.70277455891149
>> StdDev: 38.4063903237421
>>
>> Paint
>> Min: 0.175048828125
>> Max: 21.754150390625
>> Mean: 7.548767089843749
>> StdDev: 8.728339324923978
>>
>> If this modification is okay, I guess this is getting somewhere?
>>
>> Evan
>>
>> On Wednesday, June 5, 2019 at 5:43:40 PM UTC-10, Alex Harsanyi wrote:
>>>
>>>
>>>
>>> On Wednesday, June 5, 2019 at 9:23:26 PM UTC+8, Alex Harsanyi wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, June 5, 2019 at 8:51:48 PM UTC+8, evdubs wrote:
>>>>>
>>>>> I ran the program with your modifications, but counter to the 
>>>>> documentation 
>>>>> <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>,
>>>>>  
>>>>> the values I get from get-time-stamp don't seem at all similar to 
>>>>> current-milliseconds or current-inexact-milliseconds. I ended up defining 
>>>>> delta as follows (with 1559695139340 being a guess):
>>>>>
>>>>> (define delta (- (current-inexact-milliseconds) 1559695139340 (send 
>>>>> event get-time-stamp)))
>>>>>
>>>>>
>>>> On my machine, `get-time-stamp` always returns 0 -- this indicates that 
>>>> the event% object itself is copied somewhere along the way but the 
>>>> timestamp is not copied, The 1559695139340 is just the unix timestamp from 
>>>> when you ran the code first time.  I don't think the mouse test is 
>>>> relevant 
>>>> as is...  unfortunately I don't have any more suggestions for now...
>>>>
>>>
>>> It looks like the `get-time-stamp` returns a value that is not what the 
>>> documentation specifies and it is also platform specific, I created an 
>>> issue with the relevant details here: 
>>> https://github.com/racket/gui/issues/132
>>>
>>> For now, I cannot think of a way to determine how old a mouse event is 
>>> when the callback is invoked.
>>>  
>>>
>>>>
>>>> Alex.
>>>>
>>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/fc444671-73b4-4d61-b9ce-8c37a4812a26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-06-07 Thread evdubs
I changed the Linux line of code to:

[time-stamp (current-milliseconds)]

Is there a reason why you did not want to do that?

Any way, when I do that, here are the results I get:

$ ~/racket-7.2/bin/racket chart-lag-test.rkt
Mouse
Min: 0.132080078125
Max: 23.10107421875
Mean: 3.257062241367008
StdDev: 4.589805152078677

Paint
Min: 0.178955078125
Max: 102.94091796875
Mean: 28.86041259765625
StdDev: 42.84071031974706

$ ~/racket-7.3.0.4/bin/racket chart-lag-test.rkt
Mouse
Min: 0.126953125
Max: 202.34912109375
Mean: 25.70277455891149
StdDev: 38.4063903237421

Paint
Min: 0.175048828125
Max: 21.754150390625
Mean: 7.548767089843749
StdDev: 8.728339324923978

If this modification is okay, I guess this is getting somewhere?

Evan

On Wednesday, June 5, 2019 at 5:43:40 PM UTC-10, Alex Harsanyi wrote:
>
>
>
> On Wednesday, June 5, 2019 at 9:23:26 PM UTC+8, Alex Harsanyi wrote:
>>
>>
>>
>> On Wednesday, June 5, 2019 at 8:51:48 PM UTC+8, evdubs wrote:
>>>
>>> I ran the program with your modifications, but counter to the 
>>> documentation 
>>> <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>,
>>>  
>>> the values I get from get-time-stamp don't seem at all similar to 
>>> current-milliseconds or current-inexact-milliseconds. I ended up 
>>> defining delta as follows (with 1559695139340 being a guess):
>>>
>>> (define delta (- (current-inexact-milliseconds) 1559695139340 (send 
>>> event get-time-stamp)))
>>>
>>>
>> On my machine, `get-time-stamp` always returns 0 -- this indicates that 
>> the event% object itself is copied somewhere along the way but the 
>> timestamp is not copied, The 1559695139340 is just the unix timestamp from 
>> when you ran the code first time.  I don't think the mouse test is relevant 
>> as is...  unfortunately I don't have any more suggestions for now...
>>
>
> It looks like the `get-time-stamp` returns a value that is not what the 
> documentation specifies and it is also platform specific, I created an 
> issue with the relevant details here: 
> https://github.com/racket/gui/issues/132
>
> For now, I cannot think of a way to determine how old a mouse event is 
> when the callback is invoked.
>  
>
>>
>> Alex.
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c6e5ea22-78ff-427b-95f9-282405541ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-06-05 Thread evdubs
I ran the program with your modifications, but counter to the documentation 
<https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>,
 
the values I get from get-time-stamp don't seem at all similar to 
current-milliseconds or current-inexact-milliseconds. I ended up defining 
delta as follows (with 1559695139340 being a guess):

(define delta (- (current-inexact-milliseconds) 1559695139340 (send event 
get-time-stamp)))

Here are the results:

$ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt 
Mouse
Min: 2.425048828125
Max: 97.818115234375
Mean: 30.901338585251057
StdDev: 28.349128820378922

Paint
Min: 0.282958984375
Max: 10.380859375
Mean: 4.27886962890625
StdDev: 4.162199753791872

$ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt 
Mouse
Min: 2.034912109375
Max: 295.45703125
Mean: 54.28094064372857
StdDev: 40.51587689852278

Paint
Min: 0.177978515625
Max: 6.715087890625
Mean: 3.2418212890625
StdDev: 2.868002614564615

So this perhaps shows that mouse events are being triggered almost twice as 
slowly in 7.3, but I think my hack makes these numbers unreliable. Also, 
the latency experienced interacting with the plot seems much worse than 
just twice as slow. Are you at least able to see a disconnect between 
current-inexact-milliseconds and get-time-stamp?

Evan

On Wednesday, June 5, 2019 at 2:17:46 AM UTC-10, Alex Harsanyi wrote:
>
> I had a look at the code and it is not exactly what I had in mind for the 
> measurements.  The problem with your measurements is that the canvas is 
> re-drawn only when needed, so the time between two calls to on-paint is not 
> relevant for performance measurements.
>
> For the on-paint, the time of the draw itself needs to be measured:
>
> (define/override (on-paint)
>   (define begin-timestamp (current-inexact-milliseconds))
>   (super on-paint)
>   (define end-timestamp (current-inexact-milliseconds))
>   (set! paint-event-stats
> (update-statistics paint-event-stats (- end-timestamp begin-
> timestamp
>
> For the mouse event, the time between when the event is created and the 
> time it is passed to the callback:
>
> (define ((make-current-value-renderer fn) snip event x y)
>   (define delta (- (current-inexact-milliseconds) (send event get-time-
> stamp)))
>   (set! mouse-event-stats (update-statistics mouse-event-stats delta))
>   (define overlays
> (and x y (eq? (send event get-event-type) 'motion)
>  (list (vrule x #:style 'long-dash)
>(point-label (vector x (fn x)) #:anchor 'auto
>   (send snip set-overlay-renderers overlays))
>
>
> Alex.
>
> On Wednesday, June 5, 2019 at 8:06:26 PM UTC+8, evdubs wrote:
>>
>> Thanks for responding, Alex.
>>
>> Here's what I came up with <http://pasterack.org/pastes/893> that I 
>> think satisfies your recommendations. It shows the sin() plot, expects 
>> interaction for 10 seconds, then prints min/max/mean/std dev for both the 
>> mouse-event-callback for the snip and on-paint for the editor-canvas%.
>>
>> Here's the output from running that with Racket 7.2 and Racket 7.3.0.4:
>>
>> $ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt 
>> Mouse
>> Min: 1.115966796875
>> Max: 1209.123046875
>> Mean: 40.23961775104986
>> StdDev: 81.88591520019294
>>
>> Paint
>> Min: 3.35302734375
>> Max: 275.579833984375
>> Mean: 79.6534423828125
>> StdDev: 113.45367443728956
>>
>> $ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt 
>> Mouse
>> Min: 1.072021484375
>> Max: 1095.2412109375
>> Mean: 21.93592705160883
>> StdDev: 54.53777963909044
>>
>> Paint
>> Min: 3.18798828125
>> Max: 284.447998046875
>> Mean: 80.8831787109375
>> StdDev: 117.90272049413493
>>
>> These numbers seem to suggest that 7.3 is an improvement, at least from 
>> the mouse-event stats, even though that is counter to the experience from 
>> interacting with the plot. Have any other ideas?
>>
>> Evan
>>
>> On Tuesday, June 4, 2019 at 1:39:49 PM UTC-10, Alex Harsanyi wrote:
>>>
>>>
>>>
>>> On Tuesday, June 4, 2019 at 11:32:42 AM UTC+8, evdubs wrote:
>>>>
>>>> Thanks for trying it out.
>>>>
>>>> I just tried using the bash installer from 
>>>> https://download.racket-lang.org/ and I experience the same issue of 
>>>> lagginess in 7.3. I also tried using a snapshot release from 
>>>> https://plt.eecs.northwestern.edu/snapshots/ and I experienced the 
>>>> same issue. 
>>>>
>>>> I am not su

Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-06-05 Thread evdubs
Thanks for responding, Alex.

Here's what I came up with <http://pasterack.org/pastes/893> that I think 
satisfies your recommendations. It shows the sin() plot, expects 
interaction for 10 seconds, then prints min/max/mean/std dev for both the 
mouse-event-callback for the snip and on-paint for the editor-canvas%.

Here's the output from running that with Racket 7.2 and Racket 7.3.0.4:

$ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt 
Mouse
Min: 1.115966796875
Max: 1209.123046875
Mean: 40.23961775104986
StdDev: 81.88591520019294

Paint
Min: 3.35302734375
Max: 275.579833984375
Mean: 79.6534423828125
StdDev: 113.45367443728956

$ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt 
Mouse
Min: 1.072021484375
Max: 1095.2412109375
Mean: 21.93592705160883
StdDev: 54.53777963909044

Paint
Min: 3.18798828125
Max: 284.447998046875
Mean: 80.8831787109375
StdDev: 117.90272049413493

These numbers seem to suggest that 7.3 is an improvement, at least from the 
mouse-event stats, even though that is counter to the experience from 
interacting with the plot. Have any other ideas?

Evan

On Tuesday, June 4, 2019 at 1:39:49 PM UTC-10, Alex Harsanyi wrote:
>
>
>
> On Tuesday, June 4, 2019 at 11:32:42 AM UTC+8, evdubs wrote:
>>
>> Thanks for trying it out.
>>
>> I just tried using the bash installer from 
>> https://download.racket-lang.org/ and I experience the same issue of 
>> lagginess in 7.3. I also tried using a snapshot release from 
>> https://plt.eecs.northwestern.edu/snapshots/ and I experienced the same 
>> issue. 
>>
>> I am not sure what I should try next other than maybe profiling, but I 
>> have not had much luck making effective use of the profiler in the past for 
>> interactive applications.
>>
>
> Here are a few things you can try:
>
> First, check again whether there’s a performance drop in Racket 7.2 too -- 
> you
> don’t want to spend time tracking down a Racket problem only to find out 
> that
> the latest Ubuntu update disabled the hardware acceleration on the graphics
> card.
>
> If it is indeed a regression in Racket 7.3, you can try narrowing the 
> problem
> down to either rendering or mouse event delays:
>
> * you can measure the time it takes to render the plot by measuring the 
> time
>   the paint method of the `editor-canvas%`. You will need to create a 
> custom
>   `editor-canvas%` and override `on-paint` and use
>   `current-inexact-milliseconds` to measure the time.
>
> * to check if mouse events are delivered too late to the callback. You can 
> use
>   the `get-time-stamp` method on the event and compare it against
>   `current-inexact-milliseconds` to determine the delay.
>
> You will need to compare both values against Racket 7.2 to see which one is
> causing the slow down.
>
> Alex.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8da34303-b3aa-4e01-881d-4806f4a0b75a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Racket 7.3 Plot Performance Regression

2019-06-03 Thread evdubs
Thanks for trying it out.

I just tried using the bash installer from 
https://download.racket-lang.org/ and I experience the same issue of 
lagginess in 7.3. I also tried using a snapshot release from 
https://plt.eecs.northwestern.edu/snapshots/ and I experienced the same 
issue. 

I am not sure what I should try next other than maybe profiling, but I have 
not had much luck making effective use of the profiler in the past for 
interactive applications.

Evan

On Thursday, May 30, 2019 at 4:23:13 AM UTC-10, Sam Tobin-Hochstadt wrote:
>
> I just tried this on my build (from HEAD) and I also do not see any 
> slowdown. Trying with a regular installer would be helpful. 
>
> Sam 
>
> On Fri, May 17, 2019 at 5:09 PM evdubs > 
> wrote: 
> > 
> > Hi All, 
> > 
> > I have noticed sluggish performance with my plot overlays in Racket 7.3 
> that I had not noticed in versions 7.2 and prior. Here's the code I am 
> using to test (taken from here): 
> > 
> > (require plot) 
> > 
> > (define ((make-current-value-renderer fn) snip event x y) 
> >   (define overlays 
> > (and x y (eq? (send event get-event-type) 'motion) 
> >  (list (vrule x #:style 'long-dash) 
> >(point-label (vector x (fn x)) #:anchor 'auto 
> >   (send snip set-overlay-renderers overlays)) 
> > 
> > (define snip (plot-snip (function sin) #:x-min 0 #:x-max (* 2 pi) 
> #:y-min -1.5 #:y-max 1.5)) 
> > (send snip set-mouse-event-callback (make-current-value-renderer sin)) 
> > snip 
> > 
> > With 7.3, it feels like the frame rate hovers around 5-10 fps and the 
> mouse pointer input is buffered so you can move around the plot and it will 
> slowly try to catch up to where your pointer was. 7.2 and prior all felt 
> snappy and seemed to be at least 20-30 fps. 
> > 
> > Here are my installation details: 
> > 
> > Ubuntu 19.04 
> > Intel Core i5-7400 
> > 16GB RAM with only ~10GB in use (no swapping) and <1GB in use by 
> DrRacket 
> > Racket 7.3 installed from the PPA 
> > 
> > I asked Alex H. if he had noticed this regression and he said he had 
> not. He uses Windows. I have not tried to see if the PPA version is any 
> different from the official installer to see if there's a difference. Maybe 
> that's the next step? 
> > 
> > Evan 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/b68b9731-3163-4d0b-9edc-32c3774b6243%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a79a3b45-ea09-4b62-af58-3a367d1d799d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Racket 7.3 Plot Performance Regression

2019-05-17 Thread evdubs
Hi All,

I have noticed sluggish performance with my plot overlays in Racket 7.3 
that I had not noticed in versions 7.2 and prior. Here's the code I am 
using to test (taken from here 

):

(require plot)

(define ((make-current-value-renderer fn) snip event x y)
  (define overlays
(and x y (eq? (send event get-event-type) 'motion)
 (list (vrule x #:style 'long-dash)
   (point-label (vector x (fn x)) #:anchor 'auto
  (send snip set-overlay-renderers overlays))

(define snip (plot-snip (function sin) #:x-min 0 #:x-max (* 2 pi) #:y-min 
-1.5 #:y-max 1.5))
(send snip set-mouse-event-callback (make-current-value-renderer sin))
snip

With 7.3, it feels like the frame rate hovers around 5-10 fps and the mouse 
pointer input is buffered so you can move around the plot and it will 
slowly try to catch up to where your pointer was. 7.2 and prior all felt 
snappy and seemed to be at least 20-30 fps. 

Here are my installation details:

Ubuntu 19.04
Intel Core i5-7400
16GB RAM with only ~10GB in use (no swapping) and <1GB in use by DrRacket
Racket 7.3 installed from the PPA 


I asked Alex H. if he had noticed this regression and he said he had not. 
He uses Windows. I have not tried to see if the PPA version is any 
different from the official installer to see if there's a difference. Maybe 
that's the next step?

Evan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/b68b9731-3163-4d0b-9edc-32c3774b6243%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-11-01 Thread evdubs
*Resurrecting an old thread.*

I recently tried to see what would happen if I changed the 
interactions-canvas% and definitions-canvas% to be the following:

  (define interactions-canvas%
(class editor-canvas%
  (init [style '(transparent)])
  (super-new (style (cons 'auto-hscroll style)))
  (inherit set-scroll-via-copy)
  (set-scroll-via-copy #t)))

  (define definitions-canvas%
(class editor-canvas%
  (init [style '(transparent)])
  (super-new (style (cons 'auto-hscroll style)))
  (inherit set-scroll-via-copy)
  (set-scroll-via-copy #t)))

This seemed to work well for entering text into a blank file, but opening 
another file still showed the same lag. I was able to remove this last bit 
of lag by unchecking Edit / Preferences / Editing / General Editing / Color 
syntax interactively. I can now enter text into Dr Racket as smoothly as I 
can in most other text editors and even the example 'transparent 
editor-canvas% text editor. Background expansion can even be enabled 
without incurring a per-character-entered performance hit. 

I do not know why setting 'transparent helps the performance of 
editor-canvas%. Likewise, I do not know why interactive syntax coloring 
also incurs a noticeable performance hit. As a reminder, this is mostly a 
problem for large resolution displays. Shrinking the DrRacket window will 
improve performance at the cost of not being able to see as much of the 
text.

If anyone has advice for why this might be so, or how to better profile 
this code to determine what can be improved, please share. I do not think 
my current modifications merit a PR to the DrRacket repository.

Evan

On Wednesday, February 21, 2018 at 10:50:58 PM UTC-10, evdubs wrote:
>
> 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 <https://github.com/racket/gui/pull/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 
>>>> <https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/window.rkt>'s
>>>>  
>>>> flush-display
>>>>
>>>> (define (flush-display)
>>>

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-02-22 Thread 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 <https://github.com/racket/gui/pull/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 
>>> <https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/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 
>>> <https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-process-all-updates>
>>>
>>> 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)))
>>>

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-02-21 Thread evdubs
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 <https://github.com/racket/gui/pull/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 
>> <https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/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 
>> <https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-process-all-updates>
>>
>> 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
>>>  Idx Total  Self  Name+src 
>>>Local%
>>>  ms(pct)ms(pct) Callee
>>>
>>> 
>>> call-with-break-parameterization [2] 
>>>  100.0%
>>>  [5]  19000(10.6%)6221(3.5%)  dispatch-on-char method in window% ...
>>> ow.rkt:778:4
>>> ??? [45]   
>>> 29.3%
>>>  

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-02-11 Thread evdubs
I created PR 95 <https://github.com/racket/gui/pull/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 
> <https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/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 
> <https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-process-all-updates>
>
> 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
>>  Idx Total  Self  Name+src   
>>  Local%
>>  ms(pct)ms(pct) Callee
>>
>> 
>> call-with-break-parameterization [2] 
>>  100.0%
>>  [5]  19000(10.6%)6221(3.5%)  dispatch-on-char method in window% ...
>> ow.rkt:778:4
>> ??? [45] 
>>   29.3%
>> flush-display [14]   
>>   27.8%
>> call-pre-on-char method in window% [
>> 15]10.2%
>>
>> 
>> call-with-break-parameterization [2] 
>>  100.0%
>>  [7]   2580(1.4%) 2580(1.4%)  ??? ...acket/collects/ffi/unsafe/atomic
>> .rkt:115:16
>>
>> 
>> dispatch-on-event method in window% [
>> 9] 3.1%
>> dispatch-on-char method in window% [5
>> ] 96.9%
>> [14]   5442(3.0%) 5442(3.0%)  flush-display ...d/private/wx/gtk/
>> window.rkt:891:0
>>
>> 
>> ??? [13] 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-02-10 Thread evdubs
I made the following change to window.rkt 
<https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/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 
<https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-process-all-updates>

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
>  Idx Total  Self  Name+src   
>  Local%
>  ms(pct)ms(pct) Callee
>
> 
> call-with-break-parameterization [2] 
>  100.0%
>  [5]  19000(10.6%)6221(3.5%)  dispatch-on-char method in window% ...ow
> .rkt:778:4
> ??? [45] 
>   29.3%
> flush-display [14]   
>   27.8%
> call-pre-on-char method in window% [15
> ]10.2%
>
> 
> call-with-break-parameterization [2] 
>  100.0%
>  [7]   2580(1.4%) 2580(1.4%)  ??? ...acket/collects/ffi/unsafe/atomic.
> rkt:115:16
>
> 
> dispatch-on-event method in window% [9
> ] 3.1%
> dispatch-on-char method in window% [5] 
> 96.9%
> [14]   5442(3.0%) 5442(3.0%)  flush-display ...d/private/wx/gtk/window
> .rkt:891:0
>
> 
> ??? [13] 
>  100.0%
> [22] 179456(100.0%) 158080(88.1%) loop .../drracket/drracket/private/rep.
> rkt:1456:17
> ??? [3]   
>  11.3%
> wait-now [32] 
>   0.0%
>
> 
> ??? [70] 
>  100.0%
> [75]   5512(3.1%) 5512(3.1%)  channel-put ...lects/racket/privat

Re: [racket-users] Re: Typing lag with DrRacket on Linux

2018-02-10 Thread evdubs
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
 Idx Total  Self  Name+src 
   Local%
 ms(pct)ms(pct) Callee

call-with-break-parameterization [2]   
   100.0%
 [5]  19000(10.6%)6221(3.5%)  dispatch-on-char method in window% ...ow.
rkt:778:4
??? [45]   
29.3%
flush-display [14] 
27.8%
call-pre-on-char method in window% [15] 
   10.2%

call-with-break-parameterization [2]   
   100.0%
 [7]   2580(1.4%) 2580(1.4%)  ??? ...acket/collects/ffi/unsafe/atomic.
rkt:115:16

dispatch-on-event method in window% [9] 
3.1%
dispatch-on-char method in window% [5] 
96.9%
[14]   5442(3.0%) 5442(3.0%)  flush-display ...d/private/wx/gtk/window.
rkt:891:0

??? [13]   
   100.0%
[22] 179456(100.0%) 158080(88.1%) loop .../drracket/drracket/private/rep.rkt
:1456:17
??? [3] 
   11.3%
wait-now [32]   
0.0%

??? [70]   
   100.0%
[75]   5512(3.1%) 5512(3.1%)  channel-put ...lects/racket/private/misc.
rkt:169:2


The culprit, to me, looks like flush-display. Do you perhaps have any 
thoughts on the flush-display usage within window.rkt? I will try to poke 
at this a bit more.

Evan

On Saturday, February 10, 2018 at 3:35:35 AM UTC-10, Robby Findler wrote:
>
> If you run this code, does the profiling information reveal anything 
> interesting? 
>
> #lang racket/gui 
> (require profile) 
> (define ec% 
>   (class editor-canvas% 
> (define/override (on-paint) 
>   (profile (super on-paint))) 
> (define/override (on-char e) 
>   (profile (super on-char e))) 
> (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) 
>
>
> On Fri, Feb 9, 2018 at 11:05 PM, Evan Whitmer  > wrote: 
> > I forgot to mention that I have a 4K display, and I think that's 
> important 
> > to note here. 
> > 
> > 
> > On Friday, February 9, 2018 at 7:00:18 PM UTC-10, Evan Whitmer wrote: 
> >> 
> >> I, too, am having typing latency issues in DrRacket in the definitions 
> >> window. As Dave noted, the size of the window seems to be related to 
> the 
> >> issue, and, in my experience, it's not just an issue with the