Re: [racket-users] GUI for ffmpeg and mrlib/terminal

[Leif Andersen]

Well James, you're in luck.

The short answer is, yes, yes you can.  You should check out video at
http://lang.video (you can follow the progress either on the blog, the
twitter feed http://twitter.com/videolang , or on github itself:
https://github.com/videolang/video . Alternatively, you are welcome to
arrange a call with me some time so we can coordinate our efforts.


The (slightly) longer answer is: you can find the (private and thus
unstable) bindings here:
https://github.com/videolang/video/tree/master/video/private/ffmpeg;
and my (very early) prototype NLVE widgets here:
https://github.com/videolang/video/blob/master/video/private/editor.rkt.
In either case, contributions are absolutely welcome. Bug reports are
also welcome and very helpful.

I hope that helps, and feel free to ask any questions. If you are
interested in creating GUIs for Video editing we should also sit down
for a chat some time. (Either in person or via teleconference.)

Anyway, I hope you have a lovely day.

~Leif Andersen


On Tue, Aug 29, 2017 at 3:57 PM, James  wrote:
> I have been working through The Racket Graphical Interface Toolkit 
> documentation to learn GUI programming and I thought I would do a small but 
> useful project.  The idea is to make a simple GUI front end which will 
> formulate commands for ffmpeg to do various video and audio conversions on 
> selected files and then run those commands.  MrLib/terminal seems like just 
> the thing except there are various ways that it isn't as good as it could be 
> for this kind of project.   It's mostly small things, for example, the cancel 
> button is labeled "Abort Instillation" by default.  The one thing which is 
> not so simple is that it looks like it is intended to just run one command 
> and not create an interactive environment.  I was expecting to be able to 
> send commands to the terminal% object in order to run things one after 
> another.  Instead, you pass a function as a parameter when you create the 
> terminal% object and it just runs that function.  So, either I have to close 
> the terminal and open a new one each time I run a command or I suppose that I 
> could have the function work with a thread mailbox or channels so that I 
> could keep using it.  My question is whether MrLib Terminal the best option 
> for this kind of work or is there a better bet?
>
> https://docs.racket-lang.org/mrlib/Terminal_Window.html
>
> James
>
> --
> 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] pkgs.racket-lang.org log in is down

[Jack Firth]

On Tuesday, August 29, 2017 at 10:42:31 AM UTC-7, Tony Garnock-Jones wrote:
> It'd also be great for Racket in general to have better visibility into 
> running programs to see what's going wrong with them in situations like 
> this.

I think it's possible to do this with existing features and libraries. You 
could use a thread group[1] to make two sets of threads: one for normal user 
requests, and one for debugging and introspection requests from administrators. 
Then, if somehow the request threads got locked up on some CPU-bound infinite 
loop you could still handle debugging requests. A good debugging endpoint might 
be one that uses a statistical profiler[2] to get a sense of what the user 
request threads are doing. A package that provided some convenience wrappers 
around thread groups, the statistical profiler, and the web server library to 
automatically make such a debugging endpoint would be a good project for any 
web-oriented Racketeers out there.

[1] http://docs.racket-lang.org/reference/threadgroups.html
[2] http://docs.racket-lang.org/profile

-- 
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] GUI for ffmpeg and mrlib/terminal

[James]

I have been working through The Racket Graphical Interface Toolkit 
documentation to learn GUI programming and I thought I would do a small but 
useful project.  The idea is to make a simple GUI front end which will 
formulate commands for ffmpeg to do various video and audio conversions on 
selected files and then run those commands.  MrLib/terminal seems like just the 
thing except there are various ways that it isn't as good as it could be for 
this kind of project.   It's mostly small things, for example, the cancel 
button is labeled "Abort Instillation" by default.  The one thing which is not 
so simple is that it looks like it is intended to just run one command and not 
create an interactive environment.  I was expecting to be able to send commands 
to the terminal% object in order to run things one after another.  Instead, you 
pass a function as a parameter when you create the terminal% object and it just 
runs that function.  So, either I have to close the terminal and open a new one 
each time I run a command or I suppose that I could have the function work with 
a thread mailbox or channels so that I could keep using it.  My question is 
whether MrLib Terminal the best option for this kind of work or is there a 
better bet?

https://docs.racket-lang.org/mrlib/Terminal_Window.html

James

-- 
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] Style question: why is 'values' the identity function instead of 'identity'?

[Sam Tobin-Hochstadt]

`identity` is provided by `racket/function` for just this purpose. But
`values` is also there, and some people use it out of habit/tradition.

Sam

On Tue, Aug 29, 2017 at 2:19 PM, David Storrs  wrote:
> Title says it all; can anyone explain?
>
> I get that 'values' is variadic but I don't see the issue when you know that
> you're dealing with only one value -- e.g. in (map identity '(foo bar))  In
> such a case the name 'identity' seems much clearer.
>
> --
> 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: Library function naming

[Jeremiah Peschka]

I believe OP is referring to the paragraph about
play-with-frisky-with-laser being their default style and their sincere
recommendation for Racket code style.

It also seems to be the style that most closely matches core APIs.


On August 29, 2017 at 11:23:51, David Storrs (david.sto...@gmail.com) wrote:



On Tue, Aug 29, 2017 at 6:12 AM, Neil Van Dyke  wrote:

>
>
> (Of course, other general conventions also have their merits, in various
> languages and environments.  For example `FrskyLsr_szGetColor()`.  And
> `com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified
> form `play`.  What I mentioned above is my current default convention for
> Racket when I don't think of good reason to do it differently, and am not
> experimenting/playing with doing it differently as an exercise.)
>

Is this actually a sincere recommendation for Racket code?  Because,
personally, I think Java-style naming is an abomination before the Turing
and should be avoided at all costs.  Maybe that's just me, though.
--
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: Library function naming

[David Storrs]

On Tue, Aug 29, 2017 at 6:12 AM, Neil Van Dyke  wrote:

>
>
> (Of course, other general conventions also have their merits, in various
> languages and environments.  For example `FrskyLsr_szGetColor()`.  And
> `com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified
> form `play`.  What I mentioned above is my current default convention for
> Racket when I don't think of good reason to do it differently, and am not
> experimenting/playing with doing it differently as an exercise.)
>

Is this actually a sincere recommendation for Racket code?  Because,
personally, I think Java-style naming is an abomination before the Turing
and should be avoided at all costs.  Maybe that's just me, though.

-- 
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] Style question: why is 'values' the identity function instead of 'identity'?

[David Storrs]

Title says it all; can anyone explain?

I get that 'values' is variadic but I don't see the issue when you know
that you're dealing with only one value -- e.g. in (map identity '(foo
bar))  In such a case the name 'identity' seems much clearer.

-- 
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] Need help improving a macro

[Philip McGrath]

I would love to see some library provide better abstractions for fairly
common cases of keywords like this, but here is how I might write this:

#lang racket

(require (for-syntax syntax/parse
 syntax/define
 ))

(define-syntax (register-nvim-function! stx)
  (displayln stx)
  #`(begin))

(define-syntax (define-nvim-function stx)
  (define-syntax-rule (attr? kw pat-id)
(and (attribute pat-id) (list #'kw #'pat-id)))
  (define-splicing-syntax-class options
#:attributes (name [opt 1])
(pattern (~seq (~alt (~once (~seq #:name name:expr))
 (~optional (~seq #:range range?:expr))
 (~optional (~seq #:eval eval?:expr))
 (~optional (~seq #:sync sync?:expr)))
   ...)
 #:with (opt ...)
 #`(#,@(for*/list ([clause (in-list
(list (attr? #:range range?)
  (attr? #:eval eval?)
  (attr? #:sync sync?)))]
   #:when clause
   [term (in-list clause)])
 term
  (syntax-parse stx
[(_ raw-lhs:expr opts:options
body:expr ...+)
 #:do [(define-values (ident-stx rhs-stx)
 (normalize-definition #'(define raw-lhs body ...)
   #'λ
   #t
   #t))]
 #:with ident ident-stx
 #:with rhs rhs-stx
 #'(begin
 (define ident rhs)
 (register-nvim-function! ident opts.name opts.opt ...))]))

(define-nvim-function (foo bar baz) #:name "foo" #:sync #f
  (display bar)
  (display baz))

You would probably then want to add contracts using `expr/c`.

I also wonder if you really want to have a mandatory "name" argument or if
you should infer it based on the identifier being defined (perhaps with an
option to override).

-Philip

On Tue, Aug 29, 2017 at 11:27 AM,  wrote:

> Hello,
>
> I have a working macro written using `syntax-parse`, but it still has
> some kinks that need to be worked out. What I want the macro to do is
> define a function and as it as input to another function. Example:
>
>   (define-nvim-function (foo bar baz) #:name "foo" #:sync #f
> (display bar)
> (display baz))
>
> This would expand to
>
>   (define (foo bar baz)
> (display bar)
> (display baz))
>   (register-nvim-function! foo "foo" #:sync #f)
>
> The `register-nvim-function!` function is defined like this:
>
>   (define (register-nvim-function! proc name
>#:range [range #f]
>#:eval  [eval  (void)]
>#:sync  [sync? #f])
> ...)
>
> The point is that `proc` and `name` are mandatory, but the keyword
> arguments are optional. I want the keyword arguments of the macro to be
> optional as well, except for the name, and their order should not
> matter. Here is what I got so far:
>
>
>   (define-syntax (define-nvim-function stx)
> (syntax-parse stx
>   [(define-function (head:id arg-id:id ...)
> (~alt (~once (~seq #:name name:expr)
>  #:name "#:name name")
>   (~optional (~seq #:range range:expr)
>  #:name "#:range range"
>  #:defaults ([range #'#f]))
>   (~optional (~seq #:eval eval:expr)
>  #:name "#:eval eval"
>  #:defaults ([eval #'(void)]))
>   (~optional (~seq #:sync sync?:expr)
>  #:name "#:sync sync?"
>  #:defaults ([sync? #'#f])))
> ...
>  body:expr ...+)
>#'(define-function head #:name name #:range range #:eval eval
> #:sync sync?
>(λ (arg-id ...) body ...)) ]
>   [(define-function head:id
> (~alt (~once (~seq #:name name:expr)
>  #:name "#:name name")
>   (~optional (~seq #:range range:expr)
>  #:name "#:range range"
>  #:defaults ([range #'#f]))
>   (~optional (~seq #:eval eval:expr)
>  #:name "#:eval eval"
>  #:defaults ([eval #'(void)]))
>   (~optional (~seq #:sync sync?:expr)
>  #:name "#:sync sync?"
>  #:defaults ([sync? #'#f])))
> ...
>  

Re: [racket-users] pkgs.racket-lang.org log in is down

[Tony Garnock-Jones]

Thanks, Philip -- I've restarted the server. We need better monitoring 
for it, but I don't have the time to fix it at the moment.


It'd also be great for Racket in general to have better visibility into 
running programs to see what's going wrong with them in situations like 
this.


All I could see was an unresponsive service that hadn't logged anything 
for about a day that was using 100% CPU. What was it doing? No way to tell!


Erlang gets this right: you can connect to a running system and see what 
it is doing.


Does Chez have anything to contribute here? Could Racket-on-Chez help me 
diagnose a mysterious silent inert 100% CPU program?


Tony



On 8/28/17 5:58 PM, Philip McGrath wrote:
Attempting to log in to pkgs.racket-lang.org 
 fails with a 503 Proxy Error:



  Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request /GET /pkgn/login 
/.


Reason: *Error reading from remote server*


Apache/2.4.7 (Ubuntu) Server at pkgd.racket-lang.org 
 Port 443


--
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: Library function naming

[Greg Hendershott]

It's also worth considering that you can munge the names when you
provide -- and your users can munge them on require.

See filtered-out and filtered-in -- as well as the more commonly used
conveniences built on them, like prefix-{in out}, rename-{in out}, and
so on.


I think sometimes the goodness of a name can depend on the context
where it's being used.

If I'm implementing functions in money.rkt, it might be tedious to
have "money- money- money- money-" everywhere. The low signal:noise
ratio might detract from readability. Might cause expressions not to
fit on one line. And so on. If that bothers me, I can name functions
deposit and convert, and (provide (prefix-out money- deposit convert)
so users see money-deposit, money-convert.

It's also an interesting option to provide just the short names
deposit and convert, and assume that users will (require (prefix-in
money- "money.rkt")) -- or whatever prefix they want. Although this is
idiomatic in some langs/communities, it's not AFAICT in Racket.

Fortunately Racket makes it easy to adapt provided and required names.

-- 
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] Need help improving a macro

[hiphish]

Hello,

I have a working macro written using `syntax-parse`, but it still has
some kinks that need to be worked out. What I want the macro to do is
define a function and as it as input to another function. Example:

  (define-nvim-function (foo bar baz) #:name "foo" #:sync #f
(display bar)
(display baz))

This would expand to

  (define (foo bar baz)
(display bar)
(display baz))
  (register-nvim-function! foo "foo" #:sync #f)

The `register-nvim-function!` function is defined like this:

  (define (register-nvim-function! proc name
   #:range [range #f]
   #:eval  [eval  (void)]
   #:sync  [sync? #f])
...)

The point is that `proc` and `name` are mandatory, but the keyword
arguments are optional. I want the keyword arguments of the macro to be
optional as well, except for the name, and their order should not
matter. Here is what I got so far:


  (define-syntax (define-nvim-function stx)
(syntax-parse stx
  [(define-function (head:id arg-id:id ...)
(~alt (~once (~seq #:name name:expr)
 #:name "#:name name")
  (~optional (~seq #:range range:expr)
 #:name "#:range range"
 #:defaults ([range #'#f]))
  (~optional (~seq #:eval eval:expr)
 #:name "#:eval eval"
 #:defaults ([eval #'(void)]))
  (~optional (~seq #:sync sync?:expr)
 #:name "#:sync sync?"
 #:defaults ([sync? #'#f])))
...
 body:expr ...+)
   #'(define-function head #:name name #:range range #:eval eval #:sync 
sync?
   (λ (arg-id ...) body ...)) ]
  [(define-function head:id
(~alt (~once (~seq #:name name:expr)
 #:name "#:name name")
  (~optional (~seq #:range range:expr)
 #:name "#:range range"
 #:defaults ([range #'#f]))
  (~optional (~seq #:eval eval:expr)
 #:name "#:eval eval"
 #:defaults ([eval #'(void)]))
  (~optional (~seq #:sync sync?:expr)
 #:name "#:sync sync?"
 #:defaults ([sync? #'#f])))
...
 body:expr)
   #'(begin
   (define head body)
   (register-function! head name #:range range #:eval eval #:sync 
sync?))]))

The macros supports two variants, similar to how `define` allows two
ways of defining a function. The problems with this implementation are:

- The giant blob of keyword arguments is repeated twice
- The template is listing all the keyword arguments the function can
  take

I was thinking of a macro more like this:

  (define-syntax (define-nvim-function stx)
(define-splicing-syntax-class option
  (pattern (#:namename:expr))
  (pattern (#:range range?:expr))
  (pattern (#:eval   eval?:expr))
  (pattern (#:sync   sync?:expr)))
(syntax-parse stx
  [(define-function (head:id arg-id:id ...) option:option ...
 body:expr ...+)
   #'(define-function head option ...
   (λ (arg-id ...) body ...)) ]
  [(define-function head:id option.option ...
 body:expr)
   #'(begin
   (define head body)
   (register-function! head option))]))

This won't work though. First I lose the optional/unique specifications
from above, second the keyword-value pairs are wrapped in parentheses
for some reason. Expansion becomes

  (register-function! foo (#:name "foo") (#:sync #f))
  ;; instead of
  (register-function! foo #:name "foo" #:sync #f)

What am I doing wrong here? I have a pretty solid grasp of Racket thanks
to the great guide, but when it comes to macros I am still totally lost.

-- 
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: Library function naming

[Laurent]

On Tue, Aug 29, 2017 at 11:12 AM, Neil Van Dyke 
wrote:

>
> (Someday, I will have time to release a package that changes how
> `define-struct`/`struct` identifiers are generated, to use `.` or `:`.  To
> at least have the appearance of being more idiomatic, to hint at the
> various other specialness, and to avoid the frequent naming collisions when
> you want to provide encapsulating behavior around struct field accessors.)
>
>
+1!

-- 
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: Library function naming

[Neil Van Dyke]

I recommend trying to develop most non-core Racket modules as if you 
might want to share them as small reusable third-party open source 
packages in the near future.  Which has implications for naming.


For reusable third-party Racket packages, right now, I recommend usually 
trying to include the package name (or at least a noun or verb part of a 
package name) in each identifier provided by the package.  (This isn't a 
perfect approach considering of a large distributed flat namespace of 
provides of all the third-party packages, and you don't have to do it 
every time, but I think it's usually pretty good balance of a number of 
goals.)


Also, for other reasons, consider making provided procedures named as 
English sentences.  (Remember that Racket procedures are evaluated 
imperatively.)


For example, If your package is named `frisky` (a cat), you might 
provide procedures such as `feed-frisky`, `display-frisky`, and 
`animate-frisky`.


For another example, let's say someone else makes a package that 
augments package `frisky`, and calls their package `frisky-laser`, and 
might provide procedures like `play-with-frisky-with-laser`.


This reduces name collisions, often reads pretty easily, is a good 
convention to pick for naming consistency, and gives some imperfect 
sense of various identifiers' packages when glancing at a block of 
reusing code.


(Of course, other general conventions also have their merits, in various 
languages and environments.  For example `FrskyLsr_szGetColor()`.  And 
`com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified 
form `play`.  What I mentioned above is my current default convention 
for Racket when I don't think of good reason to do it differently, and 
am not experimenting/playing with doing it differently as an exercise.)


(Someday, I will have time to release a package that changes how 
`define-struct`/`struct` identifiers are generated, to use `.` or `:`.  
To at least have the appearance of being more idiomatic, to hint at the 
various other specialness, and to avoid the frequent naming collisions 
when you want to provide encapsulating behavior around struct field 
accessors.)


--
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: Library function naming

[Laurent]

The style guide Jack mentions is not really about the /library's/ name, but
rather about the data type of the main (usually the first) argument, as
saide. For example you could have a library called `my-wonderful-lib' that
experts `vector-splendify', which takes a vector as its first argument.

On Mon, Aug 28, 2017 at 10:26 PM, Jack Firth  wrote:

> The Racket Style Guide[1] has some notes about this in the Textual
> Matters: Names[2] section:
>
> > Use meaningful names. The Lisp convention is to use full English words
> separated by dashes. Racket code benefits from the same convention.
> > Note that _ (the underline character) is also classified as bad
> Racketeering within names. It is an acceptable placeholder in syntax
> patterns, match patterns, and parameters that don’t matter.
> > Another widely used convention is to prefix a function name with the
> data type of the main argument. This convention generalizes the
> selector-style naming scheme of struct.
>
> So yes, if you were to write a `money` library many Racketeers would
> expect it to export functions like `money-deposit` and `money-convert`.
> This has the advantage that searching "money" in Scribble will give a quick
> list of the exports of "money", since they'll all have the prefix. This
> isn't a hard and fast rule, merely a guideline.
>
> [1] http://docs.racket-lang.org/style/index.html
> [2] http://docs.racket-lang.org/style/Textual_Matters.html#%
> 28part._names%29
>
> --
> 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.