Re: [racket-dev] new package system collections and conflicts
Your frustration is understandable given the lack of charity I've shown in this thread. I apologize and promise to try to be better. I know I'm repeating myself annoyingly, but I think the most productive way to move forward is if you could identify problems that you're trying to solve where the package system is getting in the way. We can then work together to figure out a solution. I suspect that the majority of the problems you see now are due to my failure to explain the purpose of the package system and its relation to Planet. I hope to write a blog post in the very near future that explains the relationship between Planet and the package system. I intend to sketch how the latter can emulate the former in a near-perfect manner. My hope is that this post will help explain the package system and show that it does not prevent you from doing anything that Planet let you do, it only allows you to do more. I'm very sorry for my annoyed responses earlier. I'm grateful for your contributions to the Racket ecosystem. Love always, Jay On Tue, Dec 2, 2014 at 7:12 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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. -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
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
I think there is perhaps a misunderstanding. The design of the pkg system is (partly) driven by the observations the core team has about what gives us special privilege and then working to lift those restrictions so we don't need to operate under that special privilege. And I'll note that this theme is one that has long been part of the design of Racket, going back at least as far as Matthew's MrEd as OS (aka 'the revenge of the son of the Lisp machine' paper). So: it isn't about you at all, really. I don't think anyone claims to know what you want or need. It's about putting ourselves on the same footing (in terms of access) as everyone else. We see this an important step in making more effective use of the community and driving Racket forward in a more distributed, global way. As far as charity goes, I generally think the world needs more of it, even if you don't, so I'm glad to see a little of balance being restored to this particular thread. Robby On Wed, Dec 3, 2014 at 10:32 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Thanks for being with with us for so long. I think you misunderstood the word 'charity' here and perhaps Jay could have used a different, a more appropriate word than 'charity', which I now realize can have a negative connotation. Otherwise, I think that the package system design is about reducing power for core developers so that we put ourselves into the position of contributors. Our hope is that this step will eventually improve the overall social/eco system surrounding Racket. Please stay with us, and please do give constructive feedback. The most constructive feedback is of the form I would like to solve the problem ... describe problem ... We have been thinking for a long, long time about breaking up the core so that more people can become core and we realize that this is a nontrivial step. We need your helps and everyone's help. Thanks! -- Matthias On Dec 3, 2014, at 11:32 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Line editing in the default REPL
My goal was not to replace xrepl, but to provide basic line editing support to the default repl without licensing violations or massively increasing the distribution size. 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've already done this (admittedly it only works on OS X, but most Linux terminals work exactly the same with a few different constants). You can see what I have so far here: https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt Then you need to deal with the trickyness of a proper editor, with features like blinking a matching paren... While these features are cool, they are things that can be added on later (by extending the line editor I linked to above). ~Leif Andersen On Wed, Dec 3, 2014 at 2:55 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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
Re: [racket-dev] Line editing in the default REPL
On Wed, Dec 3, 2014 at 2:45 PM, Leif Andersen l...@leifandersen.net wrote: My goal was not to replace xrepl, but to provide basic line editing support to the default repl without licensing violations or massively increasing the distribution size. Yes, that's exactly what I was talking about. I hope that you know what you're doing, though so far the easy to underestimate seem to be the case: 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've already done this (admittedly it only works on OS X, but most Linux terminals work exactly the same with a few different constants). You can see what I have so far here: https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt If this works, I'd be thoroughly impressed -- so I tried it. I ran through a bunch of configurations that I use: - plain xterm, - ssh in xterm, - linux text console, - ssh in a linux console, - `term' in Emacs (a terminal emulator, not the more popular inferior shell), - ssh from windows on a mintty, - ssh from windows in a cmd box (Win7, much better than past versions) and in a powershell window, - putty from windows. (The racket process is always running in a linux machine, there's no need for it on Windows.) In each of these I first tried readline (a basic test: start racket, move around, go back in history to a multiline entry) -- it worked fine in all cases. I then tried your code -- took your file as-is, and added (module+ main (line-editor rkt )) in the end. It failed in all cases. The failures varied, but in pretty much all cases it just spits out an escape sequence (which is not the right one for the terminal, otherwise it wouldn't be shown), a different one in each case. I then tried some navigation keys, and none of them worked either. In some cases they'd move the cursor where it shouldn't go (the cmd-based cases, as expected), in other cases keys behaved in various broken ways: spitting uncaught escapes, moveing two lines up for each keypress, the end key moved down a line in one case, the return key spits out a ^M. Using C-j twice (in some cases; I'm too tired to try them all) seem to give your code what it wants to start reading so it displays the prompt when I do that -- then, the navigation keys are still broken, unsurprisingly (and random escape sequences still garble what I see). Another weirdness is that it looks like your code waits for a ^M, sometime later followed by a ^J, and then it returns a string: this is very broken since a ^J is ignored before the ^M, and there can be any number of characters between the ^M and the ^J. (But that might be bogus, since things are very garbled anyway, so it's hard to guess what's going on.) But it's actually looking at the code that makes me conclude that you're underestimating how complicated getting this right can be. Some various comments in no particular order: * Looks like there is no querying of the terminal for capabilities, and there's no form of database of terminals. See the man pages for *termcap and *terminfo for libraries that implement these things, and you can also check the Emacs source code which still has a lot of code that deals with that in the term directory. * These are needed to know what you can spit out, and what you can expect to read in. Assuming that the rest of the terminal world behaves like the random one you're using is a good recipe for getting something completely broken. * Looking at the code in `edit', the little that it does have is very very broken. (If this is a translation of linenoise, then feel free to forward it to whoever does that...) - You should generally prefer `write-bytes' and `read-byte' to avoid getting bogus character encoding in the way. (But see above: you need to consult the terminal to know if it can give you 8-bit or even wide characters.) - There is no form of abstraction here, resulting in a monolithic piece of code that is going to be a maintenance disaster. You should separate out the code that reads a key to a different function, and make it return some proper symbolic name (combined with characters for simple keys with an ascii equivalent). This way you can also hook more functionality on more keys. - Some of these escape sequences look like they could work, but there are a ton of variations. For example: I have seen the up key generate at least \e[A, \eOA, and \e1;1A. - The last form is interesting, since it's a new-ish way to represent keys with modifiers, so you get \e1;NA with N being 1 to 8 indicating no-modifiers, shift, alt/meta, shift-meta, control, etc. The are similar generic escapes for most keys, and that's one case that is easy to parse. As a different example, my xterm generates \e[27;6;85~ for shift-control-U:
Re: [racket-dev] Line editing in the default REPL
On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay e...@barzilay.org wrote: 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've already done this (admittedly it only works on OS X, but most Linux terminals work exactly the same with a few different constants). You can see what I have so far here: https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt If this works, I'd be thoroughly impressed -- so I tried it. I ran through a bunch of configurations that I use: None of which was OS X, which was what Leif's email explicitly said it _only works on_. I think we should wait till he has a version which he says works before telling people to avoid making contributions. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Line editing in the default REPL
On Wed, Dec 3, 2014 at 6:22 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay e...@barzilay.org wrote: 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've already done this (admittedly it only works on OS X, but most Linux terminals work exactly the same with a few different constants). You can see what I have so far here: https://github.com/LeifAndersen/racket-line-editor/blob/master/main.rkt If this works, I'd be thoroughly impressed -- so I tried it. I ran through a bunch of configurations that I use: None of which was OS X, which was what Leif's email explicitly said it _only works on_. My point wasn't it doesn't work outside of OSX, I was talking about a few different constants being a bad underestimation: they're not few, they're not constant, and the interfaces for getting them is what you'd expect from something that started to grow in the 70s. I think we should wait till he has a version which he says works before telling people to avoid making contributions. You should re-read my email: if there's anything that I'm telling, it's the exact opposite. A point that I repeated more than once. The thing is that it would be easy to not say anything, and watch this approach of try a few escapes and see what works fail. And it will fail, because, again, they're not constant, and you can't just get some magic combination that works for 90% of the people -- even just xterm on just linux is something that can (and often is) configured in many different ways. So what I'm doing is the opposite: I point at how such a thing should be written for it to survive -- but I appreciate Leif's time enough to warn him that this is a much bigger thing than what he seems to think. (And to be clear, the reason for this is that I've seen probably around 3 to 5 serious attempts that got dumped; and I have encountered these issues multiple times, so I know that it's hard enough that even getting simple code to work, code that I intended only for my own use, even that was pretty hard, enough to go chase old VT references and obscure man pages.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
