Re: [racket-users] Rhombus project plan
> > > They say that Racket is slow. I would like to know who are "they". > > Racket can be surprising. For example - our GUI application on RPi has a > start-up time of 24s... But when we compile it using `raco exe`, it goes > down under 2s including some hardware setup the program does. Usually > the slow startup times are caused by not using compiled byte-code. > > As I have mentioned a few times on this list, I am working on a side > project right now which pushes Racket to its limits and let's say that > the results might look impossible to many people. Full 3D rendering > pipeline in pure Racket with no external libraries (no OpenGL, no SDL, > just pure Racket) which can run at 60fps FullHD kind of beats the > argument "Racket is slow". > I would be very interested in understanding how you've been able to achieve this and look at the code as well if possible. I'm working right now on a machine learning toolkit that could use performance boosts. A. -- 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/efd81309-99d5-4d76-8bfb-368b0f7f25f6%40googlegroups.com.
[racket-users] Re: Rhombus project plan
First of all, Thank you to the team for making such a fantastic system available for the rest of us. I don't know what I'd have done without it. As a very long time Schemer/Racketeer/Lisper and a consistent industry practitioner (I have used Chez Scheme and Racket as critical parts of every one of my companies in the past 20 years). It is somewhat unclear to me from reading this proposal what the expected outcomes of this project are, or ought to be (in terms of making a real change in the language ecosystem). But, if one of the outcomes is to gain widespread adoption, my first thoughts upon reading this proposal are as follows. 1. The obsession with parentheses/syntax is misplaced. My analysis of the psychology of parentheses that it is a redirection of frustration with functional-style programming. Let's acknowledge the fact that functional programming is a difficult paradigm for the average CS graduate and they generally skew imperative (it's probably rooted in human psychology, since that is how our systems are organized: around change of state). In any case, the frustration in dealing with it is directed towards syntax in the case of Racket. Other functional languages with conventional syntax suffer the same outcome: lack of widespread adoption because of perceived "annoyances". While I would welcome the ability to more easily add new (possibly infix) notation into my own syntactic extensions, spending too much time designing a new "better" syntax for racket is not going to reduce the adoption barrier. So, I would rather own it than defend it. 2. Adoption will be widespread once the language and its accompanying platform can stake out a claim for itself in terms of what can be built with it. I can't speak to the other aspects of internal design that this post talks about but here is what I believe we need in the industry to convince my new crop of engineers to start adopting Racket at a larger scale. In some ways, I'm looking at it as a "sell" job, and here are the things I know I can sell. This is not so much about language design as much as it is about the Platform itself, although I'm sure Racketeers can do a far better job of bringing in elements of language design into this. Of course, the community needs to work towards doing this along with the Racket team, but as a community, we should set an agenda and work towards it. The Rhombus discussion provides an opportunity for this. So here are my two cents. A) Performance. As a point of comparison, the JVM has gotten amazingly good over the past couple of decades, but Java continues to be derided as a terrible language with much lower productivity. Given how productive one can be in Racket, combining that with comparable performance will make it an easy sell. This has largely been Go's and Rust's strategy. C++ level performance with high productivity. For this day and age, this would have to include GPU support (kind of like openCL). B) Web First. The current the built-in web framework is not enough. The language must support end-to-end development of asynchronous web-applications, and it must be trivial to tack on web front-ends to anything. This is the Node/JS and Ruby/Rails strategy. Racket has some elements of this, but building a web-app in racket is still a lot of work. With web-assembly on the horizon, Racket can very easily be a front-end language as well as a back-end language. C) Mobile First (ok, Second :-). The language must provide inherent support for building mobile front-ends (both android and IoS). This is the Swift/XCode strategy. D) AI Support. AI is clearly the next wave of software and people are going to be building AI into their systems for decades to come. In this instance, Lisp's AI legacy might actually be of help, if we can make it very easy to develop AI applications. While Python seems to be the preferred language right now, I don't believe it will last too long. AI programming in Python is at best a puke-worthy experience. E) Cloud Ready out of the box - Simple deployment using docker, AWS Lambda and the like; built-in support for directly working with cloud resources (buckets, ACL's, Logs, etc.) F) Broad IDE support. Rather than focus on Emacs/Dr. Racket, I believe Racket should take the approach of integrating with all the different IDE's. (JetBrains' IDEA, NetBeans, Visual Studio, Eclipse) Most are now good enough to be scripted and in many cases the click-happy younger generation deals with it better, and probably much less work than trying to maintain Dr.Racket. G) Other desirables, but less important than the ones above: - FFI for Java libraries. (One of the biggest reasons for Clojure's appeal) - CLOS. It is still the finest object system ever that most effortlessly blends functional-style with objects. Scala's success can be attributed to its functional+object+Java interoperability strategy, type-system not withstanding.
[racket-users] Racket CS Profiler
Does the profiler work as expected in Racket CS? I'm getting the total time taken, but the detailed profile has little useful information. If not, Is there a way to get better profiling information in CS? Best, Anurag. -- 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/CAHjTuf%3DAJtkg5Oq79%3DfzqstJA0UmiXpNbJGsgXqLPB6q8NviJw%40mail.gmail.com.
Re: [racket-users] planet questions
Perfect! Thanks!
A.
On Thursday, October 8, 2015 at 10:17:48 AM UTC-7, Matthew Flatt wrote:
> The details below avoid needing "libWN" on install. If you want to
> enable tests of other things that need to use "libWN", see "Working
> with Native Libraries" here:
>
> http://pkg-build.racket-lang.org/about.html
>
>
> At Thu, 8 Oct 2015 08:54:14 -0700, Anurag Mendhekar wrote:
> > Thanks for the detailed response, and apologies for the confusion regarding
> > the nomenclature. I did use the new package system, but in my head it is
> > still planet :-)
> >
> > Anything I can do about the failure on libWN?
> >
> > Best,
> >
> > A.
> >
> >
> > > At Wed, 7 Oct 2015 17:35:44 -0700 (PDT), Anurag Mendhekar wrote:
> > > > Having just submitted my first contribution to Planet
> > >
> > > [Note: We use the name "Planet" for an older package system. I see that
> > > you uploaded a package in the new system; assuming that you didn't also
> > > upload to the old system, calling the new one "Planet" may be confusing
> > > some here --- including Robby. We call the new one just "the package
> > > repository".]
> > >
> > > > 1. My module is an FFI which requires a specific library. Quite
> > > obviously, the
> > > > building daemon fails (because it doesn't have this library). But, it
> > > seems
> > > > like this a mischaracterization of the package (which does build fine).
> > > My
> > > > question is whether this is fixable.
> > > > 2. I have included scribble documentation with the module, but it seems
> > > like
> > > > it is not being found. I am not sure if this is somehow linked to the
> > > problem
> > > > above.
> > > >
> > > > What do I need to do to fix these two issues? My info.rkt is below.
> > >
> > > Yes, these are the same issue. Your documentation starts
> > >
> > > #lang scribble/manual
> > > @(require racket/base "wn.ss")
> > >
> > > which means that "wn.ss" must be run to build the document. Running
> > > "wn.ss", in turn, needs "libWN".
> > >
> > > But you don't actually need to run "wn.ss" to build your documentation.
> > > You should instead write
> > >
> > > #lang scribble/manual
> > > @(require (for-label racket/base "wn.ss"))
> > >
> > > which pulls in the identity of bindings to "wn.ss", so that references
> > > can be hyperlinked correctly, but `for-label` does not actually run
> > > "wn.ss".
> > >
> > >
> > >
> > > If you make that change, then you'll get a new pile of warnings.
> > > Mostly, the warnings are because your
> > >
> > > @defmodule[wn/wn #:packages ("base")]
> > >
> > > declaration is inside a particular section, while the documentation for
> > > the module's content is partly in sibling sections. One way to avoid
> > > most of the warnings is to live that `defmodule` to be right after
> > > `title`, or you could leave `defmodule` in place and add
> > >
> > > @declare-exporting[wn/wn]
> > >
> > > after `title`.
> > >
> > > Then, there will still be warnings, and those have to do with things
> > > that are referenced in the documentation but not defined in the
> > > documentation.
> > >
> > > In any case, these warnings will not counts as failure for the package
> > > installation.
> > >
> > >
> > >
--
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] planet questions
Thanks for the detailed response, and apologies for the confusion regarding
the nomenclature. I did use the new package system, but in my head it is
still planet :-)
Anything I can do about the failure on libWN?
Best,
A.
On Thu, Oct 8, 2015 at 7:18 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> At Wed, 7 Oct 2015 17:35:44 -0700 (PDT), Anurag Mendhekar wrote:
> > Having just submitted my first contribution to Planet
>
> [Note: We use the name "Planet" for an older package system. I see that
> you uploaded a package in the new system; assuming that you didn't also
> upload to the old system, calling the new one "Planet" may be confusing
> some here --- including Robby. We call the new one just "the package
> repository".]
>
> > 1. My module is an FFI which requires a specific library. Quite
> obviously, the
> > building daemon fails (because it doesn't have this library). But, it
> seems
> > like this a mischaracterization of the package (which does build fine).
> My
> > question is whether this is fixable.
> > 2. I have included scribble documentation with the module, but it seems
> like
> > it is not being found. I am not sure if this is somehow linked to the
> problem
> > above.
> >
> > What do I need to do to fix these two issues? My info.rkt is below.
>
> Yes, these are the same issue. Your documentation starts
>
> #lang scribble/manual
> @(require racket/base "wn.ss")
>
> which means that "wn.ss" must be run to build the document. Running
> "wn.ss", in turn, needs "libWN".
>
> But you don't actually need to run "wn.ss" to build your documentation.
> You should instead write
>
> #lang scribble/manual
> @(require (for-label racket/base "wn.ss"))
>
> which pulls in the identity of bindings to "wn.ss", so that references
> can be hyperlinked correctly, but `for-label` does not actually run
> "wn.ss".
>
>
>
> If you make that change, then you'll get a new pile of warnings.
> Mostly, the warnings are because your
>
> @defmodule[wn/wn #:packages ("base")]
>
> declaration is inside a particular section, while the documentation for
> the module's content is partly in sibling sections. One way to avoid
> most of the warnings is to live that `defmodule` to be right after
> `title`, or you could leave `defmodule` in place and add
>
> @declare-exporting[wn/wn]
>
> after `title`.
>
> Then, there will still be warnings, and those have to do with things
> that are referenced in the documentation but not defined in the
> documentation.
>
> In any case, these warnings will not counts as failure for the package
> installation.
>
>
>
--
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] planet questions
Having just submitted my first contribution to Planet, I am struggling with a
couple of things:
1. My module is an FFI which requires a specific library. Quite obviously, the
building daemon fails (because it doesn't have this library). But, it seems
like this a mischaracterization of the package (which does build fine). My
question is whether this is fixable.
2. I have included scribble documentation with the module, but it seems like it
is not being found. I am not sure if this is somehow linked to the problem
above.
What do I need to do to fix these two issues? My info.rkt is below.
Best,
A.
#lang setup/infotab
(define name "wn")
(define blurb '("FFI interface to the WordNet 3.0 Library: A Lexical Database
for English"))
(define primary-file "wn.rkt")
(define scribblings '(("wn.scrbl" (
(define categories '(misc nlp))
(define homepage "https://github.com/themetaschemer/wn/;)
(define collection "wn")
(define version "0.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.
[racket-users] Matrices and GPU acceleration
Hi All, I'm embarking on a rather ambitious neural network project and would very much like to avoid python/numpy/theano route and stay within Racket. The only aspect that is giving me pause is that I expect my network will be large enough that I would have to use GPU acceleration for it to be tractable. Theano has an option for GPU support, which is attractive for this purpose. By way of linear algebra, I like what math/matrix has to offer but I can't find any GPU support on it. I thought I'd throw a query out to the group to see if there is another alternative. Any pointers will be appreciated. Best, A. -- 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.
