Re: [racket-users] Running racket on a #lang-less module-less file?

[William Hatch]

I've always thought that should be possible -- for instance, if someone
were to implement some pre-existing language in Racket, it would be nice to
be able to say "require this using #lang X" so that it can be parsed and
bound correctly.  Eg. if you had a Javascript implementation and some
functions to massage data between what normal Racket and
Javascript-inside-Racket expect, it might be fun to be able to consume some
node.js libraries that way.  At least for libraries that work within
whatever implementation you might have.


On Thu, May 5, 2016 at 6:45 PM, Jack Firth  wrote:

> On Thursday, May 5, 2016 at 5:39:44 PM UTC-7, Matthew Flatt wrote:
> > At Thu, 5 May 2016 17:32:20 -0700 (PDT), Jack Firth wrote:
> > > Does that evaluate the file as if it were entered in a REPL?
> >
> > Yes.
>
> What if I don't want REPL semantics, but I want behavior identical to if
> the file began with the appropriate #lang line? Is there some subtle reason
> that's not an option?
>
> --
> 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] DSL to C code generation with symbolic computations en route

[William Hatch]

Late to the party, because I've been ignoring most of my email for a week.

I'm the one at the U of U that has started working on the problem as Jay
mentioned.  But with classes and other study on related, tangentially
related, or simply tangential topics I haven't gone beyond the very
simplest of code generation.  However, now that this semester is about over
I should be able to focus entirely on pre-racket for the summer.

My plans for pre-racket will be magnolisp-style translation of fully
expanded Racket programs in #lang pre-racket, though I'm not yet sure which
features will be included in the end.  Initially it will target C, but I
would like to generalize it to support other targets as well.  So I'm very
interested to hear what others are doing in the same space.

William

On Tue, Apr 19, 2016 at 9:50 AM, Jay McCarthy 
wrote:

> This is something that comes up over and over on the list. I believe
> that there are others at U(U) that are working on this problem
> presently as a way to help port the runtime system from C. Perhaps it
> would be good to connect everyone up more efficiently.
>
> On the more boring end, I'm working right now on a language with very
> overtly C-semantics for getting some of the benefits of pretty macros
> in C. I suspect that there is a connection between what I'm doing and
> Fulmar. But I can't seem to understand Fulmar from the docs and I have
> nothing doc-like to speak of us. Another thing in this realm is the
> Terra language --- http://terralang.org --- and its associated
> projects, which are all quite beautiful.
>
> Jay
>
> On Tue, Apr 19, 2016 at 3:18 AM, Konrad Hinsen
>  wrote:
> > On 18/04/2016 19:20, Dmitry Pavlov wrote:
> >
> >> I, as a programmer in the area of numerics, just evolved to the state
> >> where the following task seem reasonable to work on:
> >
> > ...
> >
> >> I suspect I am not the only one who wants that.
> >
> >
> > Me too!
> >
> >> There must be some work already done.
> >> What would you advise to start with?
> >
> >
> > I am not aware of anything very close to your goals in Racketland, but
> there
> > are people much more knowledgeable than me on this list.
> >
> > I have played with similar ideas as well, but never found the means to
> work
> > on this seriously. But I'd participate in a collaborative project.
> >
> > My idea for this is:
> >
> >  1) Define a language with C-level semantics but S-expression syntax. A
> > language that can be easily compiled to C, Fortran, LLVM byte code, and
> > perhaps even JVM bytecode, in a way that the performance implications of
> > each statement are understandable to a software developer.
> >
> >  2) Develop whatever backends (C, Fortran, LLVM, ...) people find most
> > useful. But make sure that at least one backend integrates transparently
> > with Racket's FFI, so that one can "just run" such code from Racket.
> >
> >  3) Develop DSLs that compile to this language.
> >
> > In the long run, the low-level language could be extended by optimization
> > hints, similar to #pragmas as used in OpenMP.
> >
> > Symbolic derivatives and similar transformations would be part of the DSL
> > implementations. For the specific case of derivates, Jerzy's remark is
> > important: automatic derivatives are often the better choice. But for the
> > big picture, that's a secondary question; a numeric DSL framework should
> > support both approaches.
> >
> > Konrad.
> >
> >
> > --
> > 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.
>
>
>
> --
> Jay McCarthy
> Associate Professor
> PLT @ CS @ UMass Lowell
> http://jeapostrophe.github.io
>
>"Wherefore, be not weary in well-doing,
>   for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
>   - D 64:33
>
> --
> 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: Case for net/url.rkt to read HTTP proxy servers from environment

[William Hatch]

I would like to see it fall back on HTTP_PROXY if PLT_HTTP_PROXY is not
found.  It is annoying that the cases vary (eg. wget uses http_proxy and
https_proxy, curl uses http_proxy and HTTPS_PROXY), but maybe we could
prefer the one in all caps and fall back on lowercase.  My last job was
behind a proxy, and it was so annoying to have to figure out how to get
every program to use a proxy.  So falling back on the (more or less)
standard environment variables would be really helpful so end users of
racket programs have less to configure to have things "just work".

On Mon, Oct 12, 2015 at 8:19 AM, Tim Brown  wrote:

> I’ve just created PR:
>  PLT_HTTP_PROXY and PLT_NO_PROXY honoured #1089
>
> It doesn’t use the standard HTTP_PROXY and NO_PROXY from the environment,
> since
> I want to be able to control the proxies for Racket obviously and
> separately
> from the rest of the environment.
>
> It’s kinda tested, and only documented in the PR at the moment.
>
> Could someone form an opinion of this PR for me :-)
>
> Thanks,
>
> Tim
>
> On Friday, October 9, 2015 at 2:39:26 PM UTC+1, Tim Brown wrote:
> > Is there any merit in taking the current environment variable values
> > (on UNIX at least) of “proxy”, “http_proxy” and “https_proxy” and
> > loading them by default into current-proxy-servers? (net/url.rkt l.26)
> >
> > Are these even the right variables to go for?
> >
> > What do we think?
> >
> > Tim
> >
> > --
> > Tim Brown CEng MBCS 
> > 
> > City Computing Limited · www.cityc.co.uk
> >   City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
> > T:+44 20 8770 2110 · F:+44 20 8770 2130
> > 
> > City Computing Limited registered in London No:1767817.
> > Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
> > VAT No: GB 918 4680 96
>
> --
> 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.