Re: [racket-users] Re: reporting contract violations in executable programs

[Shu-Hung You]

Thanks for catching this! This is a bug in the setup/dirs library,
which the contract system transitively depends on to compute the path
in the error message. I opened a pull request and let's see how it
goes (#2352).
On Thu, Nov 1, 2018 at 5:23 PM Alex Harsanyi  wrote:
>
>
>
> On Thursday, November 1, 2018 at 7:38:29 PM UTC+8, Alexander McLin wrote:
>>
>> I’m a little confused here, to me it looks like the second contract 
>> violation is completely different from the first one.
>
>
> My program is only seven lines of code and does not call `build-path`.  Also, 
> if I fix the incorrect call to `foo` and rebuild the executable, the 
> `build-path` contract violation is no longer reported and the program runs 
> fine.  You might wan to actually build the executable and run it using the 
> instructions I provided, to understand what I am trying to explain.
>
> #lang racket
> (require racket/contract)
>
> (define/contract (foo n)
>   (-> integer? any/c)
>   (printf "foo: ~a~%" n))
>
> (module+ main
>   (foo "hello"))
>
> This is just a small example that illustrates the problem -- I have an actual 
> application which is built into an executable and, whenever there is a 
> contract violation error reported, regardless of what the contract violation 
> is about, always the `build-path` contract violation shows up.  At first, I 
> was puzzled by this, but now, I have learned that when I see a build path 
> contract error, I try to run the application in un-compiled mode (is there a 
> better term?) and try to reproduce the issue -- but this is not always easy 
> with complex applications.
>
> Alex.
>
>>
>> You were expecting `foo` to raise a contract violation but in your 
>> executable example it appears that contract violation is being raised by the 
>> `build-path` function not `foo`.
>>
>> Maybe it’s a entirely different error?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[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  to remove the 
>>> call to gdk_window_process_all_updates. I am still unsure if there are 
>>> legacy or compatibility reasons for having this call.
>>>
>>> Evan
>>>
>>> On Saturday, February 10, 2018 at 12:39:58 PM UTC-10, evdubs wrote:

 I made the following change to window.rkt 
 's
  
 flush-display

 (define (flush-display)
   (try-to-sync-refresh)
   ;; (gdk_window_process_all_updates)
   (gdk_display_flush (gdk_display_get_default)))


 I made this change after finding the following note for the 
 gdk_window_process_all_updates 
 documentation 
 

 gdk_window_process_all_updates has been deprecated since version 3.22 
> an

Re: [racket-users] Doing file I/O from within a macro

[Alex Knauth]

> On Nov 1, 2018, at 8:32 PM, Robby Findler  wrote:
> 
> DrRacket disallows network and filesystem access during its online expansion. 
> Partly for security reasons and partly because it seems unlikely that the 
> code one writes that does that would be kill safe. You might be able to bike 
> the abstractions you news via the FFI but I guess it will be hard to get 
> right because DrRacket just kills off compilations effectively randomly. 

Okay, thanks.

> Robby
> 
> On Thu, Nov 1, 2018 at 5:57 PM Alex Knauth  > wrote:
> Is it possible to create a temporary file, write to it, run a command on it, 
> and the possibly delete the file from within a macro? Or is it possible to 
> run a command (as in `system`) in a context where it pretends that some file 
> exists?
> 
> And, how does this play with DrRacket's background expansion?
> 
> The reason I'm thinking about this is that I want to call out to an external 
> compiler (for a language other than racket, not implemented in racket), get 
> information back from that compiler, and display that information in the form 
> of DrRacket's mouse-over-tooltips.
> 
> I tried this, and it said "forbidden (write) access" to the temporary file 
> name that it generated. I get this error from DrRacket's background expansion.
> 
> Is there a way to do this in a way I can use while generating DrRacket 
> tooltips?
> 
> #lang racket
> (require (for-syntax racket/file))
> 
> (define-syntax m
>   (λ (stx)
> (define tmp (make-temporary-file))
> (display-to-file "hello there\n" tmp #:exists 'replace)
> #'(begin)))
> 
> (m)
> ;open-output-file: forbidden (write) access to
> ;/var/folders/6f/5335m44s43g1zd2vqs7jmqshgp/T/unsaved 
> editor-7-16_15411123141541112314481
> 
> Alex Knauth
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

Re: [racket-users] Doing file I/O from within a macro

[George Neuner]

On 11/1/2018 8:32 PM, Robby Findler wrote:
DrRacket disallows network and filesystem access during its online 
expansion. Partly for security reasons and partly because it seems 
unlikely that the code one writes that does that would be kill safe. 
You might be able to bike the abstractions you news via the FFI but I 
guess it will be hard to get right because DrRacket just kills off 
compilations effectively randomly.


Robby


Ah.   I knew the reason was that it was happening at compile time, but I 
didn't know it was deliberate for security.  Thanks for the insight.


George

--
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] Doing file I/O from within a macro

[Robby Findler]

DrRacket disallows network and filesystem access during its online
expansion. Partly for security reasons and partly because it seems unlikely
that the code one writes that does that would be kill safe. You might be
able to bike the abstractions you news via the FFI but I guess it will be
hard to get right because DrRacket just kills off compilations effectively
randomly.

Robby

On Thu, Nov 1, 2018 at 5:57 PM Alex Knauth  wrote:

> Is it possible to create a temporary file, write to it, run a command on
> it, and the possibly delete the file from within a macro? Or is it possible
> to run a command (as in `system`) in a context where it pretends that some
> file exists?
>
> And, how does this play with DrRacket's background expansion?
>
> The reason I'm thinking about this is that I want to call out to an
> external compiler (for a language other than racket, not implemented in
> racket), get information back from that compiler, and display that
> information in the form of DrRacket's mouse-over-tooltips.
>
> I tried this, and it said "forbidden (write) access" to the temporary file
> name that it generated. I get this error from DrRacket's background
> expansion.
>
> Is there a way to do this in a way I can use while generating DrRacket
> tooltips?
>
> #lang racket
> (require (for-syntax racket/file))
>
> (define-syntax m
>   (λ (stx)
> (define tmp (make-temporary-file))
> (display-to-file "hello there\n" tmp #:exists 'replace)
> #'(begin)))
>
> (m)
> ;open-output-file: forbidden (write) access to
> ;/var/folders/6f/5335m44s43g1zd2vqs7jmqshgp/T/unsaved
> editor-7-16_15411123141541112314481
>
> Alex Knauth
>
> --
> 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] Doing file I/O from within a macro

[George Neuner]

Hi Alex,


On 11/1/2018 6:57 PM, Alex Knauth wrote:
Is it possible to create a temporary file, write to it, run a command 
on it, and the possibly delete the file from within a macro? 


Yes it is possible [see below].  What you need to do depends on whether 
you want to keep the file open in Racket while the other process works 
on it.  You haven't said what OS, and there are significant differences 
between Windows and *nix with respect to sharing open files.


If you make sure to close the file before running your command, there 
will be no file sharing problems.



Or is it possible to run a command (as in `system`) in a context where 
it pretends that some file exists?


You can pass arguments to a program started using *system** or 
*process**.   If you need to capture output from the child, use 
*process*/ports*.




And, how does this play with DrRacket's background expansion?

The reason I'm thinking about this is that I want to call out to an 
external compiler (for a language other than racket, not implemented 
in racket), get information back from that compiler, and display that 
information in the form of DrRacket's mouse-over-tooltips.


I tried this, and it said "forbidden (write) access" to the temporary 
file name that it generated. I get this error from DrRacket's 
background expansion.


*make-temporary-file*  plays fine with macros.  It might be a problem 
for sharing an open file [possible the file is opened exclusive], but as 
long as you make sure the file is closed before you run the command on 
it, you should be fine.


Incidentally your code is failing because the file is being 
created/written at compile time, rather than when the macro is 
executed.  If you change it to something like:


(define-syntax m
  (lambda (stx)
 #'(let [
 (tmp (make-temporary-file))
    ]
   (display-to-file "hello there\n" tmp #:exists 'replace)
   )))

then it will run when *m*  actually is called.  If you add a line to 
display the path, you'll see the difference.



Is there a way to do this in a way I can use while generating DrRacket 
tooltips?


Sorry, this I don't know ... I have never tried to extend or tap into 
DrRacket.


George

--
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] Doing file I/O from within a macro

[Alex Knauth]

Is it possible to create a temporary file, write to it, run a command on it, 
and the possibly delete the file from within a macro? Or is it possible to run 
a command (as in `system`) in a context where it pretends that some file exists?

And, how does this play with DrRacket's background expansion?

The reason I'm thinking about this is that I want to call out to an external 
compiler (for a language other than racket, not implemented in racket), get 
information back from that compiler, and display that information in the form 
of DrRacket's mouse-over-tooltips.

I tried this, and it said "forbidden (write) access" to the temporary file name 
that it generated. I get this error from DrRacket's background expansion.

Is there a way to do this in a way I can use while generating DrRacket tooltips?

#lang racket
(require (for-syntax racket/file))

(define-syntax m
  (λ (stx)
(define tmp (make-temporary-file))
(display-to-file "hello there\n" tmp #:exists 'replace)
#'(begin)))

(m)
;open-output-file: forbidden (write) access to
;/var/folders/6f/5335m44s43g1zd2vqs7jmqshgp/T/unsaved 
editor-7-16_15411123141541112314481

Alex Knauth

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

[racket-users] Re: reporting contract violations in executable programs

[Alex Harsanyi]

On Thursday, November 1, 2018 at 7:38:29 PM UTC+8, Alexander McLin wrote:
>
> I’m a little confused here, to me it looks like the second contract 
> violation is completely different from the first one. 
>

My program is only seven lines of code and does not call `build-path`.  
Also, if I fix the incorrect call to `foo` and rebuild the executable, the 
`build-path` contract violation is no longer reported and the program runs 
fine.  You might wan to actually build the executable and run it using the 
instructions I provided, to understand what I am trying to explain.

#lang racket
(require racket/contract)

(define/contract (foo n)
  (-> integer? any/c)
  (printf "foo: ~a~%" n))

(module+ main
  (foo "hello"))

This is just a small example that illustrates the problem -- I have an 
actual application which is built into an executable and, whenever there is 
a contract violation error reported, regardless of what the contract 
violation is about, always the `build-path` contract violation shows up.  
At first, I was puzzled by this, but now, I have learned that when I see a 
build path contract error, I try to run the application in un-compiled mode 
(is there a better term?) and try to reproduce the issue -- but this is not 
always easy with complex applications.

Alex.


> You were expecting `foo` to raise a contract violation but in your 
> executable example it appears that contract violation is being raised by 
> the `build-path` function not `foo`. 
>
> Maybe it’s a entirely different error?

-- 
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] reporting contract violations in executable programs

[Alexander McLin]

I’m a little confused here, to me it looks like the second contract violation 
is completely different from the first one.

You were expecting `foo` to raise a contract violation but in your executable 
example it appears that contract violation is being raised by the `build-path` 
function not `foo`.

Maybe it’s a entirely different error?

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