[racket-users] Re: Alternatives to DrRacket

[JCG]

Sorry for the delay. 

1) Coloring of a #; commented-out S-expression, as in Emacs.

2) Code folding that is saved and yet compatible with external editors.  
The way I would go about dealing with the WXME format would be be to save 
two files, with the WXME format hidden somewhere (Sqlite or a file) based 
on the hash of the content of the normal text.  If the hash matches, then 
utilize the extra goodies the WXME affords (e.g. code folding); otherwise 
just show the normal text version and nobody will be the wiser.  

3) Having the ability for the Run button to execute a different process 
would allow crash-prone C/C++/Go/Rust extensions not annihilate the GUI.

4) The first attempt to get assistance from meta-/ takes quite a while yet 
excludes operators defined in the current file.  Given that it's not 
including local definitions and/or tokens, and that the next time I start 
DrRacket, the same list will slowly appear, it ought to be cached.

5) Easy way to avoid byte-code incompatibility, e.g. I download 6.12.0.3 
and run into a repetitive dialog about 6.10 byte-code incompatibility 
without any option for correction.

6) In the preferences dialog (on a Mac at least), the "Revert All 
Preferences to Defaults" is unclear about whether the defaults are for the 
displayed tab or for all preferences.  At least twice in the past, I've 
incorrectly assumed that the defaults were for the topic displayed and not 
all preferences.  I fiddled with the background expansion and finally 
decided "Oh, I'll just put it back to whatever is suggested - bam, all my 
other settings were gone."

7) Finally, the tools tab has doubtful defaults for preloading tools, e.g. 
Algol 60.   Then there is the question about what "Skip the tool" means.  
Does that mean that I cannot access these in a running Dr Racket? 

Thanks for asking suggestions.

-John


On Sunday, November 26, 2017 at 10:42:29 AM UTC-5, spdegabrielle wrote:
>
> Hi,
>
> I’ve noticed some list members use other editors or IDE’s. 
>
> I know two big reasons for using a complex tool is it’s stickiness 
> factors; normally a combination of familiarity (hence speed) with a lot of 
> powerful features and non-transportable customisation.
>
> Putting stickiness factors aside, what features in other editors/IDE’s 
> would you like to see in DrRacket?
>
> Kind regards,
>
> Stephen
>
>
> -- 
> Kind regards,
> Stephen
> --
> Ealing (London), UK
>

-- 
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] TR hash-ref type design decision?

['John Clements' via Racket Users]

> On Jan 11, 2018, at 9:52 AM, Sam Tobin-Hochstadt  wrote:
> 
> This is an intentional design choice, but I also think it's pretty
> hard to avoid. In particular, consider immutable hash tables. In that
> case, (HT A B) is a subtype of (HT A* B), if A <: A*. But then for
> immutable hash tables, your `checked-hash-ref` has the same issue that
> the original type for `hash-ref` has, because we can just instantiate
> A to the bigger type. In general, if you take out the `HashTableTop`
> lines, you probably won't get a different behavior in the cases you're
> thinking of, and those cases are important for cases where you
> genuinely only know that you have a hash, and not something about the
> key/value types.

Okay, that makes sense. Many thanks for taking the time to write this up.

John

> 
> Sam
> 
> On Thu, Jan 11, 2018 at 12:35 PM, 'John Clements' via Racket Users
>  wrote:
>> I was surprised and a wee bit dismayed this morning to see that this code, 
>> using hash-ref with the wrong key type, typechecks:
>> 
>> #lang typed/racket
>> 
>> (define my-hash : (HashTable String String)
>>  (make-immutable-hash
>>   '(("abc" . "def")
>> ("ghi" . "jkl"
>> 
>> (hash-ref my-hash 1234)
>> 
>> So, I printed out the type of hash-ref:
>> 
>> (All (a b c)
>>  (case->
>>   (-> (U (Immutable-HashTable a b)
>>  (Mutable-HashTable a b)
>>  (Weak-HashTable a b))
>>   a
>>   b)
>>   (-> (U (Immutable-HashTable a b)
>>  (Mutable-HashTable a b)
>>  (Weak-HashTable a b))
>>   a
>>   False
>>   (U False b))
>>   (-> (U (Immutable-HashTable a b)
>>  (Mutable-HashTable a b)
>>  (Weak-HashTable a b))
>>   a
>>   (-> c)
>>   (U b c))
>>   (->* (HashTableTop a) (False) Any)
>>   (-> HashTableTop a (-> c) Any)))
>> 
>> 
>> Sure enough, hash-ref on a key outside the domain of the hash table is 
>> totally legal, and returns type Any. And why not? This is clearly sound.
>> 
>> HOWEVER, as a TR programmer, I can’t imagine a lot of situations in which 
>> I’d prefer this behavior to simply having this be a type error; I know that 
>> TR’s philosophy is to try to support gradual typing, but if I want this 
>> check, I…have to roll my own hash-ref? It’s not hard, I guess:
>> 
>> (: checked-hash-ref (All (A B) ((HashTable A B) A -> B)))
>> (define (checked-hash-ref table key)
>>  (hash-ref table key))
>> 
>> 
>> … but I just wanted to check and make sure this was a deliberate choice. 
>> Maybe I’m missing an obvious case where you want this?
>> 
>> John
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.



-- 
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/gui and the Cocoa NSRunLoop

[Mark Wunsch]

Yes — that's perfect, thank you! And it also gives me a better sense of how 
racket/gui is implemented for macOS. This snippet of code is now included in my 
library, and I wonder if there's benefit to having this be available in 
racket/gui for cross-platform usage?

Now that I understand this a bit, I tried solving the second use-case I wrote 
about, using the glimagesink. My understanding of this code is that it creates 
a subview with a CAOpenGLLayer, and then enqueues a `setNeedsDisplay`: 
https://github.com/GStreamer/gst-plugins-bad/blob/8d99867c13944be9ba75a892682204955f16f586/gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m#L332-L354

When I run equivalent code outside of racket (e.g. through the gst-launch 
tool), I see that I continuously see calls to draw 
(https://developer.apple.com/documentation/quartzcore/caopengllayer/1522316-draw).
 Those calls are not being made when run from Racket.

I realize we're venturing outside of the Realm of Racket (intentional pun)  and 
closer to Cocoa, but I'd like to have a better sense of how to dequeue these 
drawing actions. Based on your previous code, I thought that I could yield to 
the main thread by calling `run` or `runUntilDate` on the main NSRunLoop, but 
that didn't seem to accomplish this goal.

Any ideas of how to "yield" to whatever queue or thread GStreamer has running?

Thank you so much for your help!

On Wed, Jan 10, 2018, at 3:37 PM, Matthew Flatt wrote:
> At Wed, 10 Jan 2018 11:17:14 -0800 (PST), Mark Wunsch wrote:
> > The main question I have is: How does racket/gui set up and interact with 
> > the NSApplication's main thread?
> > [...]
> > My sense of this crash is that there's something inside the racket/gui 
> > internals []
> > that works around a "typical" NSApplication start-up sequence that makes 
> > the osxvideosink code believe that it's running outside of the main NSApp 
> > thread. "Typical" is in quotes because I honestly have no idea what I'm 
> > talking about.
> 
> It's true that `racket/gui` avoids the usual run loop, so I expect that
> "osxvideosink.m" will think that it needs its own. Specifically,
> `[[NSRunLoop mainRunLoop] currentMode]` will return nil. And if
> `gst_osx_videosink_check_main_run_loop` runs in the main OS thread via
> a foreign call, then no events will be dispatched while it waits to
> check in teh backup way, because the Racket-level thread that pulses
> the main run loop will be blocked until the foreign call returns.
> Finally, if "osxvideosink.m" sets up its own run loop and hacks
> `isThread`, that would interact badly with `racket/gui` and could
> explain the crash.
> 
> Does it help to wrap the `broadcast` call with
> 
>  (call-atomically-in-run-loop
>   (lambda ()
> ))
> 
> using the implementation of `call-atomically-in-run-loop` below?
> 
> 
> 
> #lang racket/base
> (require racket/gui/base
>  ffi/unsafe
>  ffi/unsafe/objc
>  ffi/unsafe/nsalloc)
> 
> (provide call-atomically-in-run-loop)
> 
> (import-class NSObject NSArray NSRunLoop)
> (define NSDefaultRunLoopMode (get-ffi-obj 'NSDefaultRunLoopMode #f _id))
> 
> (define-objc-class CallerContainer NSObject
>   [proc]
>   (-a _void (call) (proc)))
> 
> (define (call-atomically-in-run-loop proc)
>   (define result #f)
>   (define s (make-semaphore))
>   (call-with-autorelease
>(lambda ()
>  (define obj (tell CallerContainer alloc))
>  (set-ivar! obj proc (lambda () (set! result (proc)) (semaphore-post s)))
>  (tellv (tell NSRunLoop mainRunLoop)
> performSelector: #:type _SEL (selector call)
> target: obj
> argument: #f
> order: #:type _uint 0
> modes: (tell (tell NSArray alloc)
>  initWithObject: NSDefaultRunLoopMode
>   (yield s)
>   result)
> 
> ;; Example, gets a non-#f result:
> #;
> (call-atomically-in-run-loop
>   (lambda ()
> (tell (tell NSRunLoop mainRunLoop) currentMode)))
> 

-- 
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] TR hash-ref type design decision?

[Sam Tobin-Hochstadt]

This is an intentional design choice, but I also think it's pretty
hard to avoid. In particular, consider immutable hash tables. In that
case, (HT A B) is a subtype of (HT A* B), if A <: A*. But then for
immutable hash tables, your `checked-hash-ref` has the same issue that
the original type for `hash-ref` has, because we can just instantiate
A to the bigger type. In general, if you take out the `HashTableTop`
lines, you probably won't get a different behavior in the cases you're
thinking of, and those cases are important for cases where you
genuinely only know that you have a hash, and not something about the
key/value types.

Sam

On Thu, Jan 11, 2018 at 12:35 PM, 'John Clements' via Racket Users
 wrote:
> I was surprised and a wee bit dismayed this morning to see that this code, 
> using hash-ref with the wrong key type, typechecks:
>
> #lang typed/racket
>
> (define my-hash : (HashTable String String)
>   (make-immutable-hash
>'(("abc" . "def")
>  ("ghi" . "jkl"
>
> (hash-ref my-hash 1234)
>
> So, I printed out the type of hash-ref:
>
> (All (a b c)
>   (case->
>(-> (U (Immutable-HashTable a b)
>   (Mutable-HashTable a b)
>   (Weak-HashTable a b))
>a
>b)
>(-> (U (Immutable-HashTable a b)
>   (Mutable-HashTable a b)
>   (Weak-HashTable a b))
>a
>False
>(U False b))
>(-> (U (Immutable-HashTable a b)
>   (Mutable-HashTable a b)
>   (Weak-HashTable a b))
>a
>(-> c)
>(U b c))
>(->* (HashTableTop a) (False) Any)
>(-> HashTableTop a (-> c) Any)))
>
>
> Sure enough, hash-ref on a key outside the domain of the hash table is 
> totally legal, and returns type Any. And why not? This is clearly sound.
>
> HOWEVER, as a TR programmer, I can’t imagine a lot of situations in which I’d 
> prefer this behavior to simply having this be a type error; I know that TR’s 
> philosophy is to try to support gradual typing, but if I want this check, 
> I…have to roll my own hash-ref? It’s not hard, I guess:
>
> (: checked-hash-ref (All (A B) ((HashTable A B) A -> B)))
> (define (checked-hash-ref table key)
>   (hash-ref table key))
>
>
> … but I just wanted to check and make sure this was a deliberate choice. 
> Maybe I’m missing an obvious case where you want this?
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] TR hash-ref type design decision?

['John Clements' via Racket Users]

I was surprised and a wee bit dismayed this morning to see that this code, 
using hash-ref with the wrong key type, typechecks:

#lang typed/racket

(define my-hash : (HashTable String String)
  (make-immutable-hash
   '(("abc" . "def")
 ("ghi" . "jkl"

(hash-ref my-hash 1234)

So, I printed out the type of hash-ref:

(All (a b c)
  (case->
   (-> (U (Immutable-HashTable a b)
  (Mutable-HashTable a b)
  (Weak-HashTable a b))
   a
   b)
   (-> (U (Immutable-HashTable a b)
  (Mutable-HashTable a b)
  (Weak-HashTable a b))
   a
   False
   (U False b))
   (-> (U (Immutable-HashTable a b)
  (Mutable-HashTable a b)
  (Weak-HashTable a b))
   a
   (-> c)
   (U b c))
   (->* (HashTableTop a) (False) Any)
   (-> HashTableTop a (-> c) Any)))


Sure enough, hash-ref on a key outside the domain of the hash table is totally 
legal, and returns type Any. And why not? This is clearly sound.

HOWEVER, as a TR programmer, I can’t imagine a lot of situations in which I’d 
prefer this behavior to simply having this be a type error; I know that TR’s 
philosophy is to try to support gradual typing, but if I want this check, 
I…have to roll my own hash-ref? It’s not hard, I guess:

(: checked-hash-ref (All (A B) ((HashTable A B) A -> B)))
(define (checked-hash-ref table key)
  (hash-ref table key))


… but I just wanted to check and make sure this was a deliberate choice. Maybe 
I’m missing an obvious case where you want this?

John

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

Re: [racket-users] Read-only "editor" text with min-width of its content

[Laurent]

Maybe you can use snips% inside a single editor%?
Snips can be text or pictures or other things.


On Wed, Jan 10, 2018 at 9:58 PM, Christopher Lemmer Webber <
cweb...@dustycloud.org> wrote:

> Christopher Lemmer Webber writes:
>
> > Matthew Flatt writes:
> >
> >> At Wed, 10 Jan 2018 10:29:28 -0600, Christopher Lemmer Webber wrote:
> >>> I'm still not sure how to find out what the "total" height of the text
> >>> is in an editor.  Does anyone know how to look that up?
> >>
> >> I think the `get-extent` method will report the size you want.
> >
> > Thank you so much!  That plus the vertical-inset info gave me what I
> > needed:
> >
> > (let ((h-box (box 0)))
> >   (send test-text2 get-extent #f h-box)
> >   (send test-ec min-height (+ (inexact->exact (unbox h-box))
> >   (* (send test-ec vertical-inset) 2)))
> >   (send test-ec stretchable-height #f))
>
> Horray, this works!  I'm now able to display content and it's nicely
> line-wrapped, etc.
>
> Only one problem: Now I have a ton of "editors" which were probably
> never meant to be used like this for hundreds of little "microblogs". ;)
> The main issue is that scrolling with all these editor canvases in place
> is super slow and really chews up CPU.  (When I'm not scrolling, it
> seems fine.)
>
> I wonder if there are any obvious hacks I could perform?  Caching things
> (is it possible to grab a bitmap of the current text editor's display
> content?), replacing the canvases with blank content when not being
> looked at, etc?
>

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