[racket-users] Racket News - Issue 11

['Paulo Matos' via Racket Users]

The big 11 is here! :)

https://racket-news.com/2019/07/racket-news-issue-11.html

Enjoy, preferably with a strong espresso!
-- 
Paulo Matos

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/1b61022f-c146-a0cb-d445-891d8d9f4bae%40linki.tools.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program

[Thomas Dickerson]

On Mon, Jul 1, 2019 at 2:23 PM Philip McGrath 
wrote:

>
> I believe the main submodule will still be compiled the enclosing module
> is loaded from source, but that should be trivial: it really only needs a
> `require` and a function call. If the file has already been compiled to
> bytecode, the bytecode for the main submodule won't be loaded, nor for any
> of its transitive dependencies.
>
> Depending on how you are distributing your code, you may or may not want
> to add an indirection via `dynamic-require` to prevent the distribution
> building tools from shipping graphics libraries that you only need for the
> main submodule. (Basically this would be the reverse of what
> `racket/runtime-path` does.) I haven't done much with the tools for
> distributing built artifacts beyond toy experiments, but I think some of
> them may be able to do that stripping automatically or with e.g. a
> command-line flag, without needing a `dynamic-require`. At the maximum, you
> could put the graphics modules in their own package, analogous to the
> `foo`+`foo-lib`+`foo-doc`+`foo-test` convention: in that case, the support
> library for your main submodule (what I called
> `hypothetical-lanugage/private/render`) would just be a stub to
> `dynamic-require` the `render` function or do something useful if the
> graphics package isn't installed, like print a message to standard error.
>

I'll chew on this, but if the dependencies for the main submodule need to
be available at the time that it is compiled, then the easiest thing may
just be doing a dynamic-require.


>  I haven't used OpenGL, from Racket or otherwise, but it might be possible
> to use a bitmap from `make-gl-bitmap` as a buffer for your OpenGL drawing
> and copy it to the canvas via `draw-bitmap`. If you have an existing
> foreign library that does the actual drawing, you can get a
> platform-specific pointer via `gl-context<%>
> `.
>

That's an interesting possibility, and I shouldn't actually need the
gl-context pointer, just to make it current before calling the foreign
rendering code.


>  I suspect, though, that a solution would involve your support library
> cooperating with an extension set up by your #lang.
>
Right, this is what we originally hand in mind.


> On the whole, though, either returning a snip or creating a new `frame%`
> would probably be easier. Using a new `frame%` would also be entirely
> independent of DrRacket: I expect it would work with racket-mode for Emacs,
> for example.
>
frame% is portable, but also not a very nice UI. I'll see what can be done
with a snip.

On Mon, Jul 1, 2019 at 2:56 PM Robby Findler 
wrote:

> I think I'm missing a bit more context so I'll continue this line of
> questions. The path that you seem to be heading down seems to be one
> where you'll duplicate a lot of work that's already gone into
> DrRacket, and it seems unlikely to me that it is the most productive


Perhaps you could elaborate on the mechanisms you think we would be
duplicating, because those may provide either the entry points we're
looking for, or clarify a potential miscommunication on our end.


> Can you say a little more about what you want to do with DrRacket?


Currently, most of our DSL programs are constructed automatically from
inferred geometry, and it's fine, because an artist/programmer doesn't need
to do any design work.
Going forward, we would like to also be able to model reusable parametric
object classes that we can plug in to our scenes, and here it would be very
helpful to be able to visualize the geometry generated by our DSL programs
interactively.
Rather than reinventing the wheel, and writing our own editor, we would
like to bend DrRacket to our will for that purpose; however, the current
"Run" button doesn't seem like quite the right UI for that.

Do you expect to be able to run these programs? If so, does it
> make sense to run them when you aren't in the
> embedded-in-the-huge-C++-code-base mode? How about compilation of the
> programs (i.e. macro expansion)?


We've essentially phase shifted everything, so that Racket's Phase 0 is
really Phase 1 in a DSL library implemented with C++, which provides our
"core language", so the result of "running" the Racket program is a pointer
to an opaque C++ type which represents the fully expanded syntax for our
program, ready to be evaluated by the C++ geometry library.
Racket's Phase 1 handles type checking + inference of the surface language,
converting pretty surface syntax into a lot of horrific FFI code, and
providing a consistent API to the resulting modules to make it easy to grab
the C++ representation of the DSL program.

We currently can then either just run this as a Racket program, which
works, but is basically useless, *or* further stuff the Racket interpreter
into a C++ library for reading, writing, and executing our DSL programs
from elsewhere in the C++ code base. We would like to have a third option
which 

[racket-users] Drracket windows installation without admin rights

[François Lapeyrère]

Hi,

Is it possible to install Drracket on Windows without admin rights ?

Actually I also installed the Minimal Racket but I could not get to install 
Drracket from there.

Any help will be appreciated.


Regards,

François

-- 
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/ee181e67-8bcb-43bd-bd7b-c1b844380f0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Working examples of embedding Racket?

[John Williams]

I'm trying to embed Racket in a C program (Emacs, to be precise), but I'm 
running into a lot of trouble. When I try to link against libracket3m.a, 
the linker complains about undefined references to a bunch of symbols 
starting with rktio_. I tried using the Ubuntu version of Racket as well as 
the version in the PPA, and the results were the same for both. I 
downloaded the latest binary distro for Linux from racket-lang.org, and it 
also doesn't seem to include any library that defines those symbols. I also 
tried building Vim with Racket support, since it's the only example I could 
find of a program that embeds Racket, but I ran into the same issues.

I was able to find the definitions by building Racket myself, but since the 
definitions aren't included in any library that's part of a regular Racket 
distribution, it seems like the distributed libracket3m.a is pretty 
useless. Am I missing something, or is the distro broken for embedding?

-- 
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/ef326b39-1131-4bf9-949c-62077efd5ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program

[Robby Findler]

On Mon, Jul 1, 2019 at 10:40 AM Thomas Dickerson
 wrote:
> On Sun, Jun 30, 2019 at 11:44 AM Robby Findler  
> wrote:
>>
>> May I ask why you need to have the C++ code embed Racket instead of
>> the other way around (ie using the FFI)?
>
>
> The short answer is this project is a very small part of a very large 
> enterprise C++ code base, and it's not reasonable to rewrite every single 
> program in our toolkit that needs to interact with our DSL to be a dynamic 
> library with a Racket front-end.

I think I'm missing a bit more context so I'll continue this line of
questions. The path that you seem to be heading down seems to be one
where you'll duplicate a lot of work that's already gone into
DrRacket, and it seems unlikely to me that it is the most productive.

Can you say a little more about what you want to do with DrRacket? I
guess there will be some program in your DSL that you'll want to work
with. Do you expect to be able to run these programs? If so, does it
make sense to run them when you aren't in the
embedded-in-the-huge-C++-code-base mode? How about compilation of the
programs (i.e. macro expansion)?

Robby

-- 
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/CAL3TdOO4pm3N%3DyzDdyuyVO-yBk2L5YF%3DFmnb-HwuBFpn%2BDcs_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program

[Philip McGrath]

On Mon, Jul 1, 2019 at 11:40 AM Thomas Dickerson <
thomas_dicker...@alumni.brown.edu> wrote:

> On Fri, Jun 28, 2019 at 5:50 PM Philip McGrath 
> wrote:
>
>> Again, this part works just fine. In particular, because of the way Racket's
>> submodules
>> 
>> work, the code in the "main" submodule *does not* run when you
>> instantiate the parent module, whether via `scheme_dynamic_require`,
>> `dynamic-require`, `require`, or some other way: the compiled form of the
>> submodule need not even be loaded into memory. So you can use rendering
>> code in the main submodule without creating a dependency for your main
>> application.
>>
>
> Specifically, this means we can avoid byte-compiling and loading any
> graphics modules the main submodule depends on, yes?
>

I believe the main submodule will still be compiled the enclosing module is
loaded from source, but that should be trivial: it really only needs a
`require` and a function call. If the file has already been compiled to
bytecode, the bytecode for the main submodule won't be loaded, nor for any
of its transitive dependencies.

Depending on how you are distributing your code, you may or may not want to
add an indirection via `dynamic-require` to prevent the distribution
building tools from shipping graphics libraries that you only need for the
main submodule. (Basically this would be the reverse of what
`racket/runtime-path` does.) I haven't done much with the tools for
distributing built artifacts beyond toy experiments, but I think some of
them may be able to do that stripping automatically or with e.g. a
command-line flag, without needing a `dynamic-require`. At the maximum, you
could put the graphics modules in their own package, analogous to the
`foo`+`foo-lib`+`foo-doc`+`foo-test` convention: in that case, the support
library for your main submodule (what I called
`hypothetical-lanugage/private/render`) would just be a stub to
`dynamic-require` the `render` function or do something useful if the
graphics package isn't installed, like print a message to standard error.


> It could certainly open a new GUI window, and it could also return a value
>> that renders as an embedded widget (snip) in the interactions pane. (See
>> the plot library for an example.)
>>
>
> Snips seem nice, but even browsing through the source for the 3d renderers
> for plot, I don't see any way to get an OpenGL context for a snip, since
> they appear to work on predefined DCs, rather than allowing you to
> construct a canvas.
>

I haven't used OpenGL, from Racket or otherwise, but it might be possible
to use a bitmap from `make-gl-bitmap` as a buffer for your OpenGL drawing
and copy it to the canvas via `draw-bitmap`. If you have an existing
foreign library that does the actual drawing, you can get a
platform-specific pointer via `gl-context<%>
`.


> I haven't looked at the DrRacket extension APIs enough to be sure whether
>> you could open a new pane in the DrRacket window, but it certainly seems
>> possible.
>>
>
> Are you aware of any projects that usefully manipulate the interactions
> pane that I could turn to for example code? It looks like it's possible to
> extend that class.
>

I can't think of any examples that manipulate the DrRacket window from
within the program being evaluated. In general, DrRacket goes to a lot of
effort to isolate itself from the programs it runs, which is usually a good
thing. I suspect, though, that a solution would involve your support
library cooperating with an extension set up by your #lang. Communication
might need to go through a non-obvious channel like a logger: Alexis has a blog
post

about a wonderfully devious use for loggers as a communication mechanism,
but they're also used less deviously by e.g. the Future Visualizer

.

On the whole, though, either returning a snip or creating a new `frame%`
would probably be easier. Using a new `frame%` would also be entirely
independent of DrRacket: I expect it would work with racket-mode for Emacs,
for example.

-Philip

-- 
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/CAH3z3gY0qEB6VyR5xgT83aNgevSjzjMnvznFRVgSF5%2BGHrwpdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Language-Specific Plugins: Toolbar button functionality to call drracket:eval:expand-program

[Thomas Dickerson]

Thanks for the responses.

On Fri, Jun 28, 2019 at 5:50 PM Philip McGrath 
wrote:

> If you're sure you want to get the raw program source and deal with it
> manually, you can use the method `get-definitions-text
> `
> on the DrRacket frame given as an argument to your button's callback
> function. This will give you the editor object for the definitions window.
> You can then use a method like `get-flattened-text
> `
> to get the source as a sting or (probably better) the function `
> open-input-test-editor
> `
> to get an input port directly.
>

This is very helpful, thanks.


> Again, this part works just fine. In particular, because of the way Racket's
> submodules
> 
> work, the code in the "main" submodule *does not* run when you
> instantiate the parent module, whether via `scheme_dynamic_require`,
> `dynamic-require`, `require`, or some other way: the compiled form of the
> submodule need not even be loaded into memory. So you can use rendering
> code in the main submodule without creating a dependency for your main
> application.
>

Specifically, this means we can avoid byte-compiling and loading any
graphics modules the main submodule depends on, yes?


> It could certainly open a new GUI window, and it could also return a value
> that renders as an embedded widget (snip) in the interactions pane. (See
> the plot library for an example.)
>

Snips seem nice, but even browsing through the source for the 3d renderers
for plot, I don't see any way to get an OpenGL context for a snip, since
they appear to work on predefined DCs, rather than allowing you to
construct a canvas.


> I haven't looked at the DrRacket extension APIs enough to be sure whether
> you could open a new pane in the DrRacket window, but it certainly seems
> possible.
>

Are you aware of any projects that usefully manipulate the interactions
pane that I could turn to for example code? It looks like it's possible to
extend that class.


On Sun, Jun 30, 2019 at 11:44 AM Robby Findler 
wrote:

> May I ask why you need to have the C++ code embed Racket instead of
> the other way around (ie using the FFI)?


The short answer is this project is a very small part of a very large
enterprise C++ code base, and it's not reasonable to rewrite every single
program in our toolkit that needs to interact with our DSL to be a dynamic
library with a Racket front-end.


> Generally speaking, DrRacket (and other Racket tools) are going to work
> better if they get to
> "drive", I expect.


Thankfully we're not trying to embed DrRacket - our applications are
primarily command-line driven, so the editor enhancements are just for
artist convenience.

The rest of the time, Racket happily sits in its own stack
,
and has no idea we've embedded in it (although since the time that was
written, the Boost Coroutines library was deprecated, so we built our own
).

-- 
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/CA%2BHWosX%2BcPFjOTuKT6iWHoJh3M93fdOfYBijQedfkBkJszRxGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] resources on PL design

[Neil Van Dyke]

That entire famous Smalltalk issue of Byte magazine is now online, as 
good-quality scans, so you can read all the articles, and juxtaposed 
with ads of a magazine of the time:


https://archive.org/details/byte-magazine-1981-08

This was before my time, and, when I was reading this issue recently, I 
was struck by the effort that PARC made to reach out to mainstream 
industry practitioners and enthusiasts.


This was shortly before the home microcomputer explosion, when everyone 
ended up getting BASIC instead of Smalltalk.  (Though you could see a 
lot of interest in education, even with some of the nice BASIC books 
some vendors bundled with each computer, but not all the various PARC 
goodness.)


We did get the Macintosh a few years later, though it was out of the 
budgets of many people, and it didn't adopt a lot of the PARC thinking.


--
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/e9f64383-a795-9ead-fdf9-42e2c53e74db%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: resources on PL design

[Neil Van Dyke]

(This is a resend.)

Lots of earlier HOPL papers are experience writeups relevant to the 
question of PL design.  (For example, Alan Kay did a great history of 
Smalltalk, which talks about more than just the language design itself, 
and the language design was influenced by the other things.)


Separate from what's in HOPL, there are other related writeups floating 
around.  Most recently, I saw Kent Pitman did an interesting one on 
Common Lisp standardization (you'd also want look at whatever Guy Steele 
says about that, John McCarthy's HOPL on Lisp in general, and various 
other Lisp people's reports): 
http://www.nhplace.com/kent/Papers/cl-untold-story.html


Closer to home, there's Scheme.  I don't know all that's currently 
written up about Scheme history (and it's ongoing, including with RnRS 
and various implementations), but most of the players are still around, 
and they should probably be encouraged to write if they haven't 
already.  Olin Shivers wrote an account of T: 
http://www.paulgraham.com/thist.html


Then there's various papers and writeups on other Lisps (Clojure, Arc, 
Dylan, more researchy), which might be interesting in what they chose to 
change (not just added features), and why.


Separate from PL histories, and various models of computation, I think 
we start to get into human issues like linguistics and aesthetics, and I 
don't think that's well-understood in PL, nor does it seem to be the 
same for everyone.  (For example, simply from looking at how people use 
Racket syntax, put roughly, it looks like some people seem to use visual 
while others seem purely verbal or mathematical; what happens when 
someone from one of those categories tries to design an intuitive or 
convenient language for everyone, but everyone isn't processing the 
language the same way?)


--
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/c56674e0-d5a7-c128-383c-1f88531d635a%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: resources on PL design

[Neil Van Dyke]

Lots of earlier HOPL papers are experience writeups relevant to the 
question of PL design.  (For example, Alan Kay did a great history of 
Smalltalk, which talks about more than just the language design itself, 
and the language design was influenced by the other things.)


Separate from what's in HOPL, there are other related writeups floating 
around.  Most recently, I saw Kent Pitman did an interesting one on 
Common Lisp standardization (you'd also want look at whatever Guy Steele 
says about that, John McCarthy's HOPL on Lisp in general, and various 
other Lisp people's reports): 
http://www.nhplace.com/kent/Papers/cl-untold-story.html


Closer to home, there's Scheme.  I don't know all that's currently 
written up about Scheme history (and it's ongoing, including with RnRS 
and various implementations), but most of the players are still around, 
and they should probably be encouraged to write if they haven't 
already.  Olin Shivers wrote an account of T: 
http://www.paulgraham.com/thist.html


Then there's various papers and writeups on other Lisps (Clojure, Arc, 
Dylan, more researchy), which might be interesting in what they chose to 
change (not just added features), and why.


Separate from PL histories, and various models of computation, I think 
we start to get into human issues like linguistics and aesthetics, and I 
don't think that's well-understood in PL, nor does it seem to be the 
same for everyone.  (For example, simply from looking at how people use 
Racket syntax, put roughly, it looks like some people seem to use visual 
while others seem purely verbal or mathematical; what happens when 
someone from one of those categories tries to design an intuitive or 
convenient language for everyone, but everyone isn't processing the 
language the same way?)


--
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/8cab8e8a-593e-a7d2-fa56-ef9b163503c5%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.