Re: [racket-users] IMAP with racket

[Tim Hanson]

hi, I'm finally finding time to dig into this a little and have a question about

  
https://docs.racket-lang.org/net/imap.html#%28def._%28%28lib._net%2Fimap..rkt%29._imap-port-number%29%29

Does this make imap-port-number a kind of global variable? My naive view is it 
would be somewhat friendlier to make it an optional parameter to imap-connect 
along the lines of

  [ #:tls? tls?  
#:try-tls? try-tls?]

but defaulting to 143. 

Does it become an attribute of an open imap-connection or does it remain a 
global, say if I hypothetically had two imap-connections going at once? 

I will experiment and maybe learn more, but thought I'd ask about this in the 
meantime.

Cheers,

Tim

-- 
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] How to implement a dynamic plugin system?

[Laurent]

There's also a plugin system in MrEdDesigner based on the directory
structure to load various widgets at runtime:
https://github.com/Metaxal/MrEd-Designer/blob/master/mred-designer/plugin.rkt
https://github.com/Metaxal/MrEd-Designer/blob/master/mred-designer/mred-plugin.rkt
https://github.com/Metaxal/MrEd-Designer/wiki/Developer%27s-Documentation

HTH,
Laurent

On Tue, Feb 7, 2017 at 2:36 PM, Matthias Felleisen 
wrote:

>
> Erich, your needs sound very much like those of DrRacket’s.
> You may wish to study how DrRacket loads tools (as in take
> a look at the source) — Matthias
>
>
>
>
>
> > On Feb 7, 2017, at 9:31 AM, Erich Rast  wrote:
> >
> > Thanks for the advice. So I should use dynamic-require, but how? When I
> > tried to use it like "require" it didn't have the desired effect -
> > nothing was imported. I have to admit I'm struggling a bit with all the
> > different ways of load/eval/require/enter code that I've found in
> > the docs so far.
> >
> > Here is a more concrete example of what I'd like to achieve:
> >
> > (require racket/gui/base
> > gregor
> > (prefix-in internat: "../core/internat.rkt")
> > (prefix-in pref: "../core/prefs.rkt")
> > (prefix-in db: "../core/dbaccess.rkt")
> > (prefix-in dates: "../core/dates.rkt")
> > (prefix-in metafonts: "../core/metafonts.rkt")
> > (prefix-in threaded: "../core/threaded.rkt")
> > (prefix-in console: "console.rkt")
> > "../notetaker/notetaker-main.rkt")
> >
> > I'd like the last require to be dynamic, loaded at runtime from a
> > relative directory and just-in-time compiled or compiled to disk on
> > demand. "notetaker-main.rkt" needs to obtain all definitions from the
> > previous imports (with the prefixes), and the current module needs to
> > obtain notetaker-main.rkt's exports - in this case a 'notes-panel%, for
> > instance. This also needs to work in a compiled application created
> > with "Create Executable ...>Distribution" from the Racket menu.
> >
> > How would I go about that? Is it very complicated?
> >
> > If it's very complicated, maybe I should abandon the idea. But it would
> > be neat, because the main application is really just a tab panel with
> > many independent subcomponents as panel% classes.
> >
> > Best,
> >
> > Erich
> >
> >
> >
> >
> > On Tue, 7 Feb 2017 20:05:03 +0800
> > WarGrey Gyoudmon Ju  wrote:
> >
> >> I think you can check the source of `raco` which uses the `info.rkt`
> >> to search all subcommands(see `racket/getinfo`). In this way, all
> >> plugins are just normal packages, you do not have to reside them is a
> >> specific directory. Certainly, the plugin is loaded via
> >> `dynamic-require`, if the plugin needs the imports of main
> >
> > --
> > 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] How to implement a dynamic plugin system?

[Matthias Felleisen]

Erich, your needs sound very much like those of DrRacket’s. 
You may wish to study how DrRacket loads tools (as in take 
a look at the source) — Matthias





> On Feb 7, 2017, at 9:31 AM, Erich Rast  wrote:
> 
> Thanks for the advice. So I should use dynamic-require, but how? When I
> tried to use it like "require" it didn't have the desired effect -
> nothing was imported. I have to admit I'm struggling a bit with all the
> different ways of load/eval/require/enter code that I've found in
> the docs so far.
> 
> Here is a more concrete example of what I'd like to achieve:
> 
> (require racket/gui/base
> gregor
> (prefix-in internat: "../core/internat.rkt")
> (prefix-in pref: "../core/prefs.rkt")
> (prefix-in db: "../core/dbaccess.rkt")
> (prefix-in dates: "../core/dates.rkt")
> (prefix-in metafonts: "../core/metafonts.rkt")
> (prefix-in threaded: "../core/threaded.rkt")
> (prefix-in console: "console.rkt")
> "../notetaker/notetaker-main.rkt")
> 
> I'd like the last require to be dynamic, loaded at runtime from a
> relative directory and just-in-time compiled or compiled to disk on
> demand. "notetaker-main.rkt" needs to obtain all definitions from the
> previous imports (with the prefixes), and the current module needs to
> obtain notetaker-main.rkt's exports - in this case a 'notes-panel%, for
> instance. This also needs to work in a compiled application created
> with "Create Executable ...>Distribution" from the Racket menu.
> 
> How would I go about that? Is it very complicated? 
> 
> If it's very complicated, maybe I should abandon the idea. But it would
> be neat, because the main application is really just a tab panel with
> many independent subcomponents as panel% classes.
> 
> Best,
> 
> Erich
> 
> 
> 
> 
> On Tue, 7 Feb 2017 20:05:03 +0800
> WarGrey Gyoudmon Ju  wrote:
> 
>> I think you can check the source of `raco` which uses the `info.rkt`
>> to search all subcommands(see `racket/getinfo`). In this way, all
>> plugins are just normal packages, you do not have to reside them is a
>> specific directory. Certainly, the plugin is loaded via
>> `dynamic-require`, if the plugin needs the imports of main
> 
> -- 
> 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] How to implement a dynamic plugin system?

[Erich Rast]

Thanks for the advice. So I should use dynamic-require, but how? When I
tried to use it like "require" it didn't have the desired effect -
nothing was imported. I have to admit I'm struggling a bit with all the
different ways of load/eval/require/enter code that I've found in
the docs so far.

Here is a more concrete example of what I'd like to achieve:

(require racket/gui/base
 gregor
 (prefix-in internat: "../core/internat.rkt")
 (prefix-in pref: "../core/prefs.rkt")
 (prefix-in db: "../core/dbaccess.rkt")
 (prefix-in dates: "../core/dates.rkt")
 (prefix-in metafonts: "../core/metafonts.rkt")
 (prefix-in threaded: "../core/threaded.rkt")
 (prefix-in console: "console.rkt")
 "../notetaker/notetaker-main.rkt")

I'd like the last require to be dynamic, loaded at runtime from a
relative directory and just-in-time compiled or compiled to disk on
demand. "notetaker-main.rkt" needs to obtain all definitions from the
previous imports (with the prefixes), and the current module needs to
obtain notetaker-main.rkt's exports - in this case a 'notes-panel%, for
instance. This also needs to work in a compiled application created
with "Create Executable ...>Distribution" from the Racket menu.

How would I go about that? Is it very complicated? 

If it's very complicated, maybe I should abandon the idea. But it would
be neat, because the main application is really just a tab panel with
many independent subcomponents as panel% classes.

Best,

Erich




On Tue, 7 Feb 2017 20:05:03 +0800
WarGrey Gyoudmon Ju  wrote:

> I think you can check the source of `raco` which uses the `info.rkt`
> to search all subcommands(see `racket/getinfo`). In this way, all
> plugins are just normal packages, you do not have to reside them is a
> specific directory. Certainly, the plugin is loaded via
> `dynamic-require`, if the plugin needs the imports of main

-- 
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] CFP: Scheme and Functional Programming Workshop 2017

[François-René Rideau]

Scheme and Functional Programming Workshop 2017
Oxford, United Kingdom
Co-located with ICFP 2017

http://scheme2017.namin.org/
Tweets by @schemeworkshop

Important Dates

Submission deadline: May 26th, 2017 (AoE)
Author notification: June 27th, 2017 (AoE)
Camera-ready deadline: July 28th, 2017 (AoE)
Workshop: September 3rd, 2017

Important Links

Submission Page: https://easychair.org/conferences/?conf=scheme17
Registration Page: (TBD)

Introduction

The Scheme and Functional Programming Workshop is a yearly meeting of
programming language practitioners who share a sense of aesthetic as
embodied by the Algorithmic Language Scheme: universality through
minimalism, adequation through self-improvement, flexibility through
rigorous design, and composability through orthogonal features.

Call For Papers

We invite high-quality papers about novel research results, lessons
learned from practical experience in industrial or educational
setting, and even new insights on old ideas. We welcome and encourage
submissions that apply to any language that can be considered Scheme:
from strict subsets of RnRS to other "Scheme" implementations, to
Racket, to Lisp dialects including Clojure, Emacs Lisp, Common Lisp,
to functional languages with continuations and/or macros (or extended
to have them) such as Dylan, ECMAcript, Hop, Lua, Scala, Rust, etc.
The elegance of the paper and the relevance of its topic to the
interests of Schemers will matter more than the surface syntax of the
examples used. Topics of interest include (but are not limited to):

Interaction: program-development environments, debugging, testing, refactoring
Implementation: interpreters, compilers, tools, garbage collectors, benchmarks
Extension: macros, hygiene, domain-specific languages, reflection, and
how such extension affects interaction.
Expression: control, modularity, ad hoc and parametric polymorphism,
types, aspects, ownership models, concurrency, distribution,
parallelism, non-determinism, probabilism, and other programming
paradigms
Integration: build tools, deployment, interoperation with other
languages and systems
Formal semantics: Theory, analyses and transformations, partial evaluation
Human Factors: Past, present and future history, evolution and
sociology of the language Scheme, its standard and its dialects
Education: approaches, experiences, curricula
Applications: industrial uses of Scheme
Scheme pearls: elegant, instructive uses of Scheme

Submission Information

Please submit full papers and experience reports to our Submission Page.

[NEW IN 2017!] Paper submissions must use the format acmart and its
sub-format acmlarge. They must be in PDF, printable in black and white
on US Letter size. Microsoft Word and LaTeX templates for this format
are available at:

http://www.sigplan.org/Resources/Author/

This change is in line with ACM conferences (such as ICFP with which
we are colocated) switching from their traditional two-column formats
(e.g. sigplanconf) to the above. While a two-column format with small
fonts is much more practical when reading printed papers, the
single-column format with large fonts is nicer to view on a computer
screen, as most papers are read these days.

To encourage authors to submit their best work, we offer three tracks:

Full Papers, with a limit to 24 pages. Each accepted paper will be
presented by its authors in a 40 minute slot including Q
Experience Reports, with a limit to 12 pages. Each accepted report
will be presented by its authors in a 20 minute slot including Q
Lightning talks, with a limit to 192 words. Each accepted lightning
talk will be presented by its authors in a 5 minute slot including
Q

The size limits above exclude references and any optional appendices.
There are no size limits on appendices, but the papers should stand
without the need to read them, and reviewers are not required to read
them.

Authors are encouraged to publish any code associated to their papers
under an open source license, so that reviewers may try the code and
verify the claims.

Proceedings will be printed as a Technical Report at Indiana University.

Publication of a paper at this workshop is not intended to replace
conference or journal publication, and does not preclude
re-publication of a more complete or finished version of the paper at
some later conference or in a journal.

Program Committee

Barış Aktemur, Ozyegin University, Turkey
Nada Amin (general chair), EPFL, Switzerland
Kenichi Asai, Ochanomizu University, Japan
Eli Barzilay, Microsoft, USA
Felix S Klock II, Mozilla Research, USA
Jay McCarthy, University of Massachusetts Lowell, USA
Christian Queinnec, Professor emeritus at Sorbonne University, France
François-René Rideau (program chair), Bridgewater Associates, USA

Steering Committee

Will Clinger, Northeastern University
Marc Feeley, Université de Montréal
Dan Friedman, Indiana University
Olin Shivers, Northeastern University
Will Byrd, University of Utah

-- 
You received this message 

Re: [racket-users] How to implement a dynamic plugin system?

[WarGrey Gyoudmon Ju]

I think you can check the source of `raco` which uses the `info.rkt` to
search all subcommands(see `racket/getinfo`). In this way, all plugins are
just normal packages, you do not have to reside them is a specific
directory. Certainly, the plugin is loaded via `dynamic-require`, if the
plugin needs the imports of main application, I think sandbox is not
necessary.

More precision, a plugin is just a normal module, if it requires the
modules that your main application uses, they will share the same status,
say you can use `(parameterize
([common-or-specific-parameters-for-the-plugin val]) (dynamic-require "..."
'greetings))` to let the plugin know its working environment; Inside the
plugin, it provides a name `greetings` with a structured value that
contains the proper icons, panel instances and so on, then the main
application will know how to deal with the plugin.

In my application, I prefer the logging facility, unlike logging facilities
in other languages, the racket one is also a multi dispatching asynchronous
mechanism which is more efficient than pipes and channels (if you do not
use place). The typical use case is, the splash screen and the main
application are both listening on the `current-logger`, and the plugin logs
itself with the proper info to `current-logger`, then the splash screen
will know a new icon should be drawn, while the main application will know
a new panel should be added to the workspace (both of them will receive all
the info but only pick up the interesting parts).

On Tue, Feb 7, 2017 at 7:21 PM, Erich Rast  wrote:

> Hi all!
>
> I'm thinking about implementing a dynamic plugin system for a large
> application. Each plugin should have the full racket/gui language and a
> number of pre-defined imports from modules of the main application
> available. Plugins should reside in a relative directory and loadable
> on demand at runtime, and I also need a way to check in the main
> application that they export certain plugin data like a name, an icon
> and a panel% class. Plugins do not need to export any macros. Security
> is not a concern and all plugins are local.
>
> My questions: Is that possible? What's the right way of doing it, should
> I use dynamic-require or racket/sandbox? How would you convert an
> ordinary module with a #lang statement and various requires into such a
> dynamic plugin?
>
> Best,
>
> Erich
>
> --
> 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] How to implement a dynamic plugin system?

[Erich Rast]

Hi all!

I'm thinking about implementing a dynamic plugin system for a large
application. Each plugin should have the full racket/gui language and a
number of pre-defined imports from modules of the main application
available. Plugins should reside in a relative directory and loadable
on demand at runtime, and I also need a way to check in the main
application that they export certain plugin data like a name, an icon
and a panel% class. Plugins do not need to export any macros. Security
is not a concern and all plugins are local.

My questions: Is that possible? What's the right way of doing it, should
I use dynamic-require or racket/sandbox? How would you convert an
ordinary module with a #lang statement and various requires into such a
dynamic plugin?

Best,

Erich

-- 
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: Package layout in docs

[Ethan Estrada]

On Mon, Jan 30, 2017 at 3:33 PM, Leif Andersen  wrote:
>
> So, I really don't care how it work. Logo is fine, seperate website is
> fine. Checkboxes that lets users say what packages come in are fine.
> Yelp reviews are fine (although if we go down that route can we also
> add Edit buttons. ;) )

It seems the discussion about splitting out packages has moved to
another thread. To wrap this thread, I just want to echo what Leif
said: in the end, I am pretty much happy with whatever solution is
decided. Being somewhat new to the community, I don't know who is the
person (or persons) in charge of green-lighting any given plan.

So my questions at this point are:

1) What direction is this headed? (the conversation seemed to hint
at implementing the planned ring system, but please correct me if I am
wrong)
2) What are the ways that I (and others in the community) can help
make it happen?

--
Ethan Estrada

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