Re: [racket-dev] having zo files from two versions

2015-01-06 Thread Neil Van Dyke

Dan Liebgold wrote on 01/06/2015 02:00 PM:
What is a straightforward way to designate the compiled directory to 
look for zo files in that can be based on the Racket version?  I'd 
like to have Racket 5.2.1 and 6.1 running in parallel to aid in 
upgrading our version.

Thanks!


I'd like for this to be the default behavior for Racket.

One possible way: Insert a directory level between the `compiled` 
directory and its contents, with the directory named with the Racket 
version number with which the code is compiled.  Only that Racket 
version will run that compiled code.


(When I've been using Racket version A to run a code tree, and then use 
Racket version B with the same code tree, I don't mind waiting for a 
recompile of the code tree, and I'd really prefer it not disturb the 
code compiled with Racket version A.  I also don't mind cluttering disk 
space with compiled code for Racket versions that I no longer use; I can 
always make a script to clean those up.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-12-03 Thread Neil Van Dyke

I don't think I need charity.

I thought the vision for the new package system had already been 
explained adequately.  I would be very interested to learn how the model 
is well-suited to third-party developers like me.


But -- I mean this constructively -- I'd be happy if someone simply came 
out and said this model is great for core developers, we still have to 
figure out everyone else, and maybe the model isn't great for everyone 
else.  The reason is that I've looked at the new package system 
seriously 5-6 times since it was announced, and I keep being told that 
the model is intended for non-core people like me, and that someone else 
knows my needs better than me.  Open source reuse was an especial area 
of interest to me, the package system is very important, and I've given 
the benefit of the doubt 5-6 times now.  (This has actually stalled most 
of my public Racket work, one way or another, for about 2 years.)


I'm not harshing on Racket; just on how the new package system was 
sprung on non-core people, and the narrative.  It doesn't look typical 
of Racket.  Racket is usually in the position that it could say we have 
a better idea (on, e.g., module system sophistication, various syntax 
extension mechanisms and mixed languages support, various aspects of 
DrRacket, the related pedagogic projects, etc.), and usually that 
doesn't have to be said, because the superiority of Racket is 
immediately apparent.  That's why I've been a Racketeer for 13 years and 
counting.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-12-02 Thread Neil Van Dyke
I think this what's the matter with conflicts, and an arbitrary package 
putting things wherever it wants, and not having a notion of 
non-backward-compatibility is similar to what's the matter with using 
eval for everything or what's the matter with defmacro or what's the 
big deal about having subroutines in a language.


The questioner's position works for them, some other person thinks it's 
a very bad idea, and you can trot out hypothetical scenarios and 
anecdotes, but -- since it can be argued to reduce to pragmatic 
tradeoffs involving unknowns -- you can't (at least I can't) persuade 
someone who thinks they know better.


How about we just say that the module system was originally designed as 
something that core Racket developers would like to use, having a low 
friction to moving an individual core developer's side projects into the 
tidy-looking core, or to doing other kinds of shifting they would like 
to do in core Racket?  Without an acknowledgement that not all 
third-party package developers will be working like that, nor that 
everyone wants to make the substantial compromises to facilitate that 
low friction.


For third-party developers like me, I can layer something to work around 
some of the drawbacks, and, pragmatically, that's what I'll have to do.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Line editing in the default REPL

2014-12-02 Thread Neil Van Dyke


Eli Barzilay wrote on 12/02/2014 09:31 PM:

On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen l...@leifandersen.net wrote:

Just to clarify a bit, we were more thinking of extending the default
repl to have line editing features, rather then making xrepl the
default,

If you're talking about implementing line editing yourself, then my
personal reaction to that would be wonderful, but doing it properly is
something that is difficult and easy to underestimate


I agree fully with Eli.

Also, separate from practical benefit of having basic `readline`-like 
line editing in pure Racket, you could go gratuitously coolness factor 
on this.  For example, I don't think I've seen a non-full-screen 
character-terminal REPL do syntax coloring, matching paren highlighting, 
and full up/down cursor navigation within a single REPL input.  That's 
labor-of-love coolness, and all who behold it will respect your name.


(http://www.neilvandyke.org/racket-charterm/; would help with some 
primitives and device portability, but you'd still have to layer a lot 
of work atop that.  Offhand, the most nonobvious tricky part I can think 
of is not getting program confused about where text and your cursor are 
on the screen.  Different terminals will have different behavior when 
cursor is in the last column, or cursor is in the last row and column, 
or you're inserting/deleting characters or lines (which some terminals 
will support differently, and others not at all).  You also have to 
decide how you want to handle the user experience of some kind of Ctrl-L 
redraw, since terminal screens get corrupted often by text written by 
other processes, Ctrl-L also helps mitigate terminal quirks you don't 
yet handle, and terminal-savvy people will expect a Ctrl-L.  It's 
possible to make a self-healing character terminal display, on those 
terminals that permit reading screen addresses and that have sufficient 
idle bandwidth, but I haven't heard of anyone doing that yet, and 
everyone just has a Ctrl-L.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] new package system collections and conflicts

2014-11-30 Thread Neil Van Dyke
Given the example from the documentation, of the `tic-tac-toe` package 
and conflicts (quoted at end of this email), instead, why isn't the 
norm to do:


(require tic-tac-toe)

Or, when necessary:

(require tic-tac-toe/matrix)

Why, when one installs a package named `tic-tac-toe`, would one be 
referencing modules of the package as `data/matrix`?


I don't recall ever seeing a situation in which I wanted different 
third-party Racket packages to be stomping over each other's 
module-naming namespaces.


For people who want to release lots of well-behaved reusable packages, 
using good practices, with minimal effort and head-scratching, things 
like this are a problem.



2 Package Concepts

A package is a set of modules in some number of collections. Modules 
installed using the Racket package manager are required like any other 
modules. For example, if the package tic-tac-toe contains the module 
matrix.rkt in a data collection, then after tic-tac-toe is installed,


(require data/matrix)

[...]

2.5 Package Conflicts

Two packages are in conflict if they contain the same module. For 
example, if the package tic-tac-toe contains the module file 
data/matrix.rkt and the package factory-optimize contains the module 
file data/matrix.rkt, then tic-tac-toe and factory-optimize are in 
conflict.


A package may also be in conflict with Racket itself, if it contains a 
module file that is part of the base Racket implementation. For 
example, any package that contains racket/list.rkt is in conflict 
with Racket.


For the purposes of conflicts, a module is a file that ends in .rkt, 
.ss, or .scrbl.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] new package system and versions

2014-11-30 Thread Neil Van Dyke
Any chance of revisiting the new package system's stances on versions -- 
specifically, on the two issues:
1. Can subsequent versions of a named package (which has an identity)  
be non-backward-compatible?
2. Can a Racket setup (and even an individual program) have multiple 
versions of a package at the same time?


Regarding #1, the requirement to never make a non-backward-compatible 
version of a package without giving up package identity is a burden, and 
a deterrent to third-party package releases.


For a real-world example, see http://planet.racket-lang.org/;, where it 
looks like most of the familiar names (who were going to a good amount 
of trouble to release already), managed to release packages marked as 
non-backward-compatible (i.e., PLaneT major version number other than 
1).  Wouldn't requiring them to never break backward compatibility be a 
deterrent to releasing at all? Or, if they still released, would 
`dherman`, following the instructions of Racket to create a new package 
identity for any backward-incompatible version, have given us packages 
`javascript`, `javascript2`, ... `javascript9`, rather than `javascript` 
versions `1.x` through `9.x`.


No-backward-incompatibility might make sense for core Racket (although 
even core Racket has broken this multiple times), but it's a big 
deterrent to researchers, and to industry developers who are willing to 
open source components of their larger systems in lightweight ways.


Regarding #2, I suggest that should be revisited if #1 is revisited.

I think PLaneT got both of these a lot closer to right, at least for 
third-party packages.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote on 11/30/2014 10:55 AM:

Another example where this happens (and in a way that couldn't be
fixed by combining packages) is with typed versions of libraries. If I
release a package with the collection `foo`, and then someone else
produces a typed version of it, that will probably be named either
`foo/typed` (and thus be in the `foo` namespace) or `typed/foo` (and
thus be in the `typed` namespace).


Personally, I'd much rather have packages respect namespace boundaries, 
and have a simpler model, and let people call that TR library 
`foo-typed` or `typed-foo`.  (Or, TR comes up with a better scheme for 
providing TR and non-TR interfaces to a module, and reduces DRY problems 
in specifying APIs at the same time.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Neil Van Dyke


Jay McCarthy wrote on 11/30/2014 12:13 PM:
The documentation cited is making clear that there is NO connection 
between the name of a package and the provided modules. There is no 
such thing as a package namespace.


I'd really like there to be.  For third-party packages.



Packages may find it convenient to build and provide reusable 
functionality with many organizational names. This is particularly 
true of data, as many packages may have useful data structures.


Of course, as such support code becomes very useful and developed, it 
makes sense to sprin it off into its own package.


Are you saying that `data` is some kind of classification of what this 
module is about, and in this case specifically, this module, which is 
part of some more specific package, happens to be regarding 
general-purpose data structures, so we're putting it over here in the 
`data` area of a shared namespace hierarchy?  If so, I don't understand 
why that would be considered a good idea.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Neil Van Dyke


Jay McCarthy wrote on 11/30/2014 12:30 PM:
On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org 
mailto:n...@neilvandyke.org wrote:



Jay McCarthy wrote on 11/30/2014 12:13 PM:

The documentation cited is making clear that there is NO
connection between the name of a package and the provided
modules. There is no such thing as a package namespace.


I'd really like there to be.  For third-party packages.


I do not know what a third party package is.


I'm thinking of *non*-core-Racket-developers.  Who have different needs 
than core Racket developers.  It's good that Racket is blurring the 
distinction, but the needs still aren't necessarily the same.  I say 
third-party as shorthand familiar to me, but perhaps there's a better 
term.






Packages may find it convenient to build and provide reusable
functionality with many organizational names. This is
particularly true of data, as many packages may have useful
data structures.

Of course, as such support code becomes very useful and
developed, it makes sense to sprin it off into its own package.


Are you saying that `data` is some kind of classification of what
this module is about, and in this case specifically, this
module, which is part of some more specific package, happens to be
regarding general-purpose data structures, so we're putting it
over here in the `data` area of a shared namespace hierarchy? 



Yes, although this is just for the benefit of search and reading docs; 
it has no technical enforcement.


If so, I don't understand why that would be considered a good idea.


It is a principle to create general purpose reusable code in the 
package ecosystem rather than little archipelagos with lots of private 
code that gets duplicated and has clever names.



I keep wanting to encourage lots-and-lots of packages, and they can be 
packaged and released in a very lightweight yet well-conceived manner.


To go back to your example, if it's a useful general-purpose data 
structures library, then that's another package, which should be very 
easy to do.  If the package author isn't ready to split it out, then 
they're not ready to split it out, so no sense talking about it.  As far 
as I can tell, in no case is this `data` namespace relevant.


Side note: I really don't think ontological classification of package 
topics belongs in package names.  Topical classifications evolve over 
time, and independent of the objects themselves. Classifications belong 
in directories, not in names.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new package system collections and conflicts

2014-11-30 Thread Neil Van Dyke


Sam Tobin-Hochstadt wrote on 11/30/2014 12:52 PM:

Are you saying that `data` is some kind of classification of what this
module is about, and in this case specifically, this module, which is part
of some more specific package, happens to be regarding general-purpose data
structures, so we're putting it over here in the `data` area of a shared
namespace hierarchy?

Yes, the idea is that it makes sense for `data/hamt` to come from the
hamt package, and for `data/fector` to come from the fector
package (this is currently the case on pkgs.racket-lang.org).


  If so, I don't understand why that would be
considered a good idea.

Because the client of these modules shouldn't have to think about
which package they belong in to use them. This gives the package
developer freedom to combine or split packages without requiring code
changes from clients.


I think this might be centralized, core-Racket-developer, thinking. I 
think that some people might be trying to herd decentralized development 
to build what looks then like a tidy, centralized library.


This would also explain why the new package system originally advised to 
use generic names for packages, which I think is not a great match for 
organic, decentralized development.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] generic API names considered harmful

2014-07-06 Thread Neil Van Dyke


Roman Klochkov wrote at 07/06/2014 10:15 PM:

What about 3rd party modules?

For example, should 
http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss provide
syntactic-closures-compile, syntactic-closures-execute and 
syntactic-closures-scheme-syntactic-environment ?


Idiomatic names might be compile-syntactic-closures, 
execute-syntactic-closures, etc.  If this library became a very common 
thing to use, familiar to most Racket programmers, maybe someone would 
come up with catchier names eventually (like 
call-with-current-continuation became call/cc).




Collections may be renamed. Eventually collection names will become 
longer, because they have to be unique (like in 
java: org.apache.commons.lang.builder.ToStringBuilder). Besides we 
have modules and prefix-in.


I suspect that, in practice for the foreseeable future, if we use 
non-generic names, we won't have many collisions.  With the level of 
third-party reuse that I and my consulting clients have been doing over 
the last 10 years with Racket, I found that we only rarely use 
prefix-in.  This is out of over 1,000 Racket modules and over a 
million of lines of Racket code, written by several people of varying 
background and style.


My recollection offhand is that, when we have used prefix-in, it's for 
improving code readability when:
* using the profiler (due to its use of generic names like render, 
used in large modules that often dealt with more prominent/likely 
``render'' concepts),
* using the old SSAX/SXML PLaneT packages (due to not-entirely-idiomatic 
API and packaging), and

* using some SRFI implementations (due to name conflicts),
* doing Scheme/Racket dialect language work (to keep straight what 
dialect's identifiers we're talking about in a module).
All other times I can think of, having sensible non-generic names and 
not needing the headache of prefix-in has seemed to be a win.


Granted, I have a research interest in much more heavy fine-grain reuse, 
and if that's ever realized, I assume we'll see more identifier 
collisions and more confusing overloading of terms (e.g., the several 
different kinds of date objects I've seen in various code).  I 
couldn't say for certain that generic names and prefix-in (or some 
other facility) wouldn't start to be practical at that time; I'd have to 
wait and see.  Of course, the programming language technology is not the 
only way that these problems are solved, but can be solved in the 
ecology of development and reuse (e.g., as development and reuse 
sophistication increases, we might actually see fewer different kinds of 
things called date than we see now, since one kind might mature more, 
and consequently people might less often have occasion to make an 
alternative one).


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] generic API names considered harmful

2014-07-04 Thread Neil Van Dyke
For documented public API of modules that are part of core Racket, 
shouldn't pretty much all the identifiers be descriptive enough to be 
unique within the scope of core Racket?  (Excepting name conflicts from 
SRFIs and teaching languages?)


I've now noticed generic API names like make and render in core 
Racket modules written by, I think, 3 different very smart core Racket 
developers.  I don't understand why we're still doing this. Was it for 
use with the unitssignatures (which are more trouble than they're 
worth, IMHO)?


For code using these APIs, for readability (since any generic names in a 
module are relative to what that module is about, not the possibly many 
modules that module uses), I end up using prefix-in on modules with 
generic API names, which is still harder to read than natural identifiers.


And even if I do the prefix-in like foo-lib:, with a colon on the 
end, foo-lib:make is still harder for someone reading the code to look 
up the identifier in Racket doc search, compared looking up a unique API 
identifier like make-foo or foo-make.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] for loops with interleaved escape continuations

2014-07-02 Thread Neil Van Dyke
Loop syntax and sugar is fine.  And having #:continue and #:break 
keywords at the top of the form is sufficient warning of surprises 
ahead, IMHO.


I do have a minor ongoing concern that people coming from other 
languages lately latch onto the for family of forms from the start, 
don't get enough exposure to named-let, and/or mutually/self-recursive 
procedures, and then end up shoehorning problems into the for forms 
(with flag variables and redundant checks and such).  break and 
continue can be good shoehorns.


I still half-seriously like the idea of having unlockable language 
feature achievements, like unlockable equipment in video games.  I might 
play with that idea soon.


Neil V.

attachment: neil.vcf_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] for loops with interleaved escape continuations

2014-07-01 Thread Neil Van Dyke
If adding breakcontinue features to your fancy iteration syntax, I 
propose that any uses of these features in source code be somehow very 
prominent.


For example, perhaps there is a keyword that must be at the top of the 
fancy iteration form, something like 
#:enable-continue-here-because-programmer-cannot-be-bothered-to-write-this-in-idiomatic-racket.


This prominence warns readers of the code to be on the lookout for 
surprise control flow (like they would on the rare occasion that they 
saw a call/ec around a loop).  It also hints to newbie programmers 
that they are discouraged from simply transliterating syntax from other 
languages (rather than learning better control flow and structuring 
techniques).


Neil V.

attachment: neil.vcf_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] lab notebook on learning process

2014-05-06 Thread Neil Van Dyke


Jens Axel S√łgaard wrote at 05/06/2014 02:02 PM:

Sam:


Could we
  - warn people when they use `time` in DrRacket?
- provide a performance mode that runs programs out-of-process, or
   just in another place?
- something else?

I like this. DrRacket has a performance mode already (disable
profiling and debugging) in the (hidded part) of the language dialog.
The casual beginner
is not likely to recognize it as such though.

How about an extra button, a  Run Benchmark button?


In addition to these, would it make sense for the REPL banner in the 
Interactions pane to indicate when DrRacket debugging and profiling are on?


This would be a hint to people about some of the common parameters 
affecting performance, along with Racket version, memory limit, GC, 
JIT,general platform, CPU arch, and maybe number of cores Racket knows 
about.


When showing the run of some timed code on the email list, we can even 
copypaste this banner with it, as a quick way to convey some of the 
pertinent parameters of our setup.


Maybe don't show this info in student languages, but show it everywhere 
else.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] lab notebook on learning process

2014-05-06 Thread Neil Van Dyke
Just remember, any self-respecting benchmark feature of a platform 
will detect standard benchmarks and substitute hand-tuned assembler. :)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] comments on comments on learning Racket

2014-04-26 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 04/26/2014 07:26 PM:

On this topic (which is about the Choose a language language that
DrRacket starts in when newly installed), I think we should just
delete all of this code, and start in the Racket language.


How about make Run and other very language-specific DrRacket operations 
require a #lang line?


When the operation is invoked and there isn't a #lang line, pop up an 
explanatory dialog box that lets user click on button for desired 
language.  Button inserts #lang at top of file before continuing with 
operation.


(I like this better than having a default #lang line, because you'll 
get people accepting the wrong default, different people with different 
defaults, etc.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] comments on comments on learning Racket

2014-04-26 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 04/26/2014 08:06 PM:

On Sat, Apr 26, 2014 at 7:58 PM, Neil Van Dyke n...@neilvandyke.org wrote:

Sam Tobin-Hochstadt wrote at 04/26/2014 07:26 PM:


On this topic (which is about the Choose a language language that
DrRacket starts in when newly installed), I think we should just
delete all of this code, and start in the Racket language.


How about make Run and other very language-specific DrRacket operations
require a #lang line?

When the operation is invoked and there isn't a #lang line, pop up an
explanatory dialog box that lets user click on button for desired language.
Button inserts #lang at top of file before continuing with operation.

(I like this better than having a default #lang line, because you'll get
people accepting the wrong default, different people with different
defaults, etc.)

This isn't quite about the issue I'm talking about, although I think
this is a good idea for helping people deal with (some) problems with
having the wrong language.

What I'm referring to is that when you download DrRacket for the first
time, and open it, it puts you in a situation where nothing works,
until you choose a language. I think we should get rid of that, and
switch to defaulting to the current Racket language.


Yes, but I thought what I described addresses that problem as well. (And 
avoids making a new default from the first run, which I think is 
problematic.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] comments on comments on learning Racket

2014-04-26 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 04/26/2014 08:13 PM:
I'm confused about what you're suggesting, then. Is there a 
difference, under your suggestion, between opening DrRacket for the 
first time, entering `1` in the definitions window, and hitting run, 
and doing that same thing in an existing DrRacket where we've already 
selected the Racket language?


No difference.  No default/preference setting for language.  People will 
learn what they want and either type the #lang line, or click the 
button.  Until people know what they want, they'll keep getting the 
explanatory dialog popup.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] pi, was: Re: [plt] Push #28592: master branch updated

2014-04-22 Thread Neil Van Dyke

Matthias Felleisen wrote at 04/22/2014 01:37 PM:

I think we should dedicate this commit to Kate Bush's PI song (or vice versa?):

   https://www.youtube.com/watch?v=kZSHr5E7fZY


Are Kate Bush dedications a slippery slope?  Software developers will 
tend to work towards the metrics.  Soon the canonical Kate Bush catalog 
gets exhausted, and some desperate programmer winds up coding Bagger 
288.  http://www.youtube.com/watch?v=azEvfD4C6ow


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] gui responsiveness

2014-04-17 Thread Neil Van Dyke

Matthew Flatt wrote at 04/16/2014 01:56 PM:

  (set! needed? #t)
  (queue-callback (lambda () (when needed?
   (set! needed? #f)
   (send this refresh)))
  #f) ; = low priority


This is what I'd try first.  If it works well for your app, there are 
also micro-optimizations you could try atop it (e.g., if event queue is 
empty, do send refresh without queue-callback; and put a big or 
around it all, to not do anything if needed? is true, which I'm 
guessing shouldn't present a malignant race condition if you always 
clear the flag immediately before send refresh).


If that doesn't work well enough for your app, you could try to get 
fancy with prioritizing events (perhaps by moving events off into 
secondary queues, or shoving events back onto the head of the main 
queue), but that could become hard to reason about and debug.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] class implementation and make-primitive-class

2014-04-17 Thread Neil Van Dyke
For purposes of your course project, couldn't you make your own 
class-instance object system, atop structs or hashes, that gives you 
whatever dynamic programming features you want?  It's very-very easy to 
do a basic one (with single inheritance and single dispatch), until you 
get into speed optimizations.


Or, if Swindle has a MOP, you could use that.

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] planet bug tracking system spam

2014-04-14 Thread Neil Van Dyke


Robby Findler wrote at 04/14/2014 01:27 PM:

I think that the problem Neil is having with it is the ridiculous
amount of spam that gets trapped inside it.

(But correct me if I'm wrong, Neil!)


I also have other objections to it.  But if Doug is still using it, I 
guess leaving it running makes sense.  Making an opt-out at this late 
date doesn't make sense.  I will find some other way to punish it.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] planet bug tracking system spam

2014-04-13 Thread Neil Van Dyke

Can the PLaneT bug-tracking system be shut down, please?

(I have never wanted my packages to be in the PLaneT bug-tracking 
system.  It has never been anything for me but counterproductive and 
annoying.  It was not there when I first added my packages to PLaneT.  I 
really-really want to opt-out of it.  But maybe whoever maintains it 
will decide that shutting it down is less work than adding an opt-out 
feature.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] zoom-to-fit-width text in new documentation layout

2014-04-13 Thread Neil Van Dyke

In the new documentation layout, the zoom-to-fit-width behavior is bad.

I mentioned this before 
(http://lists.racket-lang.org/users/archive/2013-November/060480.html;), but 
I don't recall hearing any rationale, and it doesn't seem to have changed.


Is this going to be changed, or do I have to write a Greasemonkey script?

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.

2014-04-09 Thread Neil Van Dyke
* Is anyone up to auditing the C code?  To support my earlier concern 
(http://lists.racket-lang.org/dev/archive/2014-February/013935.html;), 
you've probably heard in the last few days about a C oops bug in OpenSSL 
that has compromised the private keys of 2/3 of the Internet for over a 
year now.  I think we are going to keep seeing exploits like this in 
SSL/TLS/etc. implementations, because some of the protocols are hairy, 
and the implementations don't seem to be perfect like they we need them 
to be.


* Are all the new (to Racket) OpenSSL code paths enabled by this change 
disabled *entirely* by default, or are there some new-to-Racket code 
paths that can be negotiated by the other party with the default Racket 
use of OpenSSL?  The reason I ask is that I believe that the fewer 
unnecessary OpenSSL code paths available, the fewer OpenSSL 
vulnerabilities available.


(BTW, I'm not harshing on OpenSSL entirely.  OpenSSL been indispensible 
for some of my work, dealing with myriad oddball security protocols that 
no one wants to take the huge development cost hit of coding and 
validating from scratch.  But I don't have a high level of confidence in 
the code.)


Neil V.

Edward Lee wrote at 04/09/2014 04:20 PM:

I previously submitted this patch in late January; I've not received any
progress updates with regards to this patch recently - did this patch
get lost between then and now?

This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings.
This patch has been tested on Ubuntu 12.04 (and appears to work
correctly in a production environment).


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.

2014-04-09 Thread Neil Van Dyke

Edward, your patch sounds OK to me, FWIW.

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Too many license files

2014-02-21 Thread Neil Van Dyke
For at least third-party packages (though you might want something 
trickier for core Racket)...


I'm not a lawyer, but I figured that, for most packages I author, I 
probably don't *need* to include the full text of a well-known license 
(e.g., LGPLv3).  Instead, I give the copyright notice, state that the 
license using the recognized full name of the license (and a URL), and 
then some disclaimers.


I include this legal info in metadata in info.rkt, and McFly makes it 
appear automatically in the documentation (with, e.g., LGPLv3 at the 
top of the document, and the free-form legal blurb at the end of the 
document).  Example at: http://www.neilvandyke.org/racket-roomba/


I've started to also add a one-line copyright notice at the top of each 
source file in the package, something like ;; Copyright Neil Van Dyke. 
See file info.rkt.  (I might have to move to a legal notice comment 
block at the top of each file, but I'd really rather not.  Notice blocks 
don't seem to be a barrier to abuse anyway.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] [patch] OpenSSL ECDH(E) + DHE support.

2014-02-09 Thread Neil Van Dyke

Edward Lee wrote at 02/08/2014 05:52 PM:
[...]

Racket's OpenSSL bindings do not currently enable the ECDH(E) and the
DHE ciphers, which are needed for perfect forward secrecy.

I've attached a patch that:
   

[...]

First, thanks for taking the initiative and contributing.  Second, I 
feel a little embarrassed saying this, since I don't have time to 
volunteer myself right now, but I think the following is important...


I suggest that any contributions touching SSL in the core need careful 
auditing by someone who understands the mechanics fully.  If Edward is 
an expert on this aspect of OpenSSL, his audit would be fine, but 
otherwise someone else has to audit it.


To emphasize: The SSL infrastructure and OpenSSL are both hairy, and a 
small mistake can defeat SSL altogether without being detected for 
years.  This has actually happened before, notably with SSL traffic on 
Debian and Ubuntu systems being compromised for over a year by a 
one-line mistake 
(https://www.schneier.com/blog/archives/2008/05/random_number_b.html;).  From 
a Racket extension perspective, in addition to possible logic errors of 
API usage, there's also possible C memory errors through the FFI.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Racket v5.92

2014-01-27 Thread Neil Van Dyke
The 5.92 CSS also doesn't seem to differentiate the different link types 
by color or other visual emphasis.


IMHO, this is a step backwards, especially when it comes to visually 
distinguishing the three kinds of links: (1) identifier definition; (2) 
tech, and (3) everything else.  As I said in an earlier message on the 
CSS, overall I think the CSS is an improvement, but the new links 
appearances are a poor for reading typical Racket docs with their 
plethora of links.


Neil V.

Asumu Takikawa wrote at 01/27/2014 10:54 AM:

BTW, the 5.92 docs are missing some of the recent CSS changes from HEAD.
Could we cherry-pick some of those for 6.0? For example, the blue boxes
don't work here:
   http://docs.racket-lang.org/inside/Evaluation.html
   

[...]

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] new package system status

2013-11-20 Thread Neil Van Dyke

What's the status of the package system?

This morning I thought I'd compromise, and use the new package system 
for a package that would only ever need one version installed per Racket 
installation (though I still really want multiple-installed-version 
support for libraries, like PLaneT has in some form).  This was the 
fourth time I tried to use the new package system, and what I found was:


* The documentation for the package system in 5.3.6 does not seem to 
reflect previous discussion, and the chapter title still says (Beta).


* https://pkg.racket-lang.org/; has roughness like requiring JavaScript 
to navigate, which is not only bad for browsers but bad for search 
engines.  (Usually, for this kind of site, we'd want to start with a 
page structure, and then add in backward-compatible JS for slickness.)


* How are people even supposed to view package documentation while 
browsing packages on https://pkg.racket-lang.org/;?  For example, I 
looked at a package that I knew had documentation (someone had put an 
old version of one of my PLaneT packages into pkg.racket-lang.org[*]), 
and the only way one could view the documentation in any form is if they 
knew to navigate several clicks through the Github repository to find 
the .scrbl source file buried in one of the directory trees.


I understand that PLaneT was a pain to package for, especially without 
McFly, and so people releasing packages like that the new package system 
means less immediate work for them (just put github repo URLs for them 
all, and let G-d sort 'em out), but it's unclear that the new package 
system is improving its third-party packages story.  Is it still focused 
on breaking up core Racket, and someday we'll see more thinking about 
third-party packages?


[*] Ahem, in the process of someone forking my package into the new 
thing, they lost my name from the metadata, broke my legal notices, and 
added a LICENSE file that claimed copyright to their name.  I'm sure 
that was just a careless accident, since that package has some of the 
very first Scheme code I ever wrote, and nobody would claim ownership of 
it intentionally. :)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] reading :foo as keyword in Racket 6.0?

2013-11-06 Thread Neil Van Dyke
Any chance that 6.0 will read symbols beginning with : (other than : 
exactly) as keywords?


(I was thinking that a major version number might be a good time to do 
this change, in case anyone is concerned that the change might break 
some code somewhere.  IIRC, someone said there was a SRFI implementation 
that kludged its own keywords from symbols and might need a small tweak 
in response to this change.  I'm not aware of any other code that would 
be affected by this change.  Racket could continue to *write* keywords 
with #: for now, if that makes the change easier.)


P.S., This change would make this the most magical holiday season ever.

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] should package X imply package X-test?

2013-10-16 Thread Neil Van Dyke
I'm speaking of third-party packages only; I don't know about the 
packages that make up core Racket.  (But perhaps whatever is done for 
any special needs of core Racket can avoid complicating things for 
third-party packages.)


For third-party packages, for the audience of technical users of Racket, 
I think that getting documentation, source code, and tests by default is 
a good thing.  Not only do technical users often want those things, but 
IMHO we should be encouraging people to use those things.  This could be 
the simple case.


For use or installation of third-party packages on very small devices, 
such as on an OpenWRT router, or for packaging shrinkwrap apps, maybe 
there should be a directive in info.rkt for what files can be excluded 
in ``tiny'' installations, in addition to not including docs.  This 
seems like an unusual case, but seems like there is a simple solution, 
while also keeping the usual case simple.


For third-party package authors who want to avoid some big dependency in 
the tests (e.g., huge data set, or dependencies on some other packages), 
maybe the solution is the same as ``tiny'' above, maybe they need to 
separate out some of their tests into a separate package, or maybe the 
dependency is not all that necessary.  This too seems like an unusual 
case to me, although I do have one package myself that kinda runs into 
it (non-small test files in 
http://www.neilvandyke.org/racket-mediafile/;).  Again, it seems to me 
like the solution for this unusual case is simple and keeps the usual 
case simple.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Revising Racket's home page

2013-08-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 08/20/2013 09:40 AM:

Are you referring to the Quick tutorial?  I don't think that's aimed
at children, per se -- just people who have no experience w/ Racket.
   


OK, I can only offer a single data point: to me, one glance at the 
Quick tutorial looks like educational language for children; close 
browser tab and find another thing to look at.  I don't know how anyone 
else perceives it.



  I also don't think we need to give up and assume that
we can't create a page that works for everyone.
   


OK.

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Revising Racket's home page

2013-08-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 08/20/2013 09:52 AM:

Can you say more about why this is? Is it the pictures?
   


Yes, I scroll down the page and I see pictures and a simple picture 
language, and it seems to be using them to introduce some pretty simple 
and familiar concepts, so I assume it's for children.



  How does it
compare to one of these tutorials for Processing:
http://processing.org/tutorials/ ?
   


Processing is considerably cooler, in a hipster-designer way, than 
Racket.  Processing has street cred before people ever see a tutorial.  
Cool kids start from a very different position than us nerds, and even 
if they shouted, Look at my circles, pledge dog, look at them!, people 
would lap it up.  And the Processing circles probably would be cool circles.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] racket 5.3.6 db/postgresql ssl performance fix

2013-07-24 Thread Neil Van Dyke
Did a PostgreSQL SSL performance fix get into 5.3.6 pre-release in some 
form?


In the pre-release I just downloaded, I don't see Ryan's original fix to 
collects/db/private/postgresql/connection.rkt.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] racket 5.3.6 db/postgresql ssl performance fix

2013-07-24 Thread Neil Van Dyke
Thanks, Ryan.  And thanks for the earlier reminder for me to test the 
pre-release; I was distracted with other work, and probably would've 
missed this pre-release.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] package-system update

2013-07-15 Thread Neil Van Dyke

Matthew Flatt wrote at 07/13/2013 02:56 PM:

Others seem
overwhelmed by the details, unsure of how it will all work out, and
disconcerted by conflicting messages from others who seem to
understand the issues.


BTW, I don't know whether I'm involved in anyone being disconcerted.  If 
I am, please let me clarify that I agree that this effort looks like a 
win for development of variations on core Racket, and for packaging of 
shrinkwrapped apps built with Racket.  (Praisecondolences to those 
people doing a lot of non-fun work to achieve those goals.)


In addition to those goals, I also had some research and advocacy goals 
that are affected by the package system model.  Now is not the time to 
get into that, but perhaps we can discuss at a later date, as the model 
evolves in subsequent versions of Racket.


Much secondarily, there are lots of little details, about which 
different people will feel differently.  I suspect we'll all quickly get 
accustomed to the little details, and if any little detail becomes 
ornery for lots of people, it could be refined.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-18 Thread Neil Van Dyke

Matthew Flatt wrote at 06/18/2013 07:59 AM:

In principle, you should add a versioned dependency on racket to
indicate that the package does not work with version 5.3.4, and so
users of v5.3.4 should get an earlier revision of the package.


Just a general comment... For production use, I try not to have 
libraries push people to new versions of Racket without good reason.


Despite my general awareness and practice, I was actually bit by this 
problem recently.  A consulting client who used one of my open source 
libraries in production had a problem that I had addressed in a new 
version of the library.  But it turned out that an interim version of 
the library added a dependency on some new Racket feature, and client's 
production setup would be disrupted if they had to move Racket versions 
(increases unknowns).  I ended up forking my own library for the client, 
and merging the fix into their fork.


In the more distant past, I think I've also had at least one situation 
in which I made a Racket (or PLT Scheme) library version use some new 
Racket feature, then in a subsequent version I reversed this change, so 
that it could work with an older Racket version.


This doesn't have to be a big encumbrance -- I do adopt new Racket 
features when they are win (e.g., submodules, define-logger), but I try 
to make small efforts to avoid requiring newer Racket versions than I 
really need, since pushing people to new Racket versions does seem to 
cause problems in practice.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] ready for the package switch?

2013-06-18 Thread Neil Van Dyke

Carl Eastlund wrote at 06/18/2013 01:36 PM:
rantI don't understand why version control systems don't take 
directories and renames more seriously, because this stuff is part of 
the development cycle and should be recorded like any other change./rant


This doesn't help, but...  I think the reason is that it's hard to do, 
so most SCM systems haven't even tried.  It's very common for a rename 
to be a delete-plus-add in the model.  Or, in an RCS/SCCS/etc.-backed 
system like CVS, for someone to simply rename the files in the 
repository server's filesystem and break any branches that did not want 
those files renamed.


Perhaps the most sophisticated SCM I've used, Atria ClearCase (a 
descendant of Apollo DSEE) in the early-mid 1990s, had a much more 
sophisticated model than the others, and, IIRC, even did fancy things 
like monitoring filesystem operations(?), but it cost a lot of money and 
required a lot of sys-admin.


Git's free-ness and popularity makes it the obvious choice to use 
nowadays, but in my limited experience with it, Git seems to have a lot 
of evolution of let's add on yet another somewhat different concept to 
our numerous existing concepts that originally built upon some scripts 
that Linus found useful for managing kernel patches, rather than 
nailing a clean and sufficient model from the start.  This is a source 
of frustration to those of us who have used a dozen other SCM systems 
and recall basic things being easier to do in the past.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Keywords

2013-06-17 Thread Neil Van Dyke

Laurent wrote at 06/07/2013 02:12 AM:


What I'd really like, for the sake of flexibility / ease of use, is to
have no explicit keyword argument, but all arguments are implicit 
ones, so
that you can call a function by mixing by position and by name as you 
like,

without having specified so in the function's header.
(Visual Basic[1] and Python[2] do something along these lines.)



I have used this in Python, and it is kinda neat and has its uses, but 
overall, I prefer the current way in Racket.


One reason I prefer the current way in Racket is that, if every argument 
can be positional, then you have to keep this in mind when adding 
keyword arguments to a procedure that is used by other code: new 
arguments can only be added at the end of the list, even if that does 
not make the most sense for documentation purposes.


Another reason is that the keyword arguments restrict the syntax 
somewhat, so, when a mistaken extraneous sexp is where we'd expect a 
keyword, it is flagged as an error, rather than be considered a 
positional argument.


Related to the previous reason, if the programmer is *intentionally* 
intermixing keyword arguments with positionals, such as (foo 37 #:x 41 
74 #:a 34), that seems error-like that I wish they would get an error 
and change their ways.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-14 Thread Neil Van Dyke
I've been hesitant to comment on any of this, for three reasons: (1) 
I've read the new package system documentation on at least 3 separate 
occasions, and -- perhaps because I'm biased by having already formed 
some ideas about where I'd like things to go -- I've had trouble 
understanding the rationale behind a lot of the decisions; (2) I'm not 
familiar enough with DrRacket internals to know whether there's some 
unusual barrier to keeping things simpler than it seems like people have 
been talking about, so I can't help with that; and (3) I'm confused 
about what's already decided and what's open to discussion, and suspect 
it would take many more hours to understand.


Since I'm heavily invested in Racket packages but lost in the current 
discussion (sorry), all I can offer right now are some comments that 
start from the concepts of the original PLaneT, in case anyone who 
understands the new system sees anything of interest in this quick brain 
dump...


For all of my packages, as well as any package I can imagine, I think 
that the original PLaneT got many things right or close to right:


* Some kind of unique package-name controlled by a developer.

* Multiple versions for a given package-name (I'll call them 
package-versions in this email) can be installed, and there is some 
version selection mechanism.


* Files from a package-version end up grouped together in the directory 
structure, specific to that package-version, and certainly not mixed 
into directories with files from package-versions of different 
package-names.


* Flat namespace (let's ignore the PLaneT package-owner part for now), 
without attempt to name packages according to some topical ontology.


* Metadata in info.rkt.

I was expecting to use this original PLaneT as a starting point, and 
evolve it in ways like the following...


* In addition to the (planet ...) require-specs, package-versions also 
can come from http:, https:, and git: URLs.  (github: would also 
be OK.)  Each such URL would identify trees or a tarball.  Then we see 
how people choose the PLaneT server vs. HTTP vs. Git over time.


* Simple web-of-trust package-version public-key signing of 
package-versions (e.g., URLs plus hashes of contents), to start with, 
perhaps initially with only centralized repository for signatures.  Soon 
build distributed web-of-trust, plus multiple repositories so 
organizations have option to keep their signatures separate.  Build 
mechanisms atop that, including advancing the state of the art.


* Maybe improve the version-selection and compatibility support.  
Investigate whether it's worthwhile to separate out the 
backward-compatibility information from the static package-version 
distribution (and especially from the version number), or whether in 
practice there are simpler ways that are satisfactory.


* Maybe a facility in info.rkt to provide aliases for require specs.  
Otherwise, people writing nontrivial multi-file code that uses other 
packages from PLaneT/whatever end up having to make wrapper modules so 
that we don't goof our require-specs and accidentally depend on multiple 
package-versions for the same package-name.  Note that, with URLs, these 
aliases *might* be the only actual package-name construct in the 
HTTP/Git system as distinct from URL similarities of package-versions.  
This info might be implicit in a package-version's info.rkt's 
reference to a previous package-version, perhaps coming from an 
assertion of compatibility info.  This might be simpler than it might 
sound, but it has some interesting implications, including for forking 
and web-of-trust.)


* Automate and simplify releasing in general.  With PLaneT, it's been 
not-unusual for even core Racket developers to avoid releasing some 
add-on code to PLaneT, perhaps because the clerical stuff was a 
headache.  For the old PLaneT, I was simplifying this with McFly, but 
with new a package mechanism, I would start with that and then ask what 
clerical parts still need help.  (For example, if doing development in 
an SCM repository that's accessed directly via require-specs, then 
releasing a package-version might consist mainly of adding a tag/label.  
planet-lang.org's directory might even update automatically, given info 
about a previously-released package-version of the same package-name.)


* Use submodule support to support single-file packages, at least for 
the HTTP/Git package-versions.  (module+ info ...).  It seems from 
Emacs history that some people really like the single-file module, it 
lowers barriers, and now submodules give us an easy way to finally do it.


* Do whatever is necessary to avoid blocking the program for 
few/several-minutes while documentation is reformatted, when requiring 
an uncached package-version.  Maybe even moving it to an async process 
that's run when idle (Unix nice?) would work.


* To put it vaguely: keep things simple in most cases, but don't 
dumb-down in practically restrictive ways, and 

Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.

2013-06-08 Thread Neil Van Dyke
Mayank, paredit-like features for DrRacket would be good.  You might 
also want to look at some similar work from around the same time as 
paredit was created: http://cs.brown.edu/research/plt/software/divascheme/


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.

2013-06-08 Thread Neil Van Dyke

Asumu Takikawa wrote at 06/08/2013 05:26 PM:

(maybe you can port paredit by replacing the emacs text buffer
  manipulation function calls with method calls into these interfaces)
   


If you wanted to make it even more cool... One of the original goals of 
Guile (a Scheme implementation that was once intended to be the new GNU 
language, including for Emacs) was to implement backward-compatibility 
interpreter for existing Emacs Lisp add-ons code.  If someone made a 
Racket #lang emacs-lisp that used DrRacket text buffers -- even if 
only a small subset of Emacs Lisp operations -- I think that would earn 
them some kudos, besides being a fun exercise for Racket's language 
support.  (The hardest part might be translating some of the Emacs Lisp 
dynamically-scoped variables into Racket parameters.  You don't need the 
dynamic scoping for most of them, though, but you have to decide which 
ones.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] proposal for moving to packages

2013-05-20 Thread Neil Van Dyke
I'm calling for making Racket and package source transparently 
accessible, even though not actually bundled into distribution downloads...


Racket has a research and education bent, and also attracts some of the 
more sophisticated developers.  For all of these audiences, there's a 
tradition of accessibility of source, and arguably value in that.


I think transparent navigability to source would be appropriate for 
Racket.  Transparent navigability to source could mean that DrRacket 
will download source on-demand for any binary package that is installed, 
rather than source having to be bundled with the package, or requiring 
user to go get source separately.


Admittedly, I think source accessibility is not as important in Racket 
as in Emacs.  (Because, for general programming, the Racket 
documentation is sufficient and the source wouldn't help.  And for 
extension of the programming environment, which was one of Emacs's 
greatest achievements, extending DrRacket is much harder; plus, the 
DrRacket source is not much help if you didn't previously tackle the 
manuals on frameworks and such, which almost no one does.)  But there 
are uses for source accessibility, especially for independent add-on 
packages, and the principle of being able to easily pop the hood still 
has value.


Example: Imagine I'm in the middle of writing a Racket program and am 
wondering about characteristics of some kind of I/O port in Racket.  
With transparent source accessibility, I can just click on an identifier 
in my program in DrRacket to start browsing the implementation.  Maybe I 
see a possible improvement, or seeing the source pre-empts yet another 
email list question that otherwise only Matthew could answer, or I feel 
empowered to go add a new feature.  If the source is not as accessible, 
then I'm more likely to be a mere naive user of the tools, rather than 
to understand the tools and help improve them.


Side note: I'm also looking forward to seeing how this new packaging 
works out, especially if it leads to me being able to ship small binary 
packages for iPhone/Mac/Windows, implemented in Racket.  (I don't care 
about open source principles on those very closed platforms; I just want 
their money.  Which is totally different from what I want from an 
intellectually-inclined open source development platform.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] proposal for moving to packages

2013-05-20 Thread Neil Van Dyke

Juan Francisco Cantero Hurtado wrote at 05/20/2013 11:20 PM:


I also think that git submodules are a bad idea for packages. One git 
repo per package is more simple and less problematic.


Do people expect to often do commits involving changes across these 
package boundaries?  If so, would another option be to keep a single 
repo, not use these Git submodules, and just have Racket translate the 
Git paths behind-the-scenes for packages coming from this core Racket repo?


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Symlink trouble

2013-04-17 Thread Neil Van Dyke

Matthew Flatt wrote at 04/17/2013 10:39 AM:

It would be great if we could normalize every path
to a canonical form, but path normalization in general seems to
intractable due to the possibilities of soft links, hard links,
multiple mount points, case-sensitivity choices, and probably other
twists that I'm forgetting.


Agreed intractable, and agreed with your approach.

Just FYI for anyone who Googles this in the future and wants a limited 
but tractable pretty-good path canonicalization for their application 
(at least on Unix-y filesystems)... canonicalize-path from the 
following library might be good enough: 
http://www.neilvandyke.org/racket-path-misc/  (I wrote this for 
scan-mediafiles in http://www.neilvandyke.org/racket-mediafile/;, and 
put it in a separate PLaneT package because I've needed such a procedure 
from time to time.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] amd64 out of memory

2013-04-16 Thread Neil Van Dyke
On these out-of-memory conditions, you might want to look at the kernel 
logs for what the OOM-killer said about what processes were running, 
their sizes, and who it thought the culprit was.


If the OOM logs show GB of virtual memory missing, but not used by any 
userspace process, you might want to email me privately so we can 
compare notes.  I've seen multiple instances of this quite recently, on 
multiple systems.  My prime person-of-interest is a particular kernel 
service that is used actively by only a small minority of GNU/Linux 
installations.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] planet2

2012-12-10 Thread Neil Van Dyke

Jay McCarthy wrote at 12/10/2012 02:22 PM:
On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke n...@neilvandyke.org 
mailto:n...@neilvandyke.org wrote:



* I'm very concerned about discarding support for mixing versions
of packages.  PLaneT 1 didn't fully nail this, but I suspect
planet2 is punting needlessly, rather than getting data and
solving problems (perhaps due to changing mission, as speculated
in next two points).


My rationale is that what OSes provide is good enough for wide uses 
and we can more easily build the right versioned package system on top 
of this than a non-versioned package system on top of one that is 
versioned.


Perhaps some multiple version support can be grafted on later 
satisfactorily.  I'm just surprised by abandoning the problem, after 
PLaneT made a credible first attempt, and before Racket actually got 
much experience with apps built from lots of independently-developed 
packages.


I still suspect that multiple versions support is a good thing and 
doable.  I wonder whether the design of a new packaging system would 
benefited from having worked through the versioning problem in the 
earlier stages of design, rather than after migrating people from one 
system to a new one.  I don't really know.


For example, the various library collections on P1 (like scheme, 
unlib, etc) seems to me a product of the pain of P1 deployment 
encouraging monolithic packages.


There are also lots of small, loosely-coupled packages in PLaneT.  
Certainly, getting things into PLaneT is tricky, and sometimes, even if 
people got one version into PLaneT, sometimes they'd tell people a 
better version is in Git because they didn't want to go through PLaneT 
hoops again.  And there are other reasons people make monolithic 
libraries -- this is not at all peculiar to PLaneT.  Which is part of 
why I was planning in my book to push people to developing around 
loosely-coupled reusable modules, with very low friction to moving the 
module to PLaneT.  I was working on tools to make that a reasonable story.



* Related to previous point, it also looks like there *might*
(unclear) be a desire to increasingly centralize or canonicalize
some of the kinds of library work that I've been thinking are
generally best done in a more decentralized and organic manner.
 If so, have to be careful with this.


I assume you are referring to the suggestion to (a) use known 
collections like data, (b) not give things cute names, and (c) not 
name things after developers. 


No, it looked like it might be an implicit, pervasive influence.

This would, for instance, make it so that we have net/soap package 
rather than roap, unroap, and super-soap. I think this is a good 
thing. We should be encouraging collaboration to produce excellent 
packages rather than having many 20% solutions.


If one has the resources to pull this off, more power to one.  I'm not 
sure Racket has the resources.  (One way you could do it is if PLT 
Design hired expensive full-time engineers who don't have 
research/teaching commitments.  Or you could do it as projects for 
undergrad team software engineering courses, but I suspect the quality 
of design and implementation would often not be up to what people come 
to Racket for.)


I suspect there's still a big place for grassroots library development 
for Racket.  So I hope the design of the new package system hasn't been 
biased away from grassroots needlessly.


Above are my main points.  Rest of this email is asides, some 
supporting, and some tangential.  All can be skipped.


If you want me to see a response, please CC me.

* * *

Aside #1: On your net/soap example... I think a generally better 
practice would be to name it soap rather than try to munge a 
conceptual taxonomy into the name as net/soap, unless net/ is some 
intertangled framework (which it doesn't seem to be).  The taxonomies 
change over time -- more frequently than the names should.  I think one 
of the PLT lists discussed this before.  Thankfully, people nowadays 
avoid putting these taxonomies as part of the key for most purposes.  
For example, package namespaces for various GNU/Linux distros are flat, 
even if they tend to use taxonomies for UI purposes elsewhere.  For a 
negative example fresh in my mind, CDDB is reviled for using genre as 
part of its key, rather than showing more foresight with their namespace.


Aside #2: Don't be *too* hard on the cutesy names.  Even when projects 
do the officially blessed module with boring name, they tend to wind up 
with better modules arising separate from the official one.  If they do 
eventually move to bring the iconoclast into the fold, blessing it with 
an official generic name, sometimes they tack a 2, new, ng, or 
other suffix/prefix onto the old generic name, or sometimes they simply 
break backward compatibility, so you get people talking about which 
version of a language you used for an app when they're really asking

[racket-dev] planet2

2012-12-09 Thread Neil Van Dyke

My biggest comments on planet2...

* I like the general ideas of permitting more decentralized sharing of 
packages (such as through some kind of Git URLs).


* I like the idea of making it easier to modify the source of a package 
and share changes with upstream (which is needlessly cumbersome with 
PLaneT 1).


* I'm very concerned about discarding support for mixing versions of 
packages.  PLaneT 1 didn't fully nail this, but I suspect planet2 is 
punting needlessly, rather than getting data and solving problems 
(perhaps due to changing mission, as speculated in next two points).


* Other than GitHub support, a lot of what I saw in the planet2 
documentation was not intuitive to me, wrt how I was thinking would be a 
good direction for Racket grassroots package development.  It looks like 
maybe planet2 is biased towards the way core developers work (e.g., 
centralized, large, monolithic code base, with single version), and/or 
towards modularizing Racket distributions, rather than towards 
grassroots package development.


* Related to previous point, it also looks like there *might* (unclear) 
be a desire to increasingly centralize or canonicalize some of the kinds 
of library work that I've been thinking are generally best done in a 
more decentralized and organic manner.  If so, have to be careful with this.


* We'd talked about planet2 on-and-off for years, but I didn't realize 
planet2 was imminent, so I recently somehow managed to spent a lot of 
unpleasant time working on PLaneT tools and such that now look moot in 
light of planet2.  Every now and then, the rug gets pulled out from 
under a non-core developer (this has happened a few times that I know 
of), and it can be a waste of energy and morale, so we should keep 
trying to avoid rug-pulling when practical.


I have numerous small comments, (like, just from glancing at currently 
open browser window) you probably don't want to call anything PNS, and 
the names galaxy, solar-system, and planet would be confusing 
(something else already called planet that is very related, plus 
running into HtDP world, universe, etc.).  Before I'd nitpick at 
that small level of issue, I'd need the bigger questions above 
addressed, and then I'd have to get practical experience with planet2 
and comment on that level of issue.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Revision to the Language Dialog

2012-11-06 Thread Neil Van Dyke

Matthias Felleisen wrote at 11/05/2012 10:14 PM:

* racket/base (for scripting)
* racket (for programming)


After thinking about it, I think I see what you mean with the 
distinction between ``for scripting''  and ``for programming''.  But I 
think this might be confusing.


(Explanation... I have been thinking of it the other way around: #lang 
racket is what you use when you want to just start typing and have 
everything available and type less text, in a scripting-language kind of 
way, and #lang racket/base is what one uses when putting a little more 
care into engineering, and doesn't mind the extra thinking and text.  
For example, when making a reusable PLaneT package, I think it's good 
practice to go to the extra effort to use #lang racket/base instead of 
#lang racket; otherwise, you doom all users of your package to pull in 
all of #lang racket, which they might have engineering reasons not to 
do.  But I guess you were speaking only of process load times -- that 
people would use racket/base so that standalone ``scripting'' programs 
would load quicker from the command line -- not about a quick-scripting 
nature of the programming activity?)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #25466: master branch updated

2012-10-16 Thread Neil Van Dyke

John Clements wrote at 10/16/2012 04:51 PM:

Data point: I have no idea what define/match does, and the name by itself does 
nothing to enlighten me.
   


Another data point: If define/match expands to a define of a 
procedure that dispatches to a set of implementations based on a 
pattern-match of actual arguments... then the name is exactly what I'd 
expect for such a feature in a Scheme dialect.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Racket 5.3 pre-release impressions?

2012-07-29 Thread Neil Van Dyke
Thanks, Doug.  From talking with a few people, it sounds like 5.3 is 
shaping up pretty normally for a release, and the releases have been 
high-quality.


I was just a little spooked by running into two bugs very quickly (two 
points determine a line, after all), but I haven't found any since those.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?

2012-07-28 Thread Neil Van Dyke

Matthew Flatt wrote at 07/26/2012 06:36 PM:

I've pushed a repair. Thanks for the report!


Thanks, Matthew.  Today, I plan to run a large pile of code through the 
20120727 pre-release.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] possible 5.2.900.1 bug involving rest argument

2012-07-28 Thread Neil Van Dyke

Looks like a minor compiler/optimizer bug in Friday's 5.2.900.1 pre-release.

I haven't yet found a simpler test case, but you can reproduce by 
installing a particular PLaneT package as shown below.


The line 1275 it's complaining about is the following, which starts a 
procedure definition that is later applied at toplevel in the same module:


(define (charterm-make-keydec keydec-id . keysets)

The demo program for this PLaneT package seems to run correctly despite 
these install/compile-time error messages.


Racket 5.2.1 does not give these install/compile-time errors, as is also 
shown below.


$ /usr/local/racket-5.2.900.1-20120727/bin/raco planet remove neil 
charterm.plt 3 0

[...]
$ /usr/local/racket-5.2.900.1-20120727/bin/racket -p neil/charterm:3:=0
andmap: contract violation
  expected: list?
  given: 
'(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 
keydec-id . 
#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 
keysets)

  argument position: 2nd
  other arguments...:
   #procedure:void
andmap: contract violation
  expected: list?
  given: 
'(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 
keydec-id . 
#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 
keysets)

  argument position: 2nd
  other arguments...:
   #procedure:void
raco setup: error: during making for planet/neil/charterm.plt/3/0 
(CharTerm)

raco setup:   andmap: contract violation
raco setup: expected: list?
raco setup: given: 
'(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 
keydec-id . 
#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 
keysets)

raco setup: argument position: 2nd
raco setup: other arguments...:
raco setup:  #procedure:void
raco setup: error: during Building docs for 
/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/doc.scrbl

raco setup:   andmap: contract violation
raco setup: expected: list?
raco setup: given: 
'(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 
keydec-id . 
#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 
keysets)

raco setup: argument position: 2nd
raco setup: other arguments...:
raco setup:  #procedure:void
$

$ /usr/local/racket-5.2.1/bin/raco planet remove neil charterm.plt 3 0
[...]
$ /usr/local/racket-5.2.1/bin/racket -p neil/charterm:3:=0
[...no output...]
$

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] Racket 5.3 pre-release impressions?

2012-07-28 Thread Neil Van Dyke
Regarding Racket 5.3, I am more cautious than I recall being about a 
previous Racket minor version release.


The information I have so far is mixed, rather that overwhelmingly 
reassuring.


If anyone has comments on their sense of 5.3 reliability at this point, 
that might help me.


Some good news: one of my consulting clients had me do some preliminary 
testing of their large code base with the Racket 5.3 pre-release, and 
there has been no problem with that testing so far.


However, in testing 5.3 pre-releases with my personally-owned code, 
rather than clients' code, so far I've found what looks like 2 bugs in 
the 5.3 pre-release.  This was surprising to me, since I expected 0 
bugs.  I have not yet tried the majority of my personally-owned code.


Until I get a better sense, I would expect to keep production servers at 
5.2.1 for a while after the 5.3 release.  I'm also probably going to go 
to some trouble to avoid using new 5.3 features in some code that might 
be deployed to production in the very near term.


More information might be reassuring to me.

Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Racket 5.3 pre-release impressions?

2012-07-28 Thread Neil Van Dyke
FWIW, I just tested 16 or so additional PLaneT packages in DrRacket 5.3 
pre-release, and no problems.


Neil Van Dyke wrote at 07/28/2012 02:56 PM:
Regarding Racket 5.3, I am more cautious than I recall being about a 
previous Racket minor version release.


The information I have so far is mixed, rather that overwhelmingly 
reassuring.


If anyone has comments on their sense of 5.3 reliability at this 
point, that might help me.


Some good news: one of my consulting clients had me do some 
preliminary testing of their large code base with the Racket 5.3 
pre-release, and there has been no problem with that testing so far.


However, in testing 5.3 pre-releases with my personally-owned code, 
rather than clients' code, so far I've found what looks like 2 bugs in 
the 5.3 pre-release.  This was surprising to me, since I expected 0 
bugs.  I have not yet tried the majority of my personally-owned code.


Until I get a better sense, I would expect to keep production servers 
at 5.2.1 for a while after the 5.3 release.  I'm also probably going 
to go to some trouble to avoid using new 5.3 features in some code 
that might be deployed to production in the very near term.


More information might be reassuring to me.

Neil V.


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


[racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?

2012-07-26 Thread Neil Van Dyke

Anyone know offhand why this error with 5.3 pre-release from yesterday?

UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573]
  context...:
   
/usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: 
loop
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: 
%html-template:transform
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0


I built Racket from source.  32-bit x86 on Debian Stable.  I don't think 
there are any old versions of code in compiled directories being 
picked up, but I might have missed some, but I'd expect get an error 
message about the version mismatch.  PLaneT html-template:1:1 is 
currently a bit messy with syntax objects and phases, and might be doing 
something questionable that 5.2.1 permitted.  This works fine with 
Racket 5.2.1.


Unfortunately, I don't have time to debug at this moment.  I'm posting 
now because I understand that a release is close, and I don't know how 
likely it is that this is a Racket bug.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?

2012-07-26 Thread Neil Van Dyke

Definitely looks like a Racket bug (or really broken hardware/OS)...

If I start DrRacket 5.2.900.1-20120725 and load up the below file, the 
first few clicks on the Run button give the ill-formed code error, and 
then, after trying the Run button for 10+ seconds, suddenly Run starts 
working.


#lang racket/base
(require (planet neil/html-template:1:=1))
(html-template (hr (@ (clear all) (id foo

If I quit DrRacket and start it back up, the problem is reproducible.

Problem with background optimizing of some kind?

That's all I can spend on this right now; hopefully other people can 
reproduce based on this info.


Neil V.

Neil Van Dyke wrote at 07/26/2012 05:18 PM:

Anyone know offhand why this error with 5.3 pre-release from yesterday?

UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573]
  context...:
   
/usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: 
loop
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: 
%html-template:transform
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0 



I built Racket from source.  32-bit x86 on Debian Stable.  I don't 
think there are any old versions of code in compiled directories 
being picked up, but I might have missed some, but I'd expect get an 
error message about the version mismatch.  PLaneT html-template:1:1 
is currently a bit messy with syntax objects and phases, and might be 
doing something questionable that 5.2.1 permitted.  This works fine 
with Racket 5.2.1.


Unfortunately, I don't have time to debug at this moment.  I'm posting 
now because I understand that a release is close, and I don't know how 
likely it is that this is a Racket bug.


Neil V.


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?

2012-07-26 Thread Neil Van Dyke

This version :2:0 is a better test case than :1:1 :

#lang racket/base
(require (planet neil/html-template:2:=0))
(html-template (hr (@ (clear all) (id foo


Neil Van Dyke wrote at 07/26/2012 05:33 PM:

Definitely looks like a Racket bug (or really broken hardware/OS)...

If I start DrRacket 5.2.900.1-20120725 and load up the below file, the 
first few clicks on the Run button give the ill-formed code error, 
and then, after trying the Run button for 10+ seconds, suddenly Run 
starts working.


#lang racket/base
(require (planet neil/html-template:1:=1))
(html-template (hr (@ (clear all) (id foo

If I quit DrRacket and start it back up, the problem is reproducible.

Problem with background optimizing of some kind?

That's all I can spend on this right now; hopefully other people can 
reproduce based on this info.


Neil V.

Neil Van Dyke wrote at 07/26/2012 05:18 PM:

Anyone know offhand why this error with 5.3 pre-release from yesterday?

UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573]
  context...:
   
/usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: 
loop
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: 
%html-template:transform
   
/home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0 



I built Racket from source.  32-bit x86 on Debian Stable.  I don't 
think there are any old versions of code in compiled directories 
being picked up, but I might have missed some, but I'd expect get an 
error message about the version mismatch.  PLaneT html-template:1:1 
is currently a bit messy with syntax objects and phases, and might be 
doing something questionable that 5.2.1 permitted.  This works fine 
with Racket 5.2.1.


Unfortunately, I don't have time to debug at this moment.  I'm 
posting now because I understand that a release is close, and I don't 
know how likely it is that this is a Racket bug.


Neil V.


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:23 AM:

I was thinking that it'd be more appropriate to put the
'parser-combinator' and 'tex2page' packages under such an account rather
than under mine.
 

Note that it's probably easier for people who need these packages to
use them from GitHub with 'raco link', since then they wouldn't need
to change any `require` lines.
   


Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off 
of Git brand dog treats.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM:

On Fri, Jul 20, 2012 at 7:36 AM, Neil Van Dyken...@neilvandyke.org  wrote:
   

Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
Git brand dog treats.)
 

Whether or not that's the case in general, in 5.2.1 you can do:

(require combinator-parser)

which can't be replicated with a PLaneT package, but can be replicated
with a library set up with `raco link`, so this may be more useful for
existing users of this now-deprecated code.
   


In the August release, should collection links support PLaneT versions 
(whether coming from PLaneT server or PLaneT dev links)?  (I don't know 
the answer; I don't know the philosophy of how these links are supposed 
to fit with PLaneT.)


Regarding the case in general, occasionally it seems to me like there is 
a dogfood issue there.  Which is why I jump on any additional precedent 
for using Git instead of PLaneT -- jump like an alpha Shih Tzu.


Neil

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Official PLaneT account?

2012-07-20 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM:

Shouldn't everyone try to eat PLaneT brand dog food?  (Not subsist off of
Git brand dog treats.)
 

Whether or not that's the case in general, in 5.2.1 you can do:

(require combinator-parser)

which can't be replicated with a PLaneT package, but can be replicated
with a library set up with `raco link`, so this may be more useful for
existing users of this now-deprecated code.
   


In the August release, should collection links support PLaneT versions 
(whether coming from PLaneT server or PLaneT dev links)?  (I don't know 
the answer; I don't know the philosophy of how these links are supposed 
to fit with PLaneT.)


Regarding the case in general, occasionally it seems to me like there is 
a dogfood issue there.  Which is why I jump on any additional precedent 
for using Git instead of PLaneT -- jump like a bloodthirsty Shih Tzu.


Neil

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #24958: master branch updated

2012-07-12 Thread Neil Van Dyke
I spent some time working with taxonomies and ontologies, and switched 
to generally preferring that the permanent names for things be in a flat 
namespace, and that any organizations (e.g., hierarchical) be separate, 
indirect, and more fluid.


One possible exception is when there is a strong, exclusive, permanent 
``part of'' relationship.


For example, I think that the PlaneT categories are already getting 
outdated, and I am glad that the categories are not used in naming.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Deprecating collects

2012-07-10 Thread Neil Van Dyke

Robby Findler wrote at 07/10/2012 05:20 PM:

On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu  wrote:
   

- mzlib [...]
- mzscheme [...]
   

I don't think these should be removed or deprecated, ever. I have lots
of code that still refers to them --- I doubt that I'm alone --- and I
think we should be able to support them.
 

I agree that these should never be removed. I would not mind if they
were marked in some way as these are here for legacy reasons. New
code should use XYZ with specific pointers and helpful advice.
   


I'm still using some mzlib in *new* code.  Specifically, getpid, 
this-expression-source-directory, gethostname, and perhaps one or 
two other things.  I could find other ways to do those things if I had 
to, but those definitions pop up when I search, and there's no glaring 
warning not to use them.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Deprecating collects

2012-07-10 Thread Neil Van Dyke
If someone has a good reason to get rid of 
this-expression-source-directory, I'm mostly indifferent.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Error message structure (error-message overhaul)

2012-06-20 Thread Neil Van Dyke

Eli Barzilay wrote at 06/19/2012 08:11 PM:

   * There's a whole range of tools that work with the usual
 file:line:vol: message per line format -- Emacs compilation
 buffer, the on-line-check-syntax-like error highlighting, log
 parsers, etc.  (The emacs on-line checking is something that two
 people already noticed as a victim...)
   


FWIW, I think I can make the Emacs stuff work better with the new error 
message format.


On a related matter, it's helpful when file names in error messages 
contain a complete path.  (Prior to these new error messages, for 
example, raco setup would produce a mix of relative and absolute paths 
in error messages.)


Performance-wise, for exceptions involving paths, if resolving a 
complete path happens to be expensive... If the site that constructs an 
exn that includes a relative path also has a way to include in the 
struct a complete path to which the path in question is relative, that 
would let error message rendering show a full path without slowing 
things in cases in which the exception is handled without rendering the 
path.  Or maybe resolving a complete path is relatively inexpensive in 
cases in which we'd want to raise and handle an exception with a path.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] check-syntax hack: patch to show how many uses an identifier has

2012-06-20 Thread Neil Van Dyke

John Clements wrote at 06/20/2012 10:48 PM:
When I'm using online check syntax, I often look at the lines leaving 
an identifier and wonder: is that just one line, or are there two or 
three? When lines overlap, there's no easy way to tell. This can be 
important in refactoring decisions, or in debugging (how many uses of 
this thing are there to check?).


Yes, I've wondered this too.  And in large files, it's often really hard 
to tell, like in your first screenshot.


Maybe, if the mouse hovers over the center point of a binding 
identifier, there's a tooltip that shows useful info, such as how many 
references (maybe in what procedures?), and whether it's provided by the 
module.  (I haven't thought about submodules, though.)


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] [racket] scribble formatting tweak?

2012-06-19 Thread Neil Van Dyke
Thanks, Matthew!  I really like this.  (And I know it was a lot of work 
to wrangle the HTML and CSS in this case.)


It looks good to me as it is, although Robby's suggestion of lowercase 
sounds good too.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Potential search improvement

2012-05-29 Thread Neil Van Dyke

Eli Barzilay wrote at 05/29/2012 07:17 AM:

I have made a possibly useful improvement to the JS search code.
It's not pushed, yet, but I dropped the revised JS code on the
pre-built pages so you can try it out here:

   http://pre.racket-lang.org/docs/html/search/
   

[...]

Eli, looks like a noticeable improvement over 5.2.1 search to me so 
far.  Thank you for working on this.


Here's a small quirk on pre: searching for scribble doesn't get the 
Scribble manual as the first hit, but the incremental search as you're 
typing gets you the Scribble manual as the first hit for scri through 
scribbl.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax

2012-05-09 Thread Neil Van Dyke

Laurent wrote at 05/09/2012 06:55 AM:

* Line-width

In GEdit, there's an option to show a thin vertical line at 80 chars 
(modifiable number).
I find it of great help to avoid writing long lines, which I tend to 
not do otherwise or often (inconveniently) look at the column number 
to see where I am.

Such a vertical line might be a good idea for DrRacket.


This has come up before.  I doubt anyone would complain if someone 
implemented this and made it optional.  Some people (including me) would 
very much like it.  I think that the least-controversial default 
preference settings would be 80 characters, light gray, and disabled.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Generics and data structures

2012-05-09 Thread Neil Van Dyke

Asumu Takikawa wrote at 05/09/2012 06:13 PM:

Any thoughts or suggestions?
   


When you say dictionaries, sequences,, are you including the Racket 
types hash, vector, and list?


If so, would current performance for those Racket types be affected?  
And does this have implications for what optimizations the compiler 
would likely make in the foreseeable future?


Thanks,
Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] current-*-port

2012-05-07 Thread Neil Van Dyke

Marijn wrote at 05/07/2012 10:54 AM:

How about prefixing a tilda (~) instead of current-? It looks like a
current ;P and also like a snake (parameters could be thought to
``snake'' through the code). Alternatively the at-sign (@) to
represent currentness. To make them stand out more (if that is
desirable) the same symbol could be postfixed as well. In conclusion,
some options are:

~error-port
@error-port
~error-port~
@error-port@
   


I don't mind having stdout, stderr, and stdin as aliases for their 
current names.


As a naming convention for all parameters, however, I wouldn't mind 
keeping the existing one (current- prefix), although it is a little 
cumbersome.  And even though it's a little cumbersome, a little 
cumbersome is good, considering that I think parameters are for special 
occasions only.


I was thinking before about alphabetic naming convention, rather than 
using symbol characters.  For one reason, I'd like to save the few 
remaining ASCII symbol characters for other linguistic purposes, 
especially considering that Racket is also a language experimenter's 
platform, and we should leave some characters for future expansion.  For 
another reason, I think that alphabetic names can be less 
cryptic-looking (and easier to pronounce) than symbol characters, so I 
try to use symbol characters with hesitation only.


I'm not in love with any of the alternative alphabetic naming 
conventions I've thought of: cur- prefix, -param suffix, -parm 
suffix, -parameter suffix.  (And, if -parm suffix, I'd end up using 
chicken-parm as an example in language tutorials, making them 
gratuitously obtuse.)


Thinking about this has me coming back around to thinking that 
current- is not so bad, after all.  The main drawback is that one's 
demos look verbose, when one wants to win over the half-dozen people 
using Arc.


Incidentally, starting an identifier with @ is a little bit 
problematic because of how the reader handles ,@ (unquote-splicing).


Neil V.

--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] current-*-port

2012-05-04 Thread Neil Van Dyke

Matthias Felleisen wrote at 05/04/2012 10:41 AM:

On May 4, 2012, at 10:34 AM, Laurent wrote

An interesting idea would be to count the number of times each identifier is 
used in the sources, and see how many characters would be saved by using 
different conventions.
 

That sounds like a fantastic exercise for someone who is truly skilled at 
scripting the shell with all kinds of find/wc/add knowledge.


Heresy.  Racket is actually well-suited for this task.

(At the risk of stating the obvious... Well, you have to do some of the 
mechanics of directory tree traversal manually, unless someone's already 
written a directory-fold or similar.  Other than that, just call the 
reader for each Racket file, building a hash of symbols to appearance 
counts, then run down that hash and another of some candidate renaming 
scheme, doing the arithmetic.  A Unix shell script, on the other hand, 
would be kludgey even for an expert, and probably take one at least as 
long to write.)


Neil V.

--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] current-*-port

2012-05-03 Thread Neil Van Dyke

Eli Barzilay wrote at 05/03/2012 03:48 PM:

   (parameterize ([stderr (stdout)])
 ...)
   


I'm not sure how I feel about shortening these, but an additional 
consideration is that a naming convention for parameters (so far, 
prefixing with current-) has been useful.  I think a naming convention 
can help remind people that this won't work with renaming alone:


(fprintf stderr Oops!)

Neil V.


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] current-*-port

2012-05-03 Thread Neil Van Dyke

Matthias Felleisen wrote at 05/03/2012 10:57 PM:

I don't think Eli is proposing an elimination of the old names but 
supplementing the code base with new ones.

I am in favor -- Matthias


Would be good to have a shorter naming convention for all parameters.  
The current- prefix is not short, but it's what I've been using when 
coding new parameters, because that's the convention.


Of course, a naming convention is much less important when we have 
static checking of argument types, but we usually don't.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] skip release

2012-04-23 Thread Neil Van Dyke
One opinion: I appreciate the diligence and caution.  That Racket's 
releases are high quality is one of the attractions of the platform.  I 
can wait a few more months for submodules.


Neil V.

--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] consistency in names and signatures

2012-03-27 Thread Neil Van Dyke

FWIW...

* I have no strong opinion on whether it would be worthwhile, if done in 
a backward-compatible way.


* If done in a *non*-backward-compatible way, it might be a headache.  I 
know of systems in production with millions of lines of PLT/Racket code, 
and -- although PLT/Racket have been pretty good about backward 
compatibility -- it seems like every little non-backward-compatible 
change to a PLT/Racket version, my big clients feel it significantly.  I 
make a little money every time a platform change inflicts pain, since I 
have to fix it, but it's a net loss for me when goodwill for the 
platform is eroded.  (And perhaps eroded goodwill for me, who is 
implicitly endorsing the platform, and who has sometimes been asked 
directly to explain *why* such-and-such changed happened.  I would 
rather be paid to invent and build new stuff, not be responding to the 
platform breaking.)


* I am sympathetic to the idea of being more explicit about types in 
identifiers.  In nontrivial code, I do sometimes end an identifier as 
-or-false or -or-f, and sometimes I have /error or /exn variants 
of procedures.  It helps me keep track of whether the value can be #f.  
I usually avoid being this explicit in identifiers in APIs, because it's 
a little ugly-looking, it has not been idiomatic Racket thus far, and it 
hasn't seemed necessary.


* If we're going to have exception-raising and #f-producing variants of 
a procedure, how about accommodating both the little language and big 
language people by having *three* variants: /exn and /f (or 
/false) for the big language people who want to be explicit, and 
no-suffix for the littler language people who don't need or want all 
that clutter.


* Would this new world of naming conventions be a good time to replace 
the somewhat clunky-looking - naming convention with  or something 
else?  numberstring? number-to-string?  number-as-string?  (No 
non-ASCII, unless I can get an APL keyboard for my ThinkPad.)


* Maybe we should consider otherwise simplifying some of these 
identifiers.  To use an example, bytes-string/utf-8 is already a 
mouthful for a pretty common thing, even before we start adding suffixes 
onto it.  (bytes-string/utf-8 might be too easy an example, since 
UTF-8 encoding would be an appropriate default for a bytes-string 
nowadays, and consistent with Racket's current behavior when writing a 
string to a bytes port.)


* Will there be more consistency in how / in an identifier should be 
read?  It seems that X/Y sometimes reads as X with behavior Y, 
sometimes as X with a Y argument, sometimes as X or Y, and sometimes 
as something else.


Neil V.

--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Fwd: [racket-bug] all/12642: #lang slideshow gets error message module: this function is not defined

2012-03-21 Thread Neil Van Dyke

How about a change to the purpose of the Languages control?

Currently, I think of the control *selecting how to determine* which 
language to use.  Example settings whatever #lang says, Beginning 
Student, etc.


The control could be changed to *present the determination* (by #lang or 
by some default), and only secondarily as a means to *change the 
determination* (which might mean automatically changing the #lang in the 
file).  The list of override alternatives would be something like the 
languages that this DrRacket instance knows about.  There would not be a 
whatever #lang says alternative, since that behavior is always the case.


For determining the language when no #lang is present (such as when 
opening a file without a #lang, or when creating a new file), the 
default could be a preference setting, with alternatives like Guess, 
beginning-student, advanced-student, racket, racket/base... and 
whatever other languages this DrRacket knows.  Default alternative would 
be Guess, which I suspect will work fine for most people.


The Guess alternative in this preference could be some heuristics like 
Emacs and the file command use (later on we could make these 
heuristics extensible by packages that implement languages), and default 
to the last #lang used.  I suspect last-#lang-used would be fine, and 
any heuristics are a bonus.  (The heuristics might determine language of 
the file as distinct from #lang languages, and for each file language, 
keep track of a last-#lang-used.  So, a heuristic might recognize Scheme 
as the file's language, and then Guess would go and find what #lang the 
user last used for a Scheme file.  Again, last-#lang-used, with no 
heuristics, is fine 95%+ of the time; heuristics are mostly for 
delighting the user with DrRacket's cleverness the other 5% of the time.)


Robby's suggestion of *always* requiring #lang is tempting, and I am 
close to that, except that it would be nice to support languages that 
don't syntactically permit #lang.  For example, if we wanted to load up 
JavaScript, XML, HTML, or Java files in DrRacket.


Neil V.

--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] odd error message in race setup

2012-03-09 Thread Neil Van Dyke

Robby Findler wrote at 03/08/2012 08:00 PM:

I think that the issue probably does not predate Kevin's recent push
(distributed places).

If you'd like to audit the push security concerns, I'm sure that'd be welcome.
   


I meant that I might need to take a look at it because the example we 
saw would raise eyebrows with some of my consulting clients.  Sounds 
like it was just a documentation example that is being removed before 
release, so a non-issue.


Separate from that, I wouldn't mind taking a look at security 
implications of whatever this mechanism, but I doubt I'd notice anything 
that a PLTer who designed the mechanism hadn't already identified.


--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] odd error message in race setup

2012-03-08 Thread Neil Van Dyke

Robby Findler wrote at 03/08/2012 05:45 PM:

Looks like something is trying to ssh while building the docs?


Can whoever figures this out let the list know, or email me privately?  
Thanks.


If it turns out that a use of SSH made it into a *released* version of 
Racket source, I might have to take a look at it, regardless of how 
legitimate it is.


(Looks like something is trying to SSH, and localhost's fingerprint 
disagrees with user's SSH known_hosts.  So might have been going on 
for a while, quietly, and only noticed now because of the unusual 
situation of the fingerprint being different.  And noticed because 
someone was paying attention to the raco setup logs (if that indeed 
raco setup process was the source, rather than some other process that 
just had a handle for the stdio/terminal).  I don't grep an obvious 
use of SSH in the 5.2.1 sources I'm using right now.)


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] odd error message in race setup

2012-03-08 Thread Neil Van Dyke
Probably mere coincidence, but GitHub has disclosed a security 
vulnerability of their service, which was exploited to target Rails 
developers and unnamed others: 
https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation


Neil Van Dyke wrote at 03/08/2012 06:32 PM:

Robby Findler wrote at 03/08/2012 05:45 PM:

Looks like something is trying to ssh while building the docs?


Can whoever figures this out let the list know, or email me 
privately?  Thanks.


If it turns out that a use of SSH made it into a *released* version of 
Racket source, I might have to take a look at it, regardless of how 
legitimate it is.


(Looks like something is trying to SSH, and localhost's fingerprint 
disagrees with user's SSH known_hosts.  So might have been going on 
for a while, quietly, and only noticed now because of the unusual 
situation of the fingerprint being different.  And noticed because 
someone was paying attention to the raco setup logs (if that indeed 
raco setup process was the source, rather than some other process 
that just had a handle for the stdio/terminal).  I don't grep an 
obvious use of SSH in the 5.2.1 sources I'm using right now.)


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Any notion of .jar files for Racket?

2012-03-06 Thread Neil Van Dyke

Brian Mastenbrook wrote at 03/06/2012 03:43 PM:
On my system, DrRacket 5.2.1 opens almost 1800 files to start. The 
vast majority (1376) are .zo files, and another 133 are uncompiled 
.rkt files from the Racket distribution.


It gets much faster once the files are in OS caches, which helps with 
successive invocations of the command-line tools.


The uncached accesses going over NFS could be especially painful, such 
as if you are running a copy of DrRacket from a slow NFS home dir.


(I feel for anyone who has to use NFS nowadays, such as some university 
communal computers are no doubt still set up to use.  NFS and AFS were 
great 20 years ago, at least when the servers and the network were 
non-flaky and not oversaturated.  Today, we usually want to be using our 
own computer with a local copy of files (or a USB flash drive with 
communal computers), not having every file access go out to centralized 
server.  Popular SCM systems like Git and Subversion are good ways to 
replicate most of our files among systems, and permit disconnected 
operation in between.  I'd still offer students an NFS dir they're free 
to use, especially new students working from lab computers, but 
encourage them to use their own local storage for most things.  And I'd 
provide a big Git server with private accounts, which students may use 
for coursework if they wish.)


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] possible bug in openssl/mzssl

2012-02-29 Thread Neil Van Dyke

Matthew Flatt wrote at 02/29/2012 11:20 AM:

So far, I haven't managed to replicate the problem on my machine. Do
you have any hints on how to configure Apache to trigger the problem or
a server that I might try?
   


I'm afraid I don't have that test setup or notes anymore.  I do recall 
it was with PLT 4.2.5 (CGC collector) on Debian Stable (Lenny) 32-bit 
x86 machine with the Apache that Debian packaged, in a pretty stock 
configuration.  (This was likely also tested on other systems, but I 
can't say for certain.)  As noted in the email thread back then, every 
other HTTPS client tool I tried with the same files and server worked 
fine.  It's possible that I made a bug in the Scheme code, but 
everything I did was pretty straightforward, and I could not see a bug.  
Unfortunately, I couldn't share a complete test case for a PLT bug 
report at the time, or perhaps we could have figured it out then.


--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] possible bug in openssl/mzssl

2012-02-28 Thread Neil Van Dyke

Timur Sufiev wrote at 02/27/2012 08:58 AM:
[...] Raw ports were wrapped with SSL successfully, but then program 
has hung up between 2 last actions: sending the request to server and 
reading its reply. Further investigation showed that in the course of 
SSL processing the server had requested session renegotiation from the 
client and would provide it with requested data if the client sent 
negotiation info to server. [...]


This sounds like a problem that I had over a year ago with having Racket 
(PLT Scheme) send HTTPS client certificates:

http://lists.racket-lang.org/users/archive/2010-September/041519.html

I did not solve that exact problem.  A consulting client had an urgent 
need, so I worked around the problem by making a Racket module that 
provided an abstraction over external curl processes, and used that 
module instead.  (Which also probably increased app performance, when 
that client moved to Web SCGI with Racket and added some new behavior, 
since large HTTPS and file I/O that happened in the background of Web 
requests could bypass the Racket process and could also be scheduled by 
the host OS on other processors.)  That particular Racket curl module 
is not currently open source, but you might find a similar Racket 
library, or implement your own simple library pretty easily.


Also, a tip on one way to decrypt the SSL traffic:
http://www.neilvandyke.org/weblog/2010/09/#2010-09-12

Neil V.

--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] collections with no one responsible

2012-02-17 Thread Neil Van Dyke

Sam Tobin-Hochstadt wrote at 02/17/2012 05:38 PM:

2. We keep it where it is, and don't maintain the code other than
fixing life-threating bugs.  This is basically the status quo, and I
think it means people who report other, non-life-threatening bugs
should be informed that we're not maintaining the code, and thus their
bug isn't going to get fixed.
   


Side comment, which will probably sound odd: I'm not sure if you mean 
life-threatening literally in this case, and I'm not criticizing that 
use, but I think probably best if people don't adopt this term and start 
using it loosely on the Racket email lists.


I believe that some people on Racket lists also work on life-critical or 
safety-critical systems, and are all kinds of serious about it.  Please 
to be gentle with delicate sensibilities of engineers.


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new logo

2012-02-14 Thread Neil Van Dyke

Neil Toronto wrote at 02/14/2012 03:37 PM:
Here's the deal, though. This one, even just the lambda r. in a 
circle, is pushing complexity. We've been approaching logo design too 
much like language design, trying to cram as much semantic content as 
possible into a small space or into the fewest shapes. A logo exists 
primarily to make a good impression on outsiders. Filling it with too 
much meaning works actively against this.


Good point.

This full banner would be good printed as a big stripe across light gray 
T-shirts and hoodies (like university-branded merchandise using 
unofficial visuals), but is pretty busy as the canonical logo.  It's not 
a bad allusion to Racket's quality of we've crammed a lot of clever 
stuff into this thing, and you'll need to spend a lot of time going 
through all of it.


The lambda r. in a circle part alone is not bad.  I wonder how well it 
could work with more of a nod to the long-time red and blue of the PLT 
logos.


And I still like the only-slightly-odd-looking parenthesis added to 
current logo, to make an R idea.


--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] new logo

2012-02-12 Thread Neil Van Dyke

Eli Barzilay wrote at 02/12/2012 01:50 AM:

An hour ago, Michael W wrote:
   

http://img513.imageshack.us/img513/5233/lambdarechopng.jpg
 

   http://tmp.barzilay.org/cr.png
   


Yes!  I think that cr.png has nailed the design.

lambdarechopng.jpg especially got my attention before, but I thought 
it needed major aesthetic changes to fit Racket better.


I think cr.png is a big step in the aesthetic fit direction.

cr.png also has nice continuity of evolution from the current Racket 
logo and preceding PLT Scheme logos.


cr.png is a bit geeky and slightly awkward -- moreso than the current 
Racket logo -- but it's supposed to represent a computer programming 
platform that grew out of Scheme, so a bit geeky is appropriate. And it 
has more character (no pun) than the current Racket logo.


I could see cr.png as a rough draft of a good final version of the 
logo, with the design being pretty much complete, and needing only some 
experimentingtweaking of subtleties of the rendering (in the graphic 
artistry sense).


(I don't mean to discourage further ideas with this opinion; maybe 
someone has an even better refinement, or some different ideas.)


--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Racket logo

2012-02-10 Thread Neil Van Dyke

Eli Barzilay wrote at 02/09/2012 09:27 PM:

([2] What Neil VD said.)
   


It's just Neil V. -- no social diseases.

--
http://www.neilvandyke.org/
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Racket logo

2012-02-09 Thread Neil Van Dyke
Of these two, I like the second (plastic) one a bit better.  The blue in 
the glass is distracting to me.


Careful that it doesn't look too much like the new Pepsi logo, which has 
its own burden:

http://blowatlife.blogspot.com/2009/02/pepsi-logo-response.html

I still like the current lambda logo.  Though the lowercase 'R' letter 
would hang out better with the typical icons for Twitter and Facebook.  
And peeve Ruby and R people.


Marijn wrote at 02/09/2012 11:17 AM:

On 09-02-12 02:18, Robby Findler wrote:
   

John Clements and Neil Toronto have put together a new Racket logo
that I've just put on the DrRacket splash screen. See what you think.
 

Ooh, shiny!

Marijn


_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] dependencies and racket

2011-12-30 Thread Neil Van Dyke
Another variation, if you're thinking about cloud infrastructure today: 
you could pretty easily make your own faux PLaneT server that either is 
for a single app or takes the identity/profile of the app as part of the 
URL the app uses to access the PLaneT server.


The faux server can be a tiny HTTP server process, as it only has to 
perform a single, simple REST operation.


This faux PLaneT server would *enforce* the same profile of PLaneT 
package versions for the app, and also serve the packages from a trusted 
cache at app compile time.


Or you can use the careful-crafted ~/.racket/ directory approach.  I 
suppose the choice depends on which is easier to do well in your 
existing infrastructure.


It's good to see interest in Racket from cloud people.  Feel free to ask 
lots of questions on the Racket users and dev email lists as you 
work through your solution.


--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] dependencies and racket

2011-12-29 Thread Neil Van Dyke

Daniel Farina wrote at 12/29/2011 07:59 PM:

The goal is that a program written, say, three
years ago should be able to run the same way it did when it was
written, so it's really useful to freeze all the dependencies into the
file system somehow and preserve it.
   


Someone else can comment on any automated ways of ``compiling in'' 
PLaneT packages, and solutions like that.


A so-so solution I *don't* recommend... If you preserved the exact 
PLaneT linkage table, and were very careful, then I think you could 
preserve the exact versions of PLaneT modules used (required directly, 
and indirectly).  This assumes either: (1) integrity of the PLaneT 
server, and trust in your connection to it; or (2) preservation of the 
pertinent parts of ~/.racket.  Then you'd want to disable attempts to 
access the PLaneT server.  Perhaps, if you were to automate this, it 
could be done safely and reliably.


Something that has been done for a large Racket-based Web app on 
production servers is to manually determine all the PLaneT packages that 
are used, downloaded and extract these packages (in a directory scheme 
that preserves naming and version info), check it all into their 
configuration management system, change all the PLaneT module references 
to filesystem ones, check it into CM again, and audit.  PLaneT server 
access is always blocked, except for the manual download.  You can make 
simple tools to help automate the more mechanical parts of this (I don't 
know of any such tools publicly available at this time), but the audit 
is mostly human expertise-intensive.  This  cloning of PLaneT packages 
is not something that most people need to do, and it totally spoils the 
buzz of ``I'll just add a (require (planet ...)) and bam!,'' but it's 
not too hard to do if you choose to.


PLaneT isn't my baby (I think Jay and Eli are leading it right now), but 
I'm looking into funding so that I can put solid chunks of time into 
helping with ways to improve PLaneT security.  Security is usually a 
constant consideration in my Internet consulting work.  Part of this 
tentative work will address your concerns about stability, and (in my 
current thinking) about having the option of removing PLaneT server 
dependencies for an app.  Much of this work has implications for some 
other network software distribution methods, so PLaneT is both a 
research testbed and an early practical beneficiary (much like Racket in 
general).  Stay tuned (I have a lot more experience in solving problems 
than in writing research grant proposals).


--
http://www.neilvandyke.org/

_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Is it possible / How to use racket in C++ Applications?

2011-12-23 Thread Neil Van Dyke

x...@ncdy.org wrote at 12/22/2011 03:42 AM:

I opened the question on StackOverflow
http://stackoverflow.com/questions/8599844/is-it-possible-how-to-use-racket-in-c-applications

They pointed me to mailing list, so I want to know if that possible to run
racket in such embedded mode?
   


Yes.  See: 
http://docs.racket-lang.org/inside/overview.html#%28part._embedding%29


Note that embedding Racket like this is unusual.  Usually you develop 
the entire application in Racket, or develop most of the application in 
Racket and then call out to a C library or two.


(Reply-To set to the Racket users email list.)

--
http://www.neilvandyke.org/

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket home page proposal

2011-12-20 Thread Neil Van Dyke

Eli Barzilay wrote at 12/20/2011 01:45 PM:

and there no sane way to debug it other than viewing it in all browsers.



Asumu, it seems like you're on a good track, but after you get the 
layout how you like it in your browser, I don't envy you the 
cross-browser testing to which Eli refers. :)


FWIW, this has a few layout problems in the (rebranded) Firefox that's 
in Debian Stable.  Two most obvious problems: font sizes appear wrong, 
and then change to different wrong when switching to single-column mode, 
some blocks are overlaid.


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket home page proposal

2011-12-20 Thread Neil Van Dyke

Matthias Felleisen wrote at 12/20/2011 08:02 AM:

I wouldn't mind a second Racket site that has some of what Asumu proposes, say 
Racket-fans.org
   


BTW, I recently registered racket-club.{org,com}, mainly for the humor 
potential. If there is a site that someone has been aching to see 
happen, which for some reason can't be part of racket-lang.org, let me 
know.


(I'd like to see racket-lang.org (hopefully someday racket.org) be 
the one-stop shopping center for all things Racket, not fragment that 
without a good reason.  Ad revenue is not a good reason to fragment.)


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Racket home page proposal

2011-12-19 Thread Neil Van Dyke

Asumu Takikawa wrote at 12/20/2011 12:34 AM:

How would people feel about adding more content below the fold on the
website?


Seems OK to me, but two points:

1. Don't let the Twitter and such dominate the page visually.  Things 
like Twitter are for bringing people in, not sending them away or 
distracting once they're already at the page where we can tell them what 
we most want to tell them.


2. Don't use the Twitter, Facebook, etc. Web bugs.  They already track 
individual's browsing behavior in detail across most Web sites, but 
Racket can be better than that, on principle.  You can implement this in 
server-side Racket code.


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] scribble -- an ncurses game

2011-12-13 Thread Neil Van Dyke

Jon Rafkind wrote at 12/13/2011 06:27 PM:

A user of mine alerted me to the fact that 'scribble' is a crossword puzzle 
similar to scrabble. He had it installed in ubuntu so when he typed make in my 
source tree he ended up playing a game instead of generating documentation.
   


Given how massive Debian (and, therefore, Ubuntu) is, it's not too 
surprising that something is already called Scribble, but it's a pain.


I don't know what PLT wants to do about this, but a Debian maintainer 
will probably eventually make the call if PLT doesn't first.


Here's a Debian package name search, showing multiple Scribbles:

http://packages.debian.org/search?keywords=scribble

Here's where it looks like that scribble executable is coming from, as 
/usr/games/scribble, from an optional games package of the current 
Debian stable release (unless Ubuntu put it elsewhere):


http://packages.debian.org/squeeze/all/scribble/filelist
http://packages.ubuntu.com/oneiric/all/scribble/filelist

Based on past experience, I think that, if a Debian package maintainer 
is trying to package Racket, and they see that there is already a 
scribble executable, they will rename Racket's scribble executable 
to something else, like racket-scribble.


Two workarounds for this particular user:

1. Edit the appropriate shell initialization file, such as ~/.bashrc, 
to put the directory containing Racket's scribble ahead of 
/usr/games in the PATH environment variable.  (/usr/games should 
be at the end anyway, if it appears at all, just for good practice.)


2. For Makefiles and build scripts, put the full file path to the 
desired scribble executable.  (You would want to do this anyway, if 
your app has an official Racket version is currently is tested with, and 
you put your Racket version numbers in your Racket install tree 
directory names.)


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


[racket-dev] www.racket-lang.org/learning.html

2011-12-12 Thread Neil Van Dyke
I think that mention of the old Scheme Cookbook wiki should be removed 
from http://www.racket-lang.org/learning.html;, because it hurts much 
more than it helps.


Right now, it's in one of the most prominent positions on the page.

--
http://www.neilvandyke.org/

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Missing pregexp syntax in Racket

2011-11-29 Thread Neil Van Dyke
1. Everyone should acknowledge the JWZ quote, Some people, when 
confronted with a problem, think 'I know, I'll use regular expressions.' 
Now they have two problems.  Regular expressions are Perl's hammer that 
makes most problems look like a nail.


2. Before someone spends too much time putting the finishing touches on 
old Unix/Perl regular expression syntax, they might want to look at Olin 
Shivers's SREs.  Sexp-based regular expression syntax can be a big 
readability win when your regexps get complicated.  
http://www.ccs.neu.edu/home/shivers/citations.html#sre


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] regexp-split produces immutable cons when rnrs/base-6 is required

2011-11-25 Thread Neil Van Dyke
As an immediate solution, I suggest simply not trying to use R6RS 
compatibility libraries with Racket, and instead just use the Racket 
language.  Spend your energy on your application.  (I don't want to get 
into why right now, but my book will have an entire section or chapter 
entitled Don't Use R6RS.)


If you have some super-good reason for wanting to use R6RS, a few more 
comments...


The particular problem you're having is due to rnrs/base-6 wanting to 
use mutable pairs, while libraries implemented in Racket want to use 
immutable pairs.  They *could* be made more interoperable, but all the 
ways I can think of would have other undesirable costs, and you'd either 
end up getting bugs in other places or get really lousy performance.


As a workaround if you *really* want to use R6RS, but also use 
regexp-split, is to make a tiny #lang racket/base module that wraps 
Racket's regexp-split to convert any pairs in the return value to mpairs.


BTW, if you want to parse input like this from a port, you can use 
Racket regexp operations or a grammar-based parser directly on the port, 
rather than reading a line and then doing a regexp-split on the line.  
The latter way is a Perl idiomatic way of parsing a language like this, 
and that way will also work in Racket, but there are arguably better ways.


--
http://www.neilvandyke.org/

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


  1   2   >