gmane.comp.lang.racket.devel

Re: proposal for moving to packages

Eric Dobson — 2013-05-21T04:05:58

I'm not sure I follow on why binary packages make it easier to reduce
dependencies between packages, or why binary packages offer faster
installs.

I'm guessing that binary packages prevent cyclic dependencies between
packages, but it seems like there are many other options that still
get this side effect. Such as explicit checks when building the
package.

For faster installs, the only benefit I see of binary packages over
precompiled source packages is a small savings in size which doesn't
seem like it would amount to much of the install time.

Can someone explain the claims for binary packages?

On Mon, May 20, 2013 at 8:57 PM, Jon Zeppieri <zeppieri-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: proposal for moving to packages

Jon Zeppieri — 2013-05-21T03:57:25

+inf.0

Though the easiest way to make the source available is just to keep it
in the distribution. I'll be sad to see it go.

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

Re: proposal for moving to packages

Neil Van Dyke — 2013-05-21T03:33:35

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

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: proposal for moving to packages

Juan Francisco Cantero Hurtado — 2013-05-21T03:20:08

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

Thanks for the hard work :)


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

Re: proposal for moving to packages

Neil Van Dyke — 2013-05-21T02:04:26

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 sour

tcp_listen error handling

Alex Moiseenko — 2013-05-21T01:57:25

Hi. I've successfully started Racket 5.3.4.7 with Geiser server through JNI + SDL2 on Android (and this combination mostly works with small hacks), but got some issues due to racket's implementation. This is last one I'm trying to understand. What should be here instead of the "address" expression?

2349    } else {
2350      scheme_raise_exn(MZEXN_FAIL_NETWORK,
2351                       "tcp-listen: host not found\n"
2352                       " address: %s\n"
2353                       " system error: %N",
2354                       address, 1, err);
2355      return NULL;
2356    }
2357  }
https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2354

It looks like there should be (but i'm not sure)

   address ? address : "#f" // as i see at another place, because it's possible to have NULL according to the:

https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2147

Without such change I got segfault because sch_vsprintf tried to process NULL pointer, when i forgot to grant in

Re: proposal for moving to packages: repository

Matthew Flatt — 2013-05-21T01:07:31

It's about a kind of gradual change, but not quite so gradual. I would
like to switch immediately to a package-oriented view of Racket,
instead of thinking about packages as something that you get by
squinting at our current tree.

Concretely, new repositories that are just a subset of the current repo
would be off-by-one in directory structure compared to a normal
package. Each package should correspond to a subtree starting from the
"collects" level, not the parent of "collects". We could massage the
two views into one, but I'd rather not.

At the time time, I agree that it's tricky to properly extract history
for the new repositories, and there will be many issues in dealing with
multiple repositories (e.g., submodules may not be the way to go). So,
I'd like to delay that part until a second step.

To put it another way and overstate a little: I'm trying to get buy-in
from dev to make the switch to packages wholesale. The little bit of
staging in the plan is to make the conversion itself easier, and not

Re: proposal for moving to packages

Greg Hendershott — 2013-05-20T23:07:33

Well, ideally there would be some new module-name->source function
that could return URIs like http://path/to/file.rkt (or for that
matter, file:///path/to/file.rkt), based on info.rkt for packages?

Given that piece, a couple ways to do it -- favoring doing it more in
Emacs vs. more in Racket -- but both involve having a local cache, and
also using If-Modified-Since request headers? Maybe even the ability
to "prefill the cache and never expire it" ... which seems awfully
like source installation by other means?


p.s. An approach favoring doing it more on the Racket side than on the
Emacs side, could also support FRs like one I saw on the main list
recently, which is that File | Open in DrRacket should be able to open
remote files. That was for a classroom setting IIRC.
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: proposal for moving to packages: repository

Eli Barzilay — 2013-05-20T22:27:34

(Generally, +1.  I'll reply just on the repository point here.)



I very strongly object to this.  While in theory git will follow
everything, this requires doing some more work which most people won't
know about, so a result of all of this is going to be loss of
historical information.  So I think that it's much better to move
directly to several repositories (IIUC, one repository for each
suggested toplevbel directory).

The only goal of the intermediate state seems to be providing some
gradual change before switching to submodules -- and on one hand, I
think that the new layout will force people to learn how to deal with
it, and on the other, it'll make people spend work twice, once on the
layout change and again on the switch to modules.

So assuming that a gradual change is the goal, I think that there are
better ways to do that.  Here's a suggestion:

  * The main repository is split into the different repositories.
    Initially, this is done without any consideration for submodules,
    with the id

Re: proposal for moving to packages

Jose A. Ortega Ruiz — 2013-05-20T21:23:14

[...]


FWIW (and i know it's not much, but anyway), this will be a big loss for
Geiser users, who right know can jump to any core function source with a
single keystroke and without leaving the editor.  IME, there's a huge
difference between that and having to switch to a web browser to find
it, both when learning or programming new applications.

Here's hope that down the line there'll be binary+source packages that
end users can install with the same ease as today.

Cheers,
jao

Re: proposal for moving to packages

Carl Eastlund — 2013-05-20T21:24:44


Overall, I'm really glad to see Racket moving into the package system.  I
think it will be good for both (the Racket core and the package system).
I'd like to mention, though, that git submodules can be a real pain for
synchronizing development of multiple repositories.  They seem to have been
designed primarily for importing upstream repositories, rather than for
multiple "peer" repositories.  I'm not much more fond of the alternatives I
have tried, either; if we're committing to splitting Racket into multiple
repositories as well as multiple packages, we should be aware there may be
another minor git learning curve ahead.

Thanks to Jay and Matthew for working on all of this!

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

Re: proposal for moving to packages

Asumu Takikawa — 2013-05-20T20:58:32

One nice thing about the current repo organization is that push
notifications for every part of the PLT codebase go to all of the
developers.

Will that still be available in this organization scheme? (I don't care
if it's opt-in too much, but opt-out will hopefully mean more eyes see
the code)

Cheers,
Asumu
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

proposal for moving to packages

Matthew Flatt — 2013-05-20T20:42:15

I used to think that we'd take advantage of the package manager by
gradually pulling parts out of the Racket git repo and making them
packages.

Now, I think we should just shift directly to a small-ish Racket core,
making everything else a package immediately. "Core" means enough to
run `raco pkg'.

A key point to remember is that "package" does not mean "omitted from
the distribution". Instead, we'll construct a distribution by
combining the core with a selected set of packages. Initially the
selected set of packages will cover everything in the current
distribution.

Jay and I have been lining up the pieces for this change (it's
difficult to make a meaningful proposal without trying a lot of the
work, first), and I provide a sketch of the overall plan below.

This plan has two prominent implications:

 * The current git repo's directory structure will change.

   Anyone who currently works with the Racket repo will need to adapt
   to the new directory structure (and probably git <submodules in the
   fut

Re: [plt] Push #26861: master branch updated

Sam Tobin-Hochstadt — 2013-05-20T06:07:11

I think Bottom should be fine here (off the top of my head).

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

Re: [plt] Push #26861: master branch updated

Asumu Takikawa — 2013-05-20T01:32:38

In the error case? I'm not sure. TBH, I cargo culted that line. Sam, do
you have an opinion on this? (you had the last commit to touch that line
before me)

Cheers,
Asumu
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [plt] Push #26861: master branch updated

Eric Dobson — 2013-05-20T00:55:26

This doesn't pass with contract checking enabled. make-StructTop
requires a Struct? not any old Type?. Is there a reason that the type
is not just bottom?

On Sun, May 19, 2013 at 5:33 PM,  <asumu-GvBox1K3Ixw1Q5oZIJT9Xw< at >public.gmane.org> wrote:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: set!-transformers and syntax-local-value/immediate

Asumu Takikawa — 2013-05-17T23:59:26

Ah, thanks! I should've looked closer at the expansion.

(also thankfully it turns out I didn't need any complicated
 set!-transformer manipulation to do what I was trying to do)

Cheers,
Asumu
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: set!-transformers and syntax-local-value/immediate

Carl Eastlund — 2013-05-17T23:51:00

Asumu,

Your lookup macro's output just tells whether there is a rename somewhere
between the binding for f and its original source binding.  Rename
transformers get injected all over the place.  To get the real story, turn
your lookup macro into a loop that chases the binding back to the source.
Or, use the macro stepper with hiding off.  The let-syntax expression
expands into:

        (letrec-syntaxes+values (((f1) (make-set!-transformer values))) ()
          (letrec-syntaxes+values (((f) (values (make-rename-transformer
(quote-syntax f1))))) ()
            (lookup f)))

That's where the rename comes from.

Carl Eastlund

On Fri, May 17, 2013 at 7:30 PM, Asumu Takikawa <asumu-1vnkWVZi4QaVc3sceRu5cw< at >public.gmane.org> wrote:

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

set!-transformers and syntax-local-value/immediate

Asumu Takikawa — 2013-05-17T23:30:35

Hi all,

I'm confused about an aspect of set! and rename transformers. I'll
explain with this example:

  #lang racket

  ;; a macro that uses `syntax-local-value/immediate`
  (define-syntax (lookup stx)
    (syntax-case stx ()
      [(_ id)
       (let-values ([(f _) (syntax-local-value/immediate #'id)])
         (displayln (rename-transformer? f))
         (displayln (set!-transformer? f))
         #'0)]))

  ;; f is a set!-transformer
  (let-syntax ([f (make-set!-transformer values)])
    (lookup f))

  ;; sanity check
  (rename-transformer? (make-set!-transformer values))

In this example, `f` is bound to a set!-transformer. The macro `lookup`
will look up the value bound to `f` at compile-time, and I expected that
the result would be the set! transformer.

However, it seems like the set! transformer is somehow being turned into
a rename transformer (note the two print statements produce #t and #f
respectively). The last line suggests that set! transformers are not
actually a "subtype" of rename transfor

Re: calling make-keyword-procedure from insideathread produces a stack overflow in scheme_uncopy_stack

Matthew Flatt — 2013-05-15T15:22:37

Your example made it easy to find the problem (which would have been
difficult to track down otherwise), and I've pushed a repair.

Thanks again!

At Wed, 15 May 2013 06:47:43 -0600, Matthew Flatt wrote:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: calling make-keyword-procedure from inside athread produces a stack overflow in scheme_uncopy_stack

Matthew Flatt — 2013-05-15T12:47:43

I didn't get from your earlier message that provoking the crash is as
easy as running the expression below, but I am indeed able to replicate
the problem immediately.

Also, I have been swamped for the last couple of weeks, but I should be
able to get to this soon.

Thanks!

At Wed, 15 May 2013 13:40:04 +0100, Matthew Eric Bassett wrote:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev