gmane.comp.lang.racket.devel

Re: release 5.3.5

WarGrey Gyoudmon Ju — 2013-06-17T21:13:40

Okay I see.
I like the code style and conventions in HtDP,
and I have read lots of books about design before I am here.
I will try again when HtDP2e totally complete.

Thanks


On Mon, Jun 17, 2013 at 7:35 AM, Matthias Felleisen <matthias-1vnkWVZi4QaVc3sceRu5cw< at >public.gmane.org>wrote:

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

Re: PLaneT(2): Single vs multi-collection packages

Greg Hendershott — 2013-06-17T20:53:50

I'm still thinking that I'll keep my existing multi-collection
packages as multi, to preserve compatibility with 5.3.4. Only because,
although my packages don't have many users, I'll err on the side of
their convenience.

But if someone else did want to change from multi to single:

1. Philosophical: Wouldn't this be bad to do without renaming the
package, since the spirit of the package system versioning is, never
break backward compatibility?  Or, is it acceptable, now, since this
is technically still in beta?

2. Practical: Would `raco pkg update' handle such a multi->single
transform?  Or should packagers instruct users to (a) remove and (b)
install?

I'm asking in case it would help to have the answer(s) ready for doc
or FAQ purposes.


On Sat, Jun 15, 2013 at 11:19 AM, Matthew Flatt <mflatt-sDh8Nw2yj/+Vc3sceRu5cw< at >public.gmane.org> wrote:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: PLaneT(2): Single vs multi-collection packages

Michael Wilber — 2013-06-17T15:56:10

I vote for this change too.

I've been letting my planet packages sit in planet for too long now.
This change provides a bit nicer upgrade path. :)

Vincent St-Amour <stamourv-1vnkWVZi4QaVc3sceRu5cw< at >public.gmane.org> writes:
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: Keywords

Neil Van Dyke — 2013-06-17T15:28:42

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

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://lis

Re: Keywords

Matthias Felleisen — 2013-06-17T15:09:04

p.s. On second thought, for structs you want two constructors: 
 -- one that takes positional arguments 
 -- one that takes keyword arguments 
but perhaps 'new' can play the role for both: 

 (new fisht #:name "Nemo" #:weight 700)

and 

 (new fisht% #:name "Nemo" #:weight 700)

might work. 


On Jun 17, 2013, at 10:52 AM, Laurent wrote:


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

Re: Keywords

Matthias Felleisen — 2013-06-17T15:07:17

I like this idea a lot. -- Matthias



On Jun 17, 2013, at 10:52 AM, Laurent wrote:


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

Re: Keywords

Laurent — 2013-06-17T14:52:43

Actually I realize I'd like something exactly like `instantiate'.
If instantiate used keywords instead of bindings, and removing the
`instantiate' word, we would then even have the exact same syntax for class
instantiation and procedure call:

(define nemo (fish% "Nemo" #:age 3))   ; instantiates `fish%'

Of course this could be extended to structs.

This would harmonize different calling mechanisms, as well as being more
flexible.
Wouldn't that be nice?

Laurent


On Fri, Jun 7, 2013 at 8:12 AM, Laurent <laurent.orseau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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

Generics

Carl Eastlund — 2013-06-17T14:13:06

I have a long-running branch on github where I've been working on making
the set datatype generic the way dictionaries are, and improving the
generic system to support that effort.  Some of the people here at
Northeastern know about it, but I should probably make more people aware of
the work.  This is still a work in progress, it will be a while before it's
ready for final review and push.

  https://github.com/carl-eastlund/racket/tree/generic-sets

For sets, the main purpose has been to add gen:set and allow the set
datatype to be extended.  Along with that, I've added mutable sets and
make-custom-set, akin to make-custom-hash, and made lists usable as sets
based on equal? comparisons.

I've made an effort to put a lot of methods in gen:set, rather than the
bare minimum to make a set work.  My goal  is for an implementer to provide
whatever subset of the operations is necessary or desirable for a given set
representation, and have fallback implementations that will automatically
be used for other methods.

Re: version 5.3.5 release, ready for testing

Matthias Felleisen — 2013-06-17T13:45:30

Thanks Laurent and oev. I have pushed some repairs. -- Matthias



On Jun 17, 2013, at 6:21 AM, Laurent wrote:


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

Re: version 5.3.5 release, ready for testing

Laurent — 2013-06-17T10:21:27

Here is some feedback. I did not read the book, so please ignore whatever
is meaningless.

Tested on (uname -a):
Linux UX31A 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 13.04

Drracket starts, no problem. Games could run without major problem.

Just some typos and minor comments:

chapter2/source.rkt and chapter5/source.rkt :
"you uessed it".  -> "guessed"

Chapter 5:
guess game:
quit with q does not close the frame (maybe normal?) and has the same
behavior as =.

ufo:
The ufo "crashes" in the bottom of the frame. May be better if it "lands"
properly?
Check-syntax is activated, but does not handle non-pure text files, and
thus displays an error message. Might be confusing for a beginner?

Chapter 6:
source.rkt:
qiuckly -> quickly
"BUG? << --" to be removed?

Chapter 8:
n does not start a new game

Otherwise, looks like a lot of fun! I wish my teachers had used RoR for
teaching us PLT Scheme ;)

If anyone likes to play Dice of Doom, it has an improved ver

Re: version 5.3.5 release, ready for testing

oev — 2013-06-17T02:19:43

Is this a typo?



realm/chapter2/source.rkt
realm/chapter5/source.rkt
realm/chapter13/run.rkt




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

version 5.3.5 release, ready for testing

Matthias Felleisen — 2013-06-17T00:41:13

A candidate release v5.3.5 is ready for testing at 

   http://pre.racket-lang.org/5.3.5/ 

I have downloaded, installed, and played with the bundle on Mac OS X 10.8 w/o a hitch.

Could I ask for volunteers to check the bundle on Windows, older Macs, and *nix boxes? 

Timeline: We'd like to release tomorrow or Tuesday. 

Thanks -- Matthias





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

Re: release 5.3.5

Matthias Felleisen — 2013-06-16T23:35:37

ROAR is something like a second step but we don't assume that you have seen HtDP. 

HtDP is not about the examples but about [the] design [recipe] and as such truly novel. It isn't about Racket either, otherwise we'd use Racket in the book. As for 'interest', let freshmen judge. I'd prefer HtDP over ROAR any day. 

Thanks for your interest. 




On Jun 16, 2013, at 7:28 PM, WarGrey Gyoudmon Ju wrote:


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

Re: release 5.3.5

WarGrey Gyoudmon Ju — 2013-06-16T23:28:48

Sounds good to buy this book and I will do.
Will the book take the place of 'How to design program' in which examples
are quite simple and uninteresting even for the freshmen?

My translate LOL with the intention of exploring the racket way.
Few resources could be the guider.


On Mon, Jun 17, 2013 at 5:42 AM, Matthias Felleisen <matthias-1vnkWVZi4QaVc3sceRu5cw< at >public.gmane.org>wrote:

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

Re: release 5.3.5

Matthias Felleisen — 2013-06-16T21:42:36

Realm of Racket is not a translation of Land of Lisp, though it borrows ideas from the latter for about 1/2 of the book. The ROAR code is far more functional and GUI than LOL. -- Matthias




On Jun 16, 2013, at 2:19 AM, WarGrey Gyoudmon Ju wrote:


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

Re: PLaneT(2): Single vs multi-collection packages

Greg Hendershott — 2013-06-16T20:23:04

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

Re: release 5.3.5

WarGrey Gyoudmon Ju — 2013-06-16T06:19:31

What a pity, I did not know this book before.
I've been translating the source code of Land of Lisp using the racket way.
I just finish the Grand Theft Wumpus game.


On Sat, Jun 15, 2013 at 10:53 PM, Jay McCarthy <jay.mccarthy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

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

Re: updated proposal for moving to packages

Matthew Flatt — 2013-06-15T17:07:23

Not yet, but that's easily within reach before switching (except that
you'll cd into "plt", not "plt/racket").

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

Re: updated proposal for moving to packages

Matthias Felleisen — 2013-06-15T16:33:30

On Jun 15, 2013, at 12:15 PM, Matthew Flatt wrote:



I hadn't seen this file. 

Are you saying

 $ cd ~/plt/racket
 $ ./make 

will build the whole system and the result is the same as what we
currently build with configure/make/make-install? In that case, thank
you and I can't think of a way to simplify.

Re: experience using the `pkg` branch

Matthew Flatt — 2013-06-15T16:26:32

Yes. I have been thinking about whether there's a better solution than
just not showing the paths, but I can just drop the path list for now.


Will fix. I think this is just a matter of use $(MAKE) from the
top-level Makefile.


I think you're referring to the `server' Makefile target, which is
intended for a build process where the libraries will be needed by
clients.

In any case, the process for dealing with native libraries will likely
change/improve when we have those packages available from a catalog
server.


Definitely. You have to rebuild the local catalog after moving things
around.


True. As with the preceding two bullets, this can improve as we figure
out how we want to work.

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

Re: updated proposal for moving to packages

Matthew Flatt — 2013-06-15T16:15:52

Yes, we should wait until after v5.3.5. I imagined that v5.3.5 would
happen on Monday, but if it takes longer, then the switch will have to
wait.



Can you say more about what is needed in addition to

  https://github.com/mflatt/racket/blob/pkg/INSTALL.txt

?

We can continue to simplify the process and refine those instructions,
of course.


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